Re: Comments on "Understanding Version Control" by Eric S. Raymond

[Junio C Hamano <gitster@pobox.com>]

Theodore Tso <tytso@mit.edu> writes:

> Careful; that's actually an argument for recording the directory
> rename.

I do not think so.  More precisely, I can see people could make that
argument, but I think that argument is weak.

Suppose the original project's implementor only knew about innodb
interface, so he had the "database interface" directory and innodb access
method file in the source tree, perhaps at <db/inno.c>.

I forked the project, and added gdbm support at <db/gdbm.c>.

You also forked the project without knowing what I was working on, and you
started working on refining the innodb support.

All the while, the development community started discussing how the source
tree should be organized to support multiple backends, and you learned
that the plan is to have one directory per larger backend, while keeping
single file ones in <db/*.c>.  Specifically, you learned that innodb
related code will be stored in <innodb/*.c>, and there may be other
<somedb/*.c> and <someotherdb/*.c> groups added, but you are not
interested in anything but enhancing innodb support.

You rename "scm mv db innodb" and then add <innodb/enhanced.c>, or perhaps
you may have done it the other way, i.e. added <db/enhanced.c> and then
renamed "scm mv db innodb".

Suppose you would want to merge my changes, but the upstream's plan hasn't
happened yet.  Neither of us merged from the upstream in the meantime.

Recording your "scm mv db innodb" as "the user's intention to rename
directory" does not help when you want to merge with me to handle the new
file <db/gdbm.c> I added.  You not only need to record the "intent to
rename db to innodb", but need to know that the validity of that "intent
to rename" is contingent on the absense of anything unrelated to innodb in
db/ directory, in order to merge the two branches correctly.  Otherwise
you will end up moving my <db/gdbm.c> to <innodb/gdbm.c>.  The correct
outcome in this case would probably be to leave it as it is.

> In other cases, maybe the right thing *is* to drop the new file in the
> original directory.  So as the Hg and Bzr apologists might say, if the
> SCM actually records whether the user intention was a *directory*
> rename, versus a series of *file* rename/moves, then it becomes
> obvious what the right thing to do.

See how that argument is flawed?  The point of my example is that the line
between your example (1) and (2) in the previous message is blurry.