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
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!