Tracking files and file-level operations (was: How does Hg do file renames?)

[Ben Finney]

Howdy all,

It's a pity that the Mercurial folks don't want cross-posted
discussions, because here's yet another interesting one that would
benefit from both groups join in on a single discussion.

Pierre Asselin <pa at panix.com> writes:

> Haszlakiewicz, Eric <EHASZLA at transunion.com> wrote:
> > IMO, it would be nice if hg (and other vcs's) had a concept of a
> > file as a persistent entity, regardless of what path it happens to
> > be present in at any particular time.
>
> That's a double-edged sword. Google "evil twin" + "SCM" for some
> insight. Basically you can resurrect a deleted file incorrectly and
> get instead a new file with the same name and the same content as some
> past version, but completely unrelated to the original as far as the
> rev control system is concerned. Seems to be a common source of
> confusion in ClearCase but it is possible also e.g. in subversion.

Is Bazaar susceptible to this “evil twin” problem?

> The other thing is that tracking file identity across renames is not
> enough. You also need to follow copies where the original is not
> deleted. A legitimate use case is splitting a file. Mercurial handles
> this case just fine: the two copies are independent, but merging a
> change that predates the split causes the change to be propagated to
> both copies (with a probable conflict in one of them.)

Bazaar does not, TTBOMK, track file copies, and so when merging changes
in a single file from another branch, the changes will not be applied to
multiple files in this branch. Should there be support in Bazaar for
tracking file copies?

I can see the benefit of the use case described, but what traps are
there with that approach?

-- 
 \         “Alternative explanations are always welcome in science, if |
  `\   they are better and explain more. Alternative explanations that |
_o__) explain nothing are not welcome.” —Victor J. Stenger, 2001-11-05 |
Ben Finney