Re: adding on branch

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

> > Adding a file on a branch *MUST* (due to the nature of the RCS file format)
> > add a head revision. Since the head revision is simply a placeholder, it is
> > marked dead.
> 
> Exactly: it's an implementation detail that has unexpected consequences.
> I.e. a bug.  People shouldn't have to know about it and it shouldn't affect
> unrelated things like `import'.
> 
> Think of it this way:
> 
> 1 - create a branch B
> 2 - import a new vendor version with a new file F (gets rev 1.1.1.1)
> 3 - add a new file F on branch B
> 
> now the HEAD of the trunk for file F is 1.1.1.1 (it's magical).
> But if switch steps 2 and 3, you instead end up with a dead head
> for file F on the trunk.
> 
> Why should the order of 2 and 3 make any difference to the user ?
 
Why should they be the same? Apparently the local site has local changes
cooking that might well need to be merged into the top-level or branched
off of the top-level if the order is reversed.
 
>         Stefan
> 
> 
> PS: Note that I'm not saying it's a bug to mark the head as dead.
> The behavior as a whole exhibits a bug, but whether it's fixed by
> "not marking head as dead" or by "import notices that the head is dead
> and resurrects it" or some other mean doesn't matter.

Okay, you say you don't like this situation. 

What solution are you going to propose for it?

It sounds like you are proposing that the vendor branch be chosen based
on bringing in a new dead version on top of an existing dead version

For example,

  1.1 is dead
  1.1.2.17 is the active version on the branch
  <import>
  1.2 is dead, but copy of 1.2.1.1
  1.2.1 is the vendor branch
  1.2.1.1 is the first version on the vendor branch
  <commit to trunk>
  1.3 becomes the first local modification of the vendor branch

is this what you are suggesting? (If not, please be more explicit as to
why the behavior needs to be changed and suggest possible alternatives
to the current operation.)

If so, doesn't this violate the principle of least astonishment that
the local site may have desirable code in the 1.1.0.2 branch they
created that should be merged into the trunk if that code goes live?

Sure, I can understand that some uses of cvs may want the development at
the main site to be the driver, but then I would have expected them to
be using CVSup and CVS_LOCAL_BRANCH_NUM to make sure that everyone had
access to the master repository environment... or possibly, having the
master site create empty mainline files that could be branched and used
for distributed development.

	Thanks,
	-- Mark