Tracking files and file-level operations

[Chris Hecker]

You may want to read this:

http://wiki.bazaar.canonical.com/BzrFileCopies

I think it's pretty silly that bzr doesn't support copies, but I do 
agree with their rationale that renames are more important (at least in 
my experience), so I think it's slightly sillier that Hg doesn't support 
renames (it's one of the reasons I chose bzr over hg, I rename stuff all 
the time, but split more rarely, and hosing svn repeatedly with complex 
renames that are a walk in the park for bzr is what made me finally 
switch to a dvcs at all).

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

Hopefully bzr will add copies at some point, but it doesn't look like 
it's a high priority.

Chris


On 2010/07/19 22:28, Ben Finney wrote:
> 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?
>