On 22 Jun 2000, at 15:59, Greg A. Woods wrote:
>[ On Wednesday, June 21, 2000 at 22:50:26 (-0700), John P Cavanaugh wrote: ]
>> - Delete the whole concept of HEAD, instead generalize it to something
>>   really useful and scaleable like 
>>        <branchname>.latest - For the latest version on a branch
>>        <branchname>.base - For the version where the branch sprouted
>>                               (ie. the base from the parent branch)
>
>Agree 101%!  ;-)
>
>(There could be a bit of a chicken&egg problem to solve for ".base"
>though -- I think you actually have to create it if you want it because
>of the late branching optimisation, which is something you cannot avoid
>if you want to maintain repo compatability.)
>
>> - Allow importing directly to the main branch, get rid of the
>>   import branch.
>
>I don't like the latter half of this point though.  The magic vendor
>branch is still a major time saver vs. the effort one would have to go
>through to maintain local changes on a "normal" branch if the trunk is
>the vendor's branch (i.e. re-branching as well as re-merging after every
>import).  It would also be more error prone to have the vendor branch on
>the default branch -- people would be very likely to check it out and
>work on it by accident.

A thought...
Could it be that the vendor branch works so well because 'cvs import'-ing sets 
the 'branch 1.1.1;' field in the RCS header? Whereas 'normal' cvs commands don't
(and shouldn't).

I vaguely remember something about MKS RCS not correctly working out the default 
branch (i.e HEAD) to commit to because it didn't set the 'branch' field. But I'm going 
back 6+
years now and it's all hazy!

Mike

--
Share what you know. Learn what you don't.

Mike Little <[EMAIL PROTECTED]> 
work: <[EMAIL PROTECTED]>
Web: http://www.ampersoft.co.uk
PGP public key at http://www.ampersoft.co.uk/mike/mike.html

Reply via email to