[Top][All Lists]

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

Re: join not producing conflict

From: Derek Robert Price
Subject: Re: join not producing conflict
Date: Tue, 21 Oct 2003 11:41:12 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1

Hash: SHA1

Paul Edwards wrote:

| ie its behaviour is totally correct. I didn't see anything wrong,
|and don't see why you would seek to make any changes other
|than the one you have already made.

I'm mostly ambivalent to this change, but I think that the original
behavior might have been an intentional decision to assume that if
merging into the base revisionof a file  caused an empty diff, then no
attempt should be made to merge into the user's modified copy since they
had already seen this change and intentionally altered it.

In other words, though I agree with Paul that the comment held an
inappropriate use of the word "optimization", his argument was not a
valid one for the change since the comment might simply have held an
inappropriate use of the word, rather than inappropriate code.

Regardless, since `make check' passes for me on Linux with Mark's patch
and his changes to sanity.sh seem to be beneficial and not drastic in
nature, I don't have any immediate objections to the patch being
committed to stable, provided that a test is added to the new join6 that
produces and verifies merge markers can be generated correctly by the
new behavior.  Whether the previous behavior was by design or not, this
could be the least suprising result of an up -j -j command since every
time the command is run the requested merge will be attempted on the
local workspace, modified files or no.  The new assumption being that
the user knew about the local changes and was deliberately requesting
the re-merge, perhaps to reverse local changes (as is currently
happening in the join6 test).

As an example, a user might have merged two or more change sets, perhaps
made some local changes, then decided they didn't want one of the change
sets.  This is possible with the new behavior and may not have been
before if the merge being reversed was itself a backout of a previously
committed change.

It might still be worth asking on info-cvs whether anyone is depending
on the previous behavior.  There's a slight chance someone might read
the post and respond before we get the same information in the form of a
bug report following the next release.  :)


- --
~                *8^)

Email: address@hidden

Get CVS support at <http://ximbiot.com>!
- --
It does me no injury for my neighbor to say there are twenty gods or no god.
It neither picks my pocket nor breaks my leg.

           - Thomas Jefferson
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org


reply via email to

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