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:[EMAIL PROTECTED]] > Sent: 3. lokakuuta 2001 0:38 > To: Ian Lance Taylor > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > 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 > _______________________________________________ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
