bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Documentation suggested to clearer state restrictions to merging r


From: Derek R. Price
Subject: Re: Documentation suggested to clearer state restrictions to merging removed files
Date: 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.

[snip]

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

[snip]

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

[snip]

>         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

--
Derek Price                      CVS Solutions Architect ( http://CVSHome.org )
mailto:dprice@openavenue.com     OpenAvenue ( http://OpenAvenue.com )
--
77. (D)inner not ready: (A)bort, (R)etry, (P)izza?






reply via email to

[Prev in Thread] Current Thread [Next in Thread]