Creating a local SVN branch

Question

I am working on an SVN repository and do not want to create a new SVN branch. Instead of that, I want to create a branch local to my machine, something which could be done easily with Git.

But I am currently using SVN and need to branch out from an already-modified SVN version. In essence, I want following:

• svn_repo_version = 2259
• working_copy = modified 2259
• new_local_svn_branch = based on modified 2259

What is the best way to go about it?

Solution 1

Subversion is a centralized version control system. Some of the advantages of a centralized system is that it forces everyone to play with the same codebase. You can't hide your work for months at a time, then suddenly plop it down two days before a major release. The bad part is that you can't truly have a private branch and not have it show up in the repository.

There's no reason why you shouldn't be able to create your own branch. In fact, I use to give our developers a special "private" directory where they could put their own code, and do private branching. I had a pre-commit script that only allowed the owner of the branch to make changes, although I had it setup, so anyone could see it.

If you're worried that your private branches might clog up the branches directory, remember you can remove a branch from the branches directory when you're done. Or, you can request a parallel private directory where you can put your stuff.

If you really want to create a true private area where you can use Subversion and check in code without it appearing in the main repository, you have two choices I know of:

• SVK: This is a front end distributed version control system that uses Subversion on its backend. You can create your own Subversion repository, and post changes back and forth between your local repository and the master repository.

• Git: Git comes with a tool called git-svn which allows you to pull data off of a Subversion repository into a local Git repository. You can then use your local Git repository to do your branching, and later push your changed back into Subversion. There's even a Git version of Tortoise.

The only caveat is that you will have to get your hands dirty with the command line interface with both of these tools.

Solution 2

I'm afraid you will have to create a new branch and keep merging any changes into it. The only alternative is to simply checkout the branch, keep updating and don't commit (or keep switching prior to commits) until you are finished. You could always have two working copies if you need to work on the original branch/trunk. Nowhere near ideal, but that's the way SVN works, which is still very good given the alternatives at the time.

I personally manage local history if that is what you are after via my IDE (Eclipse).

Comments

[vcsjones]

Not a direct answer to your question, but you can use the git-svn bridge going forward so that you can use git locally to communicate to an SVN server, that's typically how I do it. That way you get local branches. See: stackoverflow.com/questions/5247435/…

[Mike Miller]

Do you need revision tracking locally? This isn't possible with svn.

[vickirk]

Of course if you are the only one working on that branch then it's not really that much of a problem, branch and switch just before you commit everything. Assuming you are not relying on svn to also do backups (which is bad!).

[agent.smith]

That is again similar to having 2 many local copies. I am doing small experiments which are not related to each other. So, I need separate copies. But at the end of it, I need to merge all of them. That is why I was exploring this options. I think I need to use svn-git. Thanks

[vickirk]

@agent.smith Personally, if they were just experiments for just me I'd rely on working copies and use whatever I saw fit locally (eclipse local history, git-svn, etc), if they where do be demoed||need sharing||recording i'd branch. You could always push for moving to git! Good luck with that ;-)