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.
On Sat, 12 Aug 2006 14:46:56 +0800, "Yongwei Wu" <wuyongwei at gmail.com> wrote: >So CVSNT is breaking compatibility with CVS now? This is quite >surprising. What if a CVS client does this operation while the server >is CVSNT? There will be an error... > >BTW, that CVS feature looks useful to me. In my current attempt, I am >not to increase the version number to 2.0, but to make it the same as Please realize the HUGE difference between *version* and *revision*! You are talking about file versions but referring to file revisions even though they are completely different animals. >the same file in another repository. I know nothing of the roadmap of Why have the same file in two places? then thery sure are not the same. It makes much more sense to use exactly the same file in both projects and then the problem you think you have will be gone... >CVSNT, but at least $Version$ shows useful version information visible >to the user, which the user might want to adjust in certain >circumstances. CVS uses *revision* numbers to mark the different revisions of a single file. The revision number is stored *inside* the file itself (actually in the "RCS" file on the server that holds all info on the file in question). Whenever a change is done to a file and committed this revision number is incremented by one on the least significant digit. This happens if you commit an edit to the file but it also happens in CVSNT if you do other things to the file such as merging from a branch even though the actual file textual contents did not change. What is stored then is the so called mergepoint. Anyway, in a given project you typically have many files and all of them are never edited at the same time and committed at the same time. Instead out of 100 files you probably are working on just a handful and you make edits several times before you are satisfied. Each time you commit these edits the revision number is incremented for the files that were edited but not for the other files. Now this leads to a situation very quickly where there are files with revision numbers spread out all over the place. These are important to CVS but not particularly so to the developer. Especially these numbers cannot be used to designate a product *version* or *release*!!! The CVS method of keeping the files of a particular product version together is by putting a textual TAG (like Ver_1-2-3) on all of them at the current state (where the files are at many different revision levels). The tag gets set to the files in one operation and afterwards (a long time later) all of the project files can be checked out to this tag and you thus retrieve the *exact* state you had when you put the tag on them.