Third-party repositories in Subversion; local mods?

Question

I'm building a small app as an interface to support functions, monitoring, web-based running of unit tests, etc. This will be checked into Subversion.

I want to include a third-party app which is also available via Subversion. Thus far I prefer to reference the remote repository to ease upgrades, particularly when I have made local modifications.

Now, I want the third-party app to be distributed alongside the parent app. Subversion externals are out, since I can't commit my local mods. git svn seems like it has potential, but I'm not sure on the details. (Seems dirty to have a .git directory with svn metadata stored in an svn repository.)

So how do you handle modifications to Subversion projects you can't commit to? I'm pretty open to any combination of git and svn, preferably allowing the code to live in our existing Subversion repository.

Update: I'm currently exploring vendor branches, which is more convention than feature. There is a tool called svn_load_dirs.pl to assist with the process.

Answer 1

Piston is ideal for this -

http://piston.rubyforge.org/

It stores the external code in the SVN respository, can easily show differences between your code and the vendor branch, and handles updating as well.

Answer 2

I handle the situation of external repositories by creating a copy on our local repository, and by periodically merging the changes from the external repository to the local repository (i.e. svn merge from external into my working copy, then commit). Thus, I can keep reasonably up-to-date on the external code, but I'm able to make (and keep) the local changes I need.

Obviously, you need to make sure that you have permission to distribute a modified version of their code alongside your app.

Answer 3

I use Subversion and what has worked best for me, is storing third party libraries within the repository in a standardised directory structure:
- Library1
-- v1.0
-- v2.0
etc

My goals are:
- ease of discovery
- change tracking
- simple checkout and build (for new Devs and Continuous Integration)
- having no external dependencies so you have everything required to run in the future

There's a good discussion over on SO for this too:

https://stackoverflow.com/questions/49196/storing-third-party-libraries-in-source-control

HTH!

Answer 4

I try to import all "old" repositories (CVS, Subversion) into a local Git or Mercurial repo. That way, I can easily track the official version, merging is much, much, much better in DCVS than in Subversion and I can branch as often as I like without any hazzle.

The only drawback so far is to get used to the idea to keep separate projects separate; don't try to import more than one project into a DCVS.