From: Eric Wong <normalperson@yhbt.net>
Date: Tue, 06 Sep 2011 20:45:58 GMT
Subject: Re: [PATCH] git-svn: teach git-svn to populate svn:mergeinfo
Message-ID: <20110906204558.GA12574@dcvr.yhbt.net>
In-Reply-To: <20110906100003.4c87daba@robyn.woti.com>

Bryan Jacobs <bjacobs@woti.com> wrote:
> On Sat, 3 Sep 2011 08:49:47 +0000
> Eric Wong <normalperson@yhbt.net> wrote:
> > dcommit needs to continually rebase because it's possible somebody
> > else may make a commit to the SVN repo while a git-svn user is
> > dcommiting and cause a conflict the user would need to resolve in the
> > working tree.
> > 
> > At least I think that was the reason...  There is also the
> > "commit-diff" command in git-svn.  It was the precursor to dcommit
> > which requires no changes to the working tree.
> 
> Let me see if I've got this right.
> 
> The goal here is to commit each x~..x for each x in A..B, aborting if
> the SVN tree is not in state "x~" when the diff arrives.

Yes.

> So why am I seeing files added in changes on alternate
> branches ending up in the working copy when I abort before apply_diff
> is called for the commit which merges them into the present branch?

I don't know.

In my past use of git-svn, I've _always_ stuck with linear changes and
avoided anything non-linear.  SVN mergeinfo didn't exist when/where I
used SVN and my only current uses of git-svn is read-only.


Anyhow, I'm willing to accept your change since it doesn't appear to
break anything for existing users and Sam seems to approve.

-- 
Eric Wong