Thoughts on file ids

[Francis Devereux]

On 18 May 2011, at 13:13, Martin Pool wrote:

> 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.

Thanks Martin. I did in fact run some renaming then merging tests a year or so ago and found that bzr behaved as I'd expect/want but git and hg didn't. I should dig out the tests and run them again to see how the most recent versions of git and hg do, and then blog about them (I had intended to do that when I originally ran them but life got in the way ;-)

Francis