[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Using git to manage multiple SVN repositories
From:       Geert Bosch <bosch () adacore ! com>
Date:       2009-06-30 14:29:16
Message-ID: DB544A72-AD2A-4E7D-8421-6B72A4DECF3E () adacore ! com
[Download RAW message or body]

Hi all,

For my work I have to deal with various related large Subversion
repositories with more than 15 years of history that need
to be kept mostly in sync, but with varying layout.

As expected, git turns out to be a truly excellent tool for this
job. My workflow seems very non-standard though, so I'd like to
share it to maybe help others in similar situations and solicit
feedback to fine-tune my setup. Also, I have the suspicion that
I should probably use submodules for some of this, but they
don't really seem to fit well.

My goal is to polish this workflow, so it's usable even by
those suffering from prolonged exposure to RCS and CVS.

Repositories:

   -- Public Subversion repository
   public/module1/...
      :   module2/...
      :   moduleX/ourstuff-public/morestuff-public


   -- Company private Subversion repository
   private/ourstuff-private
      :   /morestuff-private
      :   /our-other-stuff

In my working tree, I do a svn clone of the entire
public repository:

   %git svn clone public:/public

Then, I put our private copy of moduleX inside:
   %git svn clone private:/private/ourstuff-private
   %rm -rf public/moduleX/ourstuff-public
   %mv private/ourstuff-private public/moduleX/ourstuff-public

Finally, as ourstuff-private does not include morestuff-private,
I clone that part to and put it inside in a 3rd nested git repository:

   % git svn clone private:/private/morestuff-private
   % mv private/morestuff-private public/moduleX/ourstuff-public/ 
morestuff-public

Now, I can go to the toplevel public and do a
   public% git checkout -f

This will bring in all upstream changes. Then, going to directory
public/moduleX/ourstuff-public, I can easily see the changes done
upstream and (using git gui) commit those changes acceptable in
our private repository and work on reducing the set of differences.

When that's done, do a checkout -f in the same ourstuff-public
directory (which contains the git svn clone of ourstuff-private)
will discard any unmerged changes. Going back to the toplevel
public directory, will now let me pick any of our private changes
that are acceptable into the public Subversion repository.

For files in the ourstuff-public directory that we don't want
(like ChangeLog files) I put a .gitignore in ourstuff-public.
For private files that we intend to keep private, I add a
.gitignore in public/moduleX, containing lines of the form
ourstuff-public/topsecretfile. Differences that I'll have to
carry around for a long time, I commit locally.

Using "git svn rebase" I can pull in any new development in either
the public or private Subversion repositories. This workflow is already
light years ahead of anything I could hope to achieve with Subversion.
However, the one big thing I miss is being able to do a commit in the
outermost git repository (the clone of the public Subversion repo),  
which
includes the current heads of all the enclosed repositories.

It seems this is something that should be doable with git submodules,
but I'm not quite sure how, without messing up my somewhat non-standard
setup. Any hints/tips/comments are appreciated.

   -Geert
--
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

[prev in list] [next in list] [prev in thread] [next in thread]