git svn dcommit error ?

Sat May 21 16:01:22 EDT 2011

On zaterdag 21 mei 2011, Geert Janssens wrote:
> On zaterdag 21 mei 2011, John Ralls wrote:
> > On May 21, 2011, at 10:14 AM, Geert Janssens wrote:
> > > On zaterdag 21 mei 2011, John Ralls wrote:
> > >> On May 21, 2011, at 8:29 AM, Geert Janssens wrote:
> > >>> On zaterdag 21 mei 2011, John Ralls wrote:
> > >>>> Take a look at `git log --full-history A'..B
> > >>>> src/gnome-utils/assistant-utils.c` (filling in the actual commit
> > >>>> short hashes for A' and B, of course). It should show what git
> > >>>> thinks are the differences.
> > >>> 
> > >>> $ git log --full-history c46431964..gtk2.18
> > >>> src/gnome-utils/assistant-utils.c commit
> > >>> b0d4b0c75fcb7f91ad60e68a1939c844e8333602
> > >>> Author: Geert Janssens <janssens-geert at telenet.be>
> > >>> Date:   Fri May 20 16:31:42 2011 +0000
> > >>> 
> > >>>   Replace obsolete gnome include with gtk include
> > >>>   
> > >>>   git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@20665
> > >>> 
> > >>> 57a11ea4-9604-0410-9ed3-97b8803252fd
> > >>> 
> > >>> This commit is commit A in my diagram above and is pushed to svn as
> > >>> revision 20665.
> > >> 
> > >> OK. A bit of googling takes me to [1], which is part of what taught me
> > >> how to set this up.
> > >> 
> > >> There, I'm reminded that the problem is likely that your git reference
> > >> to SVN is outdated because of the round-trip from your repo to svn to
> > >> github (via my server). Running git-update should patch up the
> > >> references so that your dcommit will work.
> > > 
> > > I wish that were so:
> > > 
> > > $ git-update
> > > warning: refname 'trunk' is ambiguous.
> > > Current branch trunk is up to date.
> > > 
> > > $ git checkout gtk2.18
> > > Switched to branch 'gtk2.18'
> > > 
> > > $ git svn dcommit
> > > Committing to svn+ssh://gjanssens@svn.gnucash.org/repo/gnucash/trunk
> > > ...
> > > 
> > >        M       src/gnome-utils/assistant-utils.c
> > > 
> > > Transaction is out of date: File
> > > '/gnucash/trunk/src/gnome-utils/assistant- utils.c' is out of date at
> > > /usr/libexec/git-core/git-svn line 576
> > > 
> > > I'm afraid I don't understand this well enough to know what to do next.
> > > I read the link you referred to, but other than what you proposed
> > > there seems nothing in there that could help.
> > 
> > Ah, that's not what you said you were doing.
> > There is no gtk2.18 branch in the svn repo, so you can't dcommit that
> > branch until you create one.
> 
> That doesn't seem correct. I have done that without any problems for all my
> previous dcommits, which have been from a gtk2.18 branch, a bugfix
> branch,... All these branches are rebased on trunk before dcommitting, but
> I'm definitly running the dcommit from the working branches, not trunk.
> 
> > I think that git svn branch -m "Feature
> > Branch for updating Gnucash UI to gtk2.18" should do it, but you'll need
> > to pay attention to the git svn output make sure that it does the right
> > thing; you may need to dcommit the changes after creating the branch, and
> > you may need to fiddle with the config of your local branch so that it
> > tracks the new svn branch.
> > 
> > This will not, of course, add your changes to trunk, and it will mean
> > that you will have to work in this feature branch until you're finished
> > with it: With Subversion, you get only one merge from a feature branch
> > back to trunk.
> > 
> > This is probably not what you want to do.
> 
> Indeed, I don't want to create additional branches in svn.
> 
> > What you want to do is what you
> > said that you'd done in your original message: Rebase your gtk2.18 branch
> > onto trunk and dcommit trunk and dcommit trunk to subversion.
> > git checkout trunk
> > git rebase gtk2.18
> > git svn dcommit
> 
> What I have done so far which has always worked until now:
> Work on a git local branch (like gtk2.18), these branches are all branched
> off of trunk.
> When I'm ready to push to svn:
> git checkout trunk
> git-update
> git rebase trunk gtk2.18
> git svn dcommit
> 
> Until this last attempt this has always worked. I never needed my working
> branch to exist in svn, the revisions got always pushed to svn trunk.
> 
> But now you seem to suggest that is backwards, and I should rebase trunk on
> gtk2.18 instead of the other way around ?
> 
> Anyway, I tried these steps, but the error is still the same, so there must
> be something else not right in my local repo.
> 
> > (wait until after the next update; if you hurry, you can get in before
> > the next one which starts at 1900Z) git-update
> > git checkout gtk2.18
> > git merge trunk
> > 
> > And you're ready to go back to work.
> 
> Just for the record, my follow-up steps always were
> git-update
> git rebase trunk gtk2.18
> 
> So far I have always avoided merging, because I thought that might lead to
> trouble with the svn interactions.
> 
> Geert
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Ah, I have found the answer [1]

I think my workflow is ok in general, but not very resilient due to the 
updates.

From the link, I gather that git svn's "internal working directory" (or 
whatever git's representation of its svn interface should be called) was in a 
mixed checkout state.

I probably created this by dcommitting from two separate git working branches 
without first waiting for a repo sync, then git-updating and then rebasing my 
working branches to the new trunk.

Anyway the solution is the remove the .git/svn directory to reset git-svn's 
metadata. After that, dcommit worked again.

I can see also now that this probably can be avoided altogether by using your 
workflow, namely rebasing trunk on the working branch you want to dcommit 
instead of the other way around. That ensures all dcommits happen from the 
same branch (trunk).

I'll note that this was not clear from our git wiki page. I have added an 
example workflow so other new users of our git setup don't have to make the 
same mistakes. Can you proofread my additions to make sure I didn't write too 
much nonsense ?

Pfew, mixing rcs's can bring up some subtle complications.

Geert

[1] http://stackoverflow.com/questions/2922059/how-to-recover-from-an-
unwanted-rename-using-git-svn-transaction-is-out-of-date