Re: adding on branch

[Stefan Monnier]

> No, because an empty 1.1 with the same timestamp as 1.1.1.1 is how CVS
> currently detects that it should look for a version on the vendor branch.

Ahhh.... I think I understand a little better.
How about changing it from "empty 1.1 with same timestamp" to
"empty 1.1 with same timestamp or dead 1.1" ?  Would that be difficult ?
Would it break other things ?

> If we alter CVS as you suggest, and retroactively allow 1.1.1.1 to be the
> magic, base revision for 1.1, then we will have corrupted the 1.1.2 branch,
> as CVS only stores the full text of the most recent revision on the trunk ,
> to create 1.1.2.X, it must reconstruct its GCA with the trunk, in this case
> 1.1, which will retroactively have been set to the text of 1.1.1.1.  It will
> then attempt to apply the 1.1.2 diffs in the RCS file to this text, which
> will most likely not have the result you or Paul were looking for.

And now I understand yet a bit better.  So the GCA issue that Mark pointed
out is not just for merges but also to checkout revisions (I now also
understand better why the SCCS format can be faster in some cases).

But IIRC, the magic branch stuff is done on-top-of RCS rather than
underneath RCS, so changing the CVS trunk to 1.1.1.1 is not going
to change anything to the fact that the branch's GCA is 1.1.  What am
I missing ?

It seems that as long as we don't retroactively change RCS revisions
we should be safe.  I.e. if we only change the magic-handling, things
should keep working.


        Stefan