Commit in SVN without letting other to checkout - is it possible?

I am using SVN as my source control with ANKH and TortoiseSVN. I am writing a huge change in a project, and it takes a few days to make the change, but in the meantime I still want to commit once in a while for backup. But if I commit other team members will get updated with my unfinished work.

Is there a way that I can开发者_Go百科 "commit for backup" without changing the revision (so other won't get updated with my changes)?

Thanks!

This sounds like a classic case to use feature branches. This keeps your work separate, but allows all the other benefits of Subversion to continue.

To elaborate on iconik's comment:

One of the great features of SVN is the ability to branch a solution. When you create a branch, you're essentially creating a new repository by copying the existing code from the trunk.

While working on that branch, you can do anything to the code and it won't effect the trunk. When you're done with all the changes, you can merge the branch back into the trunk.

However, it is possible for other people to on the same branch you made (although rare), but you can ask them not to and they shouldn't have an issue with it.

More details can be found by reading this SVN book

The comments above are reasonable answers. You can create a separate branch for your changes which people know won't be correct (possibly not even building) and then merge the branches back together. Be warned that this can be a painful process.

Really, this sort of thing is not well served by Subversion. One of the big advantages of distributed version control systems like git, mercurial and bazaar is that they allow you to make a local commit for back-up purposes without sending it to the main repository immediately. So one option would be to double-manage this by also installing a DVCS client locally and use that to make local commits for back-up purposes. Most DVCS clients work fine without a central server being set-up so you can use it without it causing conflicts with your Subversion server. This is actually a pretty common practice among developers who want the benefits of distributed version control but who work at a company which is using centralized version control.

It is quite useful to "lock" the branch for a certain period of time so that other cannot make commits. For e.g. while making a build for a software release and you want to have a known version etc. Subversion provides "hook" mechanism.

http://svnbook.red-bean.com/en/1.1/ch05s02.html

You can write "post" or "pre" commit hooks and enable/disable the commits along with various other tasks.

Yes, use a branch (using svn copy). The part he left out is that using one svn merge command, you can take all the changes made in the branch, and apply it to the trunk (assuming all merges can be done without conflict). I've used SVN for web content this way. I had a devel branch (svn copy) I did all the web work in, and when we were ready to go live, I would do an svn merge to trunk (live) then deploy the trunk to the server.

There is a big advantage of doing this over using one of the distributed repository systems like Mercurial (though it is a fine product), which is that your branch is on the server, which has more reliable hard drives and more frequent backups. If you commit to your local Mercurial repository and your desktop computer dies, your work is lost. It also means if you do want to collaborate with a select group of people (hopefully you'll have some QA involved before you push the code to trunk!!!), you can do so by pointing them to your branch.