Any technical problems with long CVS version numbers?

Question

Our project has a history of creating new branches in CVS from existing branches. After several years, this has led to this situation on the files that are changed in every release:

new revision: 1.145.4.11.2.20.2.6.2.20.2.1.2.11.2.3.2.4.4.4.2.5.2.1.2.1.2.6.2.23;
previous revision: 1.145.4.11.2.20.2.6.2.20.2.1.2.11.2.3.2.4.4.4.2.5.2.1.2.1.2.6.2.22

Obviously this looks bad in the CVS console, but does it actually matter technically? Would we gain anything by merging everything back to the head so it is back at 1.146?

(P.S. "Switch to subversion" is not an answer.)

Answer 1

Obviously, this has worked for you for several years, so if there are technical problems, then you've not yet seen them. I don't know of any that you'll run into; however, if this continues over the next several years, I would not be surprised if you start to find limits and bugs in various tools. (Not to mention you can't ever meet source code line-length guidelines. :P)

Would we gain anything by merging everything back to the head so it is back at 1.146?

Clarity. A simpler system is easier to work with, even if the more complex equivalent is technically sound. Do you have anything to lose by merging back to 1.146? At this point, you're talking about project- and group-specific benefits whose value will vary, and you'll just have to decide if the effort is worth the result.

Answer 2

The size limit for CVS would probably depend on the specific implementation of CVS you have chosen to go with. That particular application would have set the maximum string size for the version number. I can't imagine it would be much higher than 50 or 100, but that's not the point. Although you could probably get away with having such a long version number string, it is not advisable.

If the version number is too long it will be very difficult for people read and understand. You should consider using a shorter, more condensed version which will convey the same meaning.

In some schemes, sequence-based identifiers are used to convey the significance of changes between releases: changes are classified by significance level, and the decision of which sequence to change between releases is based on the significance of the changes from the previous release, whereby the first sequence is changed for the most significant changes, and changes to sequences after the first represent changes of decreasing significance. [Wikipedia's Software versioning]

Since each number after a decimal point signifies a level of change significance, you should really only need 4 or 5 periods max. Otherwise, it is an indication that your software build cycles are TOO LONG or you are just abusing the version number conventions. I would stick with 4 or 5 periods, max.

It should go something like this: <major version>.<semi major release of version>.<release version>.<build number>, which leads to something like 4.2.12.45 if you are working on product version 4 (which is pretty much what you show to the user), and it was the second big release because there were significant changes to how 4 works, but it still works like 4 was supposed to work, and the 12th version with bug fixes, security updates, etc. And finally the 45th development build while doing testing before the release of 4.2.12. This is just an example, but something like this works very well.

Answer 3

Would we gain anything by merging everything back to the head so it is back at 1.146?

There are a few arguments for merging:

• Convenience -- It is easier to refer to shorter revision numbers than to absurdly long ones. But it is unusual to refer to CVS revisions by number, because revision numbers are not uniform across files, so this advantage is minor.

• Performance -- The way that CVS stores revision deltas is optimized for dealing with the revision at the tip of HEAD (see rcsfile(5)). If the time required for checkouts and other CVS operations is getting intolerable, merging the main line of development back to HEAD might help.

• Avoiding tool bugs -- It is quite plausible that some tool that you are working with (CVS? Commit notification tools? Web viewer? IDE plugin?) has built-in limits to the size of revision numbers that it can deal with. If you encounter such bugs, you might be forced to change your style whether you want to or not.

But there are a few significant disadvantages of merging that you should not forget:

• Given that CVS doesn't record information about merges, merging development back to head would mean losing the history of revisions leading to the new "current" version. For example, cvs log will no longer tell you the sequence of changes that led to the current revision.

• Unless you change your development process, your code base will start sprouting branches-on-branches again, rendering any gains temporary. (Conversely, if you plan to change your development process at the same time, merging back to head would be more justifiable.)

• When the (dare I say, inevitable) time comes when you decide to migrate away from CVS to a more modern version control system, the correct history (without fake merge) will probably be easier for the migration tool to make sense of.

All in all, I would recommend sticking with your current practice until you have concrete problems that outweigh the disadvantages of merging back to HEAD.