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.
Werner Weiling wrote: > foo.c (Revision 10.1) > bar.c (Revision 10.1) That is *not* a valid argument for not using tags. > 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. Source files interact. It's just not that simple. If foo.c is compatible with those product versions it should be tagged with those product version numbers. There is no other sane way of doing it. In fact from your example I can't see how the numbers are helping at all - you must be using tags and branches already to mark the individual releases. If you're retroactively changing releases just checkout the revision 1 branch, fix the bug, checkout the revision 2 branch, etc. You can use bugid merges to merge individual bugs into branches if necessary. > - Compatibility to UNIX CVS It is compatible. Compatibile does not mean identical. Unix CVS defines revision numbers within certain constraints, and CVSNT sticks to those constraints (in fact slightly more rigidly than the cvshome cvs clients themselves do - they let you force completely invalid revision numbers into the file). The actual meaning of the numbers themselves is *internal*. Originally RCS generated them. cvsnt is slowly moving to a database where they'll be generated by that - the format of the numbers won't change so clients can still make sense of them, but the meaning and values will change enormously.. there is no scope for letting users make them up. There never should have been, and getting rid of that misfeature was a long time in coming (I've been saying I'd do it for 6 months or more). TBH I'd rather the revision numbers weren't visible to clients at all - there were plans to do that but I didn't have time to do it properly. Tony