Re: Trying to sync two svn repositories with git-svn (repost)

From: Josef Wolf <jw@raven.inka.de>
Date: Apr 28, 2009, 22:37 UTC
Message-ID: <20090428223728.GE15420@raven.wolf.lan>
In-Reply-To: <32541b130904281353k572fed5la468de65f73ccd19@mail.gmail.com>

Thanks for your answer, Avery!

On Tue, Apr 28, 2009 at 04:53:52PM -0400, Avery Pennarun wrote:

Show 9 quoted lines

> On Mon, Apr 27, 2009 at 4:12 PM, Josef Wolf <jw@raven.inka.de> wrote:
> > I have two subversion repositories which I would like to synchronize via
> > git-svn.  [...]
> 
> What you're attempting is rather complicated.  I guess I'd suggest we
> back up a step: why do you want to do this?  In what way does a "pure
> svn" tool like svnsync
> (http://svnbook.red-bean.com/en/1.5/svn.ref.svnsync.html) not do what
> you want?

The explanation to that git somewhat longish, sorry for that.

The project is about configuring networks. If you think about cfengine, you get pretty close to what it is about. It started out as a single repository. But since configuring networks requires lots of "localization", it was soon split into two parts: One part are the "mechanics": generic libraries/scripts. The other part is the "policy": the configuration that specifies how the mechanics should do their task. The reason for the split was to allow multiple policies (for independent administrations) to share one common set of mechanics (as svn:externals). For security reasons, the mechanics were imported back into the (multiple) policies later on.

Currently, there exist multiple independent repositories (for security reasons). In the past, the repositories were "synchronized" manually. So technically, the repositories have no common history (at least not in svn's metadata). But the contents are actually rather "similar", since they were synchronized multiple times in the past.

In the long term, I'd like to move everything completely to git. That would make it much easier to move changes from one repos to the other while keeping the (intended) differences in the policy.

So my first goal is to bring the contents into sync. The next step would be to create a "reference" (the official) git repository, which can be cloned by the administrations to create their localized repositories.

In the meantime, I need a way to synchronize the contents from time to time. I guess it will take some time to create the official repos and get used to the work flow.

> Are you making changes to *both* svn repositories

Yes.

> and then want to synchronize their histories?

Since synchronization was done manually in the past, I do not (yet) care about the history very much. My first goal was to get the contents into a sane state: I've done lots of criss-cross cherry-picking. Now that the contents are in sync (within git branches), I'd like to do two things:

 - Set "markers" to indicate which commits are already synchronized, so
   the next synchronization will be easier.  I thought "git-merge -s ours"
   would be the correct way to do that.  But as I already wrote: this
   causes the next "git-svn rebase" to apply all the commits of the other
   branch (which I already cherry-picked)

 - Feed the cherry-picked commits back to the svn repositories.  I've not
   tried that yet, since I think I should "git-svn rebase" first.

> This is basically impossible, since svn only has a linear history.
> If you add commit A to one repo, and
> commit B to the other, you will never make the histories identical in
> both repos;

Yeah, I see. But I don't really care about that, as long as the relative order of the commits is kept when they are moved to the other repos. Since the svn repositories will die once the migration is done, this is not a big deal.

> one will necessarily have A and then B, and the other will
> have B and then A.  That's not really desirable, since one of those
> two histories is a lie.

The current situation is an even bigger lie.

> So, what is it you're *really* trying to do?

I hope my explanation was not too boring...

> Have fun,

Yeah, I am having _lots_ of fun =8)