5

I have run into a common dilemma.

Many times, our company relies on using open source libraries to get things done, but occasionally we have to modify them to get it to run on different platforms, fix bugs, etc.

We use a combination of subversion: TortoiseSVN, and AnkhSVN.

Is there a way for the following scenario to work with SVN:

  • Devs adds the source code from an open source project to our subversion (usually via export, depending on what source control they use)
  • Devs make several changes to the open source code
  • Open source project creator makes several improvements and bug fixes of their own
  • How do we merge the changes from the open source project to our subversion?

If SVN can't do this, is there a better source control option for us? We would prefer one with Visual Studio integration if possible.

jonathanpeppers
  • 26,115
  • 21
  • 99
  • 182

2 Answers2

5

Subversion can do this of course. This kind of stuff was happening before distributed VCSs existed. See Vendor Branches section from Chapter 4. Branching and Merging in Subversion book.

Quote:

Managing vendor branches generally works like this: first, you create a top-level directory (such as /vendor) to hold the vendor branches. Then you import the third-party code into a subdirectory of that top-level directory. You then copy that subdirectory into your main development branch (e.g., /trunk) at the appropriate location. You always make your local changes in the main development branch. With each new release of the code you are tracking, you bring it into the vendor branch and merge the changes into /trunk, resolving whatever conflicts occur between your local changes and the upstream changes.

bahrep
  • 29,961
  • 12
  • 103
  • 150
Peter Štibraný
  • 32,463
  • 16
  • 90
  • 116
  • Making sure I have this correct: Create a branch from the open source project via "svn copy", then merge into our main branch. Later on I would update the branch from the open source project using "svn copy" again I assume and merge again. Sounds simple enough. I will give this a try, but I'm wondering if other source control options would be better. I know some DVCS can merge better than subversion (fewer conflicts), because they keep more information about each changeset. – jonathanpeppers Apr 22 '11 at 16:08
  • @Jonathan.Peppers Any DVCS solution will be better because it will keep a Directed Acyclic Graph of the changes, splitting your changes and the open source upstream changes, and then easily merge them together (instead of just trying to squash the two together and have conflicts that shouldn't even exist). An addition the model easily supports the ability to work with the two upstream branches directly. – alternative Apr 22 '11 at 17:34
  • @Jonathan.Peppers: no, you cannot "svn copy" from different repository. You create vendor branch from stable version of downloaded (or checked out) sources. Then you import them into your own SVN. (I agree that DVCS is better in that it allows you to pull changes from remote repository into vendor branch directly, including full history. In SVN you don't get full history, and you have to do the "pull" manually) – Peter Štibraný Apr 22 '11 at 18:09
3

Subversion is not the right tool here. What you are looking for requires a Distributed Version Control System, which basically means you can pull and push across repositories, and there's no central repository.

Check out Git and Mercurial for more information. If the upstream project uses Subversion, you can use git-svn as a bridge - you create your own repository, change stuff, and you can still merge the svn into it as well as push to your own "upstream/central" git repository.

Also note: Is there a reason you don't contribute your changes directly to the project? (Especially if the project is licensed under something like GPL or LPGL that forces you to release your modified source to the public under a suitable license, which many projects are). It seems that would be a great way to give back to the people that are giving you code for free...

The following question addresses Git + Visual Studio: Using Git with Visual Studio

Community
  • 1
  • 1
alternative
  • 12,703
  • 5
  • 41
  • 41
  • Do either of these have Visual Studio integration? – jonathanpeppers Apr 22 '11 at 13:26
  • @Jonathan.Peppers I believe they do. I'm a linux user so I don't completely know. I found an SO question that gives you that answer and posted a link to it on my answer for you. – alternative Apr 22 '11 at 13:27
  • +1 for pushing upstream. This is the only way to reliably keep the maintenance cost of open source dependencies low. – David Schmitt Apr 22 '11 at 13:28
  • @mathepic: on why we don't always contribute. We do if it is something of value. Many times our changes are merely what's required to get things working in MonoTouch for the iPhone, or we will drop all classes except a few that we need. Like for example, we were using Math.Net Numerics for Matrix math, but needed it to run on Mono cross-platform and their is a lot of crazy .Net 4.0 stuff in there. We needed to drop everything except the matrix classes we needed. – jonathanpeppers Apr 22 '11 at 13:32
  • @Jonathan.Peppers Okay, that makes sense. In fact, its almost even better! You could create your own branch, say, `company`, and then put stuff on the `master` branch that you want to contribute back, and keep rebasing `company` (your company-specific stuff) on top of `master`. Then you can request the open source project to pull from your `master` but not `company` (which contains `master`) – alternative Apr 22 '11 at 13:34
  • The GPL and LGPL do NOT force you to send your patches to the upstream author(s). What they require is that you offer the source to anyone to whom you distribute binaries. – nobody Apr 22 '11 at 13:36
  • @Andrew thats what I meant; I'll edit the answer to be more clear. Thanks. – alternative Apr 22 '11 at 13:37
  • 2
    Suggesting that Subversion is not the right tool is just plain wrong. Creating a vendor branch in Subversion (as @Peter indicates) is a perfectly reasonable and maintainable solution. I'm not even sure that DVCS will make the problem easier to manage without a vendor branch strategy. – John Bledsoe Apr 22 '11 at 13:47
  • @John Bledsoe They want to have their own upstream as well from the look of it. How can you pull from somebody elses subversion repository then push to a different upstream? They need _two_ upstreams. – alternative Apr 22 '11 at 13:50
  • 2
    We handle this by branching the vendor code in our svn repository, applying our patches and then merging any subsequent vendor updates into our patched branch. I disagree that subversion is the wrong tool for this. – SteveMc Apr 22 '11 at 13:54
  • @mathepic The question states that the source control provider of the open source project is undetermined. It's not DVCS, it's not Subversion. We don't know what it is. (It could be Visual SourceSafe for all we know.) Vendor branch handles this situation and does allow for creating changesets to push back to open source projects if desired. – John Bledsoe Apr 22 '11 at 13:55
  • @mathepic, yeah, in svn you have to do imports manually (or you can use svn_load_dirs.pl tool mentioned in SVN book). Of course it's not as elegant as with DVCS, but it's certainly doable. – Peter Štibraný Apr 22 '11 at 13:57
  • @John Bledsoe When did I say what the open source version control system was? I said if it happens to be subversion, which is pretty likely, you can use git-svn. – alternative Apr 22 '11 at 14:52
  • @mathepic I was reading "somebody elses subversion repository" in your previous comment. Was I right to assume that this referred to the open source VCS? – John Bledsoe Apr 22 '11 at 15:27
  • @John Bledsoe You suggested that, I thought. Note that I'm not quite sure what a "vendor branch" is; does it not require that you branch from somebody using Subversion? – alternative Apr 22 '11 at 15:32
  • In any case I find it interesting that all the SVN guys downvoted me for suggesting that if you want to use a distributed workflow (which they do, they are using two different upstreams) then you should use a distributed VCS. – alternative Apr 22 '11 at 15:33
  • No, "Vendor Branch" is a source control pattern for managing 3rd party code that you may modify in-house and that you want to keep current with 3rd party updates. Read the link in @Peter's answer for a detailed explanation. – John Bledsoe Apr 22 '11 at 16:49
  • @John so it doesn't import history at all? Seems like a workaround more than a solution. – alternative Apr 22 '11 at 17:30
  • @mathepic: I'm not sure about your terminology, as I only see single upstream. Anyway, I agree with you that DCVS tool handles this situation better, but I don't agree with your conclusion that Subversion is not suitable for the task. – Peter Štibraný Apr 22 '11 at 18:11
  • @Peter Stribrany Well, theres the open source upstream, and the developers at the company probably want their own internal upstream. And if DVCS is better for the task, I would say its the right tool for the job. I wasn't saying its impossible to do in SVN, but rather that it is more difficult as well as less featured. – alternative Apr 22 '11 at 18:49