This is an overview of some of the changes you will encounter when going from SourceSafe to Subversion.
In SourceSafe, you work in a shared code base or line (known as a “Project” in SourceSafe) which you “share” into another line.
So you have a line that you work on, and then when you want to start adding new features or you want to change the functionality in certain pages, you share the entire line (aka “Projects”, represented by a small green folder icon 
).
If our first project was called Development1.0, you can share this into a new project called Development1.1
At this point in time, they are identical twins. In fact, they both point to the same item, sort of like how a pointer would work, they both reference the same data. If you change one of the files in Development1.0, it will instantly be updated in Development1.1. This means at this point there is no real point for creating this shared copy as they are the same.
However, if you add a new page to either Development1.0 or Development1.1, it will not appear in the other Project, it will only be in the one you put it in.
Now, if you want to “branch” some of these files, so that you can make changes to them in Development1.1, you would select them and click on “Branch files” (icon is 2 arrows coming from a file 
)
This will effectively split them, so they are distinct independent copies. All changes to either of the files will be maintained independently of the other file.
However, since all the other files are still shared, you might need to also branch any dependent files. This is good in some ways, because of the shared workspace others will see your changes and integration will be sooner then later, however it can also cause your work to break other people’s pages. What that means is if your page is dependent on some shared library or business object that is going to be modified, this can get quite messy!
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.
Subscribe RSS Feed
