[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Aspect
Subject: Re: [Gnu-arch-users] Ongoing Comparison Between Version Control Systems
Date: Tue, 9 Sep 2003 01:53:57 +1000
User-agent: Mutt/1.2.5i

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 ..


reply via email to

[Prev in Thread] Current Thread [Next in Thread]