bug-cvs
[Top][All Lists]
Advanced

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

Re: bug report: update with two -j params: join fails for a specific fil


From: Paul Edwards
Subject: Re: bug report: update with two -j params: join fails for a specific file if the first tag is not found
Date: Wed, 26 Feb 2003 08:30:41 GMT

"Horne, Graham" <address@hidden> wrote in message news:address@hidden
> Scenario:
>
> I am merging changes from a branch to the trunk. I am using tags on the
> branch to indicate which changes have already been merged to the trunk (ie
> before the merge, I tag the current state of the branch). I then use cvs
> update with two -j params to mark the scope of the changes I want to merge
> to the trunk. (eg cvs update -j tag1 -j tag2)
>
> If a file has been created on the trunk, then modified on the branch since

How did it get onto the branch?  If you merged stuff from the
trunk to the branch, then the scope of your change from tag1
to tag2 doesn't represent the changes you have made on the
branch, it represents a combination.  But since the changes
are the same, it should have worked anyway.

> the last time I did a merge, then that file will not be tagged with the tag
> used in my first -j parameter. (tag1 in the example)
>
> Expected outcome:
>
> What I would expect CVS to do in this case, is to behave as if only one -j
> had been specified (ie merge changes from the common ancestor of the working
> copy and the revision identified by the (2nd) -j parameter - (tag2 in my
> example)).
>
> Actual outcome:
>
> What CVS actually does is:
> * report an error "cvs server: file <filename> exists, but has been added in
> revision <2nd -j parameter>"
> * leave the trunk version untouched - (ie it fails to merge the branch to
> the trunk)

And not even report a conflict to be manually sorted.  Yeah, I have
the same problem.  I have since worked around it by changing the
merge procedures to include a search for "has been added" and
treat that as a conflict.  It's a pity that CVS doesn't mark it as a
conflict needing manual intervention.  I wonder how CVS actually
marks files as a status of "conflict, needs resolution"?  Does it
search for the "<<<<<" or is it in Entries or done by timestamp
or something?

BFN.  Paul.




reply via email to

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