From: William Hall <will@gnatter.net>
To: git@vger.kernel.org
Subject: SVN migration
Date: Thu, 17 Jun 2010 00:02:07 +0100 [thread overview]
Message-ID: <4C1957EF.6070504@gnatter.net> (raw)
Hi gitters,
Background - I'm trying to convince my company to ditch SVN for git -
the usual story. So for the duration of a project I'll be running git
and SVN in parallel - the idea being is that we will still commit to SVN
(and update), but the development work internal to my team will be using
git.
An absolute *must* is for the SVN repo to continue as the SCM authority
- at least until I can persuade the company to switch to git permanently.
Here's some crap ascii art to show the situation,
--------------
| non-git dev |
--------------
|
|
------- ----------------
| SVN |-------| git/SVN bridge |
------- ----------------
|
---------------
| bare git Repo |
---------------
|
------------------------------
| | |
dev_1 dev_2 dev 3
- the git/SVN bridge is a git repo created with git-svn-clone.
- the 'bare git' repo is a typical standard git repo and I'm keen for
the developers to experience a 'normal' git environment and not have to
worry about SVN interactions.
Am sure this problem has been considered many times before, but I cannot
seem to find an effective solution.
The issue is the dcommit operation from the bridge. The rebase part of
this re-writes the commit messages to include the SVN commit-ids which
is nice, but screws up the push/pulls between the bridge and the bare repo.
One solution I've tried is to create a branch in the bridge that tracks
the bare repo, and another branch to track the SVN server. If the
branches are kept separate then I can git-cherry-pick to replay changes
from one side to the other (or at least merge one-way). his is not ideal
as I really should use git's merge facility. I'd like to guarantee that
the sides are not diverging over time.
Actually I've tried all permutations of merges/rebases/update-ref, I
always fall into the same trap that befits a rebase in conjunction with
remote repositories.
I can live without tags and branches for the time being - I just want to
get a robust workflow defined in the bridge for the SVN 'trunk' - ie
read/writes in both directions.
If anyone can offer any advice then it would be hugely appreciated.
Perhaps you'll say that it cannot be done, which would make the git sell
much harder.
Hopefully by the end of this exercise git will have 800 more fans.
Many thanks
Will
next reply other threads:[~2010-06-16 23:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-16 23:02 William Hall [this message]
2010-06-17 0:41 ` SVN migration Steven Michalske
2010-06-17 10:33 ` William Hall
2010-06-17 16:27 ` William Hall
2010-06-21 21:12 ` Joshua Shrader
2010-06-21 22:26 ` William Hall
2010-06-26 10:33 ` William Hall
2010-07-03 11:37 ` David Bainbridge
2010-07-04 17:55 ` William Hall
2010-07-04 22:01 ` David Bainbridge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C1957EF.6070504@gnatter.net \
--to=will@gnatter.net \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).