Re: adding on branch

"Mark D. Baushke" <[email protected]>
Newsgroups gmane.comp.version-control.cvs.bugs
Message-ID <[email protected]>
Paul Edwards <[email protected]> writes:

> "Mark D. Baushke" <[email protected]> wrote in message news:[email protected]...
> > 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.