programming and human factors
by Jeff Atwood
Everyone agrees that source control is fundamental to the practice of modern software development. However, there are dozens of source control options to choose from. VSoft, the makers of FinalBuilder, just published the results of their annual customer survey. One of the questions it asked was which version control systems do you currently use, or plan to use, in the next 12 months?
The top 9 responses are reprinted here. I'm disheartened to see that Visual SourceSafe is still at the top of the list. If you are serious about the practice of software development, you should not be using SourceSafe. This isn't a new idea; plenty of other developers have been warning us away from SourceSafe for years:
There's simply no reason to use SourceSafe when there are so many inexpensive (and even free) alternatives that are vastly superior. The more customers I visit, and the more developers I talk to, the more I believe that SourceSafe poisons the minds of software developers. Note that I include our own shop, Vertigo Software, in this list.
SourceSafe was a perfectly adequate source control system in the late 90's. Unfortunately, SourceSafe was never updated architecturally to reflect modern source control practices. Even the latest version, SourceSafe 2005, absolutely reeks of 1999. And, to be fair, some of the same criticisms apply to CVS. CVS is no longer a modern source control system, either; it doesn't even support the concept of atomic checkins.
One of my biggest hurdles has been unlearning all the bad things SourceSafe taught me about source control. Source control is the absolute bedrock of software engineering. It's as fundamental as it gets. If my knowledge in this area isn't deep, wide, and fundamentally sound, can I really call myself a software engineer?
So, how do we learn modern source control?
Visual SourceSafe was most Microsoft developers' first introduction to any kind of source control at all. That's great. But holding on to SourceSafe's archaic source control conventions is doing more damage than good these days. Make the switch to Team System, Subversion, or any other modern source control system of your choice.
But whatever you do, please don't use Visual SourceSafe. Think of the children.
My post re Subversion wasn't in reply to Brieuc's post, though it might look like it, as it appears right after that post and just happens to be phrased as if it might be a reply! I was already typing it before Brieuc's appeared.
I think Brieuc is right that you shouldn't be relying on the computer to do an automatic merge for you. But that doesn't mean that an automatic merge is the wrong thing to do.
It depends on where the human input comes in. If you have good management which distributes relatively orthogonal packages of work to different developers, then each of them can work away on their own branch, and the merge process should be (hopefully) painless, or at least easily resolvable where conflicts emerge.
If you don't manage the process ahead of time, then merging can be a nightmare. Everyone's branches are stepping on top of everyone else's, and you can end up with merges that look like they've succeeded, but are actually semantic nonsense.
I think it's Steve Berzcuk who says that SCM is no substitute for management.
dudegalea on August 15, 2006 2:00 AM[branching and merging] is even dangerous in my opinion
Well, so is working with other developers. Don't confuse the tool with the problem..
My point is not branching and merging is dangerous. It is necessary in most real life software development projects. That being sayed, I strongly advocate manual merging after a long trip outside of the main branch.
As you point out, working with other developers is a complicated task, and in my opinion, it requires sometimes a bit of explicit synchronization and communication.
I feel like relying on a tool for this task even humans have a hard time to get done properly is simply an easy solution that enables us not to have to discuss with the busy guy at the other side of the room (or world) who is working on a different part.
Brieuc Jeunhomme on August 15, 2006 2:10 AMI've used Perforce for several years and couldn't be happier. They support all the main platforms and even some obscure ones.
I switched from SourceSafe years ago after getting sick of constant database corruption and slow performance. Ten years later, it looks like VSS still has the same issues. How sad that Microsoft won't fix or kill this broken product!
Finley Lee on August 15, 2006 2:16 AMOh, how I wish I could use VSS. We used to use it where I work and it was GRRRREAT!!!!!... compared to what we use now: ClearCase.
ClearCase : Source Control :: A barrel of rabid zombie vampire monkeys :: ANYTHING
steve minutillo on August 15, 2006 2:30 AMWe were using CVS but changed to Rational Clearcase about a year ago.
We've had nothing but pain since. It's slow, it's expensive, it has no decent reporting, it's user unfriendly, and it randomly spits up errors take take days of tech support to resolve.
Ray on August 15, 2006 2:32 AMI haven't had yet the pleasure of experiencing VSS, but I think it would be good to follow the advice of some pragmatic programmers ( http://www.pragmaticprogrammer.com/ppbook/index.shtml )* and use a _good_ source control system for your own work in parallel with VSS if you're forced to use it. It would certainly put your mind at ease, and if the dreaded moment should arrive you can at least be the clever one in the corner with the 'I told you so' smirk on your face (pleasant work environment be damned).
* they suggest doing this when your team doesn't use source control at all.. but it definitely still applies ;)
SourceSafe teaches developers bad habits: avoid branching, exclusive locks, easy permanent deletions.
On the exclusive locks point -- what process/tool are people using for group development of multimedia files? I coordinate a lot of non-technical people who produce multimedia software tutorials that don't fit the 'merge' metaphor.
Them not being able to exclusively lock binary files like these seems like a disaster waiting to happen.
I'm in a current search for a better solution than sourcesafe and would be interested in the input.
Bryan Zug on August 15, 2006 2:33 AMBrieuc, you start with the claim "I don't agree source control is fundamental to the practice of modern software development.", but then you point out potential problems with "automated merging", not "source control" in general.
Source control is more than just merging and branching. It's a centralized repository of all changes and states of the project since it was put into source control. It allows you to roll the project back to the exact state it had when you rolled it out to a certain customer. It tracks who made what changes, when. (Granted, this information can be misused, but it can also be important.) It provides an easy and supported way for multiple developers to easily work together, even on the same files at the same time, and defined mechanisms for resolving the conflicts.
And perhaps mo$t importantly of all, "the source code itself is checked out on every programmer's hard drive -- I've never heard of a project using source control that lost a lot of code." - http://www.joelonsoftware.com/articles/fog0000000043.html
This isn't even a complete list of benefits, which would really be a waste of time to type into a comment box.
I tend to agree with you about not doing long term merges automatically (mitigated by the fact that if both trees did good unit testing and the post-merge product runs all the unit tests, it's a pretty good sign, but it's a good bet if you're not even using source control you're not using any automated testing either... yeah, technically unrelated but I'll take that bet), but you're chucking an awful lot of great stuff out just so you... errr... won't have a maverick developer do an automated merge against your will? Seems like there's better ways to enforce that than to not use a vital tool.
Jeremy Bowers on August 15, 2006 2:42 AMThem not being able to exclusively lock binary files like these seems like a disaster waiting to happen.
Right. Share-Modify-Merge only makes sense if the file types you're editing aree fundamentally mergeable. Text files are mergeable; MP3 files, not so much.
A modern source control system defaults to shared checkouts, but it also gives you choices for these unmergeable file types:
- shared checkout (share-modify-merge)
- write lock (guaranteed first check in)
- read lock (exclusive lock)
In your case, the designers would place write or read locks on the binary files they're checking out.
Jeff Atwood on August 15, 2006 2:47 AMYes Jeremy, I 100% agree with you on the central repository part. But this is old stuff, it doesn't require the latest source coutrol system with a bunch of nifty features. Any source control system has this very basic functionality.
And any source control system is sufficient for automated builds and unit tests. No need for the last hype system.
My question is only about the benefits of new systems. What feature do they have that really improves the final product or its delivery time?
Brieuc Jeunhomme on August 15, 2006 3:08 AMI thought Team System utilzies VSS 2005 as its backend for source control.
It is actually based on SQL Server 2005. There are web services that provide the interfaces into it, making it very extensible.
Here is a link to a detailed FAQ on TFS's capabilities, including what "features" from VSS were left out, how to Migrate from several competitive products and more:
http://msdn.microsoft.com/vstudio/teamsystem/support/faqs/foundation_techfaq/default.aspx#version
Also, check out Brian Harry's blog for cool info and updates. http://blogs.msdn.com/bharry/
Angela Binkowski on August 15, 2006 3:33 AMSubversion supports exclusive locks as well as non-exclusive.
@Briec: Keeping the discussion to VSS vs Non-VSS, non-exclusive locks is a key feature for improving delivery time.
You might say a shared file store gives you that, true. But it doesn't give you automatic conflict detection when checking files back into the central repository, which is more important than automatic merge.
Haacked on August 15, 2006 3:35 AMWe 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.
Oran on August 15, 2006 3:38 AMBryan 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.
C-J Berg on August 15, 2006 3:51 AMnot 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
Jeff Atwood on August 15, 2006 3:55 AMNot 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.
C-J Berg on August 15, 2006 4:27 AMTortoise 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% :(.
Fred on August 15, 2006 4:32 AMC-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 :(
Brian
Oran on August 15, 2006 4:59 AMhaw 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..
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.
Alastair on August 15, 2006 6:03 AMThankfully 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!
Teman on August 15, 2006 7:15 AMWhile 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!
Brian on August 15, 2006 7:48 AMOh...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
Brian on August 15, 2006 7:50 AMJust 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.
P.S. I do NOT consider that I've been poisoned by it!
David on August 15, 2006 8:48 AMI 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.
Ted on August 15, 2006 9:15 AMIf you use SourceSafe, are you helping the terrorists?
Phil on August 15, 2006 10:41 AMSource 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.
Alan on August 15, 2006 10:42 AMTeam 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:
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!
Jeff Atwood on August 15, 2006 12:07 PMWARNING 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.
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
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
At our corp., we were using pvcs which sucked but was reliable. Us devs wanted to swtich to VSTS but we were told to we had to use Serena Dimensions which is so difficult to use that we are considering just seriously to go to VSS2005 because most of the devs are familiar with it and it does work (most of the time). Costs of VSTS and maintenance of Subversion are turns off for upper mgmt. But I'm going to look at Subversion again.
Sam on August 15, 2006 12:48 PMSourceSafe is a real pain in my ass. Its integration with VS is shite. I keep getting errors and weird dialogs with messages like "You should close this program now" and "Could not perform operation". What operation? WTF are you doing to me? And on top of all this, SS decided to revert every file I modified to a version that was a week old. Imagine sitting down and pressing a key, only to see sixty plus hours of work evaporate before your very eyes. No warning, no "Are you sure you want to do something incredibly stupid?". Just WHAMMO you're fxord. For some unknown reason it also decided to push my current work into a recursed version of my development directory, which is the only reason why I'm not swinging at the end of a rope right now. So, in addition to SS, I have a regular backup running multiple times a day. I'm definitely checking up on some of these alternatives.
mcgurk on August 15, 2006 1:30 PMI recommend SourceGear's Vault. We have been using it for the last year and a half or so with no complaints. The only thing we've had a problem with is some flaky stuff in VS2005, and both Microsoft and SourceGear are pointing at each other to blame.
Another nice thing is that you can set it up to have edit schemes like VSS(check out exclusively - edit - check in) or CVS (check out - edit - merge). It's up to you. I like VSS's edit scheme personally. It's good for small-shop development.
Branch merging is fairly painless in Vault also!
Marty Thompson on August 15, 2006 1:36 PMAbout 5 or 6 years ago, I was using SS one lunchtime to check out a project. Usually it had worked fine, but this particular time it failed in a really odd way. Some of the directories had completely the wrong contents in them.
At about the same time I was noticing this, other developers started complaining that the read-only copy of the source tree (which was updated by script every lunchtime automatically) was suffering the same problem. Random directories contained the wrong files.
To cut a long story short, I discovered that the automated checkout and my manual checkout were conflicting with each other. If the script happened to get in first with its request for a directory, then my request would checkout *that* directory, not mine. So if the script was asking for fred, and I was asking for bill, I would get fred!
And vice-versa. So when the script and I were both getting the entire source tree, each directory was a race to see who would get in first.
It was easily fixed. I had made the mistake of getting the script to run with my credentials. Once I gave it its own SS id, the problem never happened again.
But it did mean that I was careful from then on never to be checking out twice from the same repository at the same time. Not even from different PCs.
dudegalea on August 15, 2006 1:37 PMI thought Team System utilzies VSS 2005 as its backend for source control. Am I mistaken?
skain on August 15, 2006 1:46 PMI thought Team System utilzies VSS 2005 as its backend for source control.
Perish the thought! Team System uses Team System Source Control. It's a "from the ground up" rewrite. Totally new, very modern, all HTTP based.
You can download the free client and try Team System source control yourself @ http://www.codeplex.com/ . CodePlex is kind of like SourceForge or GotDotNet, but using Team System as the back-end:
http://blogs.msdn.com/robcaron/archive/2006/05/23/605555.aspx
Jeff Atwood on August 15, 2006 1:51 PMWell, I am probably the only one over there, but I don't agree source control is fundamental to the practice of modern software development.
In fact, I don't see much benefit in complex source control systems. Of course, we need a central repository that enables developers to integrate their code in the common tree, to run automatic builds and nightly tests etc. But I see no need for complex branching and merging systems.
When someones works during two weeks with no merge, I really feel like once the job is done, it is not a computer's task to figure out how to merge the whole thing and change the model consequently. It is a human job and people will have to communicate and to spend some time on the operation if it has to be a success. An automated system may give you the illusion it worked, but well, deep changes require careful human attention.
When it comes to the ability to dig in older code, I never found any problem that couldn't be solved with a bunch of daily tarballs of the 7 last days and a tarball of each release.
I recently switced from CVS to subversion, and at least, subversion doesn't stay in your way with tags that prevent you from doing what you need to do, but hell, I really don't see any clear benefit of branching mechanisms. It is even dangerous in my opinion as it will let you believe everything went well and you don't have to pay attention while you should take some time to merge things properly. And when it comes to interaction with non text based tools like an UML modeler, the nightmare begins.
Brieuc Jeunhomme on August 15, 2006 1:51 PMSubversion looks great, but unfortunately it still doesn't support automatic repeated merges, in that you have to manually track the merges you have already done in order to avoid re-applying changes. (I just checked the manual, and it says that this is still the case.)
cvsnt handles this quite well, although it is clumsy in other ways.
arch (or tla) looked promising the last time I tried it a couple of years back. The big drawback was the hideously long path names which blew right through Windows' 256 character limit; this put a dampener on its appeal. Some of us on the arch list tried various approaches to fixing this problem (including hacking Cygwin to support 256 char paths using the Unicode \\?\ hack, or 'compressing' the directory names).
arch handled merges brilliantly, including star-merge. It was also great for cherry-picking other people's branches.
dudegalea on August 15, 2006 1:52 PMAnother worth taking a look at is Mercurial. I am loving it. :-)
lukem on August 15, 2006 1:54 PMLook at the timestamp...
How on earth did you post this before anybody's comments were posted (i.e. Tomorrow)?
Brian Sherwin on August 15, 2006 1:57 PM[branching and merging] is even dangerous in my opinion
Well, so is working with other developers. Don't confuse the tool with the problem..
That said, if your team never needs to branch, then don't branch. You can certainly do the old SourceSafe style "copy to a new, unrelated tree" routine.
Jeff Atwood on August 15, 2006 1:57 PMJust use Perforce, people! Fast and powerful, utterly reliable, very flexible (disconnected editing directly on the file system is possible), excellent GUI tools, and free for up to two users.
Chris Nahr on August 16, 2006 2:01 AMThe only time when I use a 'Get Latest Version' check out, with ClearCase, is when I check in and sync after, therefore getting the morning build's sources. Or you really need something that someone has checked in during the day, again later than your sync.
If you don't do this, I can see reason to get 'latest version' at least by default, in check out. But it *is* available in ClearCase
Btw, in 1999 microsoft internally used to use their own source control, SLM, while selling VSS to the outside world.. I assume they must still be doing something like that.
ulric on August 16, 2006 3:04 AMFor anybody already using subversion I'd seriously recommend taking a look at svk; it can handle offline commits to local branches, does decent automatic merging (including star merging), when it *does* find a conflict you can invoke the external merge tool of your choice and it operates happily against standard subversion repositories. We really couldn't live without it.
Matt Trout on August 16, 2006 3:57 AMTeam System simply isn't made for half your developers eschewing workstations for beefy laptops. There are workarounds, but svn supports that scenario better. (Perforce also seems to, but $$$.) Taking forever to read everything each update is a pain, as well as tortoisesvn's lack of unicode support (3rd party uis can be used but aren't as straightforward as its own), but eh.
One of the things that has been wildly helpful in a couple of projects recently is the ability to copy/move files in from other projects as a very fast poor man's switch and have them instantly recognized as changed or correct. Normally it's insane and stupid, but as a means of finding bugs caused by integrating several independant projects (not branches), keeping a half-dozen revisions of each to test against handy, I'm not sure how else to go about it.
Foxyshadis on August 16, 2006 4:38 AMTeam System simply isn't made for half your developers eschewing workstations for beefy laptops. There are workarounds, but svn supports that scenario better. (Perforce also seems to, but $$$.) Taking forever to read everything each update is a pain, as well as tortoisesvn's lack of unicode support (3rd party uis can be used but aren't as straightforward as its own), but eh.
One of the things that has been wildly helpful in a couple of projects recently is the ability to copy/move files in from other projects as a very fast poor man's switch and have them instantly recognized as changed or correct. Normally it's insane and stupid, but as a means of finding bugs caused by integrating several independant projects (not branches), keeping a half-dozen revisions of each to test against handy, I'm not sure how else to go about it.
Haha, your blog need some atomicity; I just got a post error about renaming permissions that I presume means it was being updated simultaneously. :p
Foxyshadis on August 16, 2006 4:39 AMMy project is using subversion and I must say that it is truly amazing. I have not used any other version control software before but I have nothing but good things to say about subversion. The addition of tortoises svn makes life easier as well.
Eric on August 16, 2006 5:58 AMJust my $0.02 to add... Even if your a solo developer, you need to use source control.
I currently use SourceGear:Vault. It's free for a single developer. I believe Perforce is free for a single user also.
And I'll second the opinion on Eric Sink's articles. Well worth the read.
Eric D. Burdo on August 16, 2006 6:03 AMYou may as well call this post "Visual Source Safe Considered Harmful" and get all computer science-y about it.
Anyway, my progress: CVS - VSS - XDelta (!) - Subversion.
piyo on August 16, 2006 6:58 AMYes, Chris Nahr is right, it's more between Subversion (free) and Perforce (commercial but fair priced)*. While Team System isn't bad, it is still far from where Perforce stands today. Sure, TS most likely has a promising future, but so does Perforce, and it’s great already.
With Perforce you’ll get a proven, enterprise-ready solution with great support, something many companies cannot do without. It’s also easy to use, stable, multi-platform for those who need it, and it performs really well. And you shouldn’t overlook its integration capabilities.
Subversion may not yet be as feature packed as Perforce, and it doesn’t perform as good on large projects. Yet I prefer using Subversion+TortoiseSVN in many cases, simply because it often does everything I need it to do (although I’d like to see it track branches), and does so really well. Not to mention it’s free, easy to use and very stable.
Foxyshadis: Look at the release notes for the soon to be released TortoiseSVN 1.4 (currently released as RC1); TortoiseMerge now supports UTF-8 and UTF-16. And you can always configure it to use a custom merge tool such as Araxis Merge, UltraCompare or Beyond Compare.
*) It's not that simple of course, since there are many specialized products on the SCM market. But these two are a good fit for most development shops.
We manage *everything* in subversion here. Not only source code, but everything. Well, our accounting system is in Quickbooks, and that's not easy to version - but everything except Quickbooks and e-mail (Outlook / Exchange) is in subversion. All internal documentation, all client field notes, everything.
It's really cool to make all my field notes on my laptop, and then just update through subversion when I get back to the office - all the documentation just flows to all the other people in the office that need it. We keep about a dozen repositories running, and not everyone mounts (or needs) all of them.
Once I got over installing apache and all the Active Directory hooks for Apache, the actual install has worked awesome. I scheduled a SVN "dump" for once a day, and keep 5 rotating backups of the fully dumped repository.
It's awesome. Just make sure to buy some big-ass disks - Our storage requirements grew by about a factor of 4, but it's worth it.
David on August 16, 2006 8:17 AMour team have been using subversion for about a year now (all asp.net + c#) and it's so perfect. it integrates into our workflow very well and is easy to get new people to learn and start using.
jonezy on August 16, 2006 9:17 AMJeff, this is somewhat off-topic. But once upon a time I did some UT for a team system predecessor. At the time, it included requirements tracking and bug tracking, at least the ability to tie the two together with the source. (e.g. You check in a change and tag it as fixing a bug which marks the bug as clear.). I had this a long time ago with Perforce and Bugzilla but I don't see that in Team System anymore. The MS site for Team System is useless for discovering what the product can do, do you have any better references? Do the features I mentioned exist anymore in TS?
on topic:
David: re VSS + team offsite - tick tock tick tock, don't let that DB get over 2GB. Don't defrag the volume the VSS DB is sitting on too often. ;)
An entire post could be created on the horrible feature of Sourcesafe that is "Shared Files". Oh dear god. Sounds great in theory, in reality, it leads to so many screwed up builds it's not even funny.
Alex on August 16, 2006 10:52 AM- "I don't mean to pick on SourceSafe here. It was a perfectly adequate source control system in the late 90's."
You're kidding, right? I first had to us VSS in 1998 when consulting for a client who had a slightly different version of their software tailored to each customer. My first job was to automated the build process. I can't begin to tell you how much pain I went through with VSS and its (lack of adequate) command-line control!
The best system I've used is IntaSoft's AllChange, which combines source control and defect tracking/workflow management. The Win32 UI was a bit ropey last time I used it (2001, although it was an old release then), but apparently this is now better (and there's now a web UI for people who find such things useful).
My current employer (since Jan 06) is using Subversion/Subclipse/TortoiseSVN and I'm finding that, on the whole, it's not a bad solution. It does suffer from the usual open source issues in that when it works, it works brilliantly; when it comes across a problem it takes me ages to figure out a) what went wrong, b) how I can fix it. Doubtless I'll get better at a b as I get more experience, plus I've got a copy of Garret Rooney's "Practical Subversion" kicking around somewhere, which seems a reasonably reference.
Rob on August 16, 2006 1:13 PMWe are currently using Borland Starteam, and to be really honest: I think it sucks.
And seeing the graph above, I'm not the only one with this opinion.
I'd rather work with VSS ('99-style).
The Starteam interface looks even more pre-historic than the old VSS.
Although everything in the interface is supposed to be configurable, I can't figure out where to find those settings (or what they do). When you work with multiple development teams on the same server, you will see all developer names in all project (when assigning tasks for example, which creates a dropdown with about 50 names where I need only 5 names).
Starteam doesn't do automatic logon based on your windows logon (so you'll keep on typing passwords)
And the worst of all: they change the meaning of "get latest version", "check in" and "check out" between the Starteam interface and the Visual Studio integration.
I haven't had a chance to look into VS Team System, but I hope it is much better. Concluding from all comments above, I would also invest some time into SVN.
thijs on August 16, 2006 1:22 PMIn my opinion, the two best options right now are Subversion and Team System.
On the Team System side, bear in mind that Team System isn't *just* source control. It's also work item / bug tracking, build server, unit testing, project metric reporting, and a whole bunch of other stuff too.
Basically Team System is like the whole suite of open source tools in one box. The tradeoff is consistency/integration vs. choice/configurability. I'm not saying one is better than the other, they're different solutions for different audiences.
I did a little interview with Patrick Cauldwell and Scott Hanselman on this very topic:
http://www.hanselman.com/blog/HanselminutesPodcast21.aspx
Direct download:
http://hanselminutes.com/default.aspx?showID=30
VisualSVN, providing seamless and reliable Visual Studio integration for Subversion makes it even more attractable now.
http://www.visualsvn.com/
Source Control: anything but ClearCase is the way I would describe reality. God damn that piece of software.
Martin J Steer on August 17, 2006 2:26 AMI have just recently began using source safe at my new company. The place I worked at before used SourceGear Vault. I prefer source safe a LOT more. Vault had so many issues it drove me crazy. I'm not saying sourcesafe is the best, but it's the best I've used. I would be interested in looking at other solutions, though.
Adam on August 17, 2006 3:25 AMThe people in my former company were using VSS. When I arrived, I complained about the tool (the UI is a nightmare, it is unstable, it is way too easy to lose data with it and I just hate the echeckout-edit-checkin work style) along with other developers. People were so wary of VSS that they used virtually no SCM at all, preferring good old "one or several backup(s) a day" techniques.
The result is that we switched to subversion + TortoiseSVN, and that people started versioning again. And believe me, we all felt a lot safer.
I've been using SourceSafe for about 8 years. Never really had a problem and the integration with VS.NET is sufficient.
But I don't do branching.
Every product has it's own unique set of problems.
Me on August 17, 2006 5:25 AMAt a former place of employment, we used VSS.
We replace the icon with a custom one. The VSS icon covered in flames. And the new name? TorchSafe.
It just wasn't reliable.
Eric D. Burdo on August 17, 2006 6:11 AMI've used SourceSafe, Vault and since a few months I'm forced to work with that atrocity called ClearCase. I'm sure it really has all these powerful features and all, but where I work now they use it just like sourcesafe... none of the branching and stream functions are ever used. So you're basically stuck with a *extremely* slow sort-of-network-share-for-all-your-sourcecode that happens to do versioning... and hysterical locking.
Of all these tools I still like SourceGear Vault the best. It does branching very well, as well as labelling and it has a great interface which immediately shows you the files that have changed in the repository vs. your local drive... it's really easy to see who's checkout what. I love it.
And SourceSafe... ah well... it's still better (faster) than ClearCase.
D. Appel on August 17, 2006 12:05 PMClearCase is a Rational product - 'nuff said.
LOL! I second that. It's no wonder Rational and Lotus were acquired by IBM; their products’ user interfaces are all so bad it hurts (with few exceptions).
VSS is not 1999 - it's worse than that, it's 1993.
Take the "add new files" dialog in VSS. Please, take it. I don't want it. It's not 1999 vintage, it's 1993. It's windows 3.1 style, and doesn't play well with long file names at all.
We knew very well by the late 1990s that VSS had serious design problems that will corrupt data every now and again.
I used VSS for years with never a corruption. Unfortunately I am now not able to learn any other source control system.
Always used exclusive checkouts. This works really well if you only have 2 or 3 developers.
Thanks everyone for all the excellent "reviews".
We are currently using Borland Starteam, and to be really honest: I think it sucks.
Amen to that. We used to have it here, tossed it for subversion. How can a source control system have a status of 'unknown'? I mean, at the end of the day, isn't not knowing 180 degrees away from the purpose of a source control system? Bah.
Subversion isn't perfect, but using it in conjunction with Trac is working out well for our team.
Ed on August 18, 2006 8:35 AMCosts of VSTS and maintenance of Subversion are turns off for upper mgmt. But I'm going to look at Subversion again.
Maintenance of Subversion?
Subversion is not that high maintenance, especially if you're using FSFS (which is now the default backend), while it's true that it's a bit slower than BerkeleyDB, the stability issues and recovery needs get drastically lower.
Now if you want high maintenance cost, try Rational ClearCase: I think that most people who (rightly) bitched about ClearCase had something missing in their experience: ClearCase *requires* a team of full-time admins to make it work somewhat smoothly. And I'm not joking here.
Anyway, the top picks in centralized version control are SVN and Perforce in my opinion. Haven't tried SourceGear's Vault though.
Masklinn on August 18, 2006 1:18 PMI worked a lot with CVS but moved slowly to Subversion (and SVK). A good move as it solved the majority of drawbacks from CVS I had.
The proprietary Visual SourceSafe is a real pain and must avoid at all cost. RCS is working better than SourceSafe ;-)
The dynamic duo Subversion and SVK (http://svk.elixus.org/) is really efficient.
"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."
Maybe they stored it into Delta or MSVSS? :D
I did work with VSS for 2 years, than I had to switch to CVS. At first when I learned there are no exclusive check-outs for source code, I thought "This can't work, how can it?". After studying the inner workings of CVS and reading some tutorials I just figured I was blind, and never ever really wished to go back to VSS for no reason (especially not for exclusive checkout and corrupted database). Using WinCVS allowed me to work in easy-to-use GUI and that was it.
Now I'm almost a year working with Subversion, and when we do have some problems with it, it's usually due to someone not understanding how to work with it properly and raping his own work trying to avoid normal edit-merge-commit workflow. If you have careless programmers who don't get the idea, there's probably no good solution, but if your team understands the basic principles, I think the SVN is one of best solutions available. Especially considering the price, but so far on our small projects it gave us everything what we needed and no crash or corruption at all.
BTW TortoiseSVN is *a must* (I have no experience with SVK). Other free GUI SVN clients are far behind tortoise. For basic check-out/update/commit feel free to try RapidSVN, if you like "commander-like" GUI, but keep the Tortoise around all the time, because when it comes to branching/blaming/restoring/reverting/etc.. Tortoise saved my ass many times.
Ped on August 20, 2006 9:10 AMI agree with the downsides to Source Safe. However, I've had the misfortune of working with a source control system that is even worse than VSS: JediVCS. It doesn't support branches. It stores absolute paths in the repository. Really, it's just awful. I'm amazed that it came in 4th in the survey!
We'll be migrating to subversion very soon ...
plalonde on August 21, 2006 8:26 AMAnother good book recomendation, with an obvious Perforce bent, but really about how to use source control/software configuration management systems (SCM) in the large is _Practical Perforce_ by Laura Wingerd. I've been very pleased with it, and consider it mandatory reading if you're using Perforce, in order to get the most out of it.
Dan Moniz on August 21, 2006 9:20 AMI've been using subversion on gentoo linux/apache for 2 1/2 years - berkeley db backend. I must say the maintenance time for it has been minimal. For the first couple of months it took a reasonable amount of my time (I was the guy maintaining it) but once I got used to it and the various issues that can arise any problems became very quickly fixable. Indeed, I don't think I've had to do a svnadmin recover on any of the 7 or 8 repositories we have for at least 6 months at this stage. Admin time is _not_ a big deal for subversion - take the time to learn it and it is trivial to work with. It's not comparable to the hideous monstrosity that is VSS.
den on August 22, 2006 2:54 AMHi,
IMHO, you are looking at the problem from a wrong side. The problem is not seeing that the system isnt optimal, the problem is that the switching effort is higher than the benefits for most shacks apperently.
You motivated me to write about that btw - so enjoy here:
http://tamspalm.tamoggemon.com/2006/08/22/why-crap-can-rule-the-world/
Best regards
Tam Hanna
I've used SS, ClearCase, CVS, SVN, and Perforce, almost exclusively on Windows, developing for non-windows platforms.
SS was okay for our team (~12 developers), but was unreliable, and used lots of space. Artists were pretty unhappy, because SS large binaries don't play well together.
ClearCase was a nightmare to administrate, we could only do dynamic views (which meant every compile grabbed everything *over the network* and no offline work). I would never want to go back. We had to use it, because our company had paid for lifetime licenses.
CVS I only used briefly. I found it okay, but a little primitive.
SVN (+ TortoiseSVN) I'm *very* happy with (but I'm not the admin!). It does everything I want, smoothly, no problems so far. We're not doing big branching/merging. The weak tags support I didn't like, but tracking the revision number is almost as good.
Perforce I've only used personally, and then in only limited forms. I'm very impressed with what I've seen (and friends at my old company (that used to use SS) are also happy with it). It's reasonably priced, and powerful.
For me, apart from reliability (obvious) things like atomic check-ins, exclusive or not check-outs, and off-line working are non-negotiable.
I'm not tempted to try out MS Team thingy. I'm becoming increasingly annoyed with their whole dev suite (although I only have 2003, not 2005), and don't see any point in supporting them, if it can be avoided.
Ben StJohn on August 23, 2006 8:34 AMI would be curious to hear about people's experiences with BitKeeper or Alienbrain.
Anyone? Bueller?
Ben StJohn on August 23, 2006 8:37 AMI've used Clearcase, Perforce, CCC/Harvest, plus many rcs derivatives. I'd take Clearcase over anything I've used. I don't really understand why so many people have trouble with it, though I admit the GUI tools are old and ugly. I have aliases for all the commands I use (on Linux and Solaris). I haven't heard good things about Clearcase on Windows, but since I only use Windows to play games I couldn't say for sure.
I would only use Clearcase with dynamic views, though. Perforce is better if you're developing offline.
By the way, Clearcase isn't a Rational product. It was originally developed by Atria. Then the ownership went
Atria - Pure (Pure Atria) - Rational - IBM.
They haven't updated the GUI tools in a decade, and IBM doesn't seem to want to do anything with it. I think they were mostly interested in Rose when they bought Rational, which is like throwing away the wheat and keeping the chaff.
On the plus side they've patched it enough that it works reliably with Redhat EL 4.
Eric on August 24, 2006 11:55 AMLike some other posters, I would like to warn people away from Borland StarTeam. It blows chunks in the worst possible way. I made the mistake of buying and using it a few years ago. It is possible, for example, to have two distinct files with the same name in the same folder! Crazy, yes, but StarTeam considers this a feature. Honest.
Stay away. Far far away.
Subversion, on the other hand is brilliant! Highly recommended.
Stephen Ansell on August 29, 2006 11:20 AMI dont like systems where stubs in the filesystems keep track of things locally (CVS and Subversion) . They work ok for files but once you move a directory it creates havoc . You have to remember you cant do these dir moves in VS2005 - this is a real pain .
Surely a source control system should be simple so we can focus on design and coding ( which is hard enough) , if it requires you to read a manual its too much.
Regards,
Ben
Ben on September 12, 2006 6:07 AMI dont like systems where stubs in the filesystems keep track of things locally (CVS and Subversion). They work ok for files but once you move a directory it creates havoc. You have to remember you cant do these dir moves in VS2005 - this is a real pain.
I'm went from VSS - CVS - SVN and each step has been a major improvement in productivity AND happiness. But your quote does highlight what I consider the single greatest weakness I've had in subversion (which was also bad in VSS and CVS in the sense that getting history properly tracked was not even reasonably possible).
What I would like to see a subversion client add is the option to have the whole .svn/_svn set stored as a subdirectory off the top level directory only, so that when you tie a local folder to a repository location it adds just 1 folder for all managed client information ... which would then allow you to use any and all OS and APP level tools to mess with your working copy and still have the accounting information be correct. Obviously, just like many types of merging, when you move a directory you are going to have to tell the SVN system before the commit ... because how can it know if the 2 new "resources" folders added are copies of the existing one, moves, or new independent folders. But the way I would like to see it work is: Show the missing folders and new folders with status (like it does), and allow you to run a command to tell svn how the 2 are related before you commit (basically and after the fact svn move, or svn copy).
I've don't think ANY offline source control system handles that case right anyway, but that's no reason not to move subversion a step closer to perfection.
To the person who said "all systems have their own unique problems" ... while that's true, it is still true that the worst systems (VSS) are many times more problematic than the best systems (SVN, Perforce).
rationalmonkey on September 22, 2006 10:19 AM"If you are serious about the practice of software development, you should avoid SourceSafe"
I'm glad that your going to pay for our developers licensing for an integrated source control product. Where can I send the invoice so you can pay it for us?
Bob on September 23, 2006 8:05 AMWhere can I send the invoice so you can pay it for us?
If you're under budgetary constraints, you can download Subversion for free:
http://subversion.tigris.org/project_packages.html
Of course I won't pay for the *training* your devs might need to "get their minds right", but there are a lot of good resources out there on SVN.
Jeff Atwood on September 24, 2006 2:38 AMI don't think anyone has mentioned the issue of heterogeneous environments here regarding the "Team System vs. SVN" discussion. The company I work for is large and becoming larger, and is finding itself with a heterogeneous computing environment. Some Linux OS'es, some Oracle DB's, but still mostly SQL Server and Windows. What happens when someone from the Linux/Oracle world wants to check in their code into the repository with Team System? Does TS have any cross-platform client tools that would allow a Linux user to check in code?
What happens even when someone on the Windows side wants to use source code control with something they don't want to put in their Visual Studio solution? I guess they could use a command line, but I don't know of anything quite as nice and generic as TortoiseSVN.
And by the way, we're using SS with a database of 3-4GB. Sometimes I feel like a volcanologist on some small island in the South Pacific. All of the islanders' point to their local witch-doctor who says the volcano will never erupt, even though my seismometer is taking some very interesting readings...
Dave Markle on December 27, 2006 4:31 AMI'd like to point out that Perforce also has a special free license for open source developers.
http://www.perforce.com/perforce/price.html (under Educational licensing)
I thought that was pretty swell of them.
I'm glad that your going to pay for our developers licensing for an integrated source control product. Where can I send the invoice so you can pay it for us?
Don't be a childish idiot.
If you polled the large corporates, one would hope that the results of the poll would be different. I noticed low Serena PVCS and IBM Clearcase and zero Computer Associates AllFusion Harvest Change Manager scores. I'm not sure who VSoft polled, but Clearcase and Harvest ( http://harvest-faq.com ) have their own build tools, so perhaps they weren't targeted in the poll. Not saying these 3 are better than some of the free ones, but they would have to be better than VSS.
harvestguy on February 26, 2007 4:29 AMWhen one considers how prevalent Clearcase is, I'm amazed there aren't more Clearcase hate stories. Don't get me wrong here, I advocate Clearcase and administer this and the other Rational tools. Nobody likes change, and unfortunately some sites adopting clearcase get some person who has no understanding of CM who has just been to a Rational "UCM is the answer" course and then tries to go the full hog with the engineers off the bat.
Do they have problems? Yes, of course they do. Does the software you create have problems? yes, of course it does. This can be said regardless of the tool.
From what I have seen of perforce, I like, but I would miss the version tree and dynamic views in particular far too much. I also haven't seen perforce reported as an enterprise level implementation, so I would be wary for enterprise level CM.
Regarding the administrative overhead, I've been through this. If you take a company where each project has their own implementation of the tool, or worse, a separate tool, they will say they have no admin overheads. Then you investigate and you find that some poor sode is doing some form of admin with the tool. The admin overheads are still there, they're just hidden.
All of these tools are designed to help solve what can be an extremely complex problem. I have seen companies that allowed developers to copy, paste, add to source control for product variants and then find they have 12 completely different codebases for the same product with no hope of ever bringing it back together again.
As for SortaSafe, well I used it as a developer and kept getting defect regressions because someone else was overwriting my changes. I've also encountered a company that found that when S$afe went cacti, they found the backups hadn't run for 3 months. They had one poor sod working for 6 months trying to manually reconstruct deltas and even then found that they couldn't reproduce the code for some products. The result, a complete rewrite of the products concerned.
Reliability wise, well, if you're forking out big bucks you deserve reliability. I have seen Clearcase continue operating without file corruption on hard disks that are dying - on the same stripe. I don't see any Relational Database system handling this situation too well (including team system).
Do the UCM Guis suck? Yes. Does UCM make assumptions about all files being mergeable? Yes. Can you effectively use the tool if you're aware of these things? Definitely.
I guess what I'm getting at, is that these tools can be like a gun - regardless of who makes them or the product. I can see a lot of damage being done long term if you used say the one SVN implementation for a company of say 30,000 people, for instance.
Some of the arguments shown here can be ridiculed, but shouldn't. One thing I do know about all of these tools is that there has been very few technological advances that I have seen since Atria Released Clearcase and Clearcase Multisite. An exception would be SVNs approach to versioning, which I don't agree with, but it was a good show of lateral thinking, I must say. A lot of the rest of it seems to be the same S*( in a different package IMHO.
One more thing, I would take using Winzip over Sourcesafe any day. At least when you go back your files are in the location they originally were in!
Also, regardless of the tool you will allways have the fanatics and the gripes and so forth. Evaluate and make up your own mind, but don't just get a junior developer to do the implementation.
Well, you have to see that ClearCase do have a lot of different flavor, I worked on two different project with ClearCase BASE, with full-time competent admin, and it's really wonderful, the admin tend to do a little bit too much for us, so I'm the only one writing my own config spec, but otherwhise, it's really cool.
But between these two projects, I worked a few month with ClearCase UCM, with a, say, less competent admin...And this was the kind of bad experience I read here...
I don't have any idea of the cost of the whole thing, but my huge firm seems to think that it's well worth it, and I must admit it makes us work quicker and somehow with less stress...
At first I thought version control was overkill since at the time we were just 3 developers in the same room who didn't even work on the same projects. But the lack of version control *was* the reason we didn't work on the same project.
We started with CVS which in the Windows environment is rather crappy. At one point we added a new developer in a remote office who needed to access the repository on our file server. The update process basically ran all night. This was more a network problem than a CVS issue but never the less painful.
We switched to Subversion and it took minutes to update thru a WAN. The lightier bandwidth requirements is its best feature. We currently are planning on connect 3 remote offices together and using CruiseControl.NET to support automated builds and testing.
Its true that every system has its warts and subversion has a few. (How come you can edited a tagged version? Why come files produced by svn:externals cannot be setup to be readonly? How come log commands on the trunk don't report edits to branch version when you currently are switched to a branch?) I think I understand why these are hard issues to fix. Or at least consistent with the design.
IMHO, the most annoying issues are ones where there are obvious problems but the product is not being actively developed so there is not hope to ever see it fixed.
BTW, I think Jack's defense of ClearCase was admirable but I wouldn't recommend any system that requires an administrator. If you hate the system good luck getting rid of it. Most likely you will have an administrator tell you its great even though your experience tells you differently. I haven't used ClearCase before but it the same with Lotus Notes or VSS or any big system (subversion is a small system)
Steve on March 23, 2007 4:27 AMFair Call steve. Of course, for the sized projects I work on I wouldn't choose a CM system that doesnt' require an administrator (if that makes sense). I have seen a lot of small scale implementations that have been stuff3ed up because there is no co-ordination or management of the changes. In fact I have seen one company that had to redevelop a product line because their codebase was in such a mess.
Did I see someone up there mention Microsoft TFS as modern? :-) In that case, Clearcase is modern, too. ;-) I believe TFS is nothing more than something similar to Perforce under the covers. The only quote unquote, modern, source control tool I've looked at was Accurev and it did just win its second Jolt Award. Most source control will do if you don't have to worry about process, parallel development, branching off the mainline so to speak, managing an offshore team or collaborating on shared projects. But please don't try to use a free or RCS-based tool for these more complex problems (like using swiss cheese to hammer in a nail).
Josh on April 26, 2007 11:17 AMI've been using SS for a while, but not because I wanted to, I had to. And I must say it freaking stinks! When I get the chance I'm switching to SVN, which I've also used and it worked great. Every time I'm forced to use SS I feel violated, so take the advice - run away from it.
T1TAN on July 26, 2007 8:07 AMMichael Bolton's article, "Visual SourceSafe Version Control: Unsafe at any Speed?" has moved to "http://www.developsense.com/testing/VSSDefects.html". The link given in the original post is no longer valid.
Google uses Perforce. http://versioncontrolblog.com/2006/12/03/perforce-as-the-version-control-system-at-google/
Hillbilly on August 5, 2007 9:10 AMDon't know what all the fuss is about. Any seasoned coder gave up VSS, CVS, etc. years ago. One corruption is enough. Most switched to ZIP, touch and diff - what do you need all this other stuff for? Arse biting rubbish, all of it. Period!
And as for branching/merging - give me a break PLEASE! That's not source control, just mental masturbation pretending to be management. Never necessary (convenient as a sop to someone else's woolly headed thinking maybe). Start this silly game and source code control becomes design out of control instantly.
Beach Comber on September 10, 2007 5:11 AM"And as for branching/merging - give me a break PLEASE!... never necessary..."
Wow. It's obvious you have no experience with managing/patching production releases while continuing development. I'm glad for you, but honestly I fear you have nothing to contribute to this discussion.
And now to discredit myself. I've been using VSS for six years. Other than some quirkiness with getting project structures in place (basically bypassing the Visual Studio "integrated" approach), I've had no issue with it. Never had a corruption, never lost source code, and have had excellent experience with branching. Now, merging on the other hand is just weird and clunky, but doable. We have our automated build set up through CruiseControl and MSBuild and honestly, it runs really well. We have five developers who are fine with a checkout/edit/checkin approach, can easily identify what checkin caused build failure, and to be honest, I think most people coming in off the street would pick up on the simple paradigm quickly. While it may not be the most seamless development environment, the costs (having to wait .5 seconds for a file to be checked out) is pretty minimal considering the ease of use for the whole team.
Reading all of this convinces me that it could be better, but with a solution that I can't really complain about, I'll hold off until we lose everything for the first time.
Chris on September 20, 2007 7:04 AMSuggestion requested for a difficult need!
I work for a government division, IT will not allow any program that they don't pay $$$$ for (mentality is free = trash). That said, I can rightfully install anything I want that doesn't require administrative access (read that as windows wise I am a debugger and power user, but not a local administrator). I spent a whole day configuring and beating up WinCVS (old versions down't need administrator), WinCVS + Igloo, (CVSNT on the server side) etc. and at this point am frustrated. I need a client that integrates nicely with Visual Studio (the IDE I am obligated to), and works with a decent backend system (I am the admin of the server so I can install whatever I want). I've always been very disapointed with all the options out there since I started coding... integration wise VSS is the least worst, but it's a pretty d4mn buggy program. Anybody have any clear good suggestions for both client and server in this scenerio?
BryanV on October 3, 2007 4:29 AMadditional thoughts:
1-5 person development environment, client and server are both going to be windows, IDE will be M$ VS.
Features needed:
IDE integration with M$ VS .Net (2003)
version diff
rollback
Features irrelevant:
pin (that's A VSS term) - nothing will ever be permanently frozen forever and ever, some day someone will un-pin it
branch - branching leads to version chaos... we have learned to work with each other regarding changes and make more mature code instead of just making more more more code
concurrency - most (all?) concurrent systems increase productivity (keeping coders busy) at the cost of productivity (coders have to spend time on a lot of manual merger or at least manual double checking an auto merger)... in this environment it just isn't worth it. we can keep coders busy without them being concurrent on the same file.
BTW - Please don't tout or suggest clear case. I formerly worked for IBM. Like Microsoft, we ate our own dog food... and now that I am free of it I won't touch that piece of dog pile with a 100' pole.
The comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |