Re: adding on branch

[Mark D. Baushke]

Stefan Monnier <monnier+gnu.cvs.bug/news/@rum.cs.yale.edu> writes:

> > What you seem to have munged is that currently, the text of an initial
> > import is stored in 1.1, _not 1.1.1.1_.
> 
> I don't understand this at all.  From what I can tell, after an initial
> import, 1.1 and 1.1.1.1 (at the RCS level) are exactly the same (i.e. 1.1 is
> the text and 1.1.1.1 is a zero-diff revision deriving from it).
> 
> So we could simply always ignore 1.1 and use 1.1.1.1 instead (if the
> magic-branch-detection-logic fires).  I'm obviously still missing something.

Assumptions:

   1.1 is dead
   1.1 is HEAD (ie, 1.n does not exist for n > 1)
   The current rcs branch is not set.
   1.1.1 is the vendor branch tag or the vendor branch tag does not exist
   <vendor-branch>.1 does not exist
   The <vendor-branch> tag does not exist in the rcs file.
   The <vendor-version> tag does not exist in the rcs file.

If any of the above assumptions is not true, then special-processing for
this particular edge condition could not be performed. This will result
in the version of the file being noted as a Conflict that needs to be
resolved by a human.

Then, something like the following special-case hack would need to be done:

   Generate a delta between the 1.1 dead text and the 1.1.1.1 new import
   text. (This would need to be done via a special version of the
   add_rev() function.)

   call RCS_setbranch() to force the <vendor branch> to be the branch

   Note: Would it be a Bugfix to RCS_setbranch() to call RCS_setattic()
   to move the file out of the Attic? OR, do we need a bugfix to the
   'cvs admin' command for dealing with chaning the branch (the -b
   option) from something that is a dead revision to something that is
   alive or vice versa. [That is, it may be a bug that users can do the
   command: 'cvs admin -b1.1.1 foo' where the 1.1.1.x file is not dead
   and the current HEAD is dead.]

   RCS_settag() gets called for the vendor 1.1.1 branch

   RCS_settag() gets called for the vendor 1.1.1.1 version tag
  
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?

        Thanks,
        -- Mark