RE: Documentation suggested to clearer state restrictions to merg ing removed files

[Cameron, Steve]

> "Cameron, Steve" wrote:
> 
> >         So that brings up a third alternative, using a (previously
> created)
> >         tag to mark the origin of the branch, (or my ".origin" patch
> that I
> >         keep harping on about now and then) and two -j options:
> 
> I haven't had a chance to try those out.  What's their status?  Have many
> people been testing?  Have you received any comments that didn't go to one
> of
> the lists?
        [smc]  I haven't really gotten much feedback at all, what little
I've gotten has
        been good, but I don't thinik that those people actually tried it.
(I think I got
        responses from 2 people total. :-) oh well.

        The url is http://www.geocities.com/dotslashstar/branch_patch.html

        The status is there are no problems with it that I know of,
        except for maybe the following, which aren't serious:

        I kind of combined 2 patches together, the ".trunk" patch, which
        gives a branch name to the trunk that works just like a branch tag,
        and the ".origin" patch, which lets you refer to the starting point
        of a branch, by "branch_tag.origin".  Doing that goes against
HACKING,
        but I've had to maintain them for quite awhile now, and keeping two 
        rather largish patches up to date and separate when they both touch
        the same code was too hard, so I combined them.

        It also allows ".trunk.origin", which will give you the oldest
revision
        on the trunk, but I'm not sure allowing that was a good idea because
        as files are added to the trunk, ".trunk.origin" will give back
different
        results over time.   If files added to the trunk were added as
"dead"
        revisions first, that problem would go away I think..., 
        (but then ".trunk.origin" would probably return the empty set, how 
        useful is that?  Perhaps the combination of ".trunk" and ".origin"
        is just senseless.
        .
        Also, last time I updated it vs. the development version
        was about a month ago, so I should probably do another 
        "cvs update" and make a new patch to take into account
        any changes that have gotten checked in over the last month.

        -- steve

>