As well, you might want to maintain a link going forward, but not going backward. So you might want this file in Development1.1 to be shared to Development1.2 and Development1.3 but not shared to Development1.0
Keep in mind that nomatter what tool you use, the more parallel development you try to perform, the more messy and difficult your job is going to be. AVOID HAVING TOO MUCH PARALLEL DEVELOPMENT - TRY TO CLOSE OLD BRANCHES AS SOON AS POSSIBLE. This will save you much headache and tons of time wasted in managing lines and branches :)
The first recommendation when working with SourceSafe is to implement a continuous integration server, namely CruiseControl.NET, which at the very least will automatically build at regular intervals and apply labels each time, so that it is possible to revert to a previous version. This is super important, especially if you release your code to customers, because you might want to be able to get a piece of old code and find out why it is behaving thus.
If you do not label after every build or set of checkins, it is nearly impossible to get back to a previous version unless you are doing a very silly job of copying and maintaining a folder with all the old builds in it.
With labels, you can roll back individual files, but that individual file might have depended on an older version of say a business object, and thus you will have to roll back several files manually which is very difficult.
So CruiseControl is just a fancy batch file. It’s not too hard to set up at all, it might take you a few days, but once it’s done, its well worth it!
As well, names are different. For example, with Subversion you say “Commit” instead of “Check-in”. This takes a bit of getting used to.
Also, with Subversion, by default, there is no concept of “check out”. That is quite scary for some people. Anything you want to edit, you got it! Especially if you never turned off exclusive checkouts in SourceSafe, then you are used to the idea that if you are working on this file, nobody else can work on it. If you turn off this feature in SourceSafe, then you can have multiple checkouts, and the first person who checks in their code, wins. The rest have to manually merge the files, or depend on SourceSafe’s not so great merging tool.
With Subversion, unless there is a conflict (aka two people edited the same line of code), you will find that it will automatically merge the changes in a smart way, which is very helpful. In fact it saves you a lot of time. And you don’t even have to worry about checking out files. Although keep in mind that you should try to check in your stuff as soon as possible otherwise you might find it has changed dramatically and you will have to merge any conflicts that happened manually. (This is because a machine has no way of knowing which change was “Right”, you may have to remove your change, or the other person’s change, or keep both, in the case of conflicts!)
TortoiseSVN is the best way to get started with Subversion, it’s user friendly and requires no database (uses your file system to store data) and very little set up.
It’s not just enough to switch to Subversion, you need to know some of the
SCM best practices otherwise you will still fail.
It is very possible to continue working “sourcesafe style” in Subversion without realizing it and suffering the same problems.