[Top][All Lists]

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

Re: adding on branch

From: Paul Edwards
Subject: Re: adding on branch
Date: Fri, 30 May 2003 22:00:19 GMT

"Mark D. Baushke" <mdb@cvshome.org> wrote in message 
> > >     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.
> So, you are suggesting that an import overrite somehow rename the
> existing tags? How would an administrator set that kind of policy?

I'm not particularly saying that, I'm just saying that I have a
hack to stop files added on a branch being put into the Attic,
by making the directory temporarily not a branch, so that the
file gets committed as the head.

The first person to commit a non-dead head should probably
be the person who gets to set permissions and keyword

In fact, for our main project, it should probably be set up so
that users can't add to the head at all, they can only work on
their authorized branches, so that the administrator can
guarantee that users don't interfere with production processing.

BFN.  Paul.

reply via email to

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