Visual SourceSafe

Moving from SourceSafe to Subversion

Sameer Alibhai — Thu, 24 Apr 2008 23:25:09 GMT

This is an overview of some of the changes you will encounter when going from SourceSafe to Subversion.

Subversion is modeled on CVS, whereas SourceSafe is modeled on.... well... nothing (just a joke).

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.

SourceSafe Branch Recursively

Sameer Alibhai — Mon, 24 Sep 2007 22:05:50 GMT

Did you know there is no way to branch sourcesafe projects recursively? Or so you thought!

Here is a work around:

From Visual SourceSafe Explorer, go to View -> Search -> WildCard Search

Then search for Wildcard: *
(a single asterisk) with "Search in current project and all subprojects" selected.

Then it will give you a list of ALL of your files in that project. Simply highlight them all and click on the Branch button.

The only caveat is that you need to make sure the files are not checked out in that project in order to branch them.

And again,.. I would recommend you ditch SourceSafe and go for something better, like Perforce, Subversion, or Vault

Visual Source Safe Pinning Feature

Sameer Alibhai, Ashiq Alibhai — Tue, 12 Jun 2007 21:45:52 GMT

We have run into the situation before where we are developing code, but we don’t want other developers to get that code yet because it is not completely developed yet. However, we still want to take advantage of Source Control and put it in the repository so we have incremental changes and we can rollback incase we do something dumb. Our first solution to this was to use a “ready” label and then instead of getting latest version, we would do a “Get label ready”, and then the 'ready' label was updated when the code was more stable. However, this didn't work very well, and maybe it would have made more sense to use many different 'ready' labels, such as ready1, ready2, ready3, etc.. so that if we ever needed to revert to an older one, we could do that.

However, there is a better way to accomplish this with sourcesafe, its called “Pinning”

I created a test.txt and here is the contents: blah blah version 1

Version 1 test.txt–

blah blah version 1

Version 2 test.txt–

blah blah version 2

Version 3 test.txt–

blah blah version 3 BROKENNNN!!!

Now when you do a get latest version on the file or containing folder, it will give you version 2 (blah blah version 2), not version 3 - BROKENNNN!!!

Here are some more References:

Version Control in Source Safe (http://msdn2.microsoft.com/en-us/library/shyhfx67(VS.80).aspx)
How to Pin (http://msdn2.microsoft.com/en-us/library/xa4cy26x(VS.80).aspx)

Update (June 29, 2007) - If you pin a file, you CANNOT check it out and continue to work on it. As usual, SourceSafe takes the cake! Pinning could have been the perfect way to indicate "this version is stable, so get that one, while i continue to work on it", but it ended up being otherwise :(

Here is a blurb from that page:

Use of Pins in Version Control

Visual SourceSafe defines a pin as a marker that designates a specific version of a file as the version that is part of a project. The pin is represented by a pushpin icon, and is added through the Pin command in the History of <name> dialog box. For more information, see How to: Pin a Version.

You can pin any file, but you should do this only when you are not planning to change the marked file. Pinning is most useful when applied to shared files.

Note When you pin a shared file, you cannot make changes to it until you unpin it using the Unpin command from the History of <name> dialog box.

If you share a pinned version of a file, the projects sharing the file cannot change it. However, if you share an unpinned file, and then pin it in one project, other projects can still change and update the file.

Let's examine an example of using pins for version control. One developer has prepared a spell checker program. The first time the version of the program is stable, the developer uses pins to mark particular versions of the program code files. He then notifies a developer of a grammar checker program that uses the spell checker code that a good version is available. The second developer can share and branch the code and use the pinned file versions as the basis for his spell checking components of the grammar checker program. He only obtains the last known good code files for the spell checker, unless the first programmer unpins his file versions at some point.

SourceSafe Merges Changes, Not Branches!

Sameer Alibhai, Ashiq Alibhai — Wed, 06 Jun 2007 22:05:42 GMT

If you've ever had two or more source-safe projects with shared files, you might be shocked to learn that Visual SourceSafe 2005 breaks one of the holy grails of good design: user expectations. Again. (For the first incarnation of this evil act, see SourceSafe Shares Deleted Files)

You would expect that, if you merge a branched file from one project, it gets shared. I mean, you merged it, right? What was once double maintenance should become a single, unified soul. But alas, Visual SouceSafe 2005 merges changes, not branches!

To test this out, try the following:

Create a new project (call it "Test-A")
Add some files (some HTML or text files work best)
Create a new project (call it "Test-B")
Browse into Test-A, and select and drag some files into Test-B to share them
Branch one of the shared files
Edit the branched file in Test-B and add a line with "B: " at the prefix
Edit the branched file in Test-A and add a line with "A: " at the prefix
Select the branched file in Test-A, browse to the Versions menu, and click Merge Branches ...
Select the Test-B branch to merge to
Resolve any conflicts
Check in the file
The file is still branched!

The only consolation you may have, is that you can delete one version and manually re-share the file (for example, by dragging and dropping the merged version into the other project folder) in order to get a real merge. But, if you have a large project with hundreds of files, set aside a few days just for merging. (Or save yourself the tedious and error-prone work by switching to Subversion, Perforce, or some other real source-control solution.)

So consider yourself warned!
By Ashiq Alibhai

SourceSafe Shares Deleted Files!

Sameer Alibhai, Ashiq Alibhai — Wed, 06 Jun 2007 22:05:07 GMT

If you've ever had two or more source-safe projects with shared files, you might be shocked to learn that Visual SourceSafe 2005 breaks one of the holy grails of good design: user expectations.

You would expect that, if you delete a shared file from one project, it gets branched. I mean, you deleted it, right? You said goodbye, kaputsky, sayounara! But alas, Visual SouceSafe 2005 shares deleted files!

To test this out, try the following:

Create a new project (call it "Test-A")
Add some files (some HTML or text files work best)
Create a new project (call it "Test-B")
Browse into Test-A, and select and drag some files into Test-B to share them
Delete one of the shared files (non-permanently)
Browse to Test-B
The file is still shared!

Shocking! What's worse, the deleted file continues to be updated if the other version is updated! Try it for yourself:

Browse to Test-B
Check-out, edit, and check-in one of the files you deleted
Browse to Test-A
Recover the deleted file (right-click on the project and select Project Properties, go to the Deleted Items tab, and click Recover)
View the file
The file has the same changes as its twin in Test-B!

The only consolation you may have, is that if you destroy permanently when you delete a shared file, it becomes branched--albeit with a hideous, ugly warning pop-up.

So consider yourself warned!
By Ashiq Alibhai

Visual SourceSafe 2005 Tip (VS2005) - Keywords

Sameer — Tue, 29 May 2007 15:19:52 GMT

Using Visual SourceSafe, we can put some text at the top of our source file and it will automatically be updated by SourceSafe when you check in the file. See below for an example.

// Last updated by:
// $Author: Sameera $
// $Date: 4/13/07 11:16a $

This will allow you to quickly see who was the last person who checked in the file.