Disable "cvs tag -F" of branch tags
HMah...@aol.com
Our developers will tag their code for builds under test, and when problems
are fixed, they will move the current tag until the product is shipped and
the tag is frozen. Occasionally, someone makes the mistake of moving the
branch tag instead of one of the branch's static tags. The problem here is
that the tag is converted into a static tag. Sometimes it's hard to recover.
Maybe this falls under the "yeah, and any idiot who accidently types 'rm -rf
/usr' should have to accept the price", but it would sure seem like an easy
fix for CVS to not allow the -F option when the tag is a branch tag.
What do YOU guys think?
:)hal mahaffey
Greg A. Woods
> Subject: Disable "cvs tag -F" of branch tags
>
> Maybe this falls under the "yeah, and any idiot who accidently types 'rm -rf
> /usr' should have to accept the price", but it would sure seem like an easy
> fix for CVS to not allow the -F option when the tag is a branch tag.
>
> What do YOU guys think?
Yes, that seems logical -- CVS should not allow a branch tag to be
moved, particularly if it would be converted to a normal tag in the
process.
Although a branch could be moved within a given file before there are
commits to that file, it seem to me that the concept of moving a branch
is wrong and should not be attempted at any time. Deleting a branch tag
after there are commits to any file on the branch is only asking for
trouble too.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwo...@acm.org> <robohack!woods>
Planix, Inc. <wo...@planix.com>; Secrets of the Weird <wo...@weird.com>
David Thornley
>
> [ On Wednesday, March 29, 2000 at 13:06:20 (EST), HMah...@aol.com wrote: ]
> > Subject: Disable "cvs tag -F" of branch tags
> >
> > Maybe this falls under the "yeah, and any idiot who accidently types 'rm -rf
> > /usr' should have to accept the price", but it would sure seem like an easy
> > fix for CVS to not allow the -F option when the tag is a branch tag.
> >
> > What do YOU guys think?
>
> Yes, that seems logical -- CVS should not allow a branch tag to be
> moved, particularly if it would be converted to a normal tag in the
> process.
>
a branch tag into a normal tag. This would not have happened if
the restriction above had been in place.
I have mistyped things in the past. I have every reason to believe I
will mistype things in the future. I appreciate all the help I can
get to make sure these mistypings don't do anything too bad.
In this case, it looks irrecoverable. I updated to the correct
revision and created a new branch tag with the old branch tag name,
but this will mean that any future revisions on that branch will
have a six-digit revision number rather than a four. I've effectively
cut off a branch and added a twig. If I'm lucky, nobody's going to
change that branch any more.
--
David H. Thornley Software Engineer
at CES International, Inc.: David.T...@ces.com or (763)-694-2556
at home: (612)-623-0552 or da...@thornley.net or
http://www.visi.com/~thornley/david/
Sean Cavanaugh
the fact that branches and tags are handled by the same command (cvs tag and
cvs rtag). However it makes sense to be able to refer to both in the same
manner for 'cvs update', with the -j and -r parameters in those contexts.
Having 'cvs tag -b' and 'cvs tag' to differentiate between checkpoint vs
branch requires explaining a lot of extra stuff to the newbies, and is
mostly a throwback to the programming logic going on behind the scenes. I'm
sure it makes sense as a CVS maintainer/programmer to have -b be an option
to tag, but on the user end it should probably be a different (but similar)
command
cvs 'branch' | cvs 'rbranch' : same as cvs tag but assumes -b, and does not
understand -F. I assume taginfo logic would need to be virtually duplicated
and some file like 'branchinfo' be created to handle these operations.
cvs 'tag' | cvs 'rtag' : same as existing cvs tag but -b no longer is an
option, and -F only works on tags
Behind the scenes the uniqueness in tag names would still be required,
but it should never be possible to convert the meaning one to the other.
Note this is quite different from going back to an existing marker tag and
creating a branch from it with some other name (which is a common
occurence). In addition, both commands should probably be able to rename a
tag, a feature that as far as I can tell, does not exist in CVS at all.
- Sean
----- Original Message -----
From: <HMah...@aol.com>
To: <info...@gnu.org>
Sent: Wednesday, March 29, 2000 10:06 AM
Subject: Disable "cvs tag -F" of branch tags
> Greetings!
>
> Our developers will tag their code for builds under test, and when
problems
> are fixed, they will move the current tag until the product is shipped and
> the tag is frozen. Occasionally, someone makes the mistake of moving the
> branch tag instead of one of the branch's static tags. The problem here
is
> that the tag is converted into a static tag. Sometimes it's hard to
recover.
>
> Maybe this falls under the "yeah, and any idiot who accidently types
'rm -rf
> /usr' should have to accept the price", but it would sure seem like an
easy
> fix for CVS to not allow the -F option when the tag is a branch tag.
>
> What do YOU guys think?
>
> :)hal mahaffey
>
>
Greg A. Woods
> Subject: Re: Disable "cvs tag -F" of branch tags
>
> Yup. About fifteen minutes ago, I typed the wrong tag and changed
> a branch tag into a normal tag. This would not have happened if
> the restriction above had been in place.
Sorry to hear that....
> I have mistyped things in the past. I have every reason to believe I
> will mistype things in the future. I appreciate all the help I can
> get to make sure these mistypings don't do anything too bad.
I too have done this more than I care to admit.....
> In this case, it looks irrecoverable. I updated to the correct
> revision and created a new branch tag with the old branch tag name,
> but this will mean that any future revisions on that branch will
> have a six-digit revision number rather than a four. I've effectively
> cut off a branch and added a twig. If I'm lucky, nobody's going to
> change that branch any more.
If you can find a working directory on that branch that is reasonably
up-to-date, but unchanged since the branch tag was deleted then you can
recover the branch tag 100%. It's just very tedious to do as you have
to re-add the tag on a file-by-file basis after examining the "ancestor"
revision of every file and decoding the branch revision-ID if there has
been a commit to the file, or simply creating the branch from the
ancestor revision if there hasn't been any commit. I've always used
"cvs admin" to re-create the tags, though I don't know if that's
necessary. I suppose it could be automated but I don't know of anyone
who has written such a script to date. I've never had to do such a fix
in a module of more than a dozen or so files, fortunately.
stanislas pinte
hello hal,
how do you manage to put static tags? IS there also a way to enforce
process management with that? For example, if I want the last version of my
sources to wear the tag "dev", but I also want tha t the upperlast wear the
tag "prod".
thank you very much,
Stan
Cameron, Steve
HMah...@aol.com wrote:
> Greetings!
>
> Our developers will tag their code for builds under test, and when
> problems
> are fixed, they will move the current tag until the product is shipped and
>
> the tag is frozen. Occasionally, someone makes the mistake of moving the
> branch tag instead of one of the branch's static tags. The problem here
> is
> that the tag is converted into a static tag. Sometimes it's hard to
> recover.
>
> Maybe this falls under the "yeah, and any idiot who accidently types 'rm
> -rf
> /usr' should have to accept the price", but it would sure seem like an
> easy
> fix for CVS to not allow the -F option when the tag is a branch tag.
>
> What do YOU guys think?
[smc] Some time ago, I had made an
(admittedly idle) proposal to add a
command which might export a tag
file that would contain a definition of
all the tags and what revisions of what
files they referred to.
That way, you could do something like this:
1. restore your pre-disaster repository from backups
to some new disk space someplace
2. cvs export_tag lost_tag > lost_tag_file
3. go to your real repository
4. cvs import_tag < lost_tag_file
Or something along those lines.
Of course nothing became of my idle prattlings,
as is normally the case when it comes to CVS.
David L. Martin
(tag_check.pl) which only allows particular users to add, move or delete a
tag. For convenience, thepasswd file contain these permissions.
e.g. Our passwd file looks like this:
# PERMISSION add mov del
admin1:dkjeir738473:cvs
admin2:dkfjsk384728:cvs
# PERMISSION add
user1:fkdj3827382:cvs
user2:dkfj3847232:cvs
David Martin
Michael Gersten
> tag, a feature that as far as I can tell, does not exist in CVS at all.
>
> - Sean
Just a thought, what's wrong with
cvs rtag -r oldtagname newtagname
to rename a regular tag?
(rename a branch: Can't think of it -- the equivalent rtag -b will create a
new branch, without the -b will create a static tag, not rename.)
Sean Cavanaugh
----- Original Message -----
From: "David L. Martin" <dlm...@prodigy.net>
To: <HMah...@aol.com>; <info...@gnu.org>
Sent: Thursday, March 30, 2000 7:23 AM
Subject: Re: Disable "cvs tag -F" of branch tags
Sean Cavanaugh
space/time as the original tag. I suppose you could do a cvs tag -d of the
original afterwards and effectively get the rename behavior. This would
work fine for static tags, but seems like it would feel super dangerous on
branch tags.
----- Original Message -----
From: "Michael Gersten" <mic...@getasia.com>
To: "Sean Cavanaugh" <se...@dimensionalrift.com>; "CVS List"
<info...@gnu.org>
Sent: Thursday, March 30, 2000 10:49 AM
Subject: Re: Disable "cvs tag -F" of branch tags
Stewart Brodie
>Greetings!
>
> Our developers will tag their code for builds under test, and when problems
> are fixed, they will move the current tag until the product is shipped and
> the tag is frozen. Occasionally, someone makes the mistake of moving the
> branch tag instead of one of the branch's static tags. The problem here is
> that the tag is converted into a static tag. Sometimes it's hard to
> recover.
>
> Maybe this falls under the "yeah, and any idiot who accidently types 'rm
> -rf /usr' should have to accept the price", but it would sure seem like an
> easy fix for CVS to not allow the -F option when the tag is a branch tag.
Surely it is simple enough to be able to fix it by writing a suitable script
that is invoked from taginfo when the action is "mov".
--
Stewart Brodie, Senior Software Engineer
Pace Micro Technology PLC
645 Newmarket Road
Cambridge, CB5 8PB, United Kingdom WWW: http://www.pacemicro.com/
Cameron, Steve
Michael Gersten wrote
[...]
>
> cvs rtag -r oldtagname newtagname
>
> to rename a regular tag?
interpreted as a module name.
Michael Gersten
(as some have pointed out, it is not a rename without an rtag -d as well.)
Cameron, Steve
Oops, I wrote:
> Michael Gersten wrote
> [...]
> > Just a thought, what's wrong with
> >
> > cvs rtag -r oldtagname newtagname
> >
> > to rename a regular tag?
> [smc] Well, this is already valid syntax, in which "newtagname" is
> interpreted as a module name.
HMah...@aol.com
This is one of those problems that would not have been solved by tighter
control over WHO got to do it. The person who did it was the one who would
have been included in the PERMISSION list below... ;)
This is a very painful error to recover from, and I don't seem to be hearing
any advantages to allowing the feature. If someone would change this for me,
I'd ship them a box of their favorite chocolates! (well, or money, if you
prefer... )
Should I be so brazen as to suggest this is a "bug"? :)
:)hal mahaffey
In a message dated 3/30/2000 10:29:37 AM Eastern Standard Time,
Stephen Rasku
>
>Can you post it or mail it to me? I'd like to have^B^B^B^Bsee it :-)
>
>----- Original Message -----
>From: "David L. Martin" <dlm...@prodigy.net>
>To: <HMah...@aol.com>; <info...@gnu.org>
>Sent: Thursday, March 30, 2000 7:23 AM
>Subject: Re: Disable "cvs tag -F" of branch tags
>
>
>> In our CVS setup, we have taginfo call a small script we wrote
in-house
>> (tag_check.pl) which only allows particular users to add, move or
delete a
>> tag. For convenience, thepasswd file contain these permissions.
>>
>> e.g. Our passwd file looks like this:
>>
>> # PERMISSION add mov del
>> admin1:dkjeir738473:cvs
>> admin2:dkfjsk384728:cvs
--
Stephen Rasku E-mail: ste...@tgivan.com
Senior Software Engineer Phone: (604) 872-6676
TGI Technologies Web: http://www.tgivan.com/
David L. Martin
basis.
I also added a block to check if the tag ends in "_BRANCH", which is our
convention for naming branch tags. If it is a branch tag, no one is allowed
to move or delete it.
Again, to use this, you will need to edit your passwd file to include
comment lines that specify PERMISSION followed by one or more of add mov
del. Users will have tag permissions according to the most recently read
PERMISSION line.
e.g.
# PERMISSION add mov del
admin_user1:dkfjd83748:cvs
admin_user2:dkfjiwuerje8:cvs
# PERMISSION add
developer:dkfjdk83743:cvs
bozo:eifusi83984kd:cvs
Your taginfo should look like this:
DEFAULT /project/cvs_repository/CVSROOT/tag_check.pl $USER
I hope this is somewhat effective to help prevent inadvertent branch tag
deletion or renaming!
(I think we've all been there),
David
#!/usr/bin/perl
# -*-Perl-*-
# tag_check.pl
#
# Perl script to verify a user's permission set defined in the passwd
# file prior to executing tag commands.
#
# Developed using perl, version 5.004_04 built for sun4-solaris
#
# Usage: tag_check.pl username
#
# username = CVS client username $USER passed from taginfo
# Additional automatic taginfo arguments follow username as
# received by this script
# (tag name, operation, repository, [file, revision])
#
# Contributed under the GNU Public License
# No warranty is expressed or implied
##### MAIN PROGRAM
#
# Get program arguments
get_args() or
die "Usage: tag_check.pl <username> <tagname> <operation>\n";
read_permissions() or
die "Could not read permissions\n";
validate_permissions() or
die "Tag $operation not allowed for user $username\n";
exit( 0 );
#
###### END MAIN PROGRAM
###### SUBROUTINES
#
sub get_args {
# For our purposes here, we only want the
# first argument - username
# second argument - tag name
# third argument - operation (add, mov, or del)
$username = shift @ARGV;
if ( $username eq '' ) {
return; # Return undef indicating error
}
$tagname = shift @ARGV;
if ( $tagname eq '' ) {
return; # Return undef indicating error
}
$operation = shift @ARGV;
if ( $operation eq '' ) {
return; # Return undef indicating error
}
return ( OK );
}
sub read_permissions {
# Open the password file for input
open( AFILE, "</project/cvs_repository/CVSROOT/passwd" )
or die "Could not open password file for read\n";
# Read the whole file
while ( <AFILE> ) {
chomp;
push (@lines, $_);
}
close( AFILE );
return(OK);
}
sub validate_permissions {
# Let's be sure we aren't attempting to move or delete a branch tag
# (Our local convention is that all branch tags end in "_BRANCH")
if ( $tagname =~ m/_BRANCH$/ ) {
if ( ( $operation =~ /del/ ) ||
( $operation =~ /mov/ ) ) {
printf "No one is allowed to $operation a branch tag\n";
return;
}
}
# Initialize our allowed permissions to nothing
$allowed = '';
foreach $line (@lines) {
# Search each line for "PERMISSION" and get subsequent fields
@fields = split(/PERMISSION/, $line);
$num_fields = @fields;
if( $num_fields > 1 ) {
$allowed = @fields[ 1 ];
}
# Search each line for matching $username
@fields = split(/:/, $line);
$num_fields = @fields;
if( $num_fields > 1 ) {
$found_user = @fields[ 0 ];
# Username match - validate attempted $operation against $allowed
permissions
if( $found_user eq $username ) {
if ( $allowed =~ m/$operation/ ) {
return( OK );
}
else
{
return;
}
}
}
}
printf "User $username not found in passwd file - contact CVS
administrator\n";
return; # Return undef indicating error
}
#
##### END SUBROUTINES