Re: Maintaining branches...

[Paul Sander]

>--- Forwarded mail from address@hidden

>On Thu, Jun 14, 2001 at 12:57:30PM -0400, Greg A. Woods wrote:
>> [ On Wednesday, June 13, 2001 at 23:12:16 (-0700), Paul Sander wrote: ]
>> >  The joins shouldn't be recorded in the
>> > repository until the commits are done anyway.
>> 
>> That's true!
>> 
>> > -j makes a notation in the CVS directory (or appends an existing one if
>> > multiple joins are done between commits), and -r and -A clear out the
>> > notations.  At commit time, the notations could be recorded in the RCS
>> > files for future use.
>> 
>> That's the trick.  How do you do that without impacting RCS compatability???
>> Is doing it as part of the commit message sufficient?


>This can already be accomplished with external scripts that make use of
>magic values in commit messages.

Relying on the users to type in this info is a notoriously unreliable
method to track this stuff.  It's better to have the tool do it instead,
especially since it has already been given the necessary info once.

>And even this, it only handles very special cases of merges.  That is, were
>all changes on one branch are merged into another.

>And I think that this complete merging happens less than you might think.

>It cannot handle the situation where a specific set of changes is migrated
>before another (i.e., -j tag1 -j tag2).  It may not even be off of an 
>immediate branch, but rather a couple over.

All that's recorded is the notion that some merge has been performed.  There's
no value judgement on what features of which branch survived the merge.
The goal here is to prevent redundant conflicts because the common ancestor
is always too distant after the first merge.  Presumably, if a feature did
not survive an early merge, it's intended to be omitted from all future ones.
So, I think that your preferred case is the one that's served.  If you
really need to go back to pick up an abandoned feature, then it's still
possible to supply the branch point label with a second -j option.

Also, I don't believe that the granchild branch is an issue; it's a merge
like any other.  And the merge can also draw from an ancestor, which is
handled equally well.

>--- End of forwarded message from address@hidden