[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: adding on branch
From: |
Mark D. Baushke |
Subject: |
Re: adding on branch |
Date: |
Fri, 30 May 2003 11:35:55 -0700 |
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
- Re: adding on branch, (continued)
- Re: adding on branch, Derek Robert Price, 2003/05/28
- Message not available
- Re: adding on branch, Stefan Monnier, 2003/05/28
- Re: adding on branch, Derek Robert Price, 2003/05/29
- Message not available
- Re: adding on branch, Stefan Monnier, 2003/05/29
- Re: adding on branch, Derek Robert Price, 2003/05/29
- Message not available
- Re: adding on branch, Stefan Monnier, 2003/05/29
- Re: adding on branch, Derek Robert Price, 2003/05/29
- Message not available
- Re: adding on branch, Stefan Monnier, 2003/05/29
- Re: adding on branch, Mark D. Baushke, 2003/05/30
- Message not available
- Re: adding on branch, Paul Edwards, 2003/05/30
- Re: adding on branch,
Mark D. Baushke <=
- Message not available
- Re: adding on branch, Stefan Monnier, 2003/05/28
- Re: adding on branch, Mark D. Baushke, 2003/05/28
- Message not available
- Re: adding on branch, Stefan Monnier, 2003/05/28
- Message not available
- Re: adding on branch, Paul Edwards, 2003/05/28
- Re: adding on branch, Paul Edwards, 2003/05/29
- Re: adding on branch, Derek Robert Price, 2003/05/29
Re: adding on branch, Paul Edwards, 2003/05/30