[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Documentation suggested to clearer state restrictions to merging
From: |
Derek R. Price |
Subject: |
Re: Documentation suggested to clearer state restrictions to merging removed files |
Date: |
Thu, 07 Dec 2000 13:54:52 -0500 |
"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.