I have been using git-svn
to communicate with my companyβs svn repo for a while now without any major headaches.
Today, the βheadacheβ-part changed dramatically:
Iβve been working on master/trunk
pretty exclusively, and needed to merge most (but not all!) of those change-sets into a new svn-branch, that originated from a pre-existing svn-branch.
Basically this:
π---π©---π©---π©--1π--1π---π©--1π---π©---π©--1π--1π--1π---π© master/trunk
\
\
2π--2π--2π--2π--2π versioned-release
Should have become this:
π---π©---π©---π©--1π--1π---π©--1π---π©---π©--1π--1π--1π---π© master/trunk
\
\
2π--2π--2π--2π--2π versioned-release
\
\
1π--1π--1π--1π--1π--1π new-versioned-release
Where π©
are commits that shouldnβt be in the new-versioned-release
, and xπ
the wanted commits from the respective branches x
.
So I did the following:
git checkout -b versioned-release-svn remotes/versioned-release
git svn branch new-versioned-release -m "Preparing for merge of XXX"
git checkout -b new-versioned-release-svn remotes/new-versioned-release
git cherry-pick ...
for every 1π
, resolving any conflicts on the way.Because I wanted to be sure I was really going to target the correct branch on the repo, I then ran git svn dcommit --dry-run
which did not yield any errors or warnings, but told meβ¦
Committing to svn://username@$repo-host/$repo-name/$path/branches/new-versioned-release ...
β¦followed by a couple of diff-tree
lines.
So I attempted to omit the --dry-run
and half way through the commits ended up withβ¦
Item already exists in filesystem: File already exists: filesystem '/data/subvroot/$repo-name/db', transaction '20856-g3m', path '/$path/branches/new-versioned-release/some-directory' at /usr/libexec/git-core/git-svn line 862
β¦and a bunch of unstaged changes.
Apart from the obvious β βWTF?!?β and βHow do I get out of this mess without losing everything I did?β β I have two questions:
git svn dcommit
: How do I get my local branch dcommit to its planned destination?Everything I found for the error-message, that somehow resembled my situation, so far was this other stack overflow question and the proposed solution of βsomehow [β¦] to blow away the .git/svn
metadata directoryβ doesnβt resonate quite that well with meβ¦
Someone just upβvoted my old question, so I thought Iβd share how I do that nowadays.
It works really quite well.
Assuming the git repository has been created using
git svn clone \
--prefix svn/ \
--stdlayout \
svn://username@$repo-host/$repo-name/$path
$git_repo_name
change into the git repo, and there run
git checkout svn/versioned-release
git svn branch new-versioned-release
This will result in the following history on the SVN server:
π---π©---π©---π©--1π--1π---π©--1π---π©---π©--1π--1π--1π---π© trunk
\
\
2π--2π--2π--2π--2π versioned-release
\
\
3βοΈ new-versioned-release
Now Iβd run
git checkout svn/new-versioned-release
git checkout -b new-versioned-release
# resulting in the following **local** history:
#
# π---π©---π©---π©--1π--1π---π©--1π---π©---π©--1π--1π--1π---π© master (tracks 'svn/trunk')
# \
# \
# 2π--2π--2π--2π--2π--3βοΈ new-versioned-release (tracks 'svn/new-versioned-release')
This is the foundation for achieving what I wanted.
There is one additional commit, because branching in SVN doesnβt work the same way as in Git: creating a branch always means a new revision, (aka commit) and thatβs where the 3βοΈ
comes from. It doesnβt really matter, but itβs there.
I can now git cherry-pick
all the 1π
s, ending up with this local history:
π---π©---π©---π©--1π--1π---π©--1π---π©---π©--1π--1π--1π---π© master (tracks 'svn/trunk')
\
\
2π--2π--2π--2π--2π--3βοΈ--1π--1π--1π--1π--1π--1π new-versioned-release (tracks 'svn/new-versioned-release')
When I now git svn dcommit
while sitting on new-versioned-release
in git, the history on the SVN server looks like what I wanted to end up with:
π---π©---π©---π©--1π--1π---π©--1π---π©---π©--1π--1π--1π---π© trunk
\
\
2π--2π--2π--2π--2π versioned-release
\
\
3βοΈ--1π--1π--1π--1π--1π--1π new-versioned-release
The only difference being that additional 3βοΈ
from creating the third SVN branch.