RSS Feed

The Joel on Software Discussion Group (CLOSED)

Here's the situation - financial company, team of 10 people who develop small tools (ie. no major projects) currently with no source control. Copies and copies of the same programs laying on local machines and in several different folders in the network share.

I spoke to my manager about implementing CVS and he told me to go ahead and make it happen.

So, since we are on Windows, I thought of placing CVSNT on a server where the repository would be located and installing TortoiseCVS on each developer's machine.

I chose CVSNT and TortoiseCVS because these are the only applications I'm familiar with (well other than from a console). That's why I posted here: I just wanted to ask if there are other (better) options?

For instance, making it available through a browser and / or through Explorer - not sure how that's done (or if it's even overkill?).

We use subversion.  I dislike how CVS works.  Example, when we need to rev. our code, subversion does it on the whole repository where as CVS does not and gives each changed file it's own revision number.  I found that extremely counter productive.

Use subversion and TortoiseSVN.  You will be much happier... trust me on this.

Subversion is the only way to go - I would not even think about using CVS now.

Like everyone else has said and is going to say, Subversion. It should be easy to pick up if you know CVS. See http://svnbook.red-bean.com/en/1.1/apa.html for a quick start. TortoiseSVN is good. You might also give Trac a look. Even if you don't use the project management features, it gives some useful web-based views of the repository.

The Zeus for Windows IDE offers seamless integration with CVS:

http://www.zeusedit.com/forum/viewtopic.php?t=237

Similar to what you said about installing CVS, install SVN on a server, and install TortoiseSVN on each client. There is no need for a copy of SVN to be installed to each client unless they want the command line interface.

The TortoiseSVN Windows Explorer interface is all I use, but others in my group have installed plugins to their IDE (Eclipse, in our case).

The server might not even need to have SVN loaded.  It is possible to have the SVN repository type FSFS (the default) and access it from each client via a mapped drive.  I'm not sure if this is the best way, but it is possible.

I guess I'll have to be the one to speak up for Perforce

http://www.perforce.com.

Not cheap, but a great product.

+1 for Subversion.  Versioning entire directories is handy.

Lots of plugs for Subversion, but not many people specifically saying why. Here's why:

- Revisions. By making revisions repository-wide and not file-specific, it makes it easier (compared to CVS) to track the history of the repository and of files. For example, you can compare the histories of two files and see when they changed relative to one another based on revision numbers.

- Built-in secure access. You can use https (meaning you won't need a shell account) to access the repositories.

- Svn can move and copy files and directories.

And a few reasons why SVN is better than a number of other, non-CVS systems:

- SVN is reliable. We have a number of very large repositories (multi-gigabyte) with no trouble.

- SVN has an excellent diff/merge algorithm.

- SVN allows locking, but also allows you to work in a copy-edit-merge manner.

- SVN clients and servers are available on a large number of platforms.

- SVN is fairly fast. Not as fast as CVS, I've found, but compared to some systems, it's pretty quick.

- SVN is priced very fairly (that is, free!)

- SVN has a complete manual, and while it's not a very good tutorial, it is a great reference.

That's why I prefer SVN. I cannot recommend it highly enough.

And, if you've got a slightly higher budget than "free", check out SourceGear Vault. Its GUI is more refined than Tortise, and if you use Visual Studio, it will integrate directly into the IDE.

Oh yeah, Vault also has all the other advantages of SVN (except being free).

I second what Josh said.  I am currently (right now, in fact) using Vault and it is excellent.  I haven't had any problems with it, it was easy to install, and it integrates nicely with Visual Studio.

Vault doesn't appear to be available on nearly as many platforms as Subversion. Please correct me if I'm wrong, but I didn't see Linux, Solaris, OSX, etc listed on their site.

Of course, if you're not looking for these platforms, it's not a big deal.

+1 for SVN, our repository is now 7Gig, no problems.

CVSNT (for all intents and purposes, CVS 2) is way ahead of Subversion in terms of merging. I am not switching to SVN specifically because I need the multi-branch merging functionality.

A couple of SVN tips.
Use the standalone server on windows - much simple to get started. There is also a little utility to run it as a service.

Use file mode -fsfs it stores each file+mods in a separate file rather than a single database. When the database corrupts it's a bit of a pain to fix on windows.
Also if you accidentally checkin something you shouldn't ( like an email from a customer or confidential data) you can wipe the file permantly from the server - it's tricky to permantly remove a file on the database version.

I'll still plug NG3 if its a Windows only platform, implemented on SQL Server.  For one thing you can indicate folders for source control and the shell extensions will manage the files within that folder, quite apart from any IDE integration.

+1 for VSS....

We moved to SVN a few months ago from CVS. Before that (previous company) I used VSS.

Now that I'm used to SVN I'd never go back. But you really, really need to take some time to understand how SVN "works", and how to do branching/merging. Once you're used to "thinking in diffs" instead of "thinking in files" you'll find it's second nature, but it takes a while to get there.

Thanks for all the suggestions everyone. I spoke with someone else on the team about using Subversion and they said there might be problems selling it to management =\

Some of the points he brought up:

- is it currently in Alpha phase? (I thought it wasn't, but I can't really find anywhere that says exactly)  If it is, it won't pass the security audit.
- the features in SVN aren't enough to make it necessary to change.  I don't really have a position here since I haven't used SVN enough (or at all...).
- "Everyone knows CVS and it just works"
- SVN is going under daily development.  Although this can be taken as a good thing as well?

I'm thinking of going ahead and putting together a proposal to use Subversion and just seeing exactly what happens.  Can't hurt to try right?

- is it currently in Alpha phase? (I thought it wasn't, but I can't really find anywhere that says exactly)  If it is, it won't pass the security audit.

There's definitely a version in Alpha.  But there's also stable production code, which is what you should be using.

- the features in SVN aren't enough to make it necessary to change.  I don't really have a position here since I haven't used SVN enough (or at all...).

They aren't enough to make a change necessary from what?  From CVS?  Probably not.  From the condition of no source control at all?  Definitely there's a need to change.

- "Everyone knows CVS and it just works"

They therefor know SVN too.  The command line interface is the same.  The only difference is in how repositories are specified, and I personally find the SVN method easier to remember.  Only the administrative side of things is different.  For daily use most users aren't doing a lot of branching (or they shouldn't be).

- SVN is going under daily development.  Although this can be taken as a good thing as well?

This is definitely a good thing.  Nobody is doing any CVS development, so if there are problems, they stay there.  Have you ever seen a piece of software that didn't have problems?  Didn't think so.


I'm using Subversion myself.  I find that it integrates with other tools better than CVS.  FogBugz, for instance.    Trac doesn't hurt either.

Another advantage that probably hasn't been discussed is integrating it with your Windows network authentication.  By using Apache for Windows, webdav, the apache svn module and the windows authentication module mentioned on the apache svn module page, you can tie your subversion authentication directly to your Windows network authentication.  It sounds a lot harder than it actually is.  I found that all I really needed to do was download the modules, copy them to the right folder, and follow the instructions for modifying the config file.  Everything was really clear and easy to follow.

You can always lie to management - use CVS as a generic term and subversion for the actual implementation.

Since CVS stands for Concurrent Versions System you can truthfully say that SVN is 'a' CVS.

LOL @ Martin.

Also the great points you brought up Clay. I used them when I spoke to my manager and he seems open to it (yes!).

Quick queston, if we run the svnserve server without using SSH tunneling, does this mean that the data is insecure if the connection to the remote server isn't secure?

"Quick queston, if we run the svnserve server without using SSH tunneling, does this mean that the data is insecure if the connection to the remote server isn't secure?"

Yes.

lester,

If you slightly interested in Subversion, I've created a guide to setting up Subversion, TortiseSVN, Apache and Visual studio on Windows. I've included all little things that I found necessary to setup a complete environment like publishing scripts etc.

You could have a look through and just take out what suits you if you decide to go the Subversion route.

You can find it here:
 http://geekswithblogs.net/rwillgoss/archive/2005/10/20/57506.aspx