I don't have a problem with CVS as such. My problem is with the way CVS is often used.
Specifically, my problem is with the way that branching is sometimes done: by branching individual files, rather than the whole repository.
Why?
Because it causes more problems that it solves.
Consider this little example project:
/some-app
/some-app/build.xml
/some-app/src/org/example/SomeApp/
/some-app/src/org/example/SomeApp/Gui.java
/some-app/src/org/example/SomeApp/Handler.java
/some-app/src/org/example/SomeApp/NetClient.java
Now let us assume that we need to have multiple concurrent changes going on in this project. E.g.
- Somebody is working on improving usability.
- Somebody else are working on a bugfix for bug 1234
The problem is that we do not know in advance when these two projects are "finished". So we need some way of:
- Allow concurrent development
- Allow each team of developers to have a stable environment
- Ensure that one project does not inadvertently become dependent on the changes by another project
The Normal Way
The normal way to handle this is to create a separate branch for each team of developers:
$ cvs co -rHEAD some-app
$ cd some-app
$ cvs tag USABILITY_ROOT
$ cvs tag -b USABILITY
It's normal practice in CVS to first tag the root of a branch first)
Then all a the usability developers need to do is this:
$ cvs co -rUSABILITY some-app
and they're off. The same principle applies for bugfix 1234 - that gets its own branch too, and the developers will be working in that branch.
This allows each team of developers to work, without stepping on each others' toes. Their work gets commited their own branches.
Once a project has declared its readyness to go live (after testing, reviewing and God-Knows-What), the relevant branch can be declared dead and merged into the HEAD branch:
$ cvs checkout some-app
$ cvs update -jUSABILITY_ROOT -jUSABILITY
[[Sort out any conflicts]]
$ cvs commit
The Wrong Way
Some organisations prefer to branch individual files, rather than the whole repository.
The logic is as follows: Each project will use HEAD, except for those files which have been branched: for those files the version on the named branch will be used.
This puts the onus on the developers to make sure they branch each file they modify as they go along. If they forget to branch it, they will inadvertently commit to the HEAD branch.
When branching individual files, the developers should branch each file (from HEAD) before modifying it. Imagine that the usability developers modified these files:
/some-app/src/org/example/SomeApp/Gui.java
/some-app/src/org/example/SomeApp/Handler.java
Once the changes have been tested and put live, the branched files will be merged back to HEAD. No problem so far.
Similarly, the developers fixing bug 1234 will branch each file as they modify it. Assume that they modified these files:
/some-app/src/org/example/SomeApp/Handler.java
/some-app/src/org/example/SomeApp/NetClient.java
They will be working along quite happily on their branched files - until the usability changes are merged into HEAD. Next time they update their sandbox, they will end up with these files:
/some-app
/some-app/build.xml (from HEAD)
/some-app/src/org/example/SomeApp/Gui.java (from HEAD, by the usability developers)
/some-app/src/org/example/SomeApp/Handler.java (from the BUG123 branch)
/some-app/src/org/example/SomeApp/NetClient.java (from the BUG123 branch)
Spot the problem: They will end up with an incomplete set of usabilty changes.
Hopefully this will result in an obvious breakage. But it is also quite possible that they will not spot the missing usability changes - e.g. if none of them are aware of those changes.
Resources
Others have made the same mistake:
| < Prev | Next > |
|---|
