Re: import inconsistency

[Mark D. Baushke]

Pierre Asselin writes:

> Paul Edwards <kerravon@nosppaam.w3.to> wrote:
> > "Stefan Monnier" <monnier+gnu.cvs.bug/news/@flint.cs.yale.edu> wrote in 
> > message 5ly907faoe.fsf@rum.cs.yale.edu">news:5ly907faoe.fsf@rum.cs.yale.edu...
> >>
> >> I have no idea which inconsistency you're referring to.
> 
> > A tinpot branch who gets in first, causes the file to stay in the
> > Attic forever, which means exception coding forever.
> 
> Maybe the solution is for import to change
> 
>     1.1 (dead, empty)
>       1.1.2.1 (live)
> 
> into
> 
>     1.1 (dead, empty)
>       1.1.2.1 (live)
>     1.2 (live)
To be consistent with other imported branches, 1.2 should be dead
and have the delta to take it from 1.1 to the imported version.
>       1.2.1.1 (live, no delta from 1.2)

Both 1.2 and 1.2.1.1 should also have the same timestamp as the imported
file AND the rcs branch needs to be changed to 1.2.1

> with the RCS -b branch pointing to 1.2.1 instead of the usual 1.1.1 .

Hmmm... Actually, the

      cvs admin -b1.1.1 filename

equivalent command is going to need to do an RCS_setattic() call and it
looks like the current cvs admin command needs that as well in any case.
This would move the file out from the Attic.

> Is this feasible?  Or is 1.1.1 hard-coded all over the place?

Well, the 1.1.1 branch is hard-coded right now. This is a special
case that would be easy to get wrong. As has been previously mentioned,
there are a lot of tests that need to get written and for which we need
to determine what the correct action should be for this kind of change.

For example, what should happen in the case

    1.1 (live)
    1.1.2.1 (live)
    1.2 (dead)

if the import hapens here, then do we get

    1.1 (live)
    1.1.2.1 (live)
    1.2 (dead)
    1.3 (dead)
    1.3.1.1 (live)

with branch 'cvs admin -b1.3.1' or 'cvs admin -b""' forcing a conflict
resolution merge? If the merge should occur, what version gets used
for the older version?

> Paul, the imported file would now be live on the trunk (Attic or no Attic)
> instead of dead on the trunk.  Would that solve your problem, the one
> that forces you in to "exception coding" ?

        -- Mark