[[ The contents of the original post have been snipped.
And this is a reply to > 1 posts by
Michael Bletzinger, Donald Sharp, David Martin, and Steve Cameron. ]]
That patch experiment suggested by Steve worked fine!
I did not have any problems. The patched file was exactly the same as
that in branch B1. Only CVS had issues with merging.
On Tue, Feb 22, 2000 at 10:42:44AM -0500, Donald Sharp wrote:
> Why shouldn't it give you conflicts? It's entirely reasonable that
> you have made( or someone within your company/whatever ) conflicting
> changes within the two branches...
On Tue, Feb 22, 2000 at 02:17:26PM -0500, Donald Sharp wrote:
> > I am not expecting conflicts because of the following:
> >
> > - I make sure that the B1 sand box is up-to-date
> > - I make sure that during my merge no one commits to B1 and B2
>
> conflicts have nothing to do with either of these two cases.
> Conflicts happen because there are some differences between the files
> that are in each of the branches, that cvs is unable to merge.
>
Steve has clarified what should be the expected behaviour.
Hence, I should not get conflicts.
On Tue, Feb 22, 2000 at 02:41:31PM -0600, Michael Bletzinger wrote:
> CVS occasionally generates false conflict reports during an update. The
> best way to check this is to do a cvs diff after the merge to see what
> was changed. Particularly look for "<<<<" (or ">>>" and "====") strings
> which indicate a real conflict.
>
Can you tell me when CVS generate false conflicts?
The solution suggested needs manual intervention.
When I am not at all expecting conflicts, and CVS generates conflicts,
I would like to fix it automatedly.
On Tue, Feb 22, 2000 at 12:19:33PM -0600, David Martin wrote:
> I'm not sure if the operation you are attempting (update/merge across
> branches) is supported in CVS. I question this based on this finding in an
> old FAQ:
>
[[ FAQ snipped ]]
That FAQ is a pretty old one (I think you are referring to the one
titled CVSFAQ in all caps and dated somewhere in 1995).
And again, Steve has explained what should actually happen.
On Tue, Feb 22, 2000 at 12:56:27PM -0600, Cameron, Steve wrote:
> [...]
> What kind of conflicts...?
> What do they look like?
After the update has been done, the file is almost like the HEAD of B2
but for the conflicting portion. In fact, I had three files which
had this trouble. Two of them had conflicts "around" lines containing
keywords like $RCSfile$ and $Revision$. Of course, I did use the -kk
option. But the third file had conflicts in a different place nowhere
near the keyword lines. I don't know whether that proves that the
conflict has nothing to do with RCS keywords. But all the files have
keywords in them.
>
> For some file with a conflict, what if you do
>
> cvs diff -c -r B1 -r B2 > patchfile
> patch problem_file < patchfile
>
> Does that work as you would expect?
YES!!!
On Tue, Feb 22, 2000 at 02:41:49PM -0600, Cameron, Steve wrote:
> [smc] When you specify two "-j" options, CVS does not try to find a
> common ancestor. It merely computes the differences between
> point A and point B in the form of a patch, and attempts to apply
> that
> patch.
>
> In this case, point A is the tip of one branch, and purportedly also
> the current up-to-date contents of the sandbox, and point B is the
> tip of another branch. So CVS should compute the diffs between
> A and B, and apply those diffs to the sandbox, which is supposed
> to contain exactly A... so, reasonably one could expect the patch
> to go through without a hitch (conflict) and produce a sandbox
> with contents identical to B.
>
> This is apparently not happenning in this instance, hence the
> original question.
>
>
Yes, that is the case. Thanks Steve, for clarifying.
Regards
Sankar
