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! _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
