Re: [PATCH 2/2] git-svn: handle SVN merges from revisions past the tip of the branch

From: Toby Allsopp <toby.allsopp@navman.co.nz>
Date: Nov 13, 2009, 01:03 UTC
Message-ID: <87ws1v44o8.fsf@navakl084.mitacad.com>
In-Reply-To: <4AFCAC9C.9020305@vilain.net>

On Fri, Nov 13 2009, Sam Vilain wrote:

Show 9 quoted lines

> Toby Allsopp wrote:
> > When recording the revisions that it has merged, SVN sets the top
> > revision to be the latest revision in the repository, which is not
> > necessarily a revision on the branch that is being merged from.  When
> > it is not on the branch, git-svn fails to add the extra parent to
> > represent the merge because it relies on finding the commit on the
> > branch that corresponds to the top of the SVN merge range.
>
> I thought, "that sounds like he's repeating himself, wait a sec..."

Hmm, it makes perfect sense to me :-) Does the explanation in 1/2 make more sense?

The first sentence describes what Subversion does, the second what git-svn does in response.

> Thanks for contributing this.  There might be other bugs too, especially
> when upstream has a more complicated merge hierarchy ... apparently svn
> tends to get it wrong, so checking for all commits might not work in
> that case.

Oh yes, SVN gets the merges wrong in an alarming number of cases, it's really shocking. I only stay sane at work because I tell myself that SVN is making the case for git for me :-)

> It would be nice if "dcommit" could make these commits, too...

Yes.

Toby.