Re: [Gnu-arch-users] Ongoing Comparison Between Version Control Systems

[Robert Anderson]

On Mon, 2003-09-08 at 06:08, Momchil Velikov wrote:
> >>>>> "Peter" == Peter Conrad <address@hidden> writes:
> 
> Peter> Hi,
> Peter> On Mon, Sep 08, 2003 at 10:24:45AM +0200, Jonas Diemer wrote:
> >> On Mon, 8 Sep 2003 07:58:24 +0300 (IDT)
> >> Shlomi Fish <address@hidden> wrote:
> >> 
> >> > For merging and for tracking changes to previous versions of the file?
> >> > It's also less resource-hungry, time-consuming and space-consuming.
> >> I believe you are thinking to subversionish now... I would suggest you
> >> choose your categories a bit differently, comparing revision control
> >> tasks rather than technical stuff... In a software developers mind
> >> (using a scm) copying files at the repository level doesn't make any
> >> sense,
> 
> Peter> I believe that is wrong. It has been suggested that in order to split 
> up
> Peter> a project tree into multiple subprojects the project be "copied" by
> Peter> creating multiple branches and pruning those to contain only the 
> desired
> Peter> part of the tree.
> 
> Peter> The same can make sense at a file level: think of splitting up a large
> Peter> piece of documentation into multiple per-chapter files. Or re-factoring
> Peter> a large source file into smaller modules.
> 
>   But this is MOVING and not COPYING, because you don't end up with
> two identical files/directories in the same revision.

No, I think the point he makes is valid, if a touch myopic.

The point is that the segregated files' history could be traced back
through the point of the split.  That seems marginally useful.

BUT, if you consider the implications for merging, I think it turns out
not to be worth it.  Think about what happens in the merging of parallel
branches in which files can be copied like this.  It's ugly, and more
importantly, confusing.

And no one from the svn camp has been able to even say what _should_
happen in those cases, much less what _does_ happen, as far as I've
seen.

Bob