[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 ..
Doran
- [Gnu-arch-users] Ongoing Comparison Between Version Control Systems, (continued)
- [Gnu-arch-users] Ongoing Comparison Between Version Control Systems, Mark A. Flacy, 2003/09/07
- Re: [Gnu-arch-users] Ongoing Comparison Between Version Control Systems, Jonas Diemer, 2003/09/08
- Re: [Gnu-arch-users] Ongoing Comparison Between Version Control Systems, Peter Conrad, 2003/09/08
- Re: [Gnu-arch-users] Ongoing Comparison Between Version Control Systems, Momchil Velikov, 2003/09/08
- Re: [Gnu-arch-users] Ongoing Comparison Between Version Control Systems, Robert Anderson, 2003/09/08
- Re: [Gnu-arch-users] Ongoing Comparison Between Version Control Systems,
Aspect <=
- Re: [Gnu-arch-users] Ongoing Comparison Between Version Control Systems, Tom Lord, 2003/09/08
- Re: [Gnu-arch-users] Ongoing Comparison Between Version Control Systems, Robert Anderson, 2003/09/08
- Re: [Gnu-arch-users] Ongoing Comparison Between Version Control Systems, Ollivier Robert, 2003/09/08
Re: [Gnu-arch-users] Ongoing Comparison Between Version Control Systems, Jonas Diemer, 2003/09/08