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

On Thu, Apr 30, 2009 at 06:59:50PM -0400, Avery Pennarun wrote:

On Thu, Apr 30, 2009 at 6:28 PM, Josef Wolf [off-list ref] wrote:

quoted

 # cherry-pick from second-svn to first-svn
 #
 git svn checkout first-svn
 git cherry-pick sha1-from-second-svn # repeat as needed
 git checkout first-svn/trunk
 git merge --no-ff first-svn
 git diff first-svn/trunk first-svn >changes.diff
 git svn dcommit

[...]

quoted

But I am still somewhat confused:

 git log -1 first-svn/trunk

says "Merge branch first-svn into HEAD".  But this does not reflect
what I've actually done: I've picked _from_ second-svn and committed
that _to_ first-svn.

The most recent commit to first-svn/trunk was "git merge --no-ff
first-svn", which creates the merge commit you're seeing here.  (HEAD
== first-svn/trunk).  So this sounds right to me.

"git log -1 first-svn" would give you the first cherry-pick.  But
remember, it's a completely different branch.

I can see why this happens, but I still find it confusing.  Maybe I
should help with the -m option?

quoted

quoted

What you probably thought you should do, given that the existing
git-svn documentation says to do it, is more like this:

   # WRONG
   git checkout first-svn
   git cherry-pick some stuff
   git merge [perhaps -s ours] second-svn/trunk
   git svn dcommit

Almost... In addition, I was trying to "git svn rebase" before the
dcommit

'git svn dcommit' implies 'git svn rebase' first anyway, so it's the same.

quoted

What would happen if somebody else creates a new commit just after I
"git svn fetch" but before I dcommit?  Guess, svn will not accept this
commit, because it is based on an outdated revision.  How would I
get out from this situation?

AFAIK, it will attempt to do "git svn rebase" first, and if that
succeeds, it will do the commit.

In such a case, the rebase should be okay, because it's only changing
commits (in fact, just one commit: the merge commit) that don't exist
on any other branch.  Thus it won't mangle any other merges.

Yeah, that's the simple case.  But what if the rebase don't succeed?

quoted

Ummm, no.. I have _two_ branches:

 first-svn:  contains the cherries that I picked from second-svn. This
             branch looks the way first-svn/trunk should be
 second-svn: contains the cherries that I picked from first-svn. This
             looks the way second-svn/trunk should be

Okay, if you want to end up with two different remote branches, it
makes sense to have two different local branches.

Well, I _have_ two different remotes because I have two svn repositories.

quoted

Don't I need to rebase at least one of them if I want to "merge" those
two branches into a single one?

I don't think so.  If you merge them together, what do you *want* it
to look like?  And what do you want to do with that branch afterwards?
 It's hard for me to guess, but it seems unlikely that rebasing things
will get you there.

Then I have to keep both local branches.  But I still wonder why you
suggested to go with _one_ local branch.

If what you want is "one central branch that currently looks like
first-svn/trunk or second-svn/trunk or maybe something else, but we'll
be merging future changes to first-svn and second-svn into it in the
future", then you would do:

   git checkout -b one-true-branch
   ...make it look however you want...
   # now mark it as up-to-date with svn, but don't change anything
   git merge -s ours first-svn/trunk
   git merge -s ours second-svn/trunk

And then in the future, whenever first-svn/trunk or second-svn/trunk
change, you would do:

   git merge first-svn/trunk
   git merge second-svn/trunk

etc.

I guess that might be interesting for the generic branch, where all the
localizations are replaced by templates.