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

[Aspect]

On Mon, Sep 08, 2003 at 04:08:41PM +0300, 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.
> 
> Peter> It *can* make sense, so don't try to define the problem away.
> 
>   I think you just love your hammer :)

no, peter has a point here -- the case where you are splitting up a document
is valid. It is common when refactoring to pull a chunk of code out of one
file and into another, which produces two partial descendents of the original
file. I can't see any other practical way to represent this than the copy
operation (or more precisely, copy+patches).

Arguably the "split" is the more interesting operation here -- but it seems to
me that with the inclusion of the "Copied-Files:" ChangeLog syntax (as already
suggested by someone in this thread), tracing file history in this manner
would be trivial. Unless there is another way, and I just haven't thought of
it ..


Doran