Source control redux
-
Ok, after the major flamefest yesterday over my assertion that I personally in my shop had no use for source control a lone member of this board finally posted a single point that convinced me it might be a good idea if it doesn't slow us down too much and is a reliable product that will *NEVER LOSE OUR CODE*. Full credit to Scott Dorman in this post[^] for bringing up the entirely valid and useful point that, while we never release branch versions of our software, we do actually have a branch when we release a new version and want to separately work on the next release and bug fix of the old released version then merge them later. That's a brilliant point that I had never thought of and no one else suggested but Scott. I see subversion mentioned a lot, I also see VSS mentioned in a negative way a lot. This will be new for me and this is not hobby code it's very valuable code for a world wide used software product, I can't take any chances on losing anything. So my question is, given I want as little hassle as possible but still need something that can do the above and not much else, what source control systems should I look at for testing and suitability?
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
We are in the process of switching from VSS to subversion. The trouble we had with VSS 6.0 is its repository kept getting corrupted. Also VSS is supposed to have a merge capability but we never figured out how to use it. So far subversion is very nice. We figured out merging right away. Having all changes be transactional (all or nothing) gives us confidence it is taking good care of the source code.
-
Ok, after the major flamefest yesterday over my assertion that I personally in my shop had no use for source control a lone member of this board finally posted a single point that convinced me it might be a good idea if it doesn't slow us down too much and is a reliable product that will *NEVER LOSE OUR CODE*. Full credit to Scott Dorman in this post[^] for bringing up the entirely valid and useful point that, while we never release branch versions of our software, we do actually have a branch when we release a new version and want to separately work on the next release and bug fix of the old released version then merge them later. That's a brilliant point that I had never thought of and no one else suggested but Scott. I see subversion mentioned a lot, I also see VSS mentioned in a negative way a lot. This will be new for me and this is not hobby code it's very valuable code for a world wide used software product, I can't take any chances on losing anything. So my question is, given I want as little hassle as possible but still need something that can do the above and not much else, what source control systems should I look at for testing and suitability?
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
John, My four-person shop uses CVS. CVS is a predecessor to Subversion and is available on Windows and Un*x platforms. There is a TortoiseCVS plugin available that makes using CVS a pretty easy proposition from the Windows Explorer. Icons with a green highlight are checked in -- or at least, are the same as they were when checked out; icons with an orange hue have been modified. You use CVS as follows: check out a module, which makes a copy in your local CVS 'sandbox'. Edit it. Check it back in. If all goes well, nobody else has changed the same module, and you're done. If somebody else was working on that module and checked their changes in first, the client alerts you, and makes a local copy of the checked in version in your CVS sandbox with a slightly different file name. You can then use your favorite diff tool to figure out what needs to be altered to make the two versions one again, and then after you're done editing, you check it in. (My current favorite diff tool is DiffMerge.) If you want to make sure your copy of the module is current, say before you make changes, you perform a CVS update on it, and the tool will automatically rev the copy in your sandbox. Using the TortoiseCVS tool, you can get a chart of all the versions of the code, and perform diffs between them to see what changed where. We primarily develop in both Perl as well as C#. We're also using CVS to store our documentation, our Makefile, some small GIFs used in the web pages, etc. We have also used it in the past to store a 30+MB MSI installation file, so it can handle big stuff if need be. The big thing with this tool, and I'm sure with others like it, is the preparation you have to do before you implement it. I personally am on my second implementation of the CVS repository, because I didn't want to live with all of the mistakes I made during the first implementation. These mistakes were really ideas that seemed good at the time, but later proved to be a hassle. For example, before we went to automated builds of all our code using make and msbuild, I was manually building each program, and storing it in a separate subdirectory in the CVS repository, and then copying it to a \binaries subdirectory under the MSI CVS module. That was more work than the small benefit of having the built binaries in the repository was worth! Our current repository structure looks a little like this: \ --Server modules -----Module S-A -----Module S-B -----Module S-C.... --Client Modules -----Module C-A -----Module C-B
-
Ok, after the major flamefest yesterday over my assertion that I personally in my shop had no use for source control a lone member of this board finally posted a single point that convinced me it might be a good idea if it doesn't slow us down too much and is a reliable product that will *NEVER LOSE OUR CODE*. Full credit to Scott Dorman in this post[^] for bringing up the entirely valid and useful point that, while we never release branch versions of our software, we do actually have a branch when we release a new version and want to separately work on the next release and bug fix of the old released version then merge them later. That's a brilliant point that I had never thought of and no one else suggested but Scott. I see subversion mentioned a lot, I also see VSS mentioned in a negative way a lot. This will be new for me and this is not hobby code it's very valuable code for a world wide used software product, I can't take any chances on losing anything. So my question is, given I want as little hassle as possible but still need something that can do the above and not much else, what source control systems should I look at for testing and suitability?
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
We've been using SourceGear Vault here now for a while, it's quite simple but powerful at the same time. We use to have Seapine Surround installed but found it far to slow when checking in/out projects bigger than a few files. As for never losing code, SourceGear has a backup system build into it and it holds everything in an SQL database so that can be backed up as well.
-
What's a line? :-D Well anyway I would start to measure size by the number of methods, but even that's not quite right, because I would certainly put all overloaded versions of a method in one file. A static class as a library of methods is a simple example; say an Acme.Math class: Acme.Math.Abs.cs might contain: Acme.Math.Abs ( int ) , Acme.Math.Abs ( double ) , etc. Acme.Math.IsOdd.cs might contain: Acme.Math.IsOdd ( int ) , Acme.Math.IsOdd ( double ) , etc. But when dealing with a business object or a form things aren't quite as clear-cut, so you might need to find some conceptual similarity of functions. Maybe there are serialization methods that can be in their own file, or validation methods, or put the menu item handlers in their own. Maybe you have a Data Access Layer class and you can split it up by what sort of data are accessed by the methods; employee methods, client methods, etc. Other than method libraries, I haven't really done this myself, but mainly because I work alone and without a version control system.
This is certainly off topic, but I couldn't ignore this.
PIEBALDconsult wrote:
Acme.Math.Abs.cs might contain: Acme.Math.Abs ( int ) , Acme.Math.Abs ( double ) , etc.
I think this is a little extreme. So now you'll only have 20 lines of code per file, but now you'll have to many files to look through. You haven't simplified anything.
PIEBALDconsult wrote:
Maybe you have a Data Access Layer class and you can split it up by what sort of data are accessed by the methods; employee methods, client methods, etc.
Maybe data access for each of these entity types should just be a different class, not just a different partial class file! If you have a single class file that is "too big", then maybe that class is doing too much. Refactor, Refactor, Refactor. The best usefullness of partial classes is to separate auto-generated code from manually generated code.
Michael Lang (versat1474) http://www.xquisoft.com/[^]
-
I can recommend subversion wholeheartedly. There is an excellent subversion book (in HTML) explaining all the concepts very well (check http://svnbook.red-bean.com/). Once you've set things up, you can easily integrate with the Windows shell (TortoiseSvn), and with Eclipse (e.g. Subversive). The daily routine is just two clicks and adding some comment. To master the more complex stuff (like branching, tagging, restoring a previous version, merge other peoples changes with your changes) I can advise to create a little test repository, and just play around with it. You'll quickly get the idea. You have to invest a few hours, but they'll be worth every second!
Reinier Boon wrote:
To master the more complex stuff (like branching, tagging, restoring a previous version...
True, but that is the case with any source control system. :laugh: It's not that subversion makes it much harder, if at all, than any other source control system.
Michael Lang (versat1474) http://www.xquisoft.com/[^]
-
Tell you what. When we've finished the prototype, I'll send you a copy. You could be an unnofficial beta tester.:-D
Deja View - the feeling that you've seen this post before.
-
Ok, after the major flamefest yesterday over my assertion that I personally in my shop had no use for source control a lone member of this board finally posted a single point that convinced me it might be a good idea if it doesn't slow us down too much and is a reliable product that will *NEVER LOSE OUR CODE*. Full credit to Scott Dorman in this post[^] for bringing up the entirely valid and useful point that, while we never release branch versions of our software, we do actually have a branch when we release a new version and want to separately work on the next release and bug fix of the old released version then merge them later. That's a brilliant point that I had never thought of and no one else suggested but Scott. I see subversion mentioned a lot, I also see VSS mentioned in a negative way a lot. This will be new for me and this is not hobby code it's very valuable code for a world wide used software product, I can't take any chances on losing anything. So my question is, given I want as little hassle as possible but still need something that can do the above and not much else, what source control systems should I look at for testing and suitability?
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
I use Component Software's CS-RCS (it supports CVS too), its a nice tool but not free if your doing for profit code. I use it as a single developer for a hospital (php scripts, sql, vb, C++ etc). As far as the single user version goes it is very easy, it even plugs right into windows, so if you right click on a file, or are using word or whatever, you have an option, "check in to RCS". There is a multiple simultaneous user version, that you have to pay for, I haven't tried it, but if it is anything like the standalone version it would be nice as well. P.S. It probably goes without saying but you get the option showing up in Visual Studio as well. I don't agree with the posts saying that source control has a step learning curve. You can get by with just check out, check in, you'll get prompted for a message on checkin, there I put what I changed and a brief explanation of what remains to be done for the method if not complete. If the source control system is configured properly only one person will have the rights to check in their modified version of the program.
-
Ok, after the major flamefest yesterday over my assertion that I personally in my shop had no use for source control a lone member of this board finally posted a single point that convinced me it might be a good idea if it doesn't slow us down too much and is a reliable product that will *NEVER LOSE OUR CODE*. Full credit to Scott Dorman in this post[^] for bringing up the entirely valid and useful point that, while we never release branch versions of our software, we do actually have a branch when we release a new version and want to separately work on the next release and bug fix of the old released version then merge them later. That's a brilliant point that I had never thought of and no one else suggested but Scott. I see subversion mentioned a lot, I also see VSS mentioned in a negative way a lot. This will be new for me and this is not hobby code it's very valuable code for a world wide used software product, I can't take any chances on losing anything. So my question is, given I want as little hassle as possible but still need something that can do the above and not much else, what source control systems should I look at for testing and suitability?
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
-
Ok, after the major flamefest yesterday over my assertion that I personally in my shop had no use for source control a lone member of this board finally posted a single point that convinced me it might be a good idea if it doesn't slow us down too much and is a reliable product that will *NEVER LOSE OUR CODE*. Full credit to Scott Dorman in this post[^] for bringing up the entirely valid and useful point that, while we never release branch versions of our software, we do actually have a branch when we release a new version and want to separately work on the next release and bug fix of the old released version then merge them later. That's a brilliant point that I had never thought of and no one else suggested but Scott. I see subversion mentioned a lot, I also see VSS mentioned in a negative way a lot. This will be new for me and this is not hobby code it's very valuable code for a world wide used software product, I can't take any chances on losing anything. So my question is, given I want as little hassle as possible but still need something that can do the above and not much else, what source control systems should I look at for testing and suitability?
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
We've used CVS forever. It's what we know, and it works great. So why fight it? There is a big debate over subversion and CVS. Both have benefits that outweigh the other product. Here's a link comparing them. http://www.pushok.com/soft_svn_vscvs.php[^] In the end, it's personal preference. But VSS is usually thrown out because of it's file locking features.
-
Judah Himango wrote:
It lets multiple people work in the same code file
That's good, but it shouldn't be a frequent occurence if the files are kept small. The worst thing about C# 1 (in my opinion) was the lack of what's now partial classes; all classes should have been partial by default from the start (and there should be no partial keyword). The lack of partial classes leads to oversized files.
No, bad design and a lack of modeling lead to oversized files. But I remember when C# came out, hearing or seeing something about partial classes and I never could find it again. Then when 2.0 came out, I figured that I hadn't dreamed it but it was probably taken out of 1.0 for some reason and finalized in 2.0. It is a great tool for some situations, namely code generation, and the ideal example of that is Forms generated UI code. But I think that ommiting the
partialkeyword would be bad, and confusing to beginers. C# is a direct decendant from Java, and requires keywords likeoverrideswhere Java didn't. I can't imagine them doing that and not requiring thepartialkeyword.
Try code model generation tools at BoneSoft.com.
-
I've recently come full circle on this source control topic. After trying to use subversion, and having little success, I started to question the "Conventional Wisdom" out there, that says that VSS is horrid. First - Tell me why you think its horrible: Is it VPN? Ok, that is valid, its improved greatly in the latest version, but still its slow. Is it slower than everything else? Is it slower than Subversion? Lets see some data on that.... Is it because of Pessimistic locking? That is now a setting in VSS now.. and its always supported optimistic locking, in a "work around" sort of way... using "Get Latest Version" ...which I have come to respect. You nkow ahead of time that there might be problems merging back... and you can plan for some time to make that smooth. I like my source control IN the IDE, ..not in Explorer thank you very much.... I like my source control to be so easy, nobody can find a reason to avoid using it. I like it to be "Not in the Way", and not add more Admin activities to the team... (Subversion and Tortoise, besides having to teach everyone how to use these, need a lot of TLC on the server side.) So - I am saying: Take another look at VSS, and stop going with the latest thing people think is so sexy... Subversion is not as easy to implement in team dev as has been said.... and I see no Cost / Benefit by using it. Also - Ask me about how we tried to implement Microsoft Team Foundation Server, and then discarded it, as Alpha ware crap. Another product that is too expensive, tries to do too much, and does nothing particularly well. We try to develop software, not spend all day as network admins, or Beta Testers.
Where there's smoke, there's a Blue Screen of death.
I'll agree that IDE integration is pretty necessary. Thankfully, that's taken care of with Ankh (open source)[^] and Visual SVN (cheap commercial product)[^] But on VSS, personally I've seen it corrupt it's database several times. And even with the 2005 release, the only difference I could see was updated icons. I'm sure (and by that I actually mean hopeful) that there were under the hood improvements, but nothing I can see as a user. But my personal favorite VSS bug, is when the IDE dies for some reason, and VSS won't log you in because an empty file named after your profile doesn't exist in it's user directory. I guess it mainly comes down to personal choice and what you're most familiar with. VSS is sometimes a pain, but it's a working product. I'm just looking for something new. And SVN looks to be the most apealing choice at the moment.
Try code model generation tools at BoneSoft.com.
-
I've recently come full circle on this source control topic. After trying to use subversion, and having little success, I started to question the "Conventional Wisdom" out there, that says that VSS is horrid. First - Tell me why you think its horrible: Is it VPN? Ok, that is valid, its improved greatly in the latest version, but still its slow. Is it slower than everything else? Is it slower than Subversion? Lets see some data on that.... Is it because of Pessimistic locking? That is now a setting in VSS now.. and its always supported optimistic locking, in a "work around" sort of way... using "Get Latest Version" ...which I have come to respect. You nkow ahead of time that there might be problems merging back... and you can plan for some time to make that smooth. I like my source control IN the IDE, ..not in Explorer thank you very much.... I like my source control to be so easy, nobody can find a reason to avoid using it. I like it to be "Not in the Way", and not add more Admin activities to the team... (Subversion and Tortoise, besides having to teach everyone how to use these, need a lot of TLC on the server side.) So - I am saying: Take another look at VSS, and stop going with the latest thing people think is so sexy... Subversion is not as easy to implement in team dev as has been said.... and I see no Cost / Benefit by using it. Also - Ask me about how we tried to implement Microsoft Team Foundation Server, and then discarded it, as Alpha ware crap. Another product that is too expensive, tries to do too much, and does nothing particularly well. We try to develop software, not spend all day as network admins, or Beta Testers.
Where there's smoke, there's a Blue Screen of death.
DumpsterJuice wrote:
I like my source control IN the IDE, ..not in Explorer thank you very much....
You probably know this already, but for the benefit of others, there are options for this with Subversion. At our office we use AnkhSVN http://ankhsvn.tigris.org[^] as a plugin within Visual Studio. I bet there are others as well. Not that I'm advocating you switch to Subversion. Our shop uses both Subversion and VSS and we've had no problem with either for as long as I've been here. BDF
-
El Corazon wrote:
SVN also has the svnsync which lets you mirror subversion servers.
That would actually be very useful if we could sync to our L.A. server and here in house for added protection. I'll look into it thanks.
El Corazon wrote:
most people who set up subversion are trying to avoid backing up
:wtf: Now that is unequivocally stupid. I was a network tech for hire for many years, I've seen so much loss as a result of not backing up properly I think it's ingrained now at the cellular level. My wife and I were both network techs for hire and I find it funny sometimes when we talk about things in everyday life in those terms, like I bought a new mixer for making bread and my wife wanted me to sell the old one but I said it was good to have a hot swap backup without really meaning to say it like that. We talk about backup stuff all the time like we have two shovels, two wheelbarrows etc etc. Anything important that we use all the time.
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
Yep, most shops with any experience have a regular backup regiment that includes primarily backing up source control and database. Anything short of that would be running through a mine field with scissors.
Try code model generation tools at BoneSoft.com.
-
This is certainly off topic, but I couldn't ignore this.
PIEBALDconsult wrote:
Acme.Math.Abs.cs might contain: Acme.Math.Abs ( int ) , Acme.Math.Abs ( double ) , etc.
I think this is a little extreme. So now you'll only have 20 lines of code per file, but now you'll have to many files to look through. You haven't simplified anything.
PIEBALDconsult wrote:
Maybe you have a Data Access Layer class and you can split it up by what sort of data are accessed by the methods; employee methods, client methods, etc.
Maybe data access for each of these entity types should just be a different class, not just a different partial class file! If you have a single class file that is "too big", then maybe that class is doing too much. Refactor, Refactor, Refactor. The best usefullness of partial classes is to separate auto-generated code from manually generated code.
Michael Lang (versat1474) http://www.xquisoft.com/[^]
Mike Lang wrote:
I think this is a little extreme. So now you'll only have 20 lines of code per file, but now you'll have to many files to look through. You haven't simplified anything.
But now one person can make fixes to the ABS functionality while another is fixing another method. This is great with common routines where the methods are probably static and used throughout the application(s). Since doing this and looking at the changes in 3.0, this will be replaced with extension methods. :-D
WarePhreak Programmers are tools to convert caffiene to code.
-
Douglas Troy wrote:
VSS 6.0d is the last release of this product; now it's that Team Server thing (I know nothing about it)
Actually, that's not true. VSS 2005 was released with VS 2005. It's not a HUGE difference from VSS 6, but it seems to be more stable, and offers some extra remote features (web checkin/out). http://msdn2.microsoft.com/en-us/vstudio/aa718670.aspx[^] Also, there's SourceOffsite that lets you use VSS client/server and make remote access much easier. I recommend *NEVER* using VSS remotely under normal conditions, there's too much risk for database damage if you do. 99.9% of peoples problems with SourceSafe database damage is related to trying to use it over flaky networking, IMO.
-- Where are we going? And why am I in this handbasket?
We used Source OffSite for an out source team in India we were using once upon a time. They complained that our VPN would take them hours to get latest version. SOS seemed to do a great job of allowing VSS access that was fast and reliable.
Try code model generation tools at BoneSoft.com.
-
Erik Funkenbusch wrote:
there is *NOTHING* that i've used that is easier for newbies to version control to understand.
Sure, i'll buy that. I'd never heard of source control the first time i used VSS, and i still got the hang of it in maybe an hour or two of use. A little longer to figure out merging, etc. But then i spent the next three years doing all i could to avoid using it. I'd check in my stuff when it was time for a build, but in between i stuck with my old system of batch files, zip, and a handy network drive.
Erik Funkenbusch wrote:
If all you do is is simple stuff (and don't want to learn anything complex), and you'll never use it over dialup or a WAN, and you primarily use Visual Studio, then VSS is a perfect solution.
Ok, so if you're gonna just check a couple of files in maybe once or twice a month, or you rely entirely on the VS integration (which is maddening in its own way, but i'll leave that for another discussion), then VSS is good enough. But what's the point of that? Batch files and a network drive are good enough if you're only using it occasionally, and they have even less of a learning curve since most of us were doing it that way from jump. It's like one of those cheap food processors that are just about the right size for chopping an onion, but take so long to disassemble and clean that you end up spending more time than you would have just grabbing a knife. And that's assuming you don't accidentally end up with onion puree (the corruption issues). Don't get me wrong - i work on one fairly large project that does still use VSS for everything, and we get by - at some point, i'd like to move away from it, but 'till then it is "good enough" (at least, with a bit of help from SOS it is). That said, i'm constantly aware of how much more time i spend babysitting it: checking and double-checking merges, filling out check-in comments over and over, trying to keep changes consistent across multiple branches... all stuff that i have done in seconds in Subversion, without having to even think about it. That's why i encouraged John to read the book and read up on the concepts in general. Putting in a bit more time up-front ends up saving days in the long run.
every night, i kneel at the foot of my bed and thank t
Shog9 wrote:
That's why i encouraged John to read the book and read up on the concepts in general
True, and he did express a specific interest in branching and merging.
Try code model generation tools at BoneSoft.com.
-
Mike Lang wrote:
I think this is a little extreme. So now you'll only have 20 lines of code per file, but now you'll have to many files to look through. You haven't simplified anything.
But now one person can make fixes to the ABS functionality while another is fixing another method. This is great with common routines where the methods are probably static and used throughout the application(s). Since doing this and looking at the changes in 3.0, this will be replaced with extension methods. :-D
WarePhreak Programmers are tools to convert caffiene to code.
Ware@Work wrote:
But now one person can make fixes to the ABS functionality while another is fixing another method.
I think this is the point with two features in most source control systems; auto-merge and non-exclusive checkouts. Two developers can work on two different methods in the same file, and both can check in their changes without having to manually merge the files. Off Topic:
Ware@Work wrote:
this will be replaced with extension methods.
Hopefully people aren't planning to make every method an extension method with no methods in the actual class. That would just be too hard for most developers to understand.
Michael Lang (versat1474) http://www.xquisoft.com/[^]
-
Douglas Troy wrote:
VSS 6.0d is the last release of this product; now it's that Team Server thing (I know nothing about it)
Actually, that's not true. VSS 2005 was released with VS 2005. It's not a HUGE difference from VSS 6, but it seems to be more stable, and offers some extra remote features (web checkin/out). http://msdn2.microsoft.com/en-us/vstudio/aa718670.aspx[^] Also, there's SourceOffsite that lets you use VSS client/server and make remote access much easier. I recommend *NEVER* using VSS remotely under normal conditions, there's too much risk for database damage if you do. 99.9% of peoples problems with SourceSafe database damage is related to trying to use it over flaky networking, IMO.
-- Where are we going? And why am I in this handbasket?
I think the question of source control, is mostly dependant on scale. Single Developer has the most options... If you are in a multiple developer project, you simply must use source control. If you have people scattered about the world, then VSS is likely not the best tool. (I have to admit that SVN is a much better choice than VSS for Hundreds of developers, scattered from Indiana to Mumbai.) In a small shop, its first about personal preference, then features. In a small shop, you might be the network admin, all the way to the bottle washer... the last thing you need is an Apache server for SVN, or a Square peg install of SVN on Win2K3. However, in a large professional effort, you need something more powerful, and its really no argument that SVN is a good choice over VSS. I dont agree that SVN is in any way "easier" than VSS. It's not easier to setup, its not easier to maintain, and in my humble experience I did not find it easier to use, if you consider VSS sits right inside the IDE.
Where there's smoke, there's a Blue Screen of death.
-
Ware@Work wrote:
But now one person can make fixes to the ABS functionality while another is fixing another method.
I think this is the point with two features in most source control systems; auto-merge and non-exclusive checkouts. Two developers can work on two different methods in the same file, and both can check in their changes without having to manually merge the files. Off Topic:
Ware@Work wrote:
this will be replaced with extension methods.
Hopefully people aren't planning to make every method an extension method with no methods in the actual class. That would just be too hard for most developers to understand.
Michael Lang (versat1474) http://www.xquisoft.com/[^]
That's true, but I haven't (yet) used one that does that, so I'd be nervous about whether or not it merged properly... but that's just me. On the other hand, in an organization which doesn't have a really solid coding style standard, maybe the two developers have different styles; brace placement, indenting, etc. If each tells VS to format the file his way, then the whole file will be affected, and won't that complicate things? I expect part of the check-in process could be to run the file through a company-standard beautify routine. At any rate, this leads to a question about modern CVS VCS systems... can they be set up to ignore whitespace or otherwise reduce the effects of "style"?
-
I think the question of source control, is mostly dependant on scale. Single Developer has the most options... If you are in a multiple developer project, you simply must use source control. If you have people scattered about the world, then VSS is likely not the best tool. (I have to admit that SVN is a much better choice than VSS for Hundreds of developers, scattered from Indiana to Mumbai.) In a small shop, its first about personal preference, then features. In a small shop, you might be the network admin, all the way to the bottle washer... the last thing you need is an Apache server for SVN, or a Square peg install of SVN on Win2K3. However, in a large professional effort, you need something more powerful, and its really no argument that SVN is a good choice over VSS. I dont agree that SVN is in any way "easier" than VSS. It's not easier to setup, its not easier to maintain, and in my humble experience I did not find it easier to use, if you consider VSS sits right inside the IDE.
Where there's smoke, there's a Blue Screen of death.
DumpsterJuice wrote:
developers, scattered from Indiana to Mumbai.)
I know a few who should be. :-D