Hmmm.

I don't know if your problem is CVS or the lack of coding standards.

Just out of curiosity, why is Subversion not an option? Oh yea, hello all; this is my first post here. :)

Well, if you're looking for exclusive checkouts, Subversion certainly isn't going to fill that particular need right now. We have some plans to have some support for that kind of thing, but it's well in the post-1.0 category at this point...

Regardless, if I had to work with you I'd probably argue that if merging your changes is becoming too much work, you probably aren't committing them often enough.

Also, if you find yourself reformatting code often enough that it becomes a merging problem, either you need to remember the cardinal rule of code formatting (respect the existing style in a file), or you need to smack whoever on the team keeps screwing the formatting up.

Anyway, exclusive checkouts are evil unless you're talking about a binary file that cannot be merged, if you want I can go on about this fact at length, but I suspect you've heard all the arguments before and are just being stubborn ;-)

So, you want exclusive checkouts so you can hold the rest of the team hostage to your schedule? This sounds like you wish to replace your "I don't like to merge" with their "I can't get my work done".

Exclusive checkouts are a crutch that replaces a good mechanism for branching that a *real* version control system supports. Such as Perforce.

I wouldn't use CVS even if it were free.

Exclusive checkouts are a good way to have your coworkers beat you to death with a keyboard.

Yes, refactoring and merging don't mix together too well. I understand the problem. Luckily, the last time I worked in a big team, I had access to a source control software that allowed exclusive checkout.

Anyone that tried to refactor a couple of big files (and I'm a refactor maniac too) just to checkin and find that someone has been changing the file while you were doing it should easily understand your problem.

If paying money is acceptable, I'd switch to Perforce ASAP. http://www.perforce.com/ .

It's by *far* the best source-code management system I've ever used; the merging is notably a lot better, and yes, it does locked checkouts.

Source control is nice. And invaluable for refactoring. Regarding formatting, why not just add style tags for vim and emacs to the bottom of all your files?

George:

Something tells me that those "windows developers" are not using vim or emacs.

Just a guess...

Hey Steve, how many large projects have you worked on with a mixed theme of developers in several different states and on several platforms?

Anyway, this was a rant.. they don't have to be logical or even make sense.

Like you, I refactor my code quite a bit (although I try not to get addicted :-). I use Subversion (http://subversion.tigris.org/) which beats CVS in that it properly tracks moving, renaming and copying files and directories.

I use Eclipse to do my refactoring, but I use Subversion's command line tool to tell it about my changes. This can get quite complicated if I've made a few big changes!

At some point point I plan on installing Subclipse (http://subclipse.tigris.org/) to integrate Eclipse and Subversion. Hopefully this will keep Eclipse and Subversion in sync, even through complicated refactoring.

Don't know what to do about your exclusive checkout problem (other than merge)...

There is probably an underlying problem here - too many cooks. I am in a very similar situation right now. The conclusion I draw is that if refactoring is too hard because the code is changing underneath you then the team is too large, and/or the codebase is too tightly coupled, so everyone is touching everything to make their changes. The most telltale sign of this is when you have a bunch of classes that every commit seems to touch. Of course its a catch-22 at this point - you need to refactor to reduce coupling, but you can't because everyone needs to modify the classes you're trying to refactor! Best approach here is to probably communicate the issues, set a date (end of an iteration, say) for everyone to commit their work, then come in at the weekend and do the refactoring.

Hi, have you looked at 'arch'?

If you were on my team, I'd hate you :-)

Don't get me wrong, refactoring is a good thing. But we maintain three (yes, _three_) source branches; current development, and bug-fix trees for the last two public releases. When we fix a bug, it is trivial (with perforce) to integrate that fix across the branches (so that the bug is fixed in all three places).

UNLESS SOMEONE HAS REORGANIZED THE CODE... Then we have to fall back to merging by hand. (and as the bugs-team lead, that job usually falls to me :-). That, in turn means that those subtle, one-line bug fixes can slip through the cracks, and we end up having to debug and fix them _again_.

You mention that 'RCS is not an option' and then mention 'Windows' - is there some problem with using RCS on Windows I don't know about?

I used to loathe SourceSafe until I met CVS. Actually, they're about the same - crappy at merges.

However, the one thing that SourceSafe does give you is explicit checkouts. I don't mean 'exclusive checkouts' (though you can get it), I just mean that anyone wanting to change any code has to declare his intention to do so.

Then, when I'm on a refactoring spree, I can see that so-and-so is working on some module, and defer what I'm doing until later, thus saving us both some work. Or I can choose to go ahead and damn the torpedoes.

Yes, SourceSafe can be misused: someone can make their edits on a local copy, and then do the checkout just seconds before their checkin. On the other hand, if they do that, they own the cleanup job - so it pays them to adhere to checkout protocol.

In summary, I'd like my source control system to tell me who's probably working on what files.