Bug#408611: svn-arch-mirror: fails to sync a doubly checked out source tree

[Lionel Elie Mamane <lionel@mamane.lu>]

severity 408611 wishlist
thanks

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
essentially manually:

 * I have a coq--mainline branch in tla that mirrors the svn trunk,
   with svn-arch-mirror

 * I have a coq--mamane-interface where I do my work

 1) star-merge coq--mainline into coq--mamane-interface, deal with
    conflicts there.

    While svn commiters are faster than me and make new commits,
    loop.

 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
    does nothing!)

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


Best Regards,

-- 
Lionel Elie Mamane