[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: Mark D. Baushke
Subject: Re: [PATCH] CVSREADONLY feature
Date: Sun, 16 Mar 2003 13:03:27 -0800

Derek Robert Price <address@hidden> writes:

> Mark D. Baushke wrote:
> >         if (current_parsed_root != NULL && current_parsed_root->isremote)
> >            {
> >+            if (readonlyfs)
> >+                error (1, 0, "Read-only repository feature unavailable");
> >+
> >                /* Create a new list for directory names that we've
> >                   sent to the server. */
> >                if (dirs_sent_to_server != NULL)
> >                    dellist (&dirs_sent_to_server);
> >                dirs_sent_to_server = getlist ();
> >         }
> >
> I don't see why not.  It would at least, hopefully, discourage people
> from putting -R in their .cvsrc, a move that could cause all sorts of
> trouble.

Okay, I did that.
> I'd put the sanity check and error message at the end of the
> parse_cvsroot() function in src/root.c, though, with the other CVSROOT
> sanity checks.  And make the error message more complete.  Something
> like "Read-only repository feature unavilable with remote roots
> (cvsroot = %s)."

> I'd also change the write lock error message to make it more clear to
> a novice that the write lock failed due to an option they passed in on
> the command line and not some feature of the repository they are
> accessing. Instead of, "write lock failed - read-only repository", how
> about something more like, "write lock failed due to read-only CVS
> option (cvs -R)".

> And one more, how about always issuing a warning?  Something like,
> "WARNING:  Read-only repository access mode selected via `cvs -R'.
> Using this option to access a repository which some users write to may
> cause intermittant sandbox corruption."

I issued that message with write mode. I am not sure it should be done
for a read-only operation or when the -Q switch is used. Obviously, I
can extend it further if you feel it is needed.

I have committed this feature to the trunk.

        -- Mark

reply via email to

[Prev in Thread] Current Thread [Next in Thread]