CVS
1,466
8
Advertisement
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).
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).
Advertisement
Advertisement
Advertisement
Discussion