[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.
- Re: join not producing conflict, (continued)
- Message not available
- Re: join not producing conflict, Paul Edwards, 2003/10/21
- Re: join not producing conflict, Paul Edwards, 2003/10/21
- Re: join not producing conflict, Derek Robert Price, 2003/10/22
- Message not available
- Re: join not producing conflict, Paul Edwards, 2003/10/22
- Re: join not producing conflict, Mark D. Baushke, 2003/10/22
- Re: join not producing conflict, Derek Robert Price, 2003/10/24
- Message not available
- Re: join not producing conflict, Paul Edwards, 2003/10/22
- Message not available
- Re: join not producing conflict,
Paul Edwards <=
- Re: join not producing conflict, Derek Robert Price, 2003/10/21