>  Allright. I'll hack it in my local version, stuff up some test cases,
>  and see where it takes me :)

Hmm... the server goes ahead in server.c and calls ign_setup()
from serve_questionable.

I mean, by calling this function, the Server in itself behaves
*way* different from local only CVS... I think, right now, it cannot even
as much as care about the things ign_setup does. What it should care
about, really, is only the $CVSROOT/CVSROOT/.cvsignore.

Larry, any opinions? *grin*

Hmm, are there a lot of people using real accounts on the CVS Server
that can override the .cvsignore from the Client?
Meaning:
Assume, I have an account on my client ([EMAIL PROTECTED]) and on my
server ([EMAIL PROTECTED]). In both there is a .cvsignore.
Assume, on client, I am hacking on the module my_proj. I add a file
that is called foo_bar.c.
Assume, on the server, I was testing and had a $HOME/.cvsignore that has
foo_bar* as its only entry.

If I now cvs upd my_proj on client, the server goes ahead and ignores
foo_bar.c, although I would like to have it included...

So the strategy would be to remove this precious call to ign_setup() from
within serve_questionable() and have the client ign_setup somehow
detect, that the server might have something for him in the (!)
$CVSROOT/CVSROOT/.cvsignore list only (!).

Is this in line with what you might have in mind?

Cheers,
Guus

Reply via email to