From: Theodore Tso <tytso@mit.edu>
Date: Thu, 05 Feb 2009 21:45:36 GMT
Subject: Re: Comments on "Understanding Version Control" by Eric S. Raymond
Message-ID: <20090205214536.GB9814@mit.edu>
In-Reply-To: <200902051836.44973.jnareb@gmail.com>

On Thu, Feb 05, 2009 at 06:36:42PM +0100, Jakub Narebski wrote:
> What I wonder is how directory-id solution deals with situation
> where (for example die to some reorganization) where once was single
> directory (e.g. lib/) now there are two (include/ and src/); how it
> would deal with the new file at old directory, hmmm...?

In that case, it wouldn't be a directory rename, it would be a series
of file moves.  So in a hypothetical scm that recorded all of these
sorts of things, you'd have something like this:

scm mv lib/*.c src
scm mv lib/*.h include
scm rmdir lib

Now if you try merging in a commit that creates a files in lib (e.g.,
creates lib/foo.c and lib/foo.h and modifies lib/Makefile), presumably
either a super smart hueristic algorith might be able to figure out
the pattern and drop the new files in src and include --- or, more
likely, it would flag a merge conflict and ask the user to figure it
out by hand.

So yes, there will always be cases where directory-id won't be able to
handle a hypothetical source tree reorganization.  It really only
helps in the case where you are doing a true, full move of the
directory, i.e.:

scm mvdir src/plugin/innodb src/plugin/innodb-legacy
scm mvdir src/plugin/innodb-experimental src/plugin/innodb

							- Ted