Source Control
-
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.