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