bug-cvs
[Top][All Lists]
Advanced

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

Re: join not producing conflict


From: Paul Edwards
Subject: Re: join not producing conflict
Date: Tue, 21 Oct 2003 16:38:37 GMT

"Derek Robert Price" <derek@ximbiot.com> wrote in message 
news:mailman.2078.1066750915.21628.bug-cvs@gnu.org...
> | 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.

The specific case I used it on unsuccessfully the other day was
two people editing the same file in the same working directory.
I saved my version first, committed it, then they saved theirs,
and it (correctly) appeared to CVS that they had deleted my
change.  I then went to reapply the change, and it got squashed.

The other situation that I have attempted to use it in is where I
don't want to go to the effort of creating a new branch, what I
instead want to do is just have a base in CVS, my development
in CVS, and then in my working directory, I want to copy
someone else's changes (from the same base) into my working
directory, promptly losing all my changes.  But then promptly
reapply my changes.  That way I can incorporate other people's
changes, made outside of CVS, into my ongoing development.

I believe I can work around this problem by first of all
updating -r to the base version, then copying the external stuff,
then doing a cvs update -r to the head version.

But this workaround was not obvious to me at the time.  Also,
another workaround is to commit the 3rd party changes first,
before doing the -j -j, which creates a delta I didn't particularly
want.

Also, another circumstance where I do stuffing around is when
resolving conflicts, joining from one branch onto another branch.
I may see that they have reformatted the code, changing tabs to
spaces, so I do the same thing externally, and then ask for the
delta to be reapplied.

> 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.

True.

However, ignoring English, that still leaves the argument that
-j 1.1 -j 1.2 behaves the same as -j 1.2 -j 1.2.  That is a very
abnormal situation.

And the behaviour deviates from what diff3 would do if fed the
3 files in question.

> 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).

What other reason would a user be doing a -j -j unless they
wanted those changes incorporated into their working version,
whether or not they are already applied?  If they are already
applied, it does nothing (as I want), or if they are missing, they
get reapplied.

Exactly the same behaviour as would have happened had I
issued a spurious commit before issuing the update command.

Once again, totally consistent.  There is no reason why a
spurious commit should alter behaviour.

> 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.

ie they're explicitly doing a join and hoping that it will do nothing?

> 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.  :)

The workaround for that bug is to issue the following command:
echo hello >/dev/null

instead of cvs update -j -j

:-)

BFN.  Paul.




reply via email to

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