Bug#408611: svn-arch-mirror: fails to sync a doubly checked out source tree
severity 408611 wishlist
On Sat, Jan 27, 2007 at 12:16:57PM +0100, Jean-Marc Notin wrote:
> 'svn-arch-mirror sync' fails in a double-initialized svn/tla tree when
> changes have been commited in the tla tree:
Thank you for your bug report.
To my regret, svn-arch-mirror is just that: A utility to mirror a svn
repository and/or branch into a tla category / branch. Not to
synchronise changes that happened in both, but to mirror changes that
happened in svn into GNU Arch. One-way mirroring. I'd like it to be a
two-way synchronisation tool, but I haven't been able to develop a
design (never mind implement it in Perl...) to achieve this
cleanly. Do you have precise ideas? (see end of this email)
Depending on your needs, you may be better served by tla-svn-sync from
the tla-tools packet. Let me know.
The way I manage merges from changes on both sides for my Coq work is
* I have a coq--mainline branch in tla that mirrors the svn trunk,
* I have a coq--mamane-interface where I do my work
1) star-merge coq--mainline into coq--mamane-interface, deal with
While svn commiters are faster than me and make new commits,
2) stop svn-arch-mirror from being automatically run
3) star-merge coq--mamane-interface into coq--mainline.
4) "svn add-id", "svn mv", ... as necessary
5) svn commit
6) svn up
(this is _very_ important and necessary, although you may think it
7) tla commit
8) re-enable the svn-arch-mirror automatic running
This is a bit cumbersome and I'd like it to be a bit automated,
actually. Steps 2 to 8 should be automatable, actually.
Design problems if you want to make it a two-way synchronisation:
1) What do you do when there were multiple commits on both sides?
Does it make any sense to replay the changesets in these commits
one by one on the other side? This may give revisions that do not
compile. What do you do in face of conflicts? Bail out and tell
the user to figure it out?
Another way would be to pack changes in the tla->svn direction in
one svn commit. Makes things a bit easier.
Anyway you do it, it breaks the "mirror" idea, because at least
the order (if not the granularity) of the commits is not the same
on both sides. There is not anymore a (meaningful) bijection
between the revision number on both sides. Meaningful meaning that
if the bijection is o, then \forall FOO:revision number, "tla get
FOO" and "svn co o(FOO)" get you the same tree.
2) So maybe the best would be a model where people are forbidden to
commit to the tla side of the mirror, but are supposed to work on
a fork of it in another branch, and we have a tla-to-svn
"star-merge" that does steps 2 to 8 of my procedure automatically?
We can also have a tla-to-svn replay (or call it "copy changes"
like tla-copy-changes of tla-tools) for per-changeset replaying of
changes with a commit in-between everytime.
Do you know enough perl that we could hack this together in
svn-arch-mirror? I don't know perl well.
(You want to discuss this by phone and/or IRC? I'm available.)
Lionel Elie Mamane