git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Carsten Fuchs <carsten.fuchs@cafu.de>
To: git@vger.kernel.org
Subject: How to use subtrees when importing SVN repository with "vendor" branches?
Date: Thu, 01 Mar 2012 01:35:36 +0100	[thread overview]
Message-ID: <4F4EC458.8090808@cafu.de> (raw)

Hi all,

using git-svn, I've been converting our old SVN repositories to git with great success, 
but I don't know how to deal with our biggest and most important one.
The SVN repository structure is like this:

	branches/
	tags/
	trunk/
		ExtLibs/
			libpng/
			zlib/
			...
		some_dir_a/
		some_dir_b/
	vendor/
		libpng/
		zlib/
		...

The key problem is that we used to use the SVN "vendor branches" strategy: When a new 
version of libpng or zlib or ... is released, we update the vendor/ directory 
appropriately (essentially: delete the old files of the library, extract the tarball of 
the new release, commit).
Then we "SVN merged" the vendor/ directory into trunk/ExtLibs/.
This way, we were able to preserve our occasional customizations to the libraries in 
ExtLibs/ while updating to new vendor releases.

Using something like
	git svn init "svn://.../project_root" --trunk "trunk" git_test_project
it would be easy to fetch the projects trunk (never mind the branches and tags, we never 
used them much and are happy to ignore them). This properly converts the whole trunk to 
git, including subdirectory trunk/ExtLibs/, but with no notion of vendor/.

In contrast, using something like
	git svn init "svn://.../project_root" --trunk "trunk/ExtLibs" git_test_ExtLibs
	git config --add svn-remote.svn.fetch "vendor:refs/remotes/vendor"
	git svn fetch
yields a new clean "ExtLibs-only" git repository with the two branches trunk and vendor, 
and proper merge history (helped with grafting, where necessary), but is so far entirely 
unrelated to the main project repository.

Well... it seems like subtrees and subtree merging is a good way to proceed, but even 
though I've read everything I could find about the subject, I don't quite see how I can 
employ it in the case above, where ExtLibs/ isn't newly created, but history already exists.

Could you please give me an idea how I properly merge ExtLibs as a subdirectory into the 
main repository, including the history? I can add the ExtLibs repository (created as 
shown above) as a remote reference to the main repository, yielding a multi-root 
repository, but what then? Or should I rather convert only vendor/ and use that as a 
remote for merging? (Can grafting put to work in the subtrees context?)

I'd be very grateful for your help!

Best regards,
Carsten



-- 
    Cafu - the open-source Game and Graphics Engine
for multiplayer, cross-platform, real-time 3D Action
           Learn more at http://www.cafu.de

                 reply	other threads:[~2012-03-01  0:35 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=4F4EC458.8090808@cafu.de \
    --to=carsten.fuchs@cafu.de \
    --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).