Thoughts on file ids

[Martin Pool]

On 18 May 2011 10:33, Francis Devereux <francis at devrx.org> wrote:
> On 17 May 2011, at 01:53, Robert Collins wrote:
>>
>> In particular I think you will want tests for the various pathologies
>> on merge that both git and hg suffer from (and we don't) - it would be
>> a darn shame to generalise bzr to work more efficiently with those
>> systems by downgrading its behaviour to match them.
>
> As a user I would be very interested to hear what those merge pathologies are, if someone has time to explain them. At work we are selecting the VCS for a new project and are probably going to choose hg or git but we still have time to change our minds and I'd much rather find out why bzr is better than the others before instead of after we've made our decision! (so far my attitude has been "as long as it's a DVCS it'll be way better than what we have now (svn)")

The kind of thing Robert is referring to here is cases like renaming a
subdirectory, and then later merging in a branch that originated
before that and changes or adds some files in that directory.  Or
similarly, running log on one of the files in the directory or the
directory itself, or renaming a file and also changing it.  Because
bzr handles directories as first-class objects, and gives them a
long-term id, it has in the past shown to handle these much better
than the alternatives.

Martin