Source Control
-
CS-RCS is a fairly decent file-based version control system for Win9x/NT/2k. It integrates itself with Explorer, so it's not centralized to any one directory branch. It's free for a one-user license, and fairly inexpensive for multiple seats (sort of a peer-to-peer, client/server mix). Visit Component Software's web site for the full details. Later, Jason
I would second this... This is what I am using now, having moved from a company with an impossibily small budget to one with no budget at all. CS-RCS integrates with Visual Studio in exactly the same way as SourceSafe does, but it uses long-proven RCS technology, rather than whatever Microsoft did.
-
I have used Sourcesafe, PVCS, and one not mentioned so far, TLIB. I only acted as the administrator for the TLIB, the others being at large companies that I worked for or was seconded to. PVCS seemed to be difficult to administer, as the previous correspondent stated, although I have no concrete evidence of this. SourceSafe is the only one where serious problems happened, of the order of losing changes / source files. It seems to be as stable as any other Microsoft product, read into that, what you will :) TLIB was originally chosen by us because it was inexpensive, around 500 UK pounds for up to five developers as opposed to 500 UKP per seat for PVCS, but when it arrived it was so much easier to use I was very glad that my boss was 'not tight, but poor', his words not mine :)
Your comment about VSS losing changes requires some comment. VSS requires some maintenance. You need to run the analyze utility regularly and fix and compress the database. Additionally, you need to have a decent network, as network flakiness can cause corruption (this is true of any file based system, such as PVCS, MKS SI, etc. If a network glitch happens while you are writing the file, it will be corrupted.) I've used VSS with more than 150 developers on literally hundreds of projects. It requires a little work, but not much and certainly much less than most of the competitors. Having said that, I'm not all that fond of VSS for a number of reasons, which are not related to the issues you bring up here. My issues are with the promotion and branching models, and with distributed use. It's almost impossible to run correctly over multiple time-zones for instance.
-
I would second this... This is what I am using now, having moved from a company with an impossibily small budget to one with no budget at all. CS-RCS integrates with Visual Studio in exactly the same way as SourceSafe does, but it uses long-proven RCS technology, rather than whatever Microsoft did.
"Whatever Microsoft did"? SourceSafe is a more than 10 year old product. MS bought it from a company called OneTree 6 years ago, it's been in use for a very long time in hundreds of thousands of companies. RCS has it's own faults and limitations as well. For instance, it uses a first-delta system where each change is a diff from the previous version, which means that as the number of version increase, so does the work and time necessary to get to the most current version, since it must apply hundreds of diffs to get to the final output. SourceSafe uses a last-diff method, where the most recent version is always saved and previous versions are diffed backwards. While this may seem like it's the same thing, it's not. The most recent, or more recent versions are the more common situation than retrieving the original version.
-
"Whatever Microsoft did"? SourceSafe is a more than 10 year old product. MS bought it from a company called OneTree 6 years ago, it's been in use for a very long time in hundreds of thousands of companies. RCS has it's own faults and limitations as well. For instance, it uses a first-delta system where each change is a diff from the previous version, which means that as the number of version increase, so does the work and time necessary to get to the most current version, since it must apply hundreds of diffs to get to the final output. SourceSafe uses a last-diff method, where the most recent version is always saved and previous versions are diffed backwards. While this may seem like it's the same thing, it's not. The most recent, or more recent versions are the more common situation than retrieving the original version.
A couple of hours ago I went ahead and downloaded/installed RCS on my NT box here at work. I have a couple of projects already working fine on SourceSafe but I figured I'd give RCS a look. It installed fine and after I rebooted the machine (which it made me do) I fired VC++ back. Well guess what? I started getting errors about my project not being in the Source Control path where it had been mapped to! I guess RCS quietly took over as the Source Control system for VC++. So I couldn't do any work. I had to uninstall RCS and reboot once again. When I fired VC++ again, I discovered that it now had no Source Control system installed on it! So I had to uninstall VSS and install it again. That brought me back to normal again, thank God. I'm not putting down RCS; just commenting on my scary experience with it. By the way Erik, I thought your analysis of Source Control systems was incredible. Thanks for taking the time to give your well needed opinion on so many products. Regards, Alvaro
-
What is "better" depends entirely on your parameters and persepctive. You need to weigh lots of options: Cost, speed, features, user friendliness, newbie friendliness (ie how much will it cost to train people), architecture (client/server vs file based), and many more. Microsoft's Visual SourceSafe is a very easy to use product that requires very little training to be up and running, and only minimal effort to learn the more advanced features. It's drawbacks are that it's file based, which means data corruption can be an issue as well as the fact that it works poorly over WAN's. Starbase's StarTeam is also fairly easy to use, but has many more features and can be quite overwhelming at times. It's client/server, but it's also quite slow. It's also a bit more pricey, and has lots of quirks an annoyances (as most products do). CVS is free, and is client-server, but it's command line based and has very limited support for advanced SC features such as promotion models, workspaces, and change lists. It has several free "GUI front ends", but they all have basic issues to deal with. Perforce is very fast and has lots of nice features. It runs on lots of hardware and OS's, and they offer an "open source" license where if you are creating free open source projects, you get free licensing. It's client-server and i've found it to be quite useful, however it's a bit pricey for commercial use and it's also a command line product with a very poor GUI. AccuRev is a very nice product, again it's command line based and client-server. It's GUI is a little better than the free CVS versions and Perforce, and they have some very interesting features which include developer workspaces and promotion. PVCS... Ugh.. I hate this product and can't really give an unbiased review of it. I hate it.. I hate it.. I hate it... It's file based (non-client/server), very complicated and requires a dedicated administrator. It has promotion and a number of other features, but good luck trying to figure out how to make them work. It's GUI is quit complex and gives you lots of options, but it's still awful. Ugly. Difficult to use. MKS Source Integrity. This product is similar to PVCS, but much easier to use, and not quite so feature laden. I'm not very fond of it either. Basic Unix mindframe here applied to windows. Rational ClearCase: Very expensive, and expensive too. Did I mention expensive? It's also expensive. It has lots of nice features though, and is very good for an enterprise level source control
Thanks Eric (and everyone else) This is precisely what I was looking for - a bit of 'real world' feedback on some of the products available. It's easy to find products and download demos, but it takes a LONG time to work through them all and get a feel for the relative strengths and weaknesses. And sorry to be so vague in my question - we are looking for a system suitable for 6 - 10 developers using VC++. And we'd like "simple, robust, and cheap" !! Ian Kilmister "Without something, there is no nothing"
-
A couple of hours ago I went ahead and downloaded/installed RCS on my NT box here at work. I have a couple of projects already working fine on SourceSafe but I figured I'd give RCS a look. It installed fine and after I rebooted the machine (which it made me do) I fired VC++ back. Well guess what? I started getting errors about my project not being in the Source Control path where it had been mapped to! I guess RCS quietly took over as the Source Control system for VC++. So I couldn't do any work. I had to uninstall RCS and reboot once again. When I fired VC++ again, I discovered that it now had no Source Control system installed on it! So I had to uninstall VSS and install it again. That brought me back to normal again, thank God. I'm not putting down RCS; just commenting on my scary experience with it. By the way Erik, I thought your analysis of Source Control systems was incredible. Thanks for taking the time to give your well needed opinion on so many products. Regards, Alvaro
This all sounds very familiar. I'm one of a small (6 developers in Blackbushe, Hampshire, and one in PLymouth) team using SourceSafe 6.0 with VC 6.0. We've found that using Source Code Control integration with VC++ is bad news if the code goes away from homebase. In our case, we develop mainly at the Blackbushe site, but conduct trials on boats in Plymouth Sound, so the SCC connection is definitely part-time :cool:. Under these circumstances VC doesn't like loading projects with SCC integration enabled - and I think this will apply to any SCC provider - not just SourceSafe. We've ended up issuing a project wide instruction to disable SCC integration in VC - sure it's convenient, but there's a high price :rolleyes:. Andy Metcalfe - Sonardyne International Ltd
(andy.metcalfe@lineone.net)
http://www.resorg.co.uk"I used to be a medieval re-enactor, but I'm (nearly) alright now..."
-
Just looking for a little feedback - is anyone willing to offer some advice and experiences with the various Source Control systems available? Which is better (in your humble opinion!)? Which failed misserably ? And why ? Thanx, Ian Kilmister "Without something, there is no nothing ..."
I have been using CVS extensively for about three years, and am quite enthusiastic about it. Previously I had been using StarTeam, but the way they handle branching was so completely hosed that I needed something else. I like CVS very much, especially the WinCVS GUI front end. There was a bit of a learning curve at the beginning, but I quickly got a feel for the CVS way of doing things and found it much more compatible with my way of thinking about revision management than any other system I was looking at. CVS has some glaring weaknesses, but if one is aware of them, it's not too hard to deal with them. The strengths of CVS:
- Concurrent model of development. This is purely a matter of personal taste (or theological persuasion). CVS people are often extremely offputting because they spend lots of time going door to door telling developers to adopt the concurrent model and be saved. If you can back off a bit from the strength of the CVS rhetoric, there are many good points about the concurrent model and it suits what I do very nicely. It may not suit your needs, in which case CVS is a lousy choice. CVS is pretty much unique in supporting this development model.
- Excellent cross-platform support. Client-server model allows use across platforms. The basic command-line CVS client is widely ported. The WinCVS GUI front-end is ported to Win32, Mac, and Linux. Other GUI front ends exist as well. One of my major projects these days is a cross-platform (Win32/Unix) application, so my source-control system must be able to work with Windows and Unix clients. Other systems offer cross-platform support as well, but many do not.
- Client-server model. Many other systems have this as well. Why would it be essential? If you have developers spread around the country or around the world, this is essential. Even simple things like wanting to work on your code from home via a 56K dialup benefit greatly from c-s.
- Strong and fully-featured command-line client allows powerful scriptability.
- Good support from huge CVS community. The mailing lists for cvs and its derivatives provide better support than I have received from the paid support subscriptions of many commercial products. You have to endure a few flames from time to time, but the community is basically quite helpful. There are more flames on the main cvs mailing list and
-
"Whatever Microsoft did"? SourceSafe is a more than 10 year old product. MS bought it from a company called OneTree 6 years ago, it's been in use for a very long time in hundreds of thousands of companies. RCS has it's own faults and limitations as well. For instance, it uses a first-delta system where each change is a diff from the previous version, which means that as the number of version increase, so does the work and time necessary to get to the most current version, since it must apply hundreds of diffs to get to the final output. SourceSafe uses a last-diff method, where the most recent version is always saved and previous versions are diffed backwards. While this may seem like it's the same thing, it's not. The most recent, or more recent versions are the more common situation than retrieving the original version.
Erik, I think you are wrong about RCS. RCS uses reverse-delta storage on the main trunk, but is a bit weird about branches, where you have to backtrack to the branchpoint and then apply forward deltas. Thus, checking out the latest version from the main trunk is an O(1) operation, but getting the latest version of a branch can be time-consuming. These days, CVS has largely superceded RCS, but both share the same file format. He was allying himself to science, for what was science but the absence of prejudice backed by the presence of money? --- Henry James, The Golden Bowl
-
"Whatever Microsoft did"? SourceSafe is a more than 10 year old product. MS bought it from a company called OneTree 6 years ago, it's been in use for a very long time in hundreds of thousands of companies. RCS has it's own faults and limitations as well. For instance, it uses a first-delta system where each change is a diff from the previous version, which means that as the number of version increase, so does the work and time necessary to get to the most current version, since it must apply hundreds of diffs to get to the final output. SourceSafe uses a last-diff method, where the most recent version is always saved and previous versions are diffed backwards. While this may seem like it's the same thing, it's not. The most recent, or more recent versions are the more common situation than retrieving the original version.
-
Thanks Eric (and everyone else) This is precisely what I was looking for - a bit of 'real world' feedback on some of the products available. It's easy to find products and download demos, but it takes a LONG time to work through them all and get a feel for the relative strengths and weaknesses. And sorry to be so vague in my question - we are looking for a system suitable for 6 - 10 developers using VC++. And we'd like "simple, robust, and cheap" !! Ian Kilmister "Without something, there is no nothing"
Well, there's simple, and simplistic. What are your needs in source control? Do you just need a single project version tree? Do you need branch merging? Do you need Developer Studio Integration? How cheap is cheap? The cheapest is RCS/CVS, though these are a bit more complex becaues they're command line based.
-
I have been using CVS extensively for about three years, and am quite enthusiastic about it. Previously I had been using StarTeam, but the way they handle branching was so completely hosed that I needed something else. I like CVS very much, especially the WinCVS GUI front end. There was a bit of a learning curve at the beginning, but I quickly got a feel for the CVS way of doing things and found it much more compatible with my way of thinking about revision management than any other system I was looking at. CVS has some glaring weaknesses, but if one is aware of them, it's not too hard to deal with them. The strengths of CVS:
- Concurrent model of development. This is purely a matter of personal taste (or theological persuasion). CVS people are often extremely offputting because they spend lots of time going door to door telling developers to adopt the concurrent model and be saved. If you can back off a bit from the strength of the CVS rhetoric, there are many good points about the concurrent model and it suits what I do very nicely. It may not suit your needs, in which case CVS is a lousy choice. CVS is pretty much unique in supporting this development model.
- Excellent cross-platform support. Client-server model allows use across platforms. The basic command-line CVS client is widely ported. The WinCVS GUI front-end is ported to Win32, Mac, and Linux. Other GUI front ends exist as well. One of my major projects these days is a cross-platform (Win32/Unix) application, so my source-control system must be able to work with Windows and Unix clients. Other systems offer cross-platform support as well, but many do not.
- Client-server model. Many other systems have this as well. Why would it be essential? If you have developers spread around the country or around the world, this is essential. Even simple things like wanting to work on your code from home via a 56K dialup benefit greatly from c-s.
- Strong and fully-featured command-line client allows powerful scriptability.
- Good support from huge CVS community. The mailing lists for cvs and its derivatives provide better support than I have received from the paid support subscriptions of many commercial products. You have to endure a few flames from time to time, but the community is basically quite helpful. There are more flames on the main cvs mailing list and
Nice comments, however I'd like to point out that CVS is not unique in the concurrent model. There are several others, such as AccuRev which support this.
-
I have been using CVS extensively for about three years, and am quite enthusiastic about it. Previously I had been using StarTeam, but the way they handle branching was so completely hosed that I needed something else. I like CVS very much, especially the WinCVS GUI front end. There was a bit of a learning curve at the beginning, but I quickly got a feel for the CVS way of doing things and found it much more compatible with my way of thinking about revision management than any other system I was looking at. CVS has some glaring weaknesses, but if one is aware of them, it's not too hard to deal with them. The strengths of CVS:
- Concurrent model of development. This is purely a matter of personal taste (or theological persuasion). CVS people are often extremely offputting because they spend lots of time going door to door telling developers to adopt the concurrent model and be saved. If you can back off a bit from the strength of the CVS rhetoric, there are many good points about the concurrent model and it suits what I do very nicely. It may not suit your needs, in which case CVS is a lousy choice. CVS is pretty much unique in supporting this development model.
- Excellent cross-platform support. Client-server model allows use across platforms. The basic command-line CVS client is widely ported. The WinCVS GUI front-end is ported to Win32, Mac, and Linux. Other GUI front ends exist as well. One of my major projects these days is a cross-platform (Win32/Unix) application, so my source-control system must be able to work with Windows and Unix clients. Other systems offer cross-platform support as well, but many do not.
- Client-server model. Many other systems have this as well. Why would it be essential? If you have developers spread around the country or around the world, this is essential. Even simple things like wanting to work on your code from home via a 56K dialup benefit greatly from c-s.
- Strong and fully-featured command-line client allows powerful scriptability.
- Good support from huge CVS community. The mailing lists for cvs and its derivatives provide better support than I have received from the paid support subscriptions of many commercial products. You have to endure a few flames from time to time, but the community is basically quite helpful. There are more flames on the main cvs mailing list and
Jonathan (or anyone else who care), what about running CVS server on winNT4/win2000 machine? I look at few CVS pages, and there are all around recomendations for use CVS server on UNIX box. (Something like: 'Windows version is OK for most situations, however if you really need 100% stability it is recommended you use the Unix version if possible.' ) We (relatively small team, but geographicaly spread around the country working on Intranet projects, WAN connection) thinking about move away from VSS. But we have all-Windows environment. Have you any experience with use CVS (server & client) in windows only environment? Is CVS server windows implementation solid? Thank you. SlavoF "I hear and I forget. I see and I remember. I do and I understand." --Confucius
-
Nice comments, however I'd like to point out that CVS is not unique in the concurrent model. There are several others, such as AccuRev which support this.
Thanks for the correction. I had not known about AccuRev or other systems supporting concurrent development. Everything else I had looked at used an exclusive-lock model.
-
Jonathan (or anyone else who care), what about running CVS server on winNT4/win2000 machine? I look at few CVS pages, and there are all around recomendations for use CVS server on UNIX box. (Something like: 'Windows version is OK for most situations, however if you really need 100% stability it is recommended you use the Unix version if possible.' ) We (relatively small team, but geographicaly spread around the country working on Intranet projects, WAN connection) thinking about move away from VSS. But we have all-Windows environment. Have you any experience with use CVS (server & client) in windows only environment? Is CVS server windows implementation solid? Thank you. SlavoF "I hear and I forget. I see and I remember. I do and I understand." --Confucius
I've been using Tony Hoyle's cvsnt server on my NT4 machine ever since the beta. I've had a few problems (occasionally it's necessary to stop and restart the server to unjam things, or to manually delete locking files from the repository), but my repository integrity has been unblemished and the server generally works like a charm. You can set the server up to use Tony's ntserver protocol, which authenticates logins with the domain server using named pipes. This offers much better security than the CVS pserver protocol. I am using this server for similar things as you---geographically dispersed development in a windows-only environment---and if you're willing to put a little work into maintaining the repository, it works very well. I would recommend being fanatical about burning your repository to permanent media regularly just in case something corrupts it. I use this for my production work, but you must decide for yourself where you stand on the risk-aversion scale. I don't have time to become expert in Linux security, so I feel there is less risk working with a bleeding-edge technology under Windows than working with a somewhat more mature system on an OS that I don't know as well. Since more problems occur due to pilot error than to bugs in the system, I am comfortable with my choice of risks. You may decide differently. On the client side, there is a plug-in for the WinCVS GUI that lets you use the ntserver protocol from it, which is nice. There is also a project to add Microsoft Source Control integration to WinCVS, but it's complete vapour as of this writing (yours truly is largely to blame, since I committed to write much of the glue, but have gotten bogged down with other projects). There are also two other client-side front-ends that I have not used: Jalindi Igloo, which integrates CVS with the MSSCC so you can check files in and out from the MSDEV IDE. It's not as feature-laden as the WinCVS front-end, but the MSSCC interface exists today, not next year. There is also Tortoise CVS, which adds cvs commands to the explorer context menu. Link to both of these from the cvsgui page. He was allying himself to science, for what was science but the absence of prejudice backed by the presence of money? --- Henry Jame
-
I've been using Tony Hoyle's cvsnt server on my NT4 machine ever since the beta. I've had a few problems (occasionally it's necessary to stop and restart the server to unjam things, or to manually delete locking files from the repository), but my repository integrity has been unblemished and the server generally works like a charm. You can set the server up to use Tony's ntserver protocol, which authenticates logins with the domain server using named pipes. This offers much better security than the CVS pserver protocol. I am using this server for similar things as you---geographically dispersed development in a windows-only environment---and if you're willing to put a little work into maintaining the repository, it works very well. I would recommend being fanatical about burning your repository to permanent media regularly just in case something corrupts it. I use this for my production work, but you must decide for yourself where you stand on the risk-aversion scale. I don't have time to become expert in Linux security, so I feel there is less risk working with a bleeding-edge technology under Windows than working with a somewhat more mature system on an OS that I don't know as well. Since more problems occur due to pilot error than to bugs in the system, I am comfortable with my choice of risks. You may decide differently. On the client side, there is a plug-in for the WinCVS GUI that lets you use the ntserver protocol from it, which is nice. There is also a project to add Microsoft Source Control integration to WinCVS, but it's complete vapour as of this writing (yours truly is largely to blame, since I committed to write much of the glue, but have gotten bogged down with other projects). There are also two other client-side front-ends that I have not used: Jalindi Igloo, which integrates CVS with the MSSCC so you can check files in and out from the MSDEV IDE. It's not as feature-laden as the WinCVS front-end, but the MSSCC interface exists today, not next year. There is also Tortoise CVS, which adds cvs commands to the explorer context menu. Link to both of these from the cvsgui page. He was allying himself to science, for what was science but the absence of prejudice backed by the presence of money? --- Henry Jame
I definitely must find some time to play with cvsnt server. It is always good to hear that someone use this in production environment, and was glad about this choice. Thank you very much! SlavoF "I hear and I forget. I see and I remember. I do and I understand." --Confucius
-
The only things I can add to this are: PVCS - I agree wholeheartedly. It's a VERY capable product, but I felt I'd need a training course to even start using it :confused: (and I've been using version control systems for 6 years now). Avoid like the plague. ClearCase I haven't used this, but it was becoming the standard at my last company (Racal Instruments Ltd) just before I left. Having said that, its produced by Rational, and their tech support is the worst I've ever seen :mad: (we can't even get working licence keys out of them for our 6 copies of Rose 98 - and you don't want to know about their response to bug reports). No matter how good the product, that puts me off right away. I avoid Rational like the plague... SourceSafe 6.0 is the one we're using - mainly because its easy to use and good value. It's also (mostly) project orientated - at least for simple operations. It does lack some advanced features - e.g. you can't share/branch projects (only files) - which can make it a pain in a fast moving team environment, but this is more than made up for by the ease of use. Having said that, it's possible to put a script based front-end on SourceSafe to get around this - though the incompleteness of the COM interface makes this a bit of a pain. You can also get a third party client (SourceOffsite) to make it useable over a remote link. All things considered, I'd go with SourceSafe, unless you can find one with better support and an equal learning curve. I hope this helps. Andy Metcalfe - Sonardyne International Ltd
(andy.metcalfe@lineone.net)
http://www.resorg.co.uk"I used to be a medieval re-enactor, but I'm (nearly) alright now..."
We use SourceSafe for quite a few years, and it is great up to a point. With a few tens of developers, 6 products and 20 branchs it is a nightmare. The hard parts are the branchs (impossible) and the consistency (data corruptions). If you are doing more than a few branchs -- go for the enterprise level tools. ClearCase, Continuus (Telelogic) etc.
-
We use SourceSafe for quite a few years, and it is great up to a point. With a few tens of developers, 6 products and 20 branchs it is a nightmare. The hard parts are the branchs (impossible) and the consistency (data corruptions). If you are doing more than a few branchs -- go for the enterprise level tools. ClearCase, Continuus (Telelogic) etc.
I've been using VSS for close to 6 years. There are lots of things about it that I don't like, but I have to make a few comments here. If you're seeing common data corruption, there is something wrong with your network. Yes, VSS (and all file based version control) is more susceptible to this than a client/server based system, but having run VSS with hundreds of developers and hundreds of projects, I can tell you quite matter of factly that corruption is something that is almost always network related. The one exception to this is if someone is modifying the database when their system crashes. You shouldn't use VSS over dialup lines, since a dropped connection can result in data corruption. You shouldn't use it on flaky networks that drop packets. Now, about branching. VSS has many quirks with branching, but it's model is OK, *IF* you know what you're doing. You can't just branch willy nilly. The branches need to be planned, and you need to do them in a consistent way. For instance, the technique I like to use is to always keep the development version on the same initial project, and branch off (and pin) specific versions. This gives you a seperate project for each major version, with each version pinned at it's particular revision. This allows you to incorporate bug fixes in earlier versions by unpinning a file and repinning it at a later version (assuming that only bug fixes have occured in that file). Pinning also prevents the developers from modifying a shared file accidentally. You also can't allow developers to go branching things themselves. You should have one person responsible for the branching, so that it's always done the same way.