Source control redux
-
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]
-
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?
Lol. Ok, so maybe that was a Freudian slip... ;) I meant, If you want something simple that won't overpower you with features, and will be intuitive to use out of the box, there are other choices.. lol...
-- Where are we going? And why am I in this handbasket?
-
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.
-
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'm an *extremely* practical guy, the second I see anything of any benefit to me I'm all over it. You were the first one to suggest a solution to an actual scenario that we face.
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 1991I second that too. Also, since you're a single developer, SourceGear Vault offers a trial mode that is fully functional for a single user. I'm a single developer too, and since I'm a student I couldn't afford buying it. But this single user thing, well, gave me a HUGE advantage over my colleagues that don't use source control for their projects (well, they even aren't accustomed to zip backups, but who am I to change the concept that our seventy-years-old programming teacher taught them? For him, these are just a waste of disk space...).
Luca
The Price of Freedom is Eternal Vigilance.
En Það Besta Sem Guð Hefur Skapað, Er Nýr Dagur. But the best thing God has created, is a New Day.
-
Lol. Ok, so maybe that was a Freudian slip... ;) I meant, If you want something simple that won't overpower you with features, and will be intuitive to use out of the box, there are other choices.. lol...
-- Where are we going? And why am I in this handbasket?
:D
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?
-
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
ionForge Evolution is free for single licence users. While you may not think that version tracking is useful I'm now convinced that simply being able to go back and compare the changes I made 2 weeks ago with current code has saved me immense amounts of time and pain.
cheers, Chris Maunder
CodeProject.com : C++ MVP
-
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
Not to jump on the "bandwagon", but my choice would be Subversion (SVN). I use it on several open source projects that I work on and have had virtually no issues with it. The repository is accessible via a web address (either internal or external, secured or not) and downloading the repository for the first time is relatively fast. A few people pointed out some resources on either SVN or source control concepts in general, which are all good to look at. The area that can cause the most headache in any source control system is the idea of branching and merging. It is important to have a good understanding of how those concepts work in the chosen system, but it is also equally important to have a well thought out plan in place for when branches occur. Some questions to ask are:
- Should the branch occur immediately after the version ships?
- Should the branch occur when the first bug is received?
- Should the branch be allowed to be branched?
- When (and how often) should the branch be merged back to the trunk?
One thing you might want to consider is to set up a test repository to work out some of the implementation kinks you might run into. Then once you are comfortable with how everything is functioning, use a small project (if you have any) or possibly an isolated portion of an existing project as a pilot project. The assertion that you want a product that is guaranteed to never loose your code is valid, but I don't know of anything that can actually guarantee that 100%. That being said, as long as you continue a regular backup strategy on the repository you should be fine.
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]
-
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
-
Unfortunately their site seems to be down, is this a normal thing or... http://tortoisesvn.net/[^]
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
I just checked it and it's working for me...
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]
-
Not to jump on the "bandwagon", but my choice would be Subversion (SVN). I use it on several open source projects that I work on and have had virtually no issues with it. The repository is accessible via a web address (either internal or external, secured or not) and downloading the repository for the first time is relatively fast. A few people pointed out some resources on either SVN or source control concepts in general, which are all good to look at. The area that can cause the most headache in any source control system is the idea of branching and merging. It is important to have a good understanding of how those concepts work in the chosen system, but it is also equally important to have a well thought out plan in place for when branches occur. Some questions to ask are:
- Should the branch occur immediately after the version ships?
- Should the branch occur when the first bug is received?
- Should the branch be allowed to be branched?
- When (and how often) should the branch be merged back to the trunk?
One thing you might want to consider is to set up a test repository to work out some of the implementation kinks you might run into. Then once you are comfortable with how everything is functioning, use a small project (if you have any) or possibly an isolated portion of an existing project as a pilot project. The assertion that you want a product that is guaranteed to never loose your code is valid, but I don't know of anything that can actually guarantee that 100%. That being said, as long as you continue a regular backup strategy on the repository you should be fine.
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]
Yeah I'm going to try subversion and tortoise today. Sadly the tortoise site seems to be down and I can't download or read any of the faq's etc. Most links are dead except unsurprisingly the donate link. :) I'm going to jump right in with a test of my largest project and experiment with a copy of it. I think the when and why to merge / branch etc seems to be self explanatory it's the how that I have to examine carefully and what the consequences etc are.
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land