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

[Linus Tolke]

I would like to argue this because of two reasons.

1) It is good to be extremely clear about this since the behaviour in itself
is confusing. For example (given the following preparations):
cvs update -A
touch a b c
cvs add a b c; cvs ci -m "added" a b c
cvs tag -b branchtag
cvs update -r branchtag
touch d ; cvs add d
rm a ; cvs rm a
echo hej > c
cvs ci -m "added d, removed a, changed c"
cvs tag tag_on_branch
cvs update -A

If I do:
cvs update -jbranchtag
    a is removed
    d is added
    c is changed
in the checked out copy of my main trunk.

If I instead do:
cvs update -j tag_on_branch
    d is added
    c is changed
in the checked out copy of my main trunk.
a is not removed!

I think this is a perfect candidate for a lot of confusion, it certainly
confused be and my co-worker. I think it should be pointed out where the
merging of branches containing removal of files is discussed i.e. the node
(cvs)Merging adds and removals.

2) When reading the node (cvs)update options it says that it merge changes
from the ancestor revision to the revision specified with the -j option. It
doesn't say that the given revision in some cases need to be a branch tag
instead of a fix tag.

        /Linus



> -----Original Message-----
> From: dprice [mailto:dprice]On Behalf Of Derek R. Price
> Sent: den 29 november 2000 16:28
> To: linus@epact.se
> Cc: bug-cvs@gnu.org
> Subject: Re: Documentation suggested to clearer state restrictions to
> merging removed files
>
>
> linus@epact.se wrote:
>
> > >Description:
> > I would like the Merging and adding files to be more elaborate
> when discussing
> > how removed files are merged.
> >
> > >Fix:
> > Add a note saying:
> > Note that the `cvs update -j' command above does only work on
> branchtags.
> > This doesn't work if you are doing the update against a normal
> tag located
> > on the branch.
>
> I don't think that's really necessary.  The "Merging adds and
> removals" section comes after three
> sections which explain branching and merging pretty explicitly,
> including specifying that '-j
> BRANCH' or "two '-j REVISON' flags" are necessary.  These are all
> subnodes (or subsections in HTML
> & PS) of the "Branching & merging" section.  On a consecutive
> reading I think the extra note would
> sound pretty redundant.
>
> Feel free to argue if you like, of course.
>
> Derek
>
> --
> Derek Price                      CVS Solutions Architect

http://CVSHome.org )
mailto:dprice@openavenue.com     OpenAvenue ( http://OpenAvenue.com )
--
Doesn't expecting the unexpected make the unexpected become the expected?