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.
Tony, -C means throw away my local changes. So, a failure to update after removing the modified file is irrelevant, permission has been granted to obliterate any local modifications (and the modified file copied to a backup anyway). I see no reason to worry about successfully updating later. Also, 2.021 working may have been a fluke, might be one for the journal of irreproducible results (I'm not going to try). See my other note with a one-liner patch to client.c that does work. What has definitely changed since 2.0.12a (the last version where -C works reliably) is the new code involving "client_overwrite_existing" and "filenames_case_insensitive" in client.c. That change removed the ability of the client to honor "toss_local_changes": the other patch I sent restores toss_local_changes to former functionality though may be confusing two pieces of logic that you feel should be kept seperate. There is a clear cause in the code changes past 2.0.12a for update -C to fail, and update -C has worked very reliably for several years across multiple cvs and cvsnt versions up through 2.0.12a. The alternate approach of first finding and deleting all modified files is ok in WinCVS or equivalent in flat mode, but is not very useful from the command line with a large project. Mark "Tony Hoyle" <tmh at nodomain.org> wrote in message news:bv121j$1lv$1 at sisko.local.nodomain.org... > ..because if the update fails, your file will be deleted and you will be > left with no file. > > There are no changes at all that could affect update -C between 2.0.21 > and 2.0.22.... It's always been a bit random (I maintain that it's > never worked reliably anyway - certainly not for me) and I suspect a > change to the protocol is required - some kind of overwrite instruction. > > Tony >