Can't cvs remove in sandbox for read-only repository?

[Nelson Bolyard]

I'm developing a patch for a set of source files in a repository to 
which I have only read access.  I intend for my patch to remove two
source files from that repository on that branch.  If I can "cvs remove"
those source files, the "cvs diff -N" will generate a patch that shows
that I am removing the files.  Otherwise, cvs diff will complain that
the files are missing from my sandbox.  

But when I try to "cvs remove" those files from my sandbox, cvs 1-11-22 
tells me that I cannot cvs remove the files because I do not have write 
access.  Although I have used cvs for over a decade, I rarely use 
read-only repositories, so I was surprised by this result.

Now, given that cvs remove does not actually make ANY changes to the 
repository, and only marks the file to-be-removed in my local 
CVS/Entries file, why should cvs remove deny me the action of marking 
the file as to-be-removed in my own sandbox?  

I haven't tried it, but does "cvs add" do the same thing?  Again,
given that cvs add merely marks the file in my CVS/Entries files as 
to-be-added, and the add does not happen until a commit, why should
CVS deny me the operation to mark a file as to-be-added in my local
sandbox?

Also, I can accomplish the same things that "cvs remove" does by 
hand enditing my own CVS/Entries file (IINM), so it makes even less
sense for the cvs program to deny doing for me what I can do for 
myself, less conveniently.

In summary, the question is: 
Is there any good reason for cvs to behave this way? 
Or is this just a bug?

-- 
Want an e-mail address like mine?
Get a free e-mail account today at www.mail.com!