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 Thu, 9 Oct 2003 11:29:26 -0500, "Czarnowski, Aric" <aczarnowski at unimax.com> wrote: >1) To test this I should be able to grab tomorrow's snapshot at >http://www.cvsnt.org/cvsnt_release_snapshot.zip, copy that over my local >client directory, update the server's cvswrappers to use -m 'COPY' again >and see if I get the error during my client side cvs update right? Yes. >2) I will setup a case where I commit a file like this and test >conflicts to make sure things are working as expected (keyword >expansions but no local conflict merges). > >3) So -m should remain in the cvswrapper comments but -t and -f will be >removed? Yes. I'm surprised they're still there... the option was removed in cvs 1.9 which was years ago. >4) Should I be worried about the archive file's integrity when changing >cvswrappers from -m 'COPY' to -k 'b' and back again while development is >ongoing? No, it doesn't change the way the file is stored, just the way conflicts are handled. In a modern cvsnt it's pretty redundant - you should be able to mark the files as -kbkv and achieve the same thing (although there are still some bits of code that explicity test for -kb that I'm still hunting down and removing). Tony