[Top][All Lists]

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

RE: Removing Files on Tags

From: Mischke, MaryBeth
Subject: RE: Removing Files on Tags
Date: Wed, 18 Jun 2003 12:36:15 -0600

Maybe I'm missing something in the nuances of tags versus sticky tags.  Here
is what I am doing.

I checkout using: cvs checkout -P -r D-1-0-0-0 test 

Then mark a file to be removed by using: cvs remove test.cpp 

Then commit and the D-1-0-0-0 tag is removed from test.cpp file.  If I
checkout the module by the D-1-0-0-0 tag again, I don't get the test.cpp

Is there some configuration that needs to be set in order for CVS to prevent
this and to get the error message you described?


-----Original Message-----
From: Kaz Kylheku [mailto:address@hidden
Sent: Wednesday, June 18, 2003 11:25 AM
To: Mischke, MaryBeth
Cc: 'address@hidden'
Subject: Re: Removing Files on Tags

On Wed, 18 Jun 2003, Mischke, MaryBeth wrote:

>  I've seen the subject of CVS allowing files to be removed from tagged
> versions (as opposed to forcing you to create a branch to modify instead)

If you are talking about removing a file that has a sticky tag, no this
is not allowed. You get a message like: ``cannot remove file 'foo.c'
which has a numeric sticky tag of 1.1''.

> kicked around in a few other messages from a couple years ago.  Does
> know if there has been an update on this lately?  From what I can tell
> is still the default behavior.  The only way I can find to get around it
> to disable permission for users to remove files through an access control
> list, but that is problematic as there are files that users need to remove

What? Removing an object in CVS causes new information to be recorded in
the history file. It does not constitute removal of the history file
from the repository. So to prevent a CVS remove at the operating system
level, your access control list would have to deny writes, which would
prevent users from changing the file in any way, or even recording new

> from non-tagged versions.

Or, in general, if some software allows something dangerous to happen,
you could get intelligent users who are capable of following 
``don't do that''-type instructions.

reply via email to

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