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
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)
-
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?
Erik Funkenbusch wrote:
However, my point is not that VSS is a great, or even good version control system.
I know, and i'm not trying to draw you into an argument as the VSS Apologist. But,
Erik Funkenbusch wrote:
It's just for a guy that complains that version control takes too much of his time, i think SVN is too much.
...that's why i recommended TortoiseSVN. I mean, really, it just doesn't get any easier for the simple stuff. I committed ten files' worth of changes earlier today, spread across three projects and including three deletions, an add, and one changed file that wasn't committed because the only change was made for testing locally - something i identified by viewing a diff for that one file from the commit dialog that listed all of them. There was a conflict, so i took care of that. All of this done in about a minute, from the Open File dialog in VSS ('cause that was convenient at the time). Also, i was talking on the phone. This is the sort of thing that, for me, makes source control worthwhile. It's quick and easy, so i don't mind doing it. Because it's quick and easy, i have a rich history of changes, and can roll back or selectively merge in things i've tried and abandoned. It's actually made me use source control for experimental and prototype projects, things that may never actually see the light of day, but which, when it comes time to do it for real, might have enough history to refresh my memory as to what worked and what didn't even if i never bothered to write it down in the heat of the moment. This is what i mean when i say i no longer hate source control - with VSS, i'd spend all day in VSS, except i'd be working on a branch that couldn't easily be merged back into the main source, so after spending all day in VSS, i'd spend all night manually merging the few changes i'd managed to actually find time to make. VSS introduced me to source control, but introduced it as a tool with 90% overhead. And what's the point of a tool that's mostly overhead?
every night, i kneel at the foot of my bed and thank the Great Overseeing Politicians for protecting my freedoms by reducing their number, as if they were deer in a state park. -- Chris Losinger,
-
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
mob: " Code versions? Why the hell we need em.. we simply hate them". :) And for a versioning system, I would suggest, Rational ClearCase, but before that you would need to sell some of your properties.
The Advantage in work-from-home is that... we can blame the dog -Mark Salsbery Best wishes to Rexx[^]
-
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
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.
-
Erik Funkenbusch wrote:
However, my point is not that VSS is a great, or even good version control system.
I know, and i'm not trying to draw you into an argument as the VSS Apologist. But,
Erik Funkenbusch wrote:
It's just for a guy that complains that version control takes too much of his time, i think SVN is too much.
...that's why i recommended TortoiseSVN. I mean, really, it just doesn't get any easier for the simple stuff. I committed ten files' worth of changes earlier today, spread across three projects and including three deletions, an add, and one changed file that wasn't committed because the only change was made for testing locally - something i identified by viewing a diff for that one file from the commit dialog that listed all of them. There was a conflict, so i took care of that. All of this done in about a minute, from the Open File dialog in VSS ('cause that was convenient at the time). Also, i was talking on the phone. This is the sort of thing that, for me, makes source control worthwhile. It's quick and easy, so i don't mind doing it. Because it's quick and easy, i have a rich history of changes, and can roll back or selectively merge in things i've tried and abandoned. It's actually made me use source control for experimental and prototype projects, things that may never actually see the light of day, but which, when it comes time to do it for real, might have enough history to refresh my memory as to what worked and what didn't even if i never bothered to write it down in the heat of the moment. This is what i mean when i say i no longer hate source control - with VSS, i'd spend all day in VSS, except i'd be working on a branch that couldn't easily be merged back into the main source, so after spending all day in VSS, i'd spend all night manually merging the few changes i'd managed to actually find time to make. VSS introduced me to source control, but introduced it as a tool with 90% overhead. And what's the point of a tool that's mostly overhead?
every night, i kneel at the foot of my bed and thank the Great Overseeing Politicians for protecting my freedoms by reducing their number, as if they were deer in a state park. -- Chris Losinger,
I agree with you that once you know SVN and (and Tortoise) it's very easy to use. And it's certainly come a long way since the days when you had to configure the servers manually, and what not. But there is a lot to know to use it effectively. That was one reason I recommended Code Co-Op. No server to setup, easy to manage, IDE plug-ins, only basic features... I guess my point is simply that VSS, despite it's problems and limitations, shouldn't be dismissed out of hand. And that there are solutions other than SVN that are a lot easier for a newbie, who doesn't want to spend all their time learning about the concepts of version control. If you want a powerful SCS that's easy to use after some learning, then SVN is a good choice. If you don't want a powerful SCS that's intuitive to use out of the box, then there are other choices.
-- 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
John Cardinal wrote:
Full credit to Scott Dorman in this post[^]
Thanks John! I never expected my argument would actually cause you to change your position. I'm going to finish reading through the replies before I make further comments/suggestions.
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]
-
I agree with you that once you know SVN and (and Tortoise) it's very easy to use. And it's certainly come a long way since the days when you had to configure the servers manually, and what not. But there is a lot to know to use it effectively. That was one reason I recommended Code Co-Op. No server to setup, easy to manage, IDE plug-ins, only basic features... I guess my point is simply that VSS, despite it's problems and limitations, shouldn't be dismissed out of hand. And that there are solutions other than SVN that are a lot easier for a newbie, who doesn't want to spend all their time learning about the concepts of version control. If you want a powerful SCS that's easy to use after some learning, then SVN is a good choice. If you don't want a powerful SCS that's intuitive to use out of the box, then there are other choices.
-- Where are we going? And why am I in this handbasket?
Erik Funkenbusch wrote:
If you want a powerful SCS that's easy to use after some learning, then SVN is a good choice. If you don't want a powerful SCS that's intuitive to use out of the box, then there are other choices.
I think we can agree on that. :)
every night, i kneel at the foot of my bed and thank the Great Overseeing Politicians for protecting my freedoms by reducing their number, as if they were deer in a state park. -- Chris Losinger, Online Poker Players?
-
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.
PIEBALDconsult wrote:
That's good, but it shouldn't be a frequent occurence if the files are kept small.
Even in large files, it really shouldn't be a frequent occurence except possibly during a maintenance phase.
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]
-
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:
That would actually be very useful if we could sync to our L.A. server and here in house for added protection.
I haven't used svnsync before, but my understanding is that it would allow you to do that.
John Cardinal wrote:
El Corazon wrote: most people who set up subversion are trying to avoid backing up Now that is unequivocally stupid.
I completely agree with you on this point. Having a source control system is not a replacement for a good backup strategy.
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]