Source Control: Anything But SourceSafe

blog
14

We almost switched to Team System, but the SourceSafe-style checkout-edit-checkin working style killed the deal. We had switched from SourceSafe to Subversion a year before and absolutely loved the edit-merge-commit working style. I had an email exchange with Brian Harry about this where I asked for clarification on his statement that “we designed it so we could support edit-merge-commit in v2”, and discovered that it was nothing more than “automatic checkout from within the tool”, not true edit-merge-commit, since files are read-only on the file system and they don’t provide file system hooks like Tortoise does.

The problem is that Microsoft’s internal SourceDepot has the checkout-edit-checkin working style, so they see no need to support edit-merge-commit when they’re dogfooding it. I think that being locked into server-managed checkout-edit-checkin under the hood is one of the fundamentally broken by-design parts of SourceSafe that has carried forward to Team System.

15

Bryan Zug: Check out Alienbrain (http://www.alienbrain.com/), an SCM built for multimedia production from the ground up. Good integration with media applications, but also development tools such as Visual Studio.

16

not true edit-merge-commit, since files are read-only on the file system and they don’t provide file system hooks like Tortoise does.

Oran, this isn’t technically correct. Team System is absolutely an edit-merge-commit system at its very core. That is the default setting.

What you’re looking for a source control system that lets you edit directly from the filesystem. Team System doesn’t really do this; you have to signify intent to edit to the server through either the IDE or the command-line tool (TF.exe). You can’t just plow into the files on disk and start changing them without letting the server know what you’re doing.

The Team System model, for better or worse, is an always-connected one. It’s possible to work offline, but it takes some workarounds:

http://blogs.vertigosoftware.com/teamsystem/archive/2006/07/03/2984.aspx

17

Not having to checkout files (signify intent to edit in some way) before you start working is one of the real strength of, for instance, Subversion in my opinion. I don’t think anyone who has tried that model would like to go back to an SCM that keep files read-only until checked out. Allowing multiple, concurrent checkouts is NOT the same thing as always keeping the files writable. It’s a huge difference.

18

Tortoise SVN is a good alternative for VSS2005. Only problem with SVN is you better have a really fast hard disk and lots of memory because your machine will bog between gets, builds in VS2005, and commits.

Right now I have completed an update from our repository and I am waiting to get control back to devenv.exe from TSVNCache.exe which is currently throttling the cpu at 65-100% :(.

19

C-J: my sentiments exactly.

Jeff: in my mind “checkout” == “any source-control-specific-steps I have to take before I can edit a file that’s already on my hard drive.” Even if the IDE does this automatically for me, I hate the little delay when I start typing. And this only works in the IDE. I have to jump through all sorts of hoops if I want to make a change with Notepad.

Team System doesn’t do enough client-side tracking to provide a classic edit-merge-commit working style. Your link mentions that you should avoid off-line renames which I’m guessing is due to this not being tracked client-side.

There are a number of other issues I found with Team System when I researched it back in December. Subversion tracks changes at the directory level while VSTS only tracks per-file. You can’t exclude directories from source control in VSTS. All root VSTS folders must correspond to Team Projects. You can’t create a “simple” source-controlled folder in VSTS. VSTS doesn’t let you merge between unrelated branches, only parent-child branches. VSTS doesn’t have “blame/praise”.

In Subversion, the client keeps track of what files and versions you have. In VSTS, the server keeps track of what files and versions you have. This causes problems when moving stuff around on the client, but can speed up updates in “workspaces containing tens of thousands of files.”

In Subversion, “move” is implemented as “add with history and delete”. “Move” in VSTS is a thinly disguised alias for Rename. You also can only move one file at a time in VSTS.

Unlike Subversion, I’m guessing you can’t efficiently “switch” local files between branches, reusing the pre-existing client-side files, only transmitting and changing the diffs.

At the end of my post is Brian Harry’s response to my request for true edit-merge-commit. Notice that his goal is to stay firmly in the “checkout” camp even in v2 and convert people to that style by removing as many of the speed bumps as possible. I honestly don’t see what value those speed bumps add (even when minimized), other than seeing who has which files “checked out”, which can never be 100% accurate due to offline checkouts.

Brian’s email:

Edit-merge-commit is a model that we want to support and will some day. Unfortunately we were not able to get it implemented for V1. I don’t know what to tell you there. I’m always interested to hear from people who prefer edit-merge-commit. It seems to having explicit checkouts is better (if you can mitigate the costs and deal with the offline issue). We haven’t done everything in V1 yet to make the checkout model we have great (unfortunately). We have plans in V2 to make checkouts work while you are off line and to make it asynchronous. This way it should be transparent and appear as if you are using edit-merge-commit but have the advantages of checkouts - including enforcing exclusive checkouts of unmergable files, allowing me to easily see all files that I have modified, and allowing me to inspect files other people are working on. I think when we do this we’ll convert many people to checkouts but only time will tell.

I wish I had a better answer for you right now but I don’t :frowning:

Brian

20

haw man, source control and branch/merges not necessary… that’s crazy.

on some projects, we have groups of one or more developers working in their own branches, protected and protecting the rest of the team. This allows developers to check in often, get the source code in the system in small bites, which are build nightly and automated-tested.

We can also narrow down very quickly what project introduce a regression by comparing automated tests on two different branches.

We have migration of compiler, port 64-bit, etc, all done in separate branches and then merged in.

We do EVERYTHING with automatic merge in ClearCase. There is only ever a problem when two users checked in the same few lines of code, and ClearCase warns us of this.

We absolutely REQUIRE branches to make incremental patches for different clients, then have these merged in with other patches and versions. We absolutely REQUIRE branches to produce different products from the same code base, with different release dates and therefore different code freeze, without interrupting developement.

We have only one guys taking care of the build for all of this, merges and bullds are all automated with scripts, and spitting out 3 to 10 different builds of the application daily…

mind you, there are a couple of people taking care of ClearCase, the thing really seems to be a best. I trust it with my life, however. Too bad the VC++ plug in now sucks since either the Rationnal or IBM aquisition…

21

OK I’m going to have to pipe up in favour of ClearCase, seeing as noone else will.

For all its flaws (and there are many) ClearCase is a real source code control system. It is extremely powerful, supporting extensive branch/merge capabilities, triggers, labeling and customisation up the wazoo. The ‘dynamic view’ feature (which exposes a workspace as a ‘live’ network-based filesystem) is incredibly powerful and useful. If you can get it working, the build-avoidance stuff (which copies object files from peer workspaces rather than invoking the compiler) is amazing, and AFAIK unique. Clearcase also has the capacity to handle extremely large projects with many developers across many locations. In my years of using it, it has never once lost my data. In short, it’s reliable.

But that power and reliability comes at a high cost. Clearcase costs a lot in terms of outright expenditure on licensing, but also training for users, the need for administrators, LAN/WAN bandwidth, etc etc. Clearcase is also quite clearly showing its age and the adverse effects of too-many mergers and acquisitions. So it’s very quirky, if not outright buggy.

I am glad that there are competitors like subversion that are gaining traction and credibility in the source control world. But ClearCase is still a formidable product with many redeeming qualities despite its flaws.

22

Thankfully I have such a poor memory that two years of sourcesafe use didn’t teach me any bad habits.

I do remember the IT guy having to rebuild the database for it every couple months, and a few very close calls… don’t use sourcesafe!

23

While individual developers at my place were using source control, but policy came down from above for all developers do use a single method of control.

Their choice: Subversion

I had my own crap version of source control and never used an actual software package - I never learned how to do “real” control. So what to do? As Jeff suggests, I read the damn book (it’s free!)

I used the TortoiseSVN overlay and it totally rocks. I have had no problem with it and because of Tortoise, it was easier for me to integrate the entire versioning process into my workflow.

The only threat on this move is that we are still in a trial-ish period to see if Subversion is really the product we want to use. This article is great as a resource for some actual thoughts on other packages if we go that route. Thanks all!

24

Oh…and I spoke on version control in a one-man environment a little while ago. In case anyone is interested in the read:

http://www.morningtoast.com/index.php/2006/08/one-man-version-control/

Thanks

25

Just for the record, I’ve been using SourceSafe for years, accessing it through its well known proxy, Source Offsite. I’ve used it with various teams of different sizes and a number of projects, some large, some small…works great ---- not sure I understand what the fuss is all about.

26

P.S. I do NOT consider that I’ve been poisoned by it!

27

I started working at a place that uses ClearCase about 6 months ago.

I will never accept a position at a company that uses ClearCase again. This has moved to the top of my list of things to look out for when scanning a job posting.

Yes, it’s true, it hasn’t lost any of my code for me yet…but that’s because it’s so damn painful to check stuff in, and it has so many checks and balances to prevent you from doing something wrong that you hate it the 99% of the time that you’re just trying to do something right.

Way too many layers (activities, developer and integration streams, locked files and hijacked files). The UI tools really blow (especially on Linux) and the command line tools are only adequate.

There have been many times when a merge goes haywire and prevents me from checking in code. More than once, I’ve had to remove the entire directory, rejoin the project and copy my code back into the project to get clearcase to accept my changes.

Ick. I hate VSS, but would much rather be using it over ClearCase.

28

If you use SourceSafe, are you helping the terrorists?

29

Source Safe actually wasn’t MS’s first productized source control system. I can’t find a link for it anywhere, but in the early 90’s, MS released “Microsoft Delta”…which also sucked :}. We used it at the place I worked before I joined the empire - it was basically a productized version of the system MS was using at the time.

30

Team System doesn’t do enough client-side tracking

This is true. Team System doesn’t do ANY client-side tracking. It’s the primary architectural difference between Subversion and Team System. Subversion leaves a lot of .svn folder schmutz on the client drive, where it tracks the last version of each file. In Team System, you have to inform the server when you do things.

There is the TS PowerToy which can infer some things from client operations, however:

http://blogs.vertigosoftware.com/teamsystem/archive/2006/04/04/The_Team_Foundation_Power_Toy_and_Undo_Unchanged.aspx

your link mentions that you should avoid off-line renames which I’m guessing is due to this not being tracked client-side

The Subversion documentation has similar warnings, though. Here’s a direct quote from the online docs:

“While you can edit your files with whatever tool you like, you shouldn’t change the structure of your working copy without letting Subversion know what you’re doing. Use the svn copy, svn delete, and svn move commands to change the structure of your working copy, and use the svn add command to place new files and directories under version control.”

Subversion tracks changes at the directory level while VSTS only tracks per-file

VSTS tracks directory changes. Not sure what you mean here.

You can’t create a “simple” source-controlled folder in VSTS

I’m pretty sure you can do this with the command line tool, TF.exe

VSTS doesn’t let you merge between unrelated branches, only parent-child branches

Now this definitely isn’t true. You can do baseless merges.

http://blogs.vertigosoftware.com/teamsystem/archive/2006/07/13/3069.aspx

In my opinion, this is superior to what subversion does. It lets you “merge” anything, even totally unrelated folders!

doesn’t have blame

It’s in the power toy

http://blogs.msdn.com/buckh/archive/2006/03/13/annotate.aspx

Unlike Subversion, I’m guessing you can’t efficiently “switch” local files between branches, reusing the pre-existing client-side files, only transmitting and changing the diffs.

Sure you can-- you just switch workspaces.

I dunno, Oran. Half the items you list aren’t really problems, but signs of a new product that developers are still getting the hang of.

But you’re absolutely right that if you want to run roughshod over the filesystem without telling the server a darn thing, then Team System is definitely not the source control system for you.

I think Subversion is a fine source control system (particularly considering the price) but it has its share of architectural flaws, too. Tags, for instance, are totally a hack: they’re branches! You can check a change into a tag!

31

WARNING RANT AHEAD…
I really hated VSS until I we started using the Team System Source Control. Now everyone in my team has started uttering the words, “maybe we should go back to Source Safe.” It pains me to say it. I even have theory that MS lost the source code to VSS and that’s why it never gets anything but a button bitmap upgrade. But TSSC is just an albotross around our necks.
We’ve had many issues with the Team System Source Control. It’s freaking terrible.

  1. It has zero support for working disconnected, which is lame.
  2. For the love of god where is the search capability? I want to see what I or another team member has checked out. My two options are a 3rd party tool (Version Control Sidekick) or the command line. WTF?
  3. Check out a file, does it get the latest version? Nope. Have fun with the merge tool! That’s a feature, seriously they said it on the forum.
  4. Check in pending changes. Does everything get checked in? Maybe. Maybe not. It depends on how TSSC is feeling. This has caused us no end of frustration.

I’ve been /sorely/ disappointed with TSSC. I really wanted it to work, but it’s just a half baked beta product at best (steaming pile has also been used to dsescribe it). It’s too bad. I really like VS.Net 2005, but all the Team System crap is just weak and really expensive.
Source Safe may suck in it’s own way but TSSC has wasted so much of our time I think MS should refund some of the cost of those super expensive Team System licenses. When we get time we’re going to ditch it and try to find something we can rely on.

32

Thanks to the heads up from Alan:

–
Visual SourceSafe
Purchased from OneTree Software. Shortly after OneTree’s SourceSafe was released, Microsoft preannounced a similar application called Microsoft Delta, which failed to sell. Microsoft then purchased OneTree and renamed SourceSafe as Microsoft Visual SourceSafe.

And thus began the pain. Hard to believe this was in 1994 and SourceSafe has hardly changed at all since. That was over 10 years ago!

More here:
http://groups.google.com/groups?q=%22microsoft%20delta%22

33
  1. It has zero support for working disconnected, which is lame.

I wouldn’t say “zero support” but the Team System architecture is clearly designed around constant server communication. There is a way to do it, however:

http://blogs.vertigosoftware.com/teamsystem/archive/2006/07/03/2984.aspx

I want to see what I or another team member has checked out. My two options are a 3rd party tool (Version Control Sidekick) or the command line. WTF?

Yeah, it’s just not in the GUI. Join the club. Here, I’ll give you another one that’s easy at the command line but nonexistent in the GUI: you should be able to see all the tags for a file in the Source Control properties dialog for that file.

Check out a file, does it get the latest version? Nope. Have fun with the merge tool! That’s a feature,

The rationale is that getting latest on foo.cs could trigger a chain of dependencies and force an integration.

http://blogs.vertigosoftware.com/teamsystem/archive/2006/05/15/2755.aspx

That said, this is/was a stunningly unpopular design decision and I really wish they would give people the option to switch “get latest on checkout” on if they really want it.

Check in pending changes. Does everything get checked in? Maybe. Maybe not.

Haven’t seen this. We’ve had some intermittent, non-repeatable issues with Get Latest, but never anything with check in. I highly recommend posting on the forums if you can repeat the problem:

http://forums.microsoft.com/msdn/default.aspx?forumgroupid=5siteid=1