How to use an Internet Subversion respository when

问题:

I've painted my self into a problem working with a Subversion project from CodePlex - for this I asked for help here. I have a local repository and CodePlex has it's Internet repository for the project, and the two don't mix :-(.

But my dear departed dad used to tell me that the difference between a clever man and a wise man is that the wise man does not enter the trap a clever man find his way out of. In other words: I must have been doing something wrong. So:

Say you're a group of a few developers. There's a Subversion controlled project on the Internet you want to start modifying. You want to work on it locally, changing it to suit your needs. You want local version control. You want to control which Internet changes to accept to your repository - those that are relevant and important and don't cause noise. You want to commit to the Internet some of your local changes - those that you're sure that are stable, and that are relevant to the whole community.

This method of operation seems to me common sense, but then I've never worked on an open source project. So: 1. Is this indeed a common method of operation and 2. How do you go about doing it with Subversion without getting into trouble?

回答1:

Absorbing changes from an external source ("vendor drops") into your own local repository is covered in the SVN book in the section Vendor Branches.

Alternatively, you could just use the merge command to cherry pick revisions from a folder in repository A and apply those changes to a working copy of a folder in repository B. The merge command seems to have some support for this (at least in the latest version) so it probably works much like merging between local branches (minus the automatic merge tracking).

回答2:

Subversion is inherently a centralized revision control system. From your description, it sounds like you want a distributed revision control system. In such a system people can develop locally and then exchange their units of work (called changesets) between each other. Distributed revision control systems have excellent support for merging branches to support this.

I'm using Mercurial myself and would recommend it for a Subversion user since many of its commands a similar to the commands in Subversion. Others popular tools in this category include Git and Bazaar.

回答3:

Say you're a group of a few developers. There's a Subversion controlled project on the Internet you want to start modifying. You want to work on it locally, changing it to suit your needs. You want local version control. You want to control which Internet changes to accept to your repository - those that are relevant and important and don't cause noise.

You want to be able to work locally, and branch or merge without a second thought. You're basically talking about distributed version control. Subversion does not support this. You should instead use something like Mercurial or Git.

回答4:

It sounds like you should be looking at creating a branch for your code in the original repository. You can merge from trunk back to your branch, or the other way around, as you want.

Your other option is to export the files from the repository and add to your own repository. But that's only going to be a pain in the future.

回答5:

This is much easier with Distributed Source Control systems, such as git.

then you can have a local git repository, use git-svn to get updates from the public repo, and have your own local branch with your special tweaks.

You'll see many projects like this (extending subversion-ed OSS projects using git) on github - for NHibernate, for Castle project, etc.

if you must stick with SVN, you can manage your own change using a set of patch files over the public trunk. if you want newer stuff from trunk, create a patch with your changes, revert, update to the newer trunk, and then apply your patch selectively.

回答6:

I would generally keep one copy that I brought down from SVN which contains only the updated code from the repository and the code that I am working on and plan to commit back.

When working on a new feature, I would export the entire copy to a fresh copy on my machine, then make + test the needed changes. If I decided that I want to commit the changes back, I use some sort of merge tool (WinMerge is nice if you're on Windows), to merge my changes back into the original SVN-updated folder that I brought down.

This keeps everything fairly neat, as I am able to relatively easily avoid committing code unintentionally. I am also able to scrap changes easily by just making a fresh copy of my 'base' SVN-updated folder. The downside is that it makes working on multiple features that I do not plan to commit at once relatively unwieldy.