Larry Jones wrote:
Todd Denniston writes:
2) on linux will a `killall cvs` cause cvs (as server for :ext: /or
:pserver:)to cleanup and exit nicely or is there a particular signal I should
pass to killall? What I want is to be able to essentially tell cvs is I know
the file system is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Todd Denniston wrote:
If I am somewhat more patient, after ~30 seconds from the kill
command, cvs
[any command] will terminate. It looks like the client processes another
30-50 files after the server is given the SIGTERM, which seems like a
lot
[EMAIL PROTECTED] wrote:
Todd Denniston writes:
5) is there a more efficient way of locking the repository
than creating all
the `#cvs.rfl' in all the sub directories of all the
repositories? That is, is
there a single file I can create that blocks access to each
repo for the whole
Jim.Hyslop wrote:
[EMAIL PROTECTED] wrote:
Todd Denniston writes:
5) is there a more efficient way of locking the repository
than creating all
the `#cvs.rfl' in all the sub directories of all the
repositories? That is, is
there a single file I can create that blocks access to
Todd Denniston writes:
2) on linux will a `killall cvs` cause cvs (as server for :ext: /or
:pserver:)to cleanup and exit nicely or is there a particular signal I should
pass to killall? What I want is to be able to essentially tell cvs is I know
the file system is leaving, sync self and
Larry Jones wrote:
Todd Denniston writes:
2) on linux will a `killall cvs` cause cvs (as server for :ext: /or
:pserver:)to cleanup and exit nicely or is there a particular signal I should
pass to killall? What I want is to be able to essentially tell cvs is I know
the file system is
Todd Denniston wrote:
5) is there a more efficient way of locking the repository than creating all
the `#cvs.rfl' in all the sub directories of all the repositories? That is, is
there a single file I can create that blocks access to each repo for the whole
repo, instead of what is suggested for
