git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 5, 2009, 06:24 UTC
Message-ID
<7vmyd1ieo6.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<20090205024333.GH8945@mit.edu>
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.

Show 5 quoted lines
> 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.

Previous: Theodore TsoNext: Theodore Tso
Message 9 of 21 in “Comments on "Understanding Version Control" by Eric S. Raymond”
  1. Jakub NarebskiFeb 2, 2009
  2. Theodore TsoFeb 2, 2009
  3. Eric S. RaymondFeb 2, 2009
  4. Jakub NarebskiFeb 3, 2009
  5. Jakub NarebskiFeb 4, 2009
  6. Theodore TsoFeb 4, 2009
  7. Junio C HamanoFeb 5, 2009
  8. Theodore TsoFeb 5, 2009
  9. Junio C HamanoFeb 5, 2009
  10. Theodore TsoFeb 5, 2009
  11. Junio C HamanoFeb 5, 2009
  12. Jakub NarebskiFeb 5, 2009
  13. Theodore TsoFeb 5, 2009
  14. Miles BaderFeb 5, 2009
  15. Eric S. RaymondFeb 5, 2009
  16. Jakub NarebskiFeb 5, 2009
  17. Theodore TsoFeb 5, 2009
  18. Jakub NarebskiFeb 5, 2009
  19. Theodore TsoFeb 5, 2009
  20. Tests for "Understanding Version Control" by Eric S. RaymondJakub Narebski, Feb 4, 2009
  21. Jakub NarebskiFeb 10, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.