bug-cvs
[Top][All Lists]
Advanced

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

[Fwd: [Fwd: CVS merge issue: "cvs update -j -j"]]


From: Frederic Gioanni
Subject: [Fwd: [Fwd: CVS merge issue: "cvs update -j -j"]]
Date: Wed, 02 Apr 2003 19:19:33 +1000

    Hi,

I forwarded your answer to the person who raised this problem
originally.
You will find his reply below.

I fully agree with his comments and I do believe that CVS acts
incorrectly
in this situation.

Further comments are welcome...

    Regards,

        Frederic Gioanni

--- Begin Message --- Subject: Re: [Fwd: CVS merge issue: "cvs update -j -j"] Date: Wed, 02 Apr 2003 08:27:49 +0000 Hi Fred,

As promised, here's my reply.  I insert text after <bjacob@ca.metsci.com>'s commentary.

Regards,

O.

Frederic Gioanni wrote:

FYI

  ------------------------------------------------------------------------------

Subject: CVS merge issue: "cvs update -j -j"
Date: Fri, 28 Mar 2003 17:31:01 -0800
From: bjacob@ca.metsci.com
To: frederic.gioanni@thalesatm.com
CC: bug-cvs@gnu.org
References: <3E7D5B69.DA324628@thalesatm.com>

Frederic Gioanni writes:
>     Hi,
>
> I have got some problems when merging delta between rev1 and rev2 into
> my Working revision of a file using
>     cvs  update  -j  rev1  -j  rev2  file
>
> I am using CVS 1.10 with diff3 2.7. The same problem occurs in the
> latest version of CVS.
>
> Let's say that the content of file:rev1 is:
>
>     a
>     b
>     c
>
> Content of file:rev2 is:
>
>     a
>     b
>     c
>     d
>     e
>
> Content of my working revision is:
>
>     a
>
> When doing the merge, I am expecting 2 new lines and so I am expecting
> the following conflict:
>
>     a
>     <<<<<<< file
>     =======
>     d
>     e
>     >>>>>>> rev2

When two changes conflict, a merge utility should add conflict markers
that show both of the changes.  But the above file shows only one of
the changes, namely the addition of d and e.  But it does not show the
deletion of b and c even though that deletion conflicted with the
other change.

My reading of this situation is different.  The update command has been asked to (1) identify the change delta between rev-1 and rev-2, and (2) to insert change delta at the appropriate point into the local clone's copy of the file.    The change delta between rev-1 and rev-2 should contain the insertion of lines <<d>> and <<e>>.  The change delta should not contain references to <<b>> or <<c>> as they do not represent changes between rev-1 and rev.2

Consider the following CVS branch structure and consequential Venn diagrammes.
Here the developer has a clone of V1.5, and performs the command "cvs update -j 1.2.2.2 -j 1.2.2.3 file".

   The branch structure...

+-----+    +-----+    +-----+    +-----+    +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !   <- The main trunk
+-----+    +-----+    +-----+    +-----+    +-----+
              !
              !
              !   +---------+    +---------+    +---------+
  Branch R1fix -> ! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
                  +---------+    +---------+    +---------+
 

   The corresponding Venn diagrammes for the above branches (relevant bits only) ...

File@V1.5       File@V1.2.2.2   File@V1.2.2.3
+---------+     +---------+     +---------+
|    A    |     |    A    |     |    A    |
+---------+     |    B    |     |    B    |      
                |    C    |     |    C    |
                +---------+     |    D    |
                                |    E    |
                                +---------+

The below Venn diagramme shows the computed delta of the change from V1.2.2.2 to V1.2.2.3 ...

   Delta b/n V1.2.2.2 and V1.2.2.3
   +---------+
   |    D    | <= set insertion
   |    E    | <= set insertion
   +---------+

The below Venn diagramme shows the result of insertion of above delta above into File @ V1.5

    +---------+
    |    A    | <= from V1.5
    |    D    | <= from delta
    |    E    | <= from delta
    +---------+
 

I.e., the above file is biased in favor of one of the two new revisions
of the file.  An analogy of this would be how newspapers often have a
policy that they will report both sides of an issue so as to be fair.
For example, if there is conflict between two senators, where one
senator offers a reason in support of a bill and another senator
offers a reason to be opposed to it, then to be fair, the newspaper
should quote both of the senators.  If it quotes only one senator,
then reader might think that argument makes sense and the reader might
not know of any opposing arguments.  If the reader knew about opposing
arguments he might change his mind.
I prefer not to use analogies; they are often distracting and introduce things that are irrelevant to the discussion.
This is analogous to how the person resolving the conflict in the
above file will not know that anyone deleted b and c.  But suppose
that that deletion was a mistake.  If only the person who is resolving
the conflict knew that someone deleted it, then he might realize that
that person made a mistake.  The above file will not help him notice
that mistake which means the mistake would remain uncorrected.  The
file below is better because it does show that someone may have
mistakingly deleted b and c.
I disagree.

There is no concept of <<b>> or <<c>> in either V1.5, or the delta (resulting from the difference from V1.2.2.2 to V1.2.2.3).

As such, it should not be proposed by CVS as a part of the conflict.

>
> However, "cvs up -j -j" ends with:
>
>     a
>     <<<<<<< file
>     =======
>     b
>     c
>     d
>     e
>     >>>>>>> rev2
>
> When resolving the conflict, the user thinks that 4 lines were added
> between rev1 and rev2 whereas only 2 lines were added.

Whenever one version of a file has some text which another file does
not have, it can always be interpreted in two ways: either someone
added the text to one file or someone deleted the text from the other
file.  The user in your example is mistaken if he does not consider
both possibilities.  When cvs made the file above, cvs did not imply
one interpretation over another.  Therefore the user should likewise not
assume one interpretation must be the right one based on only seeing
the above file.  However, the user will have other information which can
help him decide which interpretation is correct.  Specially, the user
will remember what changes he made so he will know whether he added or
deleted anything.  Knowing that will help him know if the other file
added or deleted anything.  Therefore, he can figure out which
interpretation is correct.  And if he forgets what changes he made, he
can ask cvs to show him the complete file of rev1.  That will make it easy
to see whether these changes are additions or deletions.

I disagree.

CVS should not attempt to imply one interpretation from the other; CVS should not imply anything.
The user is explicitly telling CVS what to do via the sequencing of the update parameters "-j XXX -j YYY".

(It can only be interpreted in only one way, because the "-j XXX -j YYY" is ordered.  It calculates the delta between XXX and YYY *with respect to* XXX.  eg XXX + DELTA_XXX_TO_YYY = YYY.

Issuing "-j YYY -j XXX" computes the delta between XXX and YYY, with respect to YYY. eg YYY + DELTA_YYY_TO_XXX = XXX.

The deltas DELTA_XXX_TO_YYY and DELTA_YYY_TO_XXX are distinct.  If the DELTA_XXX_TO_YYY delta contains set inclusions, the corresponding DELTA_YYY_TO_XXX delta would contain set deletions.)

So, in my opinion, CVS is acting correctly.
I disagree.  In my opinion, which is based upon my reading of the CVS man and info pages, CVS is not performing correctly in this situation.

You may will continue to state that this behavior is correct, but if so then I contend that this contradicts the CVS documentation.

We welcome your reply to the above.

Regards,

O.
 

Attachment: owen.veenstra.vcf
Description: Card for Owen VEENSTRA


--- End Message ---

Attachment: frederic.gioanni.vcf
Description: Card for Frederic Gioanni


reply via email to

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