RE: .origin patch

[Cameron, Steve]

Thanks for trying it out.  Let me know especially if you
try anything with vendor branches.  (I've been meaning to
get to that... )

Stephen Rasku [mailto:stephen@tgivan.com] wrote:

> I was asked to look at Steve Cameron's .origin patch a few 
> months ago. 
>  I have had it installed for about 4 months now and none of my 
> developers have complained about anything being broken.
>
Nice to hear, though I suspect most of them aren't using the 
new features simply because there is not usually a frequent
need to do so.  (Though I could imagine using ".trunk" regularly).

> Today, I did a merge using the .origin feature.  My original merge was
> 
>       cvs update -kk -j branch
>       
> which generated a lot of spurious differences.  I then did:
> 
>       cvs update -kk -j branch.origin -j branch
>       
> and it generated a much cleaner tree.  I only had one conflict to 
> resolve.

I don't think that's really a feature of my patch, 
I would expect that you'd get the same results if 
you had done:

        cvs update -kk -j static_tag -j branch

where "static_tag" would be a normal tag you created to 
mark the beginning of the branch when the branch was created.

(If that's not the case, then something's wrong.)

The one place I can think of where merging differs
depending on if you specify one or two -j options is
for files which are removed in the development line you
are merging into your working directory.  In the case of
two -j options, file deletions will be merged in without
possibility of conflict, whereas with one -j option, if
the files have been modified on the working directory
line, file deletions on the "merge-from" line will
cause conflicts, IIRC.

Were the "spurious" conflicts coming from files which were
deleted on the branch you were merging from,
(which is what would I expect) or something else?

-- steve