Bizare Bazaar

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


...

>> Often people will have a local branch of "master" that they merge from.
>> They may not have updated it after you updated the real master before
>> they merge it.
>>
>> There are other ways to get criss-cross, such as by having 2 integration
>> branches. If they both merge feature branches, then after 2 feature
>> branches are merged, there is no longer a simple base to pick from for
>> future merges.
>>
>> A screenshot could be helpful.
> 
> Thanks for your reply. Please see the attached - master on the left,
> user Michael on the right. To me it looks like when Michael merged he
> got the master branch at revision 1583 when I would have expected him to
> get revision 1585. I then get a criss-cross merge at revision 1586 as
> there are two paths back to 1583.
> 
> I'm pretty sure none of our devs have their own copy of the master
> branch - it's on a local server so we just merge down from that.
> 
> Thanks,
> Matt

Right so the graph as seen certainly is a criss-cross. I don't have any
reason to understand why 847.1.491 would have merged 1583 rather than
1585 other than a copy-of-master that was not up to date.

There is nothing in the timestamps, etc that looks suspicious. Since you
say that everything is "on a local server", I'm also guessing that there
wouldn't be anything special about time zones.

Certainly, if you were just doing "bzr merge bzr+ssh://.../trunk" we'll
always pick the most recent revision. You'd have to explicitly use "-r"
to get an older one.

Which is why my best guess is an out-of-date mirror. Like if someone
locally has a checkout of master, and doesn't do "bzr up" before they do
"bzr merge ../trunk".

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4cSvwACgkQJdeBCYSNAAMRLgCfdYzrG8w+0aAv16t/k/Ti4aTc
c2UAn2UscduAzmoGgZzHbGIGE83nFoXe
=0yfO
-----END PGP SIGNATURE-----