Source control redux
-
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
-
I just checked it and it's working for me...
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]
That's funny, I tried it when I got your message and now it comes up and the pages look different than the ones I was getting earlier, they must have been re-jigging the site.
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
-
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
John Cardinal wrote:
it's the how that I have to examine carefully and what the consequences etc
Yes, from my experience the branching and merging concept is the one that most easily confuses people (developers, technical dev managers, and admins). It's important enough to really think through how you are going to do it and what the outcomes of the different strategies are. In some cases, it can influence the way you structure the repository.
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]
-
That's funny, I tried it when I got your message and now it comes up and the pages look different than the ones I was getting earlier, they must have been re-jigging the site.
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
You're right. I didn't even notice that the pages are different. You must have caught them right in the middle of the upload. :)
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]
-
Hi Ed, we use FogBugz for bug tracking currently. I'll check that out.
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.
I've used both FogBuz and OnTime. I prefer the interface of FogBugz, but the sheer volume of tracking features in OnTime and the fact that it does more than bug-tracking is a huge benefit to us.
Deja View - the feeling that you've seen this post before.
-
I've used both FogBuz and OnTime. I prefer the interface of FogBugz, but the sheer volume of tracking features in OnTime and the fact that it does more than bug-tracking is a huge benefit to us.
Deja View - the feeling that you've seen this post before.
-
It's good software, it could be better but I bought it more out of support for Joel than anything else. I.E. I didn't look too hard for alternatives once I saw it would do the job.
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
-
That's what I've been thinking about, it at least has some features for feature tracking etc which will be nice to have integrated. It's nice to hear someone elses opinions of this.
To be honest - we've started rolling our own bugtracker to combine the interface ideas of FogBugz with the feature set of OnTime. It's primarily intended for internal use, but if we get it to a point where we are happy with it we'll possibly look at licensing it out.
Deja View - the feeling that you've seen this post before.
-
To be honest - we've started rolling our own bugtracker to combine the interface ideas of FogBugz with the feature set of OnTime. It's primarily intended for internal use, but if we get it to a point where we are happy with it we'll possibly look at licensing it out.
Deja View - the feeling that you've seen this post before.
-
Ok, after the major flamefest yesterday over my assertion that I personally in my shop had no use for source control a lone member of this board finally posted a single point that convinced me it might be a good idea if it doesn't slow us down too much and is a reliable product that will *NEVER LOSE OUR CODE*. Full credit to Scott Dorman in this post[^] for bringing up the entirely valid and useful point that, while we never release branch versions of our software, we do actually have a branch when we release a new version and want to separately work on the next release and bug fix of the old released version then merge them later. That's a brilliant point that I had never thought of and no one else suggested but Scott. I see subversion mentioned a lot, I also see VSS mentioned in a negative way a lot. This will be new for me and this is not hobby code it's very valuable code for a world wide used software product, I can't take any chances on losing anything. So my question is, given I want as little hassle as possible but still need something that can do the above and not much else, what source control systems should I look at for testing and suitability?
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
-
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
One thing - if you go for version control you will need a good diff tool when merging. The best I've seen is Beyond compare[^]. Elaine :rose:
Visit http://www.readytogiveup.com/[^] and do something special today.
-
It'd be interesting to see what you come up with. I've thought about this myself but couldn't really be bothered.
Tell you what. When we've finished the prototype, I'll send you a copy. You could be an unnofficial beta tester.:-D
Deja View - the feeling that you've seen this post before.
-
Ok, after the major flamefest yesterday over my assertion that I personally in my shop had no use for source control a lone member of this board finally posted a single point that convinced me it might be a good idea if it doesn't slow us down too much and is a reliable product that will *NEVER LOSE OUR CODE*. Full credit to Scott Dorman in this post[^] for bringing up the entirely valid and useful point that, while we never release branch versions of our software, we do actually have a branch when we release a new version and want to separately work on the next release and bug fix of the old released version then merge them later. That's a brilliant point that I had never thought of and no one else suggested but Scott. I see subversion mentioned a lot, I also see VSS mentioned in a negative way a lot. This will be new for me and this is not hobby code it's very valuable code for a world wide used software product, I can't take any chances on losing anything. So my question is, given I want as little hassle as possible but still need something that can do the above and not much else, what source control systems should I look at for testing and suitability?
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
Welcome on the light side of the force. Subversion does a good job, offers all the needed functionalities and is free. We make it run on a source server on FreeBSD, equipped with backup facilities. To interface subversion on our windows workstations, we use TortoiseSVN as a graphical interface that enables to pilot subversion from contextual menus in Explorer. For safety and authentication we use ssh in between with Pageant from PuTTY on the workstations as SSH authentication agent. Once set, this configuration is smooth to use and secure, and all software components are free. For the one-developer case, you could use only TortoiseSVN in a purely windows environment. TortoiseSVN also has source control possibilities but is less powerful than SVN.
Patriotism is when love of your own people comes first; nationalism, when hate for people other than your own comes first Fold with us! ¤ flickr
-
The installation is easy, it's the rest that requires the learning curve.
-- Where are we going? And why am I in this handbasket?
I can recommend subversion wholeheartedly. There is an excellent subversion book (in HTML) explaining all the concepts very well (check http://svnbook.red-bean.com/). Once you've set things up, you can easily integrate with the Windows shell (TortoiseSvn), and with Eclipse (e.g. Subversive). The daily routine is just two clicks and adding some comment. To master the more complex stuff (like branching, tagging, restoring a previous version, merge other peoples changes with your changes) I can advise to create a little test repository, and just play around with it. You'll quickly get the idea. You have to invest a few hours, but they'll be worth every second!