Tracking files and file-level operations

[Stephen J. Turnbull]

Chris Hecker writes:

 > It's slightly unbelievable that none of git/bzr/hg/svn support both as 
 > first class operations.

Well, for git it's a religious issue (git tracks content, containers
are "not my job, man").

Ben wrote:

 > > Is Bazaar susceptible to this "evil twin" problem?

At least as the "evil twin" problem is defined here:

http://www.accurev.com/blog/tag/evil-twins/

yes, it is.  But I don't see any "problem".  It's just an add/add
conflict, or add/mv, or similar.  Ie, the SCM only doing its job, and
git or hg would do the same.

It's a communication problem among humans, who are doing redundant
work (in the "true twin" case).  You would expect it to occur fairly
frequently in an open source project with multiple maintainers working
with an email-based workflow (new plug-in is contributed, two of them
try to add it concurrently, one loses), but it's not clear to me why
it should occur very often in a managed project.  (Name conflicts seem
fairly likely, though, if you have a team of people working on the
"foo" feature, surely you're going to get several of them naming
things like "foo-utils.py".  But those aren't really "twins".)

I do see a bunch of complaints about ClearCase working with evil
twins, which seem to have to do with a complex, hard to discover and
remember GUI.

I'm not clear on this issue of deleting and resurrecting files (which
is quite different from "evil twins").  I don't see why it would be a
particular problem for Bazaar, and it seems to me that you'd be more
likely to get the "wrong" stuff if you use git in a straightforward
way (eg, the pickaxe might help identify the file/version you want,
but that's tedious).  Of course the *user* might be confused by a
rename, and insist on the file with the right name instead of the
right content or something like that, but that seems inherent in the
rename operation, and not a problem with container tracking.