RE: failure_exit not cleared in client.c

[Vesa Suontama]

Thanks for responses.

It seems to me that the easiest way to reproduce the "failure_exit" flag not
cleared bug is probably to have a binary file added without -kb flags as Ian
suggested.

Anyone willing to fix the sanity.sh script to include the case:

1. Client 1 adds a binary file "binary-file" to cvs without -kb flags
2. Client 1 checkouts the tree
3. Client 2 adds another file e.g. "file-new" to the repository
4. Client 2 modifies the "binary-file" in such a way that patch will get
confused and commits the changes.
5. Client 1 creates a file with the name "file-new". This file will be "on
the way" when he is next going to do an update
6. Client 1 does cvs update
7. "file-new" is on the way, and failure_exit gets set. The second pass is
never started and the "binary-file" is leaved unmodified.

Do not get confused that adding a binary file without -kb flags is already a
wrong thing to do. It is just there to be an example of an "unpatchabe
file". There are another more common causes for a file being unpatchable in
client side, as Larry said (different line-ending conventions being probably
the most common).

Vesa

> -----Original Message-----
> From: Larry Jones [mailto:larry.jones@sdrc.com]
> Sent: 3. lokakuuta 2001 0:38
> To: Ian Lance Taylor
> Cc: dprice@collab.net; vsuontam@ssh.com; bug-cvs@gnu.org
> Subject: Re: failure_exit not cleared in client.c
>
>
> Ian Lance Taylor writes:
> >
> > A typical case is that the file is somehow modified after the CVS
> > process starts, so the application of the patch fails.  Another is
> > that the file contains binary data, but is not marked as -kb, and
> > patch gets confused.
>
> Ah, I see I misunderstood the question.  There are *two* loops involving
> patching files, one on the server and another on the client.  The
> phrasing of the question ("making the file unpatchable") lead me to
> think we were talking about the server loop, since it's the server that
> decides whether a file is patchable or not.  The question was really,
> "what would cause the patch to fail?" (on the client).  In addition to
> the cases Ian mentioned, another possibility is that the file has
> changed without CVS noticing (because the timestamp didn't change).  In
> addition to various nefarious ways of causing that, sharing a working
> directory between platforms with different line-ending conventions will
> have that effect.
>
> -Larry Jones
>
> If I was being raised in a better environment, I wouldn't
> do things like that. -- Calvin
>