Re: adding on branch

[Mark D. Baushke]

Paul Edwards <kerravon@nosppaam.w3.to> writes:

> "Mark D. Baushke" <mdb@cvshome.org> wrote in message 
> news:mailman.7041.1054280546.21513.bug-cvs@gnu.org...
> > I think this ends up doing the right thing most of the time as the
> > RCS engine should be able to reconstruct version 1.1.1.1 correctly,
> > but the above violates some assumptions about version 1.1.1.1 that
> > may be used by others somewhere:
> >
> >     The timestamp of 1.1 and 1.1.1.1 will no longer be the same,
> >     nor will the author or state attributes.
> >
> >     The delta for 1.1.1.1 will no longer be empty.
> >
> >     The symbolic tags for vendor branch and vender version will
> >     no longer be in the same relative position of the file (last).
> >
> >     The execute permissions on the RCS file will no longer be that
> >     of the imported file, but instead of whatever happened to be
> >     committed to the repository first.
> >
> >     The default keyword expansion flag may not be the same as the
> >     between the pre-import and post-import versions.
> >
> > Have I missed anything?
> 
> I don't think these last two should be allowed to stand, as it
> makes a visible change to the user.  I don't want a tinpot
> branch to affect production import processing, that keyword
> expansion in particular.

Hmmm... Okay, there are existing mechanisms for altering the keyword
expansion, so it could be adjusted to trust that of the import. However,
I don't think there are presently any admin functions that twiddle the
execute bits of an existing RCS file, so that will probably need a new
hack.

> I actually created a "cvsadd" script to do a cvs add -ko because
> programmers kept on forgetting to do that, and I don't want the
> PVCS administrator to cotton on to the fact that CVS does the
> same keyword substitution and ban me from using CVS.
> 
> The other thing that "cvsadd" does is rename Tag to Tagx and
> do the commit so that it goes in as a head, and then tag it to what
> Tag is, then do an update on the branch, so that production
> imports, when they happen, don't look like exceptions.
> 
> BFN.  Paul.

So, you are suggesting that an import overrite somehow rename the
existing tags? How would an administrator set that kind of policy?

        -- Mark