Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    45
  • comments
    115
  • views
    54899

CVS

Sign in to follow this  
Kylotan

368 views

We're using CVS at work, which I always thought was a good idea, until I had to work with it for a while. Basically, in order to change a part of your project, you have to ask for the latest version from the server, make the changes, document what changes you made, and then resubmit it to the server. The idea is that the server can track your changes and undo them in the event of a mistake, and ensure that two people don't accidentally edit the same file in different ways at the same time.

Unfortunately this tends to mean that you feel obligated to take a file, make the smallest change possible, and then check it back in quickly. You do this because the longer you keep files checked out, the more chance of finding that someone else wanted to change them while you were using them, and the more changes you make, the harder it will be to merge your changes with someone else's in the event of that happening. So instead of effective refactoring that makes the code much better to use in the future, you tend to get lots of isolated little hacks, fixing the symptoms but making the code less and less maintainable. The codebase ossifies into a fragile state.

On the other hand, you're reluctant to make small changes such as fixing typos or renaming variables, as the update/commit/document overhead takes too much time. Call me lazy, but it gets tedious writing a 2 sentence summary for why I used a single search and replace.

So what are the options? Here are my somewhat uninformed thoughts:

1) Use more files - if your project uses lots of small files rather than a few big ones, you have fewer sharing conflicts and can feel safe in making larger changes. Downside - the project probably gets unmanageable quite quickly this way.

2) Use CVS differently - for any large fix, you could reasonably create a branch for that fix, work exclusively on that, and then merge it back into the main trunk development. I expect this works well, but in my opinion still neglects a category of fix which is too big for a quick edit but too small to justify creating a temporary branch of your project.

3) Use better tools - if your editor or IDE handles CVS checkins/checkouts automatically, I expect the overhead issue diminishes to nearly zero. I don't have this luxury unfortunately. And documenting the small changes may still be a hassle even with tools to manage the file handling processes. Does Subversion improve significantly over CVS in this area? I have no idea.

4) Use fewer developers - this may sound strange but I think it has benefits for the wider process anyway. In this context, fewer developers mean fewer concurrency conflicts and less dependency on having the latest version of the code at each step. Obviously with fewer developers you then have to 'work smarter' to get the same amount of work done, but there are many ways I think you can do that (which I may go into one day).

Sign in to follow this  


8 Comments


Recommended Comments

I used to hate it, but I now like the way that Visual SourceSafe does the checkin / out thing. When you check out a file, it's locked for checkouts by other people (they can still read it though) so it's yours to work on for as long as you need it. This benefits as it marks the file as effectively being a WIP, so anyone else wanting to modify it knows that someone else is making changes. The downside of this is that two people can't work on the file concurrently, so you have to plan your projects or development areas around the rest of the work people have to do. In a way, this is a good thing as it encourages people to 'stick to an area' and work only on the files in that area - but again, this then forces people into pigeon holes who then become unable to understand the rest of the code.

Version control is all about compromise, I think.

Share this comment


Link to comment
Very interesting entry [smile]

Just a by-product of my work over the years that I've had minimal exposure to version control systems. Or, rather, the exposure has been so limited as to not expose many of the potential problems.

Surely some sort of ownership structure would help out - I know they had that at IBM in some places. A product would be divided based on components, the team leader / lead developer would "own" it and give permissions to check-in/modify any of the code that was within. In the context of games that'd mean that only the graphics developers could touch the graphics engine, and if the sound guy spotted a bug he'd have to get the graphics guys to do it (or give him permission to).

Cheers,
Jack

Share this comment


Link to comment
We're using VSS at Egosoft. There's some minor things I don't like about it, but nothing that I can't live with, and nothing that I honestly think could be "fixed" by changing products. The only real scary thing is the source database which has been corrupted twice, but both cases look like hardware failure, and there's automated backup systems in place in any case so it's not really even a problem.

The locked-checkout paradigm though is absolutely amazing. As a team we seem to have just settled on a workflow that doesn't cause a lot of concurrency problems, and a tiny bit of architectural refactoring to make some of the modules more fine-grained would make it almost completely seamless. Most people on the team have their own area of expertise in the codebase anyways, and those of us who do roam around between areas usually only make "ninja changes" and don't need files checked out for very long. All in all it works superbly, and the exclusive-checkout system has definitely saved our bacon a few times.

Share this comment


Link to comment
Re: 'ownership' of modules...

In theory this is a good idea, and should probably be done where possible. Of course, if it was always possible, a distributed concurrent versioning system would probably not be necessary in the first place. ;)

The value of a system comes from how the components interact, so there is necessarily a crossover where implementation of one modules uses the interface from another. It would be nice to be able to freeze an interface, but in the real world you can't, due to the lead designer or your customers requiring changes that the original spec couldn't accommodate.

For example, I am working on a module that regulates code access to a table in a MySQL database. Occasionally I need to edit the DB-->Code function to tweak the results I get. Unfortunately other people, who work on a different part of the product, need to alter the Code-->DB part. There's an argument for splitting this up, but if you had a separate file for every database read and write then your project is surely going to become unwieldy very quickly.

I didn't like the SourceSafe approach. It seems rather clumsy compared to CVS. Although concurrent updates to one file could be problematic, I prefer being potentially able to do them than never able. After all, files can be fairly large and most merges will not pose a problem. And if someone was to check out a common file and keep it for a length of time for some reason, I can see that being an unnecessary bottleneck.

Share this comment


Link to comment
I have a solution: don't use CVS. [smile] j/k I do think it's crap though.

I've worked in both exclusive check-out (VSS style) and shared check-out environments. My personal favorite is exclusive checkout, but I know people who swear by shared checkout (CVS).

The main issue I hear from shared checkout advocates is that exclusive checkout doesn't allow more than one person to work on a file at the same time. Personally, I'm blown away by the logic that you want two people working on the same code at the same time (unless it's pair programming). You are just asking for errors to be introduced and poor design principles through the merging process. If someone really needs to modify a file to get their code to work due to an interface change or otherwise, then they can make that code file writeable until they can get the checkout. As dangerous as that sounds, I rarely see issues occur because of this approach.

Now I don't believe in exclusive ownership of code either. If two people need to work in the same area, then instead of working on it at the same time and merging they should be able to work on that same code, but do it in an organized fashion through queueing. The risks involved with this approach can be mitigated through good development strategies and planning - something I find is severely lacking in quite a few development houses out there.

That's one of the reasons I like ionForge's Evolution for source control. They give the option for shared checkouts, but it defaults to exclusive checkouts. One of their cool features is the ability to queue exclusive checkouts. So if Johnny has myfile.cpp checked out, and Susan checks out myfile.cpp while Johnny has it checked out, Johnny will be notified by email that Susan wants to checkout the file, and Susan will be notified that Johnny has it checked out. Once Johnny checks the file in, Susan will automatically be given the checkout and will be notified by email that the file is now her's.

Share this comment


Link to comment
I can see a scenario where two programmers are working on different sets of files, but which overlap slightly meaning one or two files are shared. These might be big changes and they might therefore require a working copy for a few days while they verify their amendment works. With shared checkout, there may be a slight clash when it comes to checking in the 1 or 2 shared files. But with exclusive checkout, surely to do it properly, one of those programmers couldn't really be working on that part for those few days? That feels like a bottleneck to me, and working around it with local copies of read-only files just seems to move the problem rather than solve it.

In both cases, I can see a big incentive on coders - the first for personal reasons (awkwardness of merging), the second for group reasons (desire to keep exclusive checkout duration to a minimum) - to make the smallest change possible to fix any given bug, leading eventually to a lot of hacked together and unmaintainable code. Am I right? Wrong? :)

Share this comment


Link to comment
In that case you definitely have a bottleneck, and things like that do happen. I'm not against shared checkout, so perhaps to alleviate the risks of exclusive checkouts you would want a system that has both shared and exclusive checkout options. Then you can have engineers checkout certain files as shared (for those files shared across workspace domains) and the more isolated areas can be exclusive.

Share this comment


Link to comment
1) Working on numerous small files can help but to be honest you're often gonna have "overlap" files which take a bit of a hammering throughout the life of a project.

2) Something that i really miss using AlienBrain instead of CVS is the ability to branch things. Creating a branch and developing or fixing or whatever you're doing mean't that you could sit down and spend time doing the work that needed to be done. Of course merging it back in can be it's own special pain in the backside.

3) We had both IDE integration and a system that parsed your latest checkin for the commit message. It then created an message which contained information about the commit, files, times and the commit text and posted it to our internal forum. People were expected to then make a more detailed post about what they had changed and or technical director could chase up anyone who didn't ;)

4) yes :D

I'm not a big fan of the exclusive checkout systems. AlienBrain supports it or simultaneous checkouts it's just how you setup the project. In the industry i'm in though you're frequently working on code that was written at another company, is often commented in Japanese, and doesn't actually have a specific owner. Not only that but people will make changes to your code just because you dont happen to be working that weekend or particular bit of crazy overtime.

So exclusive checkouts would be nice, they might even be possible with proper code ownership, but they're like some kind of perfect ideal and until that perfect (impossible) ideal is achieved i think i'll stick with and demand a workable solution to the fact that someone i going to be trampling on my code (whilst i'm trampling on theirs!)

Andy

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!