31

At the moment we use Visual SourceSafe for our source control, my colleague wants to migrate to Subversion but I am not entirely convinced yet. I have investigated it before and had some serious issues that appear to have been resolved now which is great, but I have one main issue with it and that is the concept of Commit/Merge.

I really don't like the idea of Commit/Merge. I love Check In/Out as you have control over the decision whether to edit now or after someone else has checked their stuff in. With Visual SourceSafe you can both edit and merge the changes so long as its not a binary file so you have a choice what to do. You don't have to wait all the time.

But with commit/merge you have no choice. You are always editing without knowledge and you always have to merge. What happens if you are editing a binary file (or something like HTML) which cannot be merged at all or cannot merge very well automatically. You have to spend a huge amount of time attempting to marge manually or lose all your changes when you could have chosen to wait a few minutes.

And please don't say Visual SourceSafe is unreliable. We have had no problems with medium sized projects in 10 years of using it. Not one, except the time McAfee decided to delete all the 'EXEs on our network ... argh!, but that's a different matter.

I would like some opinions and comparisons on core concepts and usage of Subversion or any other SCCS that is also good for remote access and perhaps uses a database rather than filesystem for its back-end.

We use Visual Studio 2008 and we have our own web editor (which I wrote) that connects to SCCS using the MSSCCI interface so it would be great to continue using that without major rewriting.

70

A few points:

  • Subversion supports both Lock-Modify-Unlock and Copy-Modify-Merge. See Versioning Models in the SVN book. You can choose which model to use on a file-by-file basis, so those big JPG files you can mark with "svn:needs-lock" and a lock will be required before edit just like VSS.
  • In practice, you will probably find that most of the time, there are no conflicts between different developers editing the same piece of code. When this happens, either it's something global like a list of error messages and you both just added a new one, or you really are editing the same piece of code which means you might not have enough communication going on.
  • VSS really is as bad as they say. It's old and unreliable and only just barely gets the job done. I can understand your comfort level with it, but it's undeserved complacency.
  • There are tools that plug Subversion in to Visual Studio using MSSCCI. One of them is AnkhSVN.
33

Have you read Jeff's rant Source Control: Anything But SourceSafe? Perhaps this clarifies matters. Think of the children. ;-)

20

CheckOut/Check in royally bites when you need to fix a bug, but someone else is working on the file.

It also stinks when someone checks out oh a project file or a web configuration. I found myself constantly needing to go to the file system and make something like the project not read only so I could add things. Then I would be in a world of hurt because there was no merge in source safe, so if I waited to check in my version, it would over write someone's changes, since last one in wins. If I let the other project overwrite mine, I would have to re-add all the class files. There was a constant: tap tap tap "can you check in xyz"?

All conflicts/merging I've had using subversion have been easy to fix. After an update, look at the diff and decide what to do from there. Easy. The gains far outweigh any issue with binaries, which I hope are images/media files and not DLLs and EXEs.

You shouldn't have to work around your version control system.

Oh I should mention TortoiseSVN is seriously awesome.

So is Visual SVN, a visual studio plug-in.

10

Dan, it sounds like you're trying very hard not to be convinced. Every possible answer seems to result in more objections.

Do you accept that a large portion of the software development community ? consisting of many thousands of developers working on many thousands of projects ? uses tools like Subversion and CVS that follow an edit-merge-commit pattern, instead of a checkout-modify-checkin pattern, without significant issue? If so, then what is different about your situation?

I've personally worked for of years on projects with up to a few dozen direct contributors using CVS and Subversion. The use of edit-merge-commit has never been a problem. However, when I used MPW Projector and Visual SourceSafe, the use of checkout-modify-checkin was regularly a problem because others would have files I needed to modify checked out.

For three developers, as it sounds like you have, there should be no problem whatsoever with using Subversion. Otherwise those of us who have worked on much larger teams and large projects using both CVS and Subversion would have run into them, and have war stories to share with you about them.

8

@Dan

I only refer to Lock/Unlock as that is what was being mentioned in the answers above. Actually it is Check In/Out, I dont know any system that uses exclusive Lock/Unlock so perhaps it is a bad term.

If multiple people cannot edit the same file simultaneously, it's a lock. If you "check out" reallyimportantfile.c and go home for the day, no one else can edit that file. This is a lock, and it's horribly brittle.

You also still have the problem where concurrent changes can conflict. E.g. You edit A to add a call to a function in B, while I edit B to rename/remove that function. We still have to merge. The only difference is that VSS doesn't understand merges at all, and has much worse granularity.

Why, we have many projects and many components. Things like String, Array, Map and many hundred other classes and Reusable components that dont get edited often ... do you mean that you edit every file in every project throughout your entire company on a daily basis, I find that hard to believe.

You shouldn't be sitting around using old versions of code. That's why SVN provides update functionality. If you keep an old version of Map on your computer long enough, someone is going to edit the source without you knowing. You're then going to commit some change that works on your machine but not on the build machine (which has the latest version of Map).

And for the record, no I don't edit every file every day, but I do update them every day.

Its potentially too late then isnt it, you have potentially committed a broken file. What you should always do is get/commit/merge to ensure you havent broken the project .. with the commit/merge model its more hidden away to do this.

No, because SVN won't commit if it detects a conflict. It's not really commit/merge. It's merge/commit. Even if you don't manually update your code first, SVN will still merge before committing. It will not let you commit if there's a conflict.

I don't have any real experience with VSS, but the way you are describing it, it sounds as if you have to check out (or manually update) Map to get the updated version. This means that it's extremely easy for your code to get out of sync with the repository.

The other way to read your description is that every time you checkout code, it does a full update. In that case, it sounds like either 1) no one else can edit anything at all or 2) no one else can safely edit anything at all. If it stops everyone else from touching the code base, then it's a full lock and completely useless. If it doesn't, then you don't have any kind of concurrent modification protection (because someone can edit Map after you check it out).

I agree that is what should happen, and it should be built it, IMO it should be forced to do this ... ie. you cant commit without doing an update first. But it doesnt enforce it and doesnt give you the implication that it is necessary and thus its potentially a problem.

A merge always happens when you commit. If you try to commit a file that someone has modified since your last update, SVN will force you to perform an update before it will even commit.

Real life issues and problems fyi. I didnt say it scambles the file did I, maybe I missed that somewhere. I did say that it can lead to 'tricky merges' that you could happily do without, something that could have taken a few seconds or minutes can take much, much longer due to merge problems.

The only way you can get into merge conflicts with a single HTML file is if multiple people simultaneously edit it. The VSS approach is to simply refuse to allow anyone else to edit the file. I fail to see how this is an improvement.

Personally, I HATE merging, I detest it, the interface in doing so is problematic in the tools I have used and I avoid it at all costs as it wastes so much time unless it is a straight forward merge. But if you have several people working on the same files its a problem, perhaps you have not experienced it, perhaps you are lucky and I am not, but its a problem that surely you cant deny that I am having.

I hate complicated merges as well. However, if the alternative is to completely lock the file, I'd rather deal with merging. The alternative is to twiddle my thumbs waiting for someone else to unlock the file. (Which can stop me from editing other files as well if there are dependencies.)

Why on earth would that be an abuse. I want to source control my documents and my graphics because I want a history of changes, why would this possibly be an abuse. Do you mean to say you only source control text files? That seems strange and unlikely in most situations and perhaps you are not using Source Control in the way it should be.

I'm not sure how you made the leap to text-only. My point is that if you have to lock everything, you give up way too much of the versioning power. The ability to edit simultaneously is vital for any large effort. Frankly, I think it's almost vital for small efforts.

And again, on the rare occasion that it's necessary to lock a file, that's still possible. It just shouldn't be the standard mode of operation.

Perhaps, but thats irrelevant. I asked for answers and comments to my observations be they right or wrong and I dont care to be denigrated for daring to question the absolute perfection of Subversion.

It's not irrelevant and I didn't "denigrate" you. I'm giving you some pretty strong evidence that your observations are flawed. If most software is maintained in SVN-style repositories, isn't it possible that the merge/commit style works pretty well?

And no one said SVN is perfect. Don't get snarky just because I disagree with you.

5

If you love VSS (Shudder) than please consider SourceGear Vault. It allows you to use either a Check-In/Checkout System or a Edit/Merge/Commit system, and has its UI modeled to be easy for VSS users to transition too.

In all honesty, its my favorite cheap SCM.

Download the demo, you will love it.

5

If you have a small team and VSS is working fine for you and doesn't annoy most of you then don't change...if it ain't broke don't fix it.

I'm going to put technical reasons aside and suggest you consider this use case scenario:-

  • You've been working on a new feature for the last few hours and have made significant changes to a number of files.
  • QA then comes to you with a bug that needs to be fixed urgently as it is stopping them from testing.
  • At the same time an issue has been reported from the Production environment and it too needs an urgent fix.

So what I would want to do is create two new 'working folders', one for the bug fix for QA and one for the Production fix. Into the QA folder goes the exact source that was release into QA and the same for the Prod folder...only the Prod release code. Plus of course I want to leave the good work I have been doing on my new feature untouched.

Is this easy if you are using VSS? Have you tried doing a 'get latest' to a different directory? It changes your working folder for you (without telling you), this is good as long as you really know what you are doing and you are aware that it has happened...but it is very easy to accidently checkin from the wrong location once you have done this (raise your hand if you have done this before :-)

Of course you could probably make the QA fix in your current working folder (that has all of your new feature changes), if it is a quick fix then fine but usually you'll spend half a day, change half a dozen files, go to lunch, have a debate about which source control to use and then you go to check in...and try to remember which files need to go in. You don't want any of your untested feature code to go in and you're praying that you haven't made a bug fix change in a file that was changed for your feature :-|

With SVN this is really easy. Take some time to understand branching in SVN (doesn't take long really) and you will see how easy it is to work on N issues at the same time, all independent of each other. I disagree with anyone who says branching in SVN is difficult, if you think it is hard you either don't understand what is happening conceptually or you are doing something wrong.

One extra plus...we use assembla.com to host our SVN repository so working anywhere in the world on any machine is as easy as saying "I'm free from the shackles of VSS!"

;-)

4

I used to have the same problem with SVN/CVS systems as you. My advice to you is just to get over it (I don't mean that in a rude way). These systems are much smarter than you probably give them credit for.

I've been working with CVS for the past two years at my job and, while I have issues with it, merging is not one of them. It's been extremely rare that something has not been merged properly (on those few occasions when it did happen, using the SVN Diff tool made solving the problem easy). I've been using SVN for much longer than that, and have never seen a merge problem with that system. The only time there has ever been a real problem is when there was a conflict (Ie, two people tried to change the same set of lines at the same time); in that case, of course you'd need to make a choice as to which is the correct change. Again, a diff tool makes this trivial.

That goes for HTML files as well. I'm not sure why you think that can't be merged; again, the system is smarter than you think.

4

It's an interesting conversation and I can surely sympathize with you, as VSS was my first ever source control software, and as I heard about CVS (which, as the predecessor of SVN has exactly the same edit-update-checkin style workflow) for the first time, I just could not believe, it would ever work. It was just so alien and there seemed to be just too much magic involved.

I took the dive and never looked back. The workflow model of CVS, SVN and practically every other source control software out there is just much more natural way to work in a team:

  1. You check out the project to your local workspace.
  2. Work on the code in your local copy as you see fit, until you have something ready to be committed.
  3. You do an update, to synchronize your working copy to the official stream, merging changes from the repository with your working copy.
  4. Resolve any conflicts by adjusting your code to changes from the repository, update again, lather, rinse, repeat...
  5. If update was successful and there were no merge conflicts, just commit your stuff.
  6. Back to point 2.

The most daunting part is accepting the automatic merging. But once you've accepted, that "it just works", you'll find that in most cases it quite simply just works. If the teamresponsibilities are properly assigned, there are almost no chances of conflicting changes. On the rare occasion of conflicts, there are host of wonderful diff/merge tools that help you out. But most of the time you can just trust SVN to do the right thing and that saves a lot of time.

Well yes, I need to be convinced and I havent been. I havent brought up more objections, just the same ones and the replies have all circled around VSS not allowing multiple-edits, which it does do, this sort of negates those arguments somewhat.

It seems you are just not listening to the content of the arguments and time and again just voicing your skepticism. Nobody is going to convince you, unless you just take the chance and try it out.

I dont know where this false understanding about VSS comes about, has no-one who has used VSS turned on the feature "Allow multiple check-outs"? Its always had it (as long as I can remember) and allows multiple people to work on one file ... there is no lock, go home, everyone is buggered situation. We use it daily without problems.

Maybe the problem is that this flag is off by default, thus only few lucky people find it out.

In any case ... You really need to make a mental leap and start trusting the software to merge changes without problems when you come from VSS. When you've done that, you'll eventually find you're better off than before.

PS - And as soon as you've gone over to SVN style of development, there is a new generation of VCS that is gaining popularity around dev. communities - distributed versioning systems, that I'd suggest to take a look at... It is just as scary, but eventually just as rewarding as the leap from VSS -> SVN

I dont know about 'large portion' of software community, I have not seen any stats. Just read up on almost any of the available commercial versioning tools and You'll find that although there is quite a difference in the way they handle change sets, brancing/mergeing, etc., most of them follow this modify-merge-commit workflow that is also the cornerstone of CVS/SVN.

I know most OS uses SVN/CVS, I presume mostly because they are free, have online interfaces and are good over the net (due to the deltas), so its hard to say its better when its free and the others are not, seems like a big jump to assume anything else. Point me to some stats on commercial software/ISVs to take a look at, I would certainly like to see.

You presume wrong. Partly, of course the vast popularity is triggered by the fact that these are free tools, but also because of their technical merits and the convenience. They do a great job of reducing micromanagement of change reconciliation and are much more scalable to larger, more active teams and larger codebase, than VSS.

3

Let me try to answer some of your questions, even though I haven't used VSS myself --- so you'll have to wait for other people with more experience to stop by :)

But With commit/merge you have no choice, you are always editing without knowledge and you always have to merge.

You mean that other people can always decide to edit the same files you're working on? Many would actually consider that an advantage, and so would I --- especially on larger projects.

I'd also say that you sound a bit 'afraid' of merging, though I don't think you should be. I've been working with Svn for quite some time now, and merging has never been a problem. 90% of the time, it's completely automatic, and the other 10%, you have tools to assist you with the merge.

Also note that you can lock files with Svn, preventing others from working on it --- this may come in handy with binary files.

All in all, why don't you give it a spin on some side project? I completely agree that one shouldn't migrate unnecessarily, so why not try it first? Do approach Svn with an open mind, though, and tell yourself you try it to see if Svn can help you --- not because you must try it because other people have told you :)

Good luck, and do have fun!

3

I found the SVN model scary at first. I've had reliability issues with VSS, certainly, but my main issues with it are actually that you can permanently delete files from it and that the check-out/check-in tends to slow down teams on larger projects.

I'd suggest trying it out on a project for a while - you get used to the change in programming patterns. I think most people prefer the auto-merging after a while, and I haven't seen one go wrong: it either merges perfectly or asks you to resolve the conflict.

2

@Dan

Many people can all edit the same file with lock/unlock on VSS so long as its not binary so I dont think this is a valid complaint with VSS.

In what sense is the file locked if multiple people can edit it? This doesn't make any sense to me.

What I like about Lock/Unlock is that it 'always' gets the latest file from the source control prior to editing, if it gets a new file you know you need to get the whole project to be sure that you arent building against really old code.

With commit/merge it doesnt. You happily and blindly carry on editing your file that you last edited months ago not knowing that a world of change has happened ... you come to merge it and everything is broken cos its nothing like the file you were writing your code against.

First off, if your check-in schedule is measured in months, you aren't really using version control anyway. Second, when you commit, SVN will tell you which files were merged, and will notify you if there is a merge conflict.

Also, you can (and should) do an update before the commit, which will cause the merge to happen without the associated commit, so that you can rebuild and test before the actual commit.

I think you need to try it and see, you will find that quite often with HTML that a lot of code changes occur on one line and so you tend to have tricky merges more often than you do with plain code ... just imagine merging a C/C++ file when someone has obfuscated lots of stuff into single lines, it doesnt tend to happen but it could.

If the code cannot be merged, you will be notified of the conflict. It won't just happily scramble your file and remain silent. Have you actually ever experienced this problem, or are you making up some crazy scenario based on your understanding of SVN? There can be problems with merging (hence update->merge being recommended), but they are really rare cases, not typical scenarios.

Thanks everyone for your answers, I didnt realise you could lock certain files .. can you do it globally on file types or be smart and say anything that has a 'null' byte in it?

I think if you want to lock on a regular basis, especially entire groups of file extensions, you are abusing version control. Locking like this should not be required on a regular basis.

I think you're forgetting that most software firms use a versioning system in the style of SVN. They all deal with merging, and it works. (Merging branches is a pain, but that's a different issue.) The lock/edit/unlock model simply doesn't scale. It's too brittle. Modify/merge works for larger groups (and smaller groups, too), and it works well.

2

TortoiseSVN. Period.

2

Dan, it sounds like you're trying very hard not to be convinced. Every possible answer seems to result in more objections.

Well yes, I need to be convinced and I haven't been. I haven't brought up more objections, just the same ones and the replies have all circled around Visual SourceSafe not allowing multiple-edits, which it does do, this sort of negates those arguments somewhat.

I find it surprising though that no-one has yet mentioned the two things that go in Subversion's favour:

  • Atomic commits
  • Deltas so checkin via HTTP are much smaller and quicker
  • Are there any others??

I don't know about 'large portion' of software community, I have not seen any stats. I know most OSes use Subversion/CVS, I presume mostly because they are free, have online interfaces and are good over the Internet (due to the deltas), so it's hard to say it's better when it's free and the others are not, seems like a big jump to assume anything else. Point me to some statistics on commercial software/ISVs to take a look at, I would certainly like to see.

without significant issue? If so, then what is different about your situation?

I was just pointing out a couple of issues with it that I could see and wondered if they were accurate observations. I don't want to have to learn a whole new way of working without being convinced that my worries are false.

However, when I used MPW Projector and Visual SourceSafe, the use of lock-modify-commit was regularly a problem because others would have files I needed to modify locked.

I don't know where this false understanding about Visual SourceSafe comes about, has no one who has used Visual SourceSafe turned on the feature "Allow multiple check-outs"? It always had it (as long as I can remember) and allows multiple people to work on one file. There is no lock, go home, everyone is buggered situation. We use it daily without problems.

In fact in the 12/13 years I have used Visual SourceSafe I haven't had any corruption or data integrity problems either, so I think the corruption 'scares' are like the false Windows Vista perception. One person has said it, everyone jumps on the bandwagon and now it become true. So it's going to take some convincing for me to change.

But I do thank everyone for their comments, I think I have been persuaded to give it a try on a minor project and see what it's like, there is no real harm in that I suppose.

2

"Many people can all edit the same file with lock/unlock on VSS so long as its not binary so I dont think this is a valid complaint with VSS."

This confusion over whether two users can edit the same file simultaneously seems quite fundamental to me. When I used vss if one person checked out a file then nobody else could edit it until that person checks it back in again. This was a cause of endless frustration.

Thankfully I no longer use vss, and the entire team can happily change anything they like whenever they like. The last merge conflict we had was some months ago. We use CVS, but we are evaluating Mercurial as the system we may move to

2

Subversion kind of underperforms in comparison to the modern "distributed" breed of VCS. Check out Git and Bazaar.

2

The most important is one specific feature: blame.

It allows you to annotate the whole source file and prefix every line, who was the last to touch this line and at which revision has this happened.

Other than that: this "lockless" development might sound scary, but it is not, because you immediately see what is modified.

1

Re: Merging SVN into Visual Studio... VisualSVN is the tool I use. Also works very well.

1

In what sense is the file locked if multiple people can edit it? This doesn't make any sense to me.

I only refer to Lock/Unlock as that is what was being mentioned in the answers above. Actually it is Check In/Out, I dont know any system that uses exclusive Lock/Unlock so perhaps it is a bad term.

First off, if your check-in schedule is measured in months, you aren't really using version control anyway.

Why, we have many projects and many components. Things like String, Array, Map and many hundred other classes and Reusable components that dont get edited often ... do you mean that you edit every file in every project throughout your entire company on a daily basis, I find that hard to believe.

Second, when you commit, SVN will tell you which files were merged, and will notify you if there is a merge conflict.

Its potentially too late then isnt it, you have potentially committed a broken file. What you should always do is get/commit/merge to ensure you havent broken the project .. with the commit/merge model its more hidden away to do this.

Also, you can (and should) do an update before the commit, which will cause the merge to happen without the associated commit, so that you can rebuild and test before the actual commit.

I agree that is what should happen, and it should be built it, IMO it should be forced to do this ... ie. you cant commit without doing an update first. But it doesnt enforce it and doesnt give you the implication that it is necessary and thus its potentially a problem.

If the code cannot be merged, you will be notified of the conflict. It won't just happily scramble your file and remain silent. Have you actually ever experienced this problem, or are you making up some crazy scenario based on your understanding of SVN? There can be problems with merging (hence update->merge being recommended), but they are really rare cases, not typical scenarios.

Real life issues and problems fyi. I didnt say it scambles the file did I, maybe I missed that somewhere. I did say that it can lead to 'tricky merges' that you could happily do without, something that could have taken a few seconds or minutes can take much, much longer due to merge problems.

Personally, I HATE merging, I detest it, the interface in doing so is problematic in the tools I have used and I avoid it at all costs as it wastes so much time unless it is a straight forward merge. But if you have several people working on the same files its a problem, perhaps you have not experienced it, perhaps you are lucky and I am not, but its a problem that surely you cant deny that I am having.

I think if you want to lock on a regular basis, especially entire groups of file extensions, you are abusing version control. Locking like this should not be required on a regular basis.

Why on earth would that be an abuse. I want to source control my documents and my graphics because I want a history of changes, why would this possibly be an abuse. Do you mean to say you only source control text files? That seems strange and unlikely in most situations and perhaps you are not using Source Control in the way it should be.

I think you're forgetting that most software firms use a versioning system in the style of SVN.

Perhaps, but thats irrelevant. I asked for answers and comments to my observations be they right or wrong and I dont care to be denigrated for daring to question the absolute perfection of Subversion.

1

but my main issues with it are actually that you can permanently delete files from it

Yes, we turned that off in Admin so only certain people (me) can do it, but its not a problem as you certainly get plenty of warning.

and that the check-out/check-in tends to slow down teams on larger projects

Ah, there are only three of us developers so we dont get team management problems at all. We do find that VSS 2005 and VS2008 is very very slow, it was okay before we upgraded, it was zippity quick with the older VSS and VC6 so we arent sure which one is at fault ... serves us right for upgrading both at the same time.

I'd suggest trying it out on a project for a while - you get used to the change in programming patterns. I think most people prefer the auto-merging after a while, and I haven't seen one go wrong: it either merges perfectly or asks you to resolve the conflict.

Yes I think thats fair, its worth doing on one project and seeing how the team copes.

We also do a lot of work from home so the Subversion method is a very interesting benefit ,,, just differences/deltas are transferred, thus quicker over the net.

1

@Dan

I think you fail to understand VSS as this isnt the case. Multiple people can edit the same file so long as its not a binary file, as I said above. VSS has allowed this for the 10 or more years that I have used it.

This doesn't make sense to me. It seems to me that checking out a file must stop others from editing it, or else checking out a file does nothing. If checking out a file doesn't lock the file, then what does it do? Can two people checkout a file, edit simultaneously, and then check the file back in? If not, then it's a lock. If so, then it either requires merging or results in the loss of someone's modifications.

Well yes, I need to be convinced and I havent been. I havent brought up more objections, just the same ones and the replies have all circled around VSS not allowing multiple-edits, which it does do, this sort of negates those arguments somewhat.

Dan, you never really made any complaints. All you did was say that you are uncomfortable with SVN-style version control. That's not a complaint. No one can "convince" you because you haven't given any actual concerns that people can rebut.

Point me to some stats on commercial software/ISVs to take a look at, I would certainly like to see.

Google uses Perforce. Microsoft uses Perforce primarily. Yahoo uses CVS and SVN (with a touch of Perforce). Can you point to any large group that uses VSS? Even Microsoft doesn't use it.

I was just pointing out a couple of issues with it that I could see and wondered if they were accurate observations. I dont want to have to learn a whole new way of working without being convinced that my worries are false.

The fact that your teammates want to switch away from VSS should be a pretty good reason to give the new way of working a try. It also makes me wonder if they are seeing some of the issues you haven't experienced with VSS.

I dont know where this false understanding about VSS comes about, has no-one who has used VSS turned on the feature "Allow multiple check-outs"? Its always had it (as long as I can remember) and allows multiple people to work on one file ... there is no lock, go home, everyone is buggered situation. We use it daily without problems.

How exactly does this work? If you can have multiple checkouts, aren't you now dealing with merges anyway? What complexity does SVN add over that?

But I do thank everyone for their comments, I think I have been persuaded to give it a try on a minor project and see what its like, there is no real harm in that I suppose.

I'm glad you're going to give SVN a try. Actual use will show its strength (and weaknesses) far better than discussion. I hope you and your team find something you both like.

1

SVN is free and open-source. It's very clean, and on par with Perforce (not free). Subversion also has fairly decent conflict resolution which addresses your merge concerns.

If you are worried about merging then you've probably got file locks in VSS, and that is extremely limiting in terms of multiple developers.

I've used SVN (with Tortoise and ANKH), (Win)CVS, VSS, VSS with Source Off Site, and a bit of Perforce experience. SVN wins hands down. I have had the misfortune of being an admin for VSS and was constantly having to run the analyze tool, and we only had 4 developers working at a time.

Perforce is one of fastest tools out there (so I'm told) but it costs a lot more. CVS is deprecated, and I recommend against. VSS doesn't scale. Since MS didn't use it, that should be telling... SVN is CVS to the next level, and wins without a doubt. Its easy to install and I recommend every developer who writes code at home use this for personal development.

0

You can use the lock/unlock functionality for binaries in svn. It's quite similar to checkout/in.
Commit/Merge works like a charm for non-binaries, really. Follow my link here, to learn more about it. Really, it's worth reading it.

0

Jeff, you might look at Perforce. It has the checkout step that you like (e.g. you "p4 edit" a file or set of files, and other people can see who has files opened with "p4 opened").

http://www.perforce.com

0

The lock/unlock model does have its uses. Commit/merge is very handy when you are building an application, but when you have a team doing maintenance on millions of lines of code involving surgical edits, lock/unlock gives you the confidence that someone isn't going to make an inadvertent tiny change without it going noticed.

0

CheckOut/Check in royally bites when you need to fix a bug, but someone else is working on the file.

Many people can all edit the same file with lock/unlock on VSS so long as its not binary so I dont think this is a valid complaint with VSS.

What I like about Lock/Unlock is that it 'always' gets the latest file from the source control prior to editing, if it gets a new file you know you need to get the whole project to be sure that you arent building against really old code.

With commit/merge it doesnt. You happily and blindly carry on editing your file that you last edited months ago not knowing that a world of change has happened ... you come to merge it and everything is broken cos its nothing like the file you were writing your code against.

Is this a fair criticsm/problem do you think?

That goes for HTML files as well. I'm not sure why you think that can't be merged; again, the system is smarter than you think.

I think you need to try it and see, you will find that quite often with HTML that a lot of code changes occur on one line and so you tend to have tricky merges more often than you do with plain code ... just imagine merging a C/C++ file when someone has obfuscated lots of stuff into single lines, it doesnt tend to happen but it could.

Thanks everyone for your answers, I didnt realise you could lock certain files .. can you do it globally on file types or be smart and say anything that has a 'null' byte in it?

0

If multiple people cannot edit the same file simultaneously, it's a lock. If you "check out" reallyimportantfile.c and go home for the day, no one else can edit that file. This is a lock, and it's horribly brittle.

I think you fail to understand VSS as this isnt the case. Multiple people can edit the same file so long as its not a binary file, as I said above. VSS has allowed this for the 10 or more years that I have used it.

0

Please, if you're starting a new project or even considering switching version control system in use, do not select any non-distributed version control. It may sound a bit scary first but distributed version control is the only way to go. Reasons:

  1. Every time there's more than a single developer (or even a single developer with more than a single branch) you're going to do merges sooner or later. You can try to target the "later" part but you cannot avoid merging in the long run.
  2. Merging is hard
  3. Distributed version control tools are designed to do merges very well because that's basically all they need to, ever.
  4. (Bonus) Distributed version control tools allow doing all the work without network traffic. Even with very fast local network, the local disk cache will be much faster (because it's all in the system RAM).

Reasonable choices are git and mercurial. I personally prefer git but as far as I know, mercuarial has better win32 front end. Subversion only has "fast" branching but poor support for merging and in addition it's much slower with everything (compared to git, it's usually a bit faster than CVS).

An entertaining presentation about git by its original author (Linus Torwalds, also known from "linux" kernel) can be found at http://www.youtube.com/watch?v=4XpnKHJAok8 - note that this is not a marketing speech, it explains very well why you really shouldn't use non-distributed tools at all.

0

Thanks, I have heard about Vault and like Eric Sinks blog but havent actually tried it yet ... perhaps the cost put me off, but I will look at it.