git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* Using git to manage multiple SVN repositories
@ 2009-06-30 14:29 Geert Bosch
  0 siblings, 0 replies; only message in thread
From: Geert Bosch @ 2009-06-30 14:29 UTC (permalink / raw
  To: git@vger.kernel.org List

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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2009-06-30 14:57 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-06-30 14:29 Using git to manage multiple SVN repositories Geert Bosch

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).