Source Control: Testing different variants of code

Question

Hi,

I new to source control, but i like the thought that i can step back to one point. I read that only code that is ready for release should checked in the repository.

If I want to play a round a little bit with one piece of code, to try different things. I can't step back to e.g. variant number 2 of my play stuff. It's not in the repository, no production ready code.

Should i checked in this code also?

Answer 1

Check in often and early. If your stuff needs to be excluded from the main development branch (often called "trunk") until it is ready for prime-time, create a branch for it and merge that branch with the main branch when you're done. With Subversion, this can be accomplished like so:

1. Create a root directory in the repository called "branches" or if you want to be more specific; "shelves" (the operation we're discussing here is popularly called "shelving" or "stashing").
2. In your Subversion client of choice, create a branch of the directory in question. Typically, you'd name this directory after the developer or the functionality you're implementing in the branch.
   • I don't think AnkhSVN has support for tagging and branching, so you'd probably need TortoiseSVN for that.
3. If you want to switch your working directory to the branch, do this. Switching makes the branch the default working copy directory, making updates and such easier.
   • If you choose not to switch, you will need to merge changes from the trunk (which usually is the default working copy) to your branch manually whenever needed. I think this is the best as it gives me more control.

As VonC writes, though, I'd highly recommend a Distributed Version Control System like git if you want to do this often. With a DVCS, every developer has their own branch and can check in as often as they like without affecting anyone but themselves.

Answer 2

You can define what is called a "private branch", that you will merge to the main branch when you are done.
You will merge all of your commits, or only some of them, depending on what you want to publish.

That is especially easy to do in a DVCS (Distributed VCS) where you control your own repository, and will merge only the relevant commits to a public branch.
That is more cumbersome in a centralized VCS where all branches are visible, usually with a unique name.

The reason is DVCS are usually more efficient when it comes to merge (due to their distributed nature, they have to merge a lot of contributions fast).
In a centralized VCS, like CVS, SVN or ClearCase, the merge is slower and more error-prone.

Answer 3

That would proberbly depend on what software your using for source control.. My reply assumes your asking based on subversion.

Basicly earch version of the code is a number, so you may be working on version 15.

Lets say you then change some code, on your machine the server its not going to know about this untill you commit it, and then the version number is going to increase to 16. But lets say the code you changed did not work out, then what you do right click on the files you have changed ( Or the entire project ) and click Revert and your code will go back to the version the server has.