Nelson Bolyard wrote, On 04/04/2008 03:36 PM:
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?
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),
Been there done that, it works. (at least for add)
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?
Sort of (I don't think it is in the bug system at
Or is this just a bug?
But we have all been to lazy^H^H^H^H^H busy to implement:
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter