Thats fine. I realize you meant no offense.
Kudos to you for even helping out.. its a difficult cross to bear.
As for CVS, you can create what is called a 'branch tag', which is like a normal tag, but allows you to actually make changes off that version of code without affecting the main trunk/head. You can even make branches off of branches.
A 'normal' tag allows you to pull a version of the code from the source tree, but does not allow checkins against that 'node'.
Normally when viewing (in your mind) a CVS code repository, its easiest to view the main trunk/head of code as a series of nodes in a flat line progressing from left to right, like this:
Code:
1.1-----1.2-----1.3-----1.4-----1.5-----1.6----->
Note: These are major and minor versions of the code. Normally we only change the major version if there is a major overhaul to the code, requiring other parts to change. For example, your new world addition to the server might be cause to move to a new major revision if it was not backwards compatible. Because the 'other MySEQ' guys already stole 'version 2' and 'version 3', I didn't want to confuse people so I elected to remain 1.x for MySEQ Open forever. Normally we might see a CVS repo that looks like:
Code:
1.1-----1.2-----1.3-----1.4-----2.0-----2.1-----3.0----->
Each of these 'nodes' start life as a 'normal tag'. Now let's assume that we are currently shipping v3.0 but some user of v1.4 wants a small bug fixed. We can do this by changing the 1.4 node to a 'branch tag' using the cvs tag command (I just use 'cvs tag -h' to see the options or view the man pages). Now the repo looks like this:
Code:
1.1-----1.2-----1.3-----1.4-----2.0-----2.1-----3.0----->
|
`-1.4.0-----1.4.1
All the tags here are normal tags except 1.4, which is a branch tag. The 1.4.0 tag is optional, but if we need to make another branch tag off of it for some reason, its nice to have a normal placeholder tag there. 1.4 and 1.4.0 are technically identical, or at least point to the same revisions of files. Now we can make our changes on the 1.4.x branch and release the update as 1.4.1. Now we don't disturb the trunk, which is v3.0, and its clear that if people like the v1.x line, they should get the v1.4.1 release to get the latest. They also know if they move to v2.x or v3.x, the interface may be completely changed.
That said, all is not lost. CVS can be fixed. Now that I think about it, and because so much time has passed (over 5 years now!) that I now think it was silly not to use v2.x. I should have done that in the first place. What I may do is convert back to the corrent naming convention and make the trunk based off 1.22 but call it 2.0, which is what it is. Since there is really a limited tag history anyhow, I will branch the 1.x line for continued use for the legacy version. So the repo would look like this:
Code:
1.0-----2.0----->
|
`-1.19-----1.25----->
This will allow the v1.x progression to continue as is, but also all the v2.x to progress if anyone decides to work on that again. At least it would be clearer what is where.
If you have any additional tags in the 1.x line you want kept, like 1.23 or whatever, let me know so I can keep the important ones. I can always create a tag based on any date, so if something is lost, its never lost forever.
-Seaxouri