flock swtiched to SVN

[Matt Mackall]

On Fri, Dec 08, 2006 at 03:09:00PM +0100, Andy Smith wrote:
> >I just learned that Flock has dropped Mercurial for SVN. Out of
> >curiousity perhaps, is anyone aware of the reasons they did so?
> 
> Wow, this reply is very late (I don't even work for Flock anymore) but
> the thread came to my attention recently.
> 
> I mention it in a blog post (http://term.ie/devdev/node/79) but
> basically the reason Flock gave up on it was because we were losing
> days at a time when people would somehow revert huge sections of the
> database at a time.
[snip]
> The file these numbers are referring to:
> * http://term.ie/data/bigbadmerge.png
> * http://term.ie/data/1823.diff
> * http://term.ie/data/diff-1807-1817.diff
> * http://term.ie/data/diff-1817-1819.diff
> 
> The Big Bad Merge
> * The merge I committed as changeset 1823 broke everything. By
> tracing through the tree in hg view, it looks like what happened was:
> 1. Anthony pushes 1807 (this is pretty much the changeset that most
> things eventually get reverted to)
> 2. Ian updates from 1807, this branch more or less sticks around for
> a while, diverging from Anthony's
> 3. I update from Ian's branch and make a bunch of commits all day.
> 4. Anthony updates again at 1818, furthering his branch along from
> 1807, then merges with Ian-Termie's branch at 1819. At this point the
> common parent for Anthony's merge is 1807, so when merging many files
> get set to their 1807 version. The changeset doesn't show this,
> theoretically because the files didn't change on Anthony's system,
> but hg view does.
> 5. Meanwhile, I commit 1822 thus creating a branch with sharing
> parent 1817 with Anthony's 1818 branch.
> 6. I update again and have to merge, the common parent between the
> two branches is 1807, and from the point of view of my tree, all of a
> sudden there were a bunch of updates to the files (the ones that had
> been set to their 1807 versions after we had changed them) so my
> merge diligently 'updated' to that version.

>From reviewing the surviving data and chatting with Andy on IRC, the
most likely hypothesis I can come up with is that one user had a
misconfigured external merge tool and this was repeatedly reverting
changes. This could happen, for instance, if Mercurial and the
external tool disagreed on the order of the three arguments local,
remote, and ancestor. Since Windows installs don't have our nice merge
helper script, it's the likely culprit here.

Unfortunately archaeology is much harder than forensics, so I can't
rule out a merge bug. But the merge scenario you've presented is not
all unusual, and a bug here would result in problems for the Mercurial
developers on a regular basis.

We'll try to come up with a scheme to test that merge and patch work
as expected.

-- 
Mathematics is the supreme nostalgia of our time.