SVN migration

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: William Hall
Subject: SVN migration
Date: Wednesday, June 16, 2010 - 4:02 pm

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




--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
SVN migration, William Hall, (Wed Jun 16, 4:02 pm)
Re: SVN migration, Steven Michalske, (Wed Jun 16, 5:41 pm)
Re: SVN migration, William Hall, (Thu Jun 17, 3:33 am)
Re: SVN migration, William Hall, (Thu Jun 17, 9:27 am)
Re: SVN migration, Joshua Shrader, (Mon Jun 21, 2:12 pm)
Re: SVN migration, William Hall, (Mon Jun 21, 3:26 pm)
Re: SVN migration, William Hall, (Sat Jun 26, 3:33 am)
Re: SVN migration, David Bainbridge, (Sat Jul 3, 4:37 am)
Re: SVN migration, William Hall, (Sun Jul 4, 10:55 am)
Re: SVN migration, David Bainbridge, (Sun Jul 4, 3:01 pm)