flock swtiched to SVN

[Andy Smith]

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

In an email I wrote to flock-dev at the time I'll paste the relevant
parts into this message
(http://lists.flock.com/pipermail/flock-dev/2006-January/000119.html)

--- SNIP ---
Friday the 13th, how fitting for what I woke up to this morning.

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.

Thus, if you compare the diff between 1807 and 1817
(diff-1807-1817.diff), the changes made up until the branch before
the bad merge, you get nearly the opposite of the 1823 changeset
(1823.diff), which is nearly the same as the diff between 1817 and
1819 (diff-1817-1819.diff), the merge with the 1807 parent. That is
to say, 1823 =~ 1817-1819, so the merge at 1819 reverted most changes
made since 1807, and my merge at 1823 noticed and made them part of
the changeset.

--- SNIP ---

Now, this was all the way back in January, and occurrences like this
were happening fairly frequently. I am not totally sure that what I
described is exactly what is happening but it was the best solution I
could figure out, the #mercurial channel didn't seem to know what I
was talking about at the time. We would also get into deadlocks from
time to time (related we think to either the windows users or
permissions) that would cause somebody's local copy to no longer be
pushable to the central repo until they re-cloned.

So, I would like to know what was *actually* happening and I would
like to know how to prevent it so that I can use and recommend
mercurial with other multi-person projects.

--andy