Re: join not producing conflict

[Paul Edwards]

"Mark D. Baushke" <mdb@cvshome.org> wrote in message 
news:mailman.1996.1066644905.21628.bug-cvs@gnu.org...
> Well, it is doing a join_file(temp.txt, 1.2, 1.1, 1.2) on the server and
> then shipping the diff (none exists as version 1.2 already has the delta
> of 1.1 to 1.2 incorporated in it)

Version 1.3 and 1.4 etc etc also theoretically have the delta
of 1.1 to 1.2 incorporated in it.  That's no reason to not give
me the diff I specifically requested to bring across!  How
can the -j of 1.1 to 1.2 possibly be exactly the same as if
I had specified -j 1.2 -j 1.2?

> across to the client to incorporate
> into the already modified file. I think that if the top-of-tree version
> were different (say version 1.3), then you might see the kind of
> conflict markers you believe should be present.

I see no reason that if I had done a commit prior to issuing
the -j -j command that the behaviour would be different
(and work).

> I could be wrong, but I suspect that this is not really a bug even though
> the output might appear surprising. Would you expect

>   cvs update -C temp.txt
>   touch temp.txt
>   cvs update -j 1.1 -j 1.2 temp.txt

> to introduce another "ddd" line with or without conflict markers? What

I would expect it to say "change has already been applied".
This is always done in terms of a 3 way diff.  In this case,
1.1 is the base, and the two derivatives are 1.2 and 1.2.
Actually, given that the changes in the two derivatives are
the same, I would expect it to silently do nothing.  That's
what it does in other circumstances.  I see that all the time
when I'm merging from my branches.  It just quietly knows
what is going on, it doesn't get spooked that the change has
already been applied.

The only time I see it get spooked is when some idiot has
a locally modified version that is one ahead, and then the
do a cvs update -A filename.ic and cvs realises that they
already have that version in reality, they've clearly copied
it from someone else's working directory, and cvs says
"I know exactly what you did, stop doing it".

>   cvs update -C temp.txt
>   (echo "new" ; cat temp.txt) > new.txt
>   mv new.txt temp.txt
>   cvs update -j 1.1 -j 1.2 temp.txt

> should that do something with the "ddd" line?

Once again, the base is 1.1, there are two derivatives.
One has ddd already in it.  The other has both ddd and new.
The second one already incorporates the first, so there is
no further work to be done.

I guess the simplest thing to do is to say "what does
diff3 do, given those 3 files"?

Does CVS behave the same as diff3?  I can't see any reason
for CVS to ever behave differently from diff3.  CVS is, at
the end of the day, a glorified version of diff3.

> In my opinion, there is no problem here, or at least I see no way to
> change the semantics of cvs to accomodate your request without making
> it break other things even more.

I think that we just need to tell it that the head version is 1.9999999
and force the server to send the proper diff, just like I asked for.

What would that break?

Also, I can't see any logic at all that the behaviour of -j 1.1 -j 1.2
should be the same as -j 1.2 -j 1.2

That screams out "broken" to me.  That's a very rare sight to see in
computing/logic, that 1.1 would be the same as 1.2.

Actually, I think I know what is required.  1.9999999 should be
used as the head if and only if there is no local modification.  A
local modification means there is a new "derivative".  If you happen
to know that there is no change made between the local version and
the repository version, then the repository version can suffice as
the derivative.  E.g. when I'm merging in my branches, following
my normal procedure:

1. I make a change on the sydney branch.
2. I ship the change to USA.
3. I import the new USA code (which contains what I just gave them)
4. I merge the USA code on to sydney branch.

CVS can optimize that and produce a smaller diff, if it can see that
I haven't made any local change.  In fact, it can send back an empty
diff in the situation where the USA has taken our changes and applied
them without any change whatsoever.

This is not my situation.  I have a local version, and the local
version is the new derivative.

CVS must pretend version 1.999999 is the head and send back
the full diff.

BFN.  Paul.