[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Documentation suggested to clearer state restrictions to merging r
Derek R. Price
Re: Documentation suggested to clearer state restrictions to merging removed files
Thu, 07 Dec 2000 10:39:34 -0500
"Cameron, Steve" wrote:
> Derek Price wrote:
> > Linus Tolke wrote:
> > > I want a note in the (cvs)Merging adds and removals also. That is where
> > I
> > > look if I want to know how the handling of added and removed files is
> > made
> > > when you merge branches.
> > > [snip]
> > Okay, I took Linus' advice to heart. Comments anybody?
> > Derek
> [smc] Hmm, interesting. I think the first time I saw this
> thread I didn't fully understand it.
> I can see *why* one might want to use a single static tag. One
> might want to do
> something like this:
Thanks. I hadn't figured out why anyone would want to do this yet. I just
figured the behavior deserved a comment in the manual since it could happen
> 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:
> cvs rtag -r branch_tag merge_point everything
> cvs update -j branch_fork_static_tag -j merge_point
> But this has another problem, namely that file removals will
> be handled *without possibility of conflict*... according to
> the comments around line 2177 of update.c (cvs 1.11)
> which say:
> And when I first came across that, it seemed like a bug, but the
> more and more I thought about it, considering especially that the
> two -j options can refer to *any* two revisions, I'm convinced that
> what the comments say here is the correct way.
Can you provide me with an example of when this might be the desired behavior?
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:address@hidden OpenAvenue ( http://OpenAvenue.com )
77. (D)inner not ready: (A)bort, (R)etry, (P)izza?