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

[Linus Tolke]

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.

I have made it a habit of browsing the info pages very quickly. Most of the
time I just search through them for a word that describes what I am looking
for and sometimes I go to the index and search there. In this case I think I
found the node (cvs)Removing files from the index or by searching and then
from there went through the note to (cvs)Merging adds and removal that was
exactly what I was looking for. This behaviour makes me in favor of placing
information like this in all relevant parts of the document.

My comments on the suggestion below is that you can remove the word "often".
Either (this is what I suspect) this happens all the time and then "often"
is incorrect or this happens in some cases only. If it only happens in some
cases I think you should somewhere explain in what cases it happens and in
what cases it does not and reference that here.

Another comment is that the explanation of how the -j tag works is also
present in the (cvs)checkout options node and I would suspect that it works
in the same way there.

Perhaps it would be better to instead enter a shorter comment in (cvs)update
options and (cvs)checkout options saying things like:
For details on merging adds and removals see (cvs)Merging adds and removals.
Then only include the complete explanation there. The reason for this is to
not clutter up the options lists with this rather long explanation of this
special case.

        /Linus

> -----Original Message-----
> From: dprice [mailto:dprice]On Behalf Of Derek R. Price
> Sent: den 30 november 2000 17:16
> To: Linus Tolke
> Cc: bug-cvs@gnu.org
> Subject: Re: Documentation suggested to clearer state restrictions to
> merging removed files
>
[snipp]
> Comments on the following addition to the "update options" node?
>
>  revision which the working directory is based on, and
>  the revision specified in the @samp{-j} option.
>
> +Note that using a single @samp{-j TAGNAME} option rather than
> +@samp{-j BRANCHNAME} to merge changes from a branch will
> +often not remove files which were removed on the branch since the dead
> +revisions do not contain the static tag.  Use the branch tag to merge all
> +changes on the branch or use two static tags as merge endpoints
> to be sure
> +all intended changes are propagated in the merge.
>
>  In addition, each @samp{-j} option can contain an optional
>  date specification which, when used with branches, can
[snipp]