Tracking filesystem entries as first-class VCS citizens (was: Bazaar still below the radar when evaluating VCS tools)

[Stephen J. Turnbull]

Ben Finney writes:

 > AFAICT, that means Git and Mercurial (by the above description) don't
 > track some important information about files that Bazaar does.

I apologize for omitting the other information; that's a good point.

 > In other words, I don't agree with Git or Mercurial that "a file is
 > a way to associate a name with content", since there are other
 > things a file is for.

I should backtrack here; I don't know what Mercurial devs think about
these things.  Linus, on the other hand, has been quite explicit about
the design principles of git.

 > What am I missing?

Nothing.  I wasn't explicit enough; I meant precisely that if you
don't agree that a VCS's mission is limited to managing content, but
rather should include more of the state of the system, you won't think
that git/hg do a good enough job of tracking renames.

Now, I happen to agree with git, partly philosophically, partly
pragmatically, but I don't see any reason why you need to.

Philosophically, I do see a VCS as primarily an SCM = source content
manager, an aid to editing working copies.  I don't see it as an SCM =
system configuration manager, taking snapshots of the state of the
whole system (although it can be used that way).

Pragmatically, git doesn't claim to do more than track content, and if
you want to do more than that, it can be built on top of git -- that's
explicitly the git design.  I think that's wise at this stage of the
game: I don't think we know enough about version control to do much
better than make a very fast content manager, and wait for best
practices to emerge on top of that core.  The Bazaar devs clearly
think otherwise, and they're making a good show of it ... but so is
git.

Does that make more sense now?