[cvsnt] Re: cvsnt 2.0.19 (and 2.0.22, not 2.0.21), cvs up -C works only for :local:

Mark Levedahl mlevedahl at raytheon.com
Mon Jan 26 01:07:58 GMT 2004


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
>





More information about the cvsnt mailing list