Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Hi Tony, There have been different threads about forcing a revision number while committing the source. I'm also a user of this feature and the absence of this option hinders me to upgrade to a newer version. I'm using UNIX very often and I'm of course very interested to have a compatible version on Windows and UNIX. I can't go back to 2.0.58 or 2.0.51 which is delivered by WinCVS because it does not descend into directories with a different CVSROOT q.v. Thread "cvs update does not descend into subdirectories with different CVSROOT". Therefore I would like to collect arguments for this option to request you to add it again. First of all: Why I would like to use it? Bo wrote this comment in an email: > Why do you want to do this at all? > The revision numbers are items used internally by CVS to keep track of > changes to the individual files themselves. There is no other meaning > attached to revision numbers and you should not interfere with the CVS > revisions. > > I suspect that somehow you are confusing product versions with the CVS > revision numbers, but they have nothing at all in common and could not > be used interchangeably. > Product versions are managed in CVS by using "tags", which can be applied > across many different files at different revisions to tie together all > files valid for a certain product version. > > Tags are what you should use! I absolutely agree that a revision number is used mainly internally by CVS. For a developer are tags the only way to determine which revision belongs to which product version. However there is a use case where it makes sense (at least for me) to support forcing a revision. We can determine with the revision whether a source file is upward compatible with a newer product. Let's assume we have this configuration: Product Version 1 foo.c (Revision 10.1) bar.c (Revision 10.1) Product Version 2 foo.c (Revision 10.1) bar.c (Revision 11.1) new.c (Revision 11.1) Product Version 3 foo.c (Revision 10.1) bar.c (Revision 11.1) new.c (Revision 12.1) A developer can recognize very easily that the file 'foo.c' is compatible with Product Version 1+2+3 and he can apply a bug fix for all product versions. In the case of file 'bar.c' he knows he has to do the bug fix twice and in the case of file new.c it is just Version 3. Yes, you can do this also by checking the tags for the product version but you can use this mechanism after on also for a validation check of the release build! If a Revision number higher than 10 would appear in the release build of Product Version 1 then we know that a developer made a mistake. We're checking this by issueing an 'ident' onto the binary libraries. For supporting this validation we need this option -r in the commit command. Other remarks: - revision number with zeros Bo: > Also note that revision numbers ending with a zero, like the one you > suggested, have special meanings to CVS and should not be used at all! Yes, but this can handled by the application that only revision numbers without a '0' are accepted or that only branch numbers are accepted like '24' or '24.0.1' - Compatibility to UNIX CVS This is one of my major requests because I need to use both worlds. Probably you have to give up this requirement at some time due to internal constraints but I would like to ask you at least for a '2.0.x' version which has a fix for recursive behaviour with different CVSROOTs and the 'commit -r' command. Unfortuneately this would be the last version I can use :-(. Thank you for your great work, Werner