Re: Documentation suggested to clearer state restrictions to merging removed files

[Derek R. Price]

"Cameron, Steve" wrote:

> > "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.

Sounds familiar.  :)


>         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.

Good excuse.  :)


>         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.

Hmm.  Yeah, and cvs co -r1.1 would do the same thing.  The only thing
meaningful I can think of for .trunk.origin would be to retreive the earliest
incarnation of the vendor branch, if present.

Does branch_name.origin retreive the branchpoint from the parent branch or from
the trunk?

You may not have to regen.  There haven't been a whole lot of changes to the
tree in the last month.  Probably couldn't hurt to check though.

Derek

--
Derek Price                      CVS Solutions Architect ( http://CVSHome.org )
mailto:dprice@openavenue.com     OpenAvenue ( http://OpenAvenue.com )
--
126. Always proof-read carefully to see if you any words out.