Source control redux
-
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!
-
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
For a Source control *redux*, I would surely recommend VSS. It's installation is just point and click, and it is integrated with all the MS tools right out of the box. You don't need to read any help files or manuals. *It just works.* I have been working with it since 1995 and never had any troubles, except for a corrupted hard drive (but that's what backups are for, right?). It has all the basic things in it, except for the more advanced stuff, like automatic merging of versions (anyway, I like to do it manually) or product (as in multiple projects) version and release management. I think the fact that it hasn't changed much for the last 10 years speaks for its usability and robustness. That fact, together with massive use (it is too easy to setup and use) accounts for "all" the criticism. JP
-
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.
Just to complement the information, there is a FREE Open Source File comparison tool called WinMerge: http://winmerge.org/[^] It is a very active project with constant improvements. (project at http://sourceforge.net/projects/winmerge/[^]) It does everything I ever needed: file comparison and merging, directory comparison and merging, colour coding, zip (7zip support) or compressed folder comparison, VSS integration, etc. The user interface rocks - it is extremely easy to learn. JP
-
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, I have a couple of other comments about Subversion that I haven't seen yet. #1. I suggest subscribing to the Subversion Users mailing list (at http://subversion.tigris.org). It gets a fair bit of traffic, but I think you'll find a number of experts regularly post, including the developers. #2. You do not need a server to use Subversion, though using one is recommended for more than the simplest implementation. However, a local repository is perfect for testing whether or not you like the product or to perfect the understanding of some features. In addition, if you use a local file based repository, you don't even need to install Subversion itself, TortoiseSVN alone is sufficient. #3. Even if you do decide you need a server, there are two different types of server you can use, an Apache based web server solution and a daemon or service based one. And even though this one has been suggested before, I'll reiterate it. Read the red-bean book. It's a valuable resource not just for Subversion, but for version control in general. Brad
-
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've recently come full circle on this source control topic. After trying to use subversion, and having little success, I started to question the "Conventional Wisdom" out there, that says that VSS is horrid. First - Tell me why you think its horrible: Is it VPN? Ok, that is valid, its improved greatly in the latest version, but still its slow. Is it slower than everything else? Is it slower than Subversion? Lets see some data on that.... Is it because of Pessimistic locking? That is now a setting in VSS now.. and its always supported optimistic locking, in a "work around" sort of way... using "Get Latest Version" ...which I have come to respect. You nkow ahead of time that there might be problems merging back... and you can plan for some time to make that smooth. I like my source control IN the IDE, ..not in Explorer thank you very much.... I like my source control to be so easy, nobody can find a reason to avoid using it. I like it to be "Not in the Way", and not add more Admin activities to the team... (Subversion and Tortoise, besides having to teach everyone how to use these, need a lot of TLC on the server side.) So - I am saying: Take another look at VSS, and stop going with the latest thing people think is so sexy... Subversion is not as easy to implement in team dev as has been said.... and I see no Cost / Benefit by using it. Also - Ask me about how we tried to implement Microsoft Team Foundation Server, and then discarded it, as Alpha ware crap. Another product that is too expensive, tries to do too much, and does nothing particularly well. We try to develop software, not spend all day as network admins, or Beta Testers.
Where there's smoke, there's a Blue Screen of death.
-
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
I'm not surprised you were down on this: source control is one of those tasks that is generally resented until the first time you really (really) need it - after that you won't look back. One of those 'voice of experience/burned' things. If you want to keep it simple, SubVersion with Tortoise is stunningly easy to use for the basics. But decide what you want it to do up front and consider the layout of what you will be storing - changing most source control systems mid-stream is a pig. "Baffled"
-
Ok, after the major flamefest yesterday over my assertion that I personally in my shop had no use for source control a lone member of this board finally posted a single point that convinced me it might be a good idea if it doesn't slow us down too much and is a reliable product that will *NEVER LOSE OUR CODE*. Full credit to Scott Dorman in this post[^] for bringing up the entirely valid and useful point that, while we never release branch versions of our software, we do actually have a branch when we release a new version and want to separately work on the next release and bug fix of the old released version then merge them later. That's a brilliant point that I had never thought of and no one else suggested but Scott. I see subversion mentioned a lot, I also see VSS mentioned in a negative way a lot. This will be new for me and this is not hobby code it's very valuable code for a world wide used software product, I can't take any chances on losing anything. So my question is, given I want as little hassle as possible but still need something that can do the above and not much else, what source control systems should I look at for testing and suitability?
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
We are in the process of switching from VSS to subversion. The trouble we had with VSS 6.0 is its repository kept getting corrupted. Also VSS is supposed to have a merge capability but we never figured out how to use it. So far subversion is very nice. We figured out merging right away. Having all changes be transactional (all or nothing) gives us confidence it is taking good care of the source code.
-
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, My four-person shop uses CVS. CVS is a predecessor to Subversion and is available on Windows and Un*x platforms. There is a TortoiseCVS plugin available that makes using CVS a pretty easy proposition from the Windows Explorer. Icons with a green highlight are checked in -- or at least, are the same as they were when checked out; icons with an orange hue have been modified. You use CVS as follows: check out a module, which makes a copy in your local CVS 'sandbox'. Edit it. Check it back in. If all goes well, nobody else has changed the same module, and you're done. If somebody else was working on that module and checked their changes in first, the client alerts you, and makes a local copy of the checked in version in your CVS sandbox with a slightly different file name. You can then use your favorite diff tool to figure out what needs to be altered to make the two versions one again, and then after you're done editing, you check it in. (My current favorite diff tool is DiffMerge.) If you want to make sure your copy of the module is current, say before you make changes, you perform a CVS update on it, and the tool will automatically rev the copy in your sandbox. Using the TortoiseCVS tool, you can get a chart of all the versions of the code, and perform diffs between them to see what changed where. We primarily develop in both Perl as well as C#. We're also using CVS to store our documentation, our Makefile, some small GIFs used in the web pages, etc. We have also used it in the past to store a 30+MB MSI installation file, so it can handle big stuff if need be. The big thing with this tool, and I'm sure with others like it, is the preparation you have to do before you implement it. I personally am on my second implementation of the CVS repository, because I didn't want to live with all of the mistakes I made during the first implementation. These mistakes were really ideas that seemed good at the time, but later proved to be a hassle. For example, before we went to automated builds of all our code using make and msbuild, I was manually building each program, and storing it in a separate subdirectory in the CVS repository, and then copying it to a \binaries subdirectory under the MSI CVS module. That was more work than the small benefit of having the built binaries in the repository was worth! Our current repository structure looks a little like this: \ --Server modules -----Module S-A -----Module S-B -----Module S-C.... --Client Modules -----Module C-A -----Module C-B
-
Ok, after the major flamefest yesterday over my assertion that I personally in my shop had no use for source control a lone member of this board finally posted a single point that convinced me it might be a good idea if it doesn't slow us down too much and is a reliable product that will *NEVER LOSE OUR CODE*. Full credit to Scott Dorman in this post[^] for bringing up the entirely valid and useful point that, while we never release branch versions of our software, we do actually have a branch when we release a new version and want to separately work on the next release and bug fix of the old released version then merge them later. That's a brilliant point that I had never thought of and no one else suggested but Scott. I see subversion mentioned a lot, I also see VSS mentioned in a negative way a lot. This will be new for me and this is not hobby code it's very valuable code for a world wide used software product, I can't take any chances on losing anything. So my question is, given I want as little hassle as possible but still need something that can do the above and not much else, what source control systems should I look at for testing and suitability?
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
We've been using SourceGear Vault here now for a while, it's quite simple but powerful at the same time. We use to have Seapine Surround installed but found it far to slow when checking in/out projects bigger than a few files. As for never losing code, SourceGear has a backup system build into it and it holds everything in an SQL database so that can be backed up as well.
-
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.
This is certainly off topic, but I couldn't ignore this.
PIEBALDconsult wrote:
Acme.Math.Abs.cs might contain: Acme.Math.Abs ( int ) , Acme.Math.Abs ( double ) , etc.
I think this is a little extreme. So now you'll only have 20 lines of code per file, but now you'll have to many files to look through. You haven't simplified anything.
PIEBALDconsult wrote:
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.
Maybe data access for each of these entity types should just be a different class, not just a different partial class file! If you have a single class file that is "too big", then maybe that class is doing too much. Refactor, Refactor, Refactor. The best usefullness of partial classes is to separate auto-generated code from manually generated code.
Michael Lang (versat1474) http://www.xquisoft.com/[^]
-
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!
Reinier Boon wrote:
To master the more complex stuff (like branching, tagging, restoring a previous version...
True, but that is the case with any source control system. :laugh: It's not that subversion makes it much harder, if at all, than any other source control system.
Michael Lang (versat1474) http://www.xquisoft.com/[^]
-
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
I use Component Software's CS-RCS (it supports CVS too), its a nice tool but not free if your doing for profit code. I use it as a single developer for a hospital (php scripts, sql, vb, C++ etc). As far as the single user version goes it is very easy, it even plugs right into windows, so if you right click on a file, or are using word or whatever, you have an option, "check in to RCS". There is a multiple simultaneous user version, that you have to pay for, I haven't tried it, but if it is anything like the standalone version it would be nice as well. P.S. It probably goes without saying but you get the option showing up in Visual Studio as well. I don't agree with the posts saying that source control has a step learning curve. You can get by with just check out, check in, you'll get prompted for a message on checkin, there I put what I changed and a brief explanation of what remains to be done for the method if not complete. If the source control system is configured properly only one person will have the rights to check in their modified version of the program.