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

[Josef Wolf <jw@raven.inka.de>]

On Thu, Apr 30, 2009 at 06:59:50PM -0400, Avery Pennarun wrote:
> On Thu, Apr 30, 2009 at 6:28 PM, Josef Wolf <jw@raven.inka.de> wrote:
> >  # 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
> [...]
> > 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?

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

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

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