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