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
John Cardinal wrote:
what source control systems should I look at for testing and suitability?
My recommendation would be Subversion. You are a small shop, and you are accustomed to using batch files. Although I would normally recommend a visual client like Tortoise SVN or Rapid SVN, you could actually probably use the command line version just fine. Or if you are accustomed to using expolorer like interfaces for shooting off those batch files, Tortoise SVN might be a good idea. There might have to be some more questions when you know what to ask. The other reason I mentioned SVN (subversion) is that you said the branch and merge following releases. This is the main reason we are subversion. we branch and merge often because of multiple customers. So our release schedule is insanely often, but we can't drop a customer's changes just because we started working on someone else's project. Subversion has the best of the freeware source control, and better than most commercial ones. There are some commercial ones that are better, but they much clearer advantages for larger teams. SVN also has the svnsync which lets you mirror subversion servers. I don't know your server issue, but you could even run the server off one of the desk machines with the other desk machines being self-backups of the main server. I do recommend you keep you backups as you are used to doing the habit is good for backing up your subversion system. If the scripts are as comfortable as you say, you have a great advantage in that most people who set up subversion are trying to avoid backing up (which is dangerous). Trust, but verify.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
To borrow one from Mr. Spolsky, I really think you'd be smuggy smug smug with Subversion and the Tortoise SVN shell extension. We've used it here to do exactly what Scott describes. It lets multiple people work in the same code file and it will merge automatically (unless you stepped on each other, in which case, you right-click and resolve it yourself using their built-in tool). It's been very solid for us.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Sound The Great Shofar! The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
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.
-
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 use SourceGear Vault[^]. We've generally been very happy with it. No loss of source code. It uses a SQL Server database to store the repository and history, so backing it up is simply a case of backing up the database and transaction log (once you have made a full backup, by default SQL Server assumes that you want a log backup chain [the Full recovery model] and retains transaction log records until backed up - if you don't back up the log, the transaction log just keeps growing). You should remember that whatever happens to your history, you still have the latest source on your developers' systems. You'll have to work some to merge it back together. Three years ago we used to work like you did - copy the whole source to a shared folder every night and whenever you've reached a suitable stopping point. Then we worked on a project that required three of us to work on the same deliverable simultaneously. It just wasn't feasible to do this by copying source files between developers. Slowly, source control has been adopted for every new project and as we work on older projects, they're brought in too. I've had to do concurrent development of a new version of a project and maintenance of the old one, which we did using branches and merging the changes from the maintenance code line to the new (or vice versa, depending on whether it was a fix already in the new version being backported). As long as you check in immediately before and immediately after making the fix, it's very easy to pick up the right changeset with Merge Branches - I rarely have to make many manual merges with it. Generally I don't actually make a branch whenever we make a release. Instead, I just label the project with the version number - this label is then associated with the file versions that made up the release. You can then later choose to branch at that point in the history, if need be.
DoEvents: Generating unexpected recursion since 1991 -
We use SourceGear Vault[^]. We've generally been very happy with it. No loss of source code. It uses a SQL Server database to store the repository and history, so backing it up is simply a case of backing up the database and transaction log (once you have made a full backup, by default SQL Server assumes that you want a log backup chain [the Full recovery model] and retains transaction log records until backed up - if you don't back up the log, the transaction log just keeps growing). You should remember that whatever happens to your history, you still have the latest source on your developers' systems. You'll have to work some to merge it back together. Three years ago we used to work like you did - copy the whole source to a shared folder every night and whenever you've reached a suitable stopping point. Then we worked on a project that required three of us to work on the same deliverable simultaneously. It just wasn't feasible to do this by copying source files between developers. Slowly, source control has been adopted for every new project and as we work on older projects, they're brought in too. I've had to do concurrent development of a new version of a project and maintenance of the old one, which we did using branches and merging the changes from the maintenance code line to the new (or vice versa, depending on whether it was a fix already in the new version being backported). As long as you check in immediately before and immediately after making the fix, it's very easy to pick up the right changeset with Merge Branches - I rarely have to make many manual merges with it. Generally I don't actually make a branch whenever we make a release. Instead, I just label the project with the version number - this label is then associated with the file versions that made up the release. You can then later choose to branch at that point in the history, if need be.
DoEvents: Generating unexpected recursion since 1991I like and use SGV, too. I'll second the recommendation.
Jon Sagara Once again, the conservative sandwich-heavy portfolio pays off for the hungry investor! *slurp* Oh, I'm ruined! -- Dr. Zoidberg .NET Blog | Personal Blog | Articles
-
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.
I agree. Out of curiosity, in your opinion, how many lines of code & comments in a class is "too big"?
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Sound The Great Shofar! The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
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, I have used several source control systems (Object Cycle, Borland StarTeam, Source Safe (VSS) and Subversion); but I'll only discuss the two worth mentioning: VSS and and Subversion. VSS 6.0 I use this today at home on many of my own projects. Pros: - Simple to admin - Easy to use client interface - Directly and tightly integrates into all versions of Visual Studio - I, personally, have NEVER had as single issue with this product - Allows you to work in a disconnected state (when you don't have access to your source control DB); when you reconnect, you can then check-out and/or merge changes you've made. - Everything in "one package" (you don't have to download a bunch of add-ons to get it all working) - It's Microsoft Cons: - It's not free, if you don't have a Universal Subscription - Branching and Merging has a good bit of a learning curve - Unusable over a modem, and by that I mean it's slower than two blind drunken mating snails, and damn-near unusable even over Cable via VPN. There is an add-on product that corrects this, but I've never used/tried it. - VSS 6.0d is the last release of this product; now it's that Team Server thing (I know nothing about it) - Virtual no community support for this product; most of the time, you'll only hear people complaining about how unstable it is, and how it killed an ate their first born. - It's Microsoft Tips: - Get the latest SP for this before you even dream of using it (I believe it's 6.0d) - When you create a new database with it, it will prompt you to use the newer 6.0 format, which is freak'in stupid, you should say YES (OK). Why they even ask, is beyond me. - You should run ANALYZE on the DB on a regular basis. Create a batch file to do this, and add it to task manager to run nightly. Subversion (using tortoise client) Pros: - Free - ATOMIC - Fast (even over a modem/VPN) - Cross platform - True Client/Server (and stable, from what I've heard) - Using Tortoise SVN, it's very easy to add/create new projects under Source control via it's windows shell integration - Excellent on-going community support for this product - It's not Microsoft Cons: - You're going to spend time setting up the server; no way around it. Just commit yourself to RTFM - You have to download several different projects to get: a UI, Merge Tools, Diff Tools, and integration with Visual Studio - It's not Microsoft I use both VSS and Subversion at home; I like VSS because of it's tight integration directly in Studio, and I kn
-
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 svn with apache 2.0.59 (also for my own 1 person projects). Pretty easy to setup, and you and your team members can get to your source from anywhere. First time took maybe half a day to setup, now I got the config files already and can do it in 20 mins or so on a clean machine.
Wout
-
John, I have used several source control systems (Object Cycle, Borland StarTeam, Source Safe (VSS) and Subversion); but I'll only discuss the two worth mentioning: VSS and and Subversion. VSS 6.0 I use this today at home on many of my own projects. Pros: - Simple to admin - Easy to use client interface - Directly and tightly integrates into all versions of Visual Studio - I, personally, have NEVER had as single issue with this product - Allows you to work in a disconnected state (when you don't have access to your source control DB); when you reconnect, you can then check-out and/or merge changes you've made. - Everything in "one package" (you don't have to download a bunch of add-ons to get it all working) - It's Microsoft Cons: - It's not free, if you don't have a Universal Subscription - Branching and Merging has a good bit of a learning curve - Unusable over a modem, and by that I mean it's slower than two blind drunken mating snails, and damn-near unusable even over Cable via VPN. There is an add-on product that corrects this, but I've never used/tried it. - VSS 6.0d is the last release of this product; now it's that Team Server thing (I know nothing about it) - Virtual no community support for this product; most of the time, you'll only hear people complaining about how unstable it is, and how it killed an ate their first born. - It's Microsoft Tips: - Get the latest SP for this before you even dream of using it (I believe it's 6.0d) - When you create a new database with it, it will prompt you to use the newer 6.0 format, which is freak'in stupid, you should say YES (OK). Why they even ask, is beyond me. - You should run ANALYZE on the DB on a regular basis. Create a batch file to do this, and add it to task manager to run nightly. Subversion (using tortoise client) Pros: - Free - ATOMIC - Fast (even over a modem/VPN) - Cross platform - True Client/Server (and stable, from what I've heard) - Using Tortoise SVN, it's very easy to add/create new projects under Source control via it's windows shell integration - Excellent on-going community support for this product - It's not Microsoft Cons: - You're going to spend time setting up the server; no way around it. Just commit yourself to RTFM - You have to download several different projects to get: a UI, Merge Tools, Diff Tools, and integration with Visual Studio - It's not Microsoft I use both VSS and Subversion at home; I like VSS because of it's tight integration directly in Studio, and I kn
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?
-
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?
Erik Funkenbusch wrote:
VSS 2005 was released with VS 2005. It's not a HUGE difference from VSS 6,
Thank you for the correction; I'll have to look into this myself, I have many projects until VSS 6.0d at home.
Erik Funkenbusch wrote:
99.9% of peoples problems with SourceSafe database damage is related to trying to use it over flaky networking, IMO
Now THAT I would believe. Thank you for your insight.
:..::. Douglas H. Troy ::..
Bad Astronomy |VCF|wxWidgets|WTL -
To borrow one from Mr. Spolsky, I really think you'd be smuggy smug smug with Subversion and the Tortoise SVN shell extension. We've used it here to do exactly what Scott describes. It lets multiple people work in the same code file and it will merge automatically (unless you stepped on each other, in which case, you right-click and resolve it yourself using their built-in tool). It's been very solid for us.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Sound The Great Shofar! The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
Actually, no. I would *NOT* recommend Subversion to anyone that thinks source control is too much effort for it's value. The problem is that there are a lot of concepts you need to grasp to use Subversion (and many other version control systems) well. There's a fairly steep learning curve. There's a lot of setup, and configuration, and piecing things together. Instead, i'd suggest something simple that does the basics. I'll write more in my response to him.
-- Where are we going? And why am I in this handbasket?
-
Actually, no. I would *NOT* recommend Subversion to anyone that thinks source control is too much effort for it's value. The problem is that there are a lot of concepts you need to grasp to use Subversion (and many other version control systems) well. There's a fairly steep learning curve. There's a lot of setup, and configuration, and piecing things together. Instead, i'd suggest something simple that does the basics. I'll write more in my response to him.
-- Where are we going? And why am I in this handbasket?
Really? We just installed subversion on a server, installed Tortoise on our dev machines, and we were pretty much done. What's hard about that?
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Sound The Great Shofar! The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
Erik Funkenbusch wrote:
VSS 2005 was released with VS 2005. It's not a HUGE difference from VSS 6,
Thank you for the correction; I'll have to look into this myself, I have many projects until VSS 6.0d at home.
Erik Funkenbusch wrote:
99.9% of peoples problems with SourceSafe database damage is related to trying to use it over flaky networking, IMO
Now THAT I would believe. Thank you for your insight.
:..::. Douglas H. Troy ::..
Bad Astronomy |VCF|wxWidgets|WTLI actually like VS 2005 a lot, but it's still based on the old VSS code, so take it with a grain of salt. The problem with VSS is that each client is allowed to read and write to the database files directly. This means that if a program crashes, or a link drops, in mid-write, the database can become corrupt. In systems where only the server reads and writes to the database directly, or systems that use a real RDBMS, this problem all but goes away (hardware failure can still cause problems, of course).
-- Where are we going? And why am I in this handbasket?
-
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
Subversion is the best so far. Besides the obvious pros, these features stand out for me: 1) IMHO, for source code the Copy-Modify-Merge model (like CVS) is better than Lock-Modify-Unlock (VSS). For exclusive use documents you just add the needs-lock property. 2) Directory versioning: You need to be judicious about its use, but the ability to restructure the repository in a controlled manner make SVN heads above the others. 3) Binary differencing: In particular, integration with Word and Excel.
-
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 highly recommend reading this[^] article by Hans, it's what really got me started into version control (and subversion). Seriously read that one, very simple introduction and got me started in next to no time at all. To be honest I've got some of the same opinions as you and have been messing around with a VM as a virtual machine. (been trying to get into this unit testing, continuous integration malarky) Read it, I can't emphasis it enough.
-
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
cvs and subversion are the best and most widely used source control systems. I mainly use cvs with wincvs [^]as the client. We do not lock any updates so that each user has their own read/write sandbox that they can commit to the repository whenever they need, however commits of common code are usually discussed before they are done. Backing up of the cvs server is done incrementally each night using bacula[^] and every once and a while we copy the repository to a DVD. One nice thing with cvs is the repository is stored as text files so it is easy to do maintenance and even some manual operations that are not supported by the cvs server (such as renaming a file or moving a folder).
John
-
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
You might want to read this post I wrote about 6.5 years ago: My Opinions on Source Control[^] Since then, Visual SourceSafe has improved a great deal, and other tools have come out such as SourceOffsite. VSS 2005 is actually a pretty good product. It's easy to use, and pretty reliable. I have issues largely with the branching and merging models, which most people never notice. However, I think you might be happier with something simple, like Code Co-op[^]. It doesn't have a server component, and uses email to keep everyone in sync, so each persons computer basically becomes a syncronized repository. I've never used it, though. So I can't say for sure how reliable or easy it is. See also this list of version control at Wikipedia[^]. Software I like (not necessarily in this order): * Visual SourceSafe (ease of use, doesn't do change sets though) * AccuRev (no check-in/out model is nice, just work on code, then merge it later) * Perforce (Fast and Reliable, and very strong in change sets.) * SourceGear Vault (designed to replace VSS, uses SQL Server) * Subversion (Free, and powerful, but there's a learning curve) Software I HATE (stay away from at all costs) * PVCS (* Hated with a burning passion of a billion suns) * MKS SourceIntegrity (* Similar to PVCS but not so bad, still difficult) * Borland StarTeam (Many features, some of them cool, but very slow and resource intensive) * IBM/Rational ClearCase (expensive, expensive, expensive, and frankly, stay away anything IBM/Rational)
-- Where are we going? And why am I in this handbasket?
-
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
Subversion. For one reason: the TortoiseSVN interface. There are lots of good, reliable systems out *, but nearly all of them share the same defining characteristic: their workhorse GUI interface was designed and written by folks who thought the Windows 3.1 file manager was just the best thing ever... except that it didn't have quite enough option-clogged modal dialogs. I'm not exaggerating. Tortoise fits into Explorer. You use its context menu to do all adds/deletes/renames/etc. as well as the standard check out / merge / commit ops. You can pick the options you use most and put them right on the main context menu. If you use Explorer, Tortoise is just about as painless as it gets. That said, if you're serious about it then you want to read the Subversion book first. Once you're familiar with the system, it's easy enough to set up, use, and maintain... but you really do want to be familiar with it first, or you'll likely get caught up in all sorts of bad assumptions about how it works. Especially if your previous experience with source control was with some abomination like VSS. Also worth reading: Eric Sink (of SourceGear)'s series of articles on the topic[^] (general concepts). *****and, of course, VSS... but seriously, don't consider VSS, just don't, or you'll end up hating source control more than ever by the time you're done. For real. I hated source control, 'till i found out that VSS wasn't the norm. Now i just hate VSS.
----
I don't care what you consider witty, but at least I do not blather on posting nonsense like Jim Crafton.
-- Stringcheese, humbled by Crafton's ability to string together multiple sentences
-
Really? We just installed subversion on a server, installed Tortoise on our dev machines, and we were pretty much done. What's hard about that?
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Sound The Great Shofar! The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
The installation is easy, it's the rest that requires the learning curve.
-- Where are we going? And why am I in this handbasket?
-
Subversion. For one reason: the TortoiseSVN interface. There are lots of good, reliable systems out *, but nearly all of them share the same defining characteristic: their workhorse GUI interface was designed and written by folks who thought the Windows 3.1 file manager was just the best thing ever... except that it didn't have quite enough option-clogged modal dialogs. I'm not exaggerating. Tortoise fits into Explorer. You use its context menu to do all adds/deletes/renames/etc. as well as the standard check out / merge / commit ops. You can pick the options you use most and put them right on the main context menu. If you use Explorer, Tortoise is just about as painless as it gets. That said, if you're serious about it then you want to read the Subversion book first. Once you're familiar with the system, it's easy enough to set up, use, and maintain... but you really do want to be familiar with it first, or you'll likely get caught up in all sorts of bad assumptions about how it works. Especially if your previous experience with source control was with some abomination like VSS. Also worth reading: Eric Sink (of SourceGear)'s series of articles on the topic[^] (general concepts). *****and, of course, VSS... but seriously, don't consider VSS, just don't, or you'll end up hating source control more than ever by the time you're done. For real. I hated source control, 'till i found out that VSS wasn't the norm. Now i just hate VSS.
----
I don't care what you consider witty, but at least I do not blather on posting nonsense like Jim Crafton.
-- Stringcheese, humbled by Crafton's ability to string together multiple sentences
Shog9 wrote:
but seriously, don't consider VSS, just don't, or you'll end up hating source control more than ever by the time you're done. For real. I hated source control, 'till i found out that VSS wasn't the norm. Now i just hate VSS.
Lol. I can understand that. VSS has a lot, and I do mean a lot of quirks and issues, but there is *NOTHING* that i've used that is easier for newbies to version control to understand. And, for the vast majority of projects, it does everything they need. Versioning, Tagging, Merging, Comparing, etc.. The problems typically come when you want to do things VSS doesn't do, or doesn't do well, such as branch/merge/branch again, and it's ansanely stupid "file linking" feature. The thing is, software like Subversion is very power, and very extensive. But that comes at the cost of having to learn a lot about the process of revision control. If all you want to do is check in, check out, and occasionally branch off a new tip, then subversion is a lot to learn for a small payoff. Seriously. 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.
-- Where are we going? And why am I in this handbasket?
-
cvs and subversion are the best and most widely used source control systems. I mainly use cvs with wincvs [^]as the client. We do not lock any updates so that each user has their own read/write sandbox that they can commit to the repository whenever they need, however commits of common code are usually discussed before they are done. Backing up of the cvs server is done incrementally each night using bacula[^] and every once and a while we copy the repository to a DVD. One nice thing with cvs is the repository is stored as text files so it is easy to do maintenance and even some manual operations that are not supported by the cvs server (such as renaming a file or moving a folder).
John
Why CVS Sucks[^] CVS Sucks[^] Bye Bye CVS. I've been Subverted[^]
-- Where are we going? And why am I in this handbasket?