Source control redux
-
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?
-
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?
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
-
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)
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
-
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
I agree, the branching problems are a mess. But that's only really an issue if you branch, merge and rebranch. I find the best way to use branching is one-way. When you get to a release, you branch a new tip and then break all the links and never look back. You will save yourself a lot of headache, and simplify the process that way. In this model, each Release becomes it's own "Project" in VSS terms. The Multiple comments issue is easy enough to deal with by copy and pasting your comment into each file check-in (and yes, it's highly annoying I agree). However, my point is not that VSS is a great, or even good version control system. But just that for simple use (and no, I don't mean doing check-ins every few months, I mean daily checkins or whenever your work is in a stable state) it's VERY easy to learn and does the job without much fuss. There are a lot of better, more powerful, less annoying to powerusers version controls out there.. and SVN is one of them. It's just for a guy that complains that version control takes too much of his time, i think SVN is too much.
-- Where are we going? And why am I in this handbasket?
-
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
I'm just throwing this out as a bit of an oddball, but keepsafe sounds like it'd be the perfect minimalist source control app for someone who doesn't want to bother with any overhead. The idea is that you tell it what folders to archive and every time you save a new version of the file it automatically stores a backup of the old one for you. That said, while I do have a copy of it at home (bundled with multiplicity) I've never actually gotten around to installing and trying it out. http://www.stardock.com/products/keepsafe/[^]
-- If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
-
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
As an added consideration, SourceGear Vault is free for a single user.
Why is common sense not common? Never argue with an idiot. They will drag you down to their level where they are an expert. Sometimes it takes a lot of work to be lazy The people in the lounge said I should google for the answer to a programming question but I do not know what search engine to use
-
That's excellent, thank you.
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
I've also found the posts on this guys blog[^] to be very useful, even though they don't directly relate to me at the moment. OT: do you use something for bug tracking etc? I've been looking at Axosoft's OnTime[^], their web-ui has been updated to include AJAX (one of the first I think) but it's supposed to be able to integrate with Subversion (not sure if it's out of the box) to track bugs in source as well.
-
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
John Cardinal wrote:
Now that is unequivocally stupid.
I agree that is why we have backups, and live swap-over systems, we have backups of backups. In my business, it doesn't pay to be down.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)