git svn dcommit error ?

[Geert Janssens]

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