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 Wed, 03 Mar 2004 15:26:44 +0100, Oliver Giesen <ogware at gmx.net> wrote: >1. using a different vendor branch is still possible and still messes up >the tagging (i.e. one branch with multiple names) - there isn't even a >warning Since it's always done this, I'm not too bothered at this stage. >2. using an already existing release tag only produces a warning - >wouldn't it be better to forbid this altogether unless the -f option was >given? - after all this is usually a clear sign of a user-mistake... It's the same as what happens if you do a 'cvs tag' and it already exists (which is essentially what you're doing). There's also the problem that there's no provision for error within the import code... it does everything in a single pass and won't abort due to errors. Because of the way it works this isn't easily fixable either. >3. it even let's me switch vendor branch and release tag again Actually you can't. It'll give an error as the tags are different... the checking will stop you doing some of the worst mistakes (even -f won't override this): D:\t\i>cvs -d d:\repo import -m "" -f test b a cvs import: ERROR: tag b already exists in D:/repo/test/t.txt,v U test/u.txt No conflicts created by this import *** ERRORS DURING THIS IMPORT *** >Thus, objectively speaking, the only change between 2.0.19 and 2.0.33 is >the warning when using an existing tag... There's quite a bit of difference really. tony