[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Documentation suggested to clearer state restrictions to merg ing
RE: Documentation suggested to clearer state restrictions to merg ing removed files
Thu, 7 Dec 2000 11:25:14 -0600
> "Cameron, Steve" wrote:
> > So that brings up a third alternative, using a (previously
> > 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
> 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
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
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
results over time. If files added to the trunk were added as
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.