On Wed, Mar 31, 2010 at 09:50:33AM +0200, Bert Huijben wrote:
> > -----Original Message-----
> > From: Stefan Sperling
> > Why not allow application of a patch which carries a diff that would
> > not
> > touch a conflicted property before the user has dealt with property
> > conflicts?
>
> Merge tracking?
>
> And even your very simple merge of 'svn merge ^/blah/foo.c_at_2 ^/blah/foo.c_at_3
> bar.c' can bring in property changes. It is not a text only merge.
I'm well aware of that. Maybe you missed this part of my
sentence: "not touch a conflicted property" ?
> You would have to run a full dry run of the merge to determine whether it
> would bring something incompatible.. And merge is slow enough as is.
> If we don't do the dry run merge, how are you going to handle the case where
> you do get the conflict?
> (We don't have the necessary storage to perform a rollback to before you
> started the merge)
I know that merge right now cannot do this properly.
But that is because of how merge is currently implemented.
It's not because it is absolutely impossible to do.
So let's think outside the box for a minute. Just because merge has
this limitation now does not mean it will have this limitation forever.
E.g. we may some day change the merge to be 2-pass.
The client would first receive a summary describing intended edits,
tree- and property changes. It could then check the conflicted state
of all affected nodes, and either allow the merge to proceed or abort
the merge, depending on whether the merge wants to edit conflicted
content, change conflicted properties, or change conflicted trees.
A 2-pass scheme would also allow us to e.g. resolve tree conflicts
during the first pass (matching up the two trees involved in the merge,
possibly with interactive prompting) and then apply text/property
changes during the second pass using the current merge algorithm
which assumes that trees on either side are identical.
So, why do you think the storage layer should care about any of this?
I think it should not care. It should not assume that our merge
operation will forever behave as it does now.
And I am not simply making requirements up.
I have seen release engineering people in a company do giant merges,
and then ask many developers to their desk, one after the other,
to help them resolve conflicts.
They had to do lots of manual edits to get all the conflicts resolved.
They could not use svn merge to apply diffs, but it would have helped
them (arguably, better rename handling may also have helped them to
the same degree.)
> Same applies for 'svn patch'. That will allow updating properties (maybe not
> in 1.7, unless it applies autoprops on new files. (Does it?))
Yes, it will allow updating properties.
But that does not mean that we couldn't check for conflicted properties
before applying any property changes from the patch. If you try to apply
a patch which wants to change conflicted properties, you get:
svn: Cannot apply patch foo/bar because property svn:eol-style on path
foo.c is still in conflict.
Regarding autoprops, no, I don't think it does, because autoprops are
done by libsvn_client. Patch calls the add function from libsvn_wc.
Good catch!
> > I don't think you understand what I want to do.
> > Adding new conflicts on top of existing conflicts is not what I was
> > suggesting to support. I'm suggesting proper layering to keep doors
> > open for future enhancements. I want the storage layer to care about
> > storage, not about policy.
>
> I don't think you can use these 'normal' operations to resolve your
> conflict.
>
> High level tools, can use very similar operations to resolve the conflict
> for you. (E.g. visual merge that retrieves all versions and perform the
> merge). But 'svn merge', 'svn update' and 'svn switch' are not safe on a
> conflicted tree.
Well, it seems we're unlikely to come to a common opinion on this
given that we've been reiterating the same points over and over in
this thread.
So... Greg said that we can always easily change the conflict skels
if we need more flexibility. So even if we limit the storage now,
we can remove these limits later (that may mean some additional work
later, but whatever).
So, asking everyone again, would you rather:
1) Encode into the storage layer that "all conflicts are created
through a single operation only, and no other operation can run
until all conflicts on a node are resolved, whether or not the
operation really has anything to do with the recorded conflicts".
2) Give the storage layer a new point of view, saying "I don't care
how conflicts come about, I just record them, including which
operation has caused them. I will allow you to look at each conflict
in isolation from all others, and resolve each independently in
whatever way you see fit (even if you want to use additional
operations to do so). I will not allow higher layers to record
conflicts which conflict with what I've already recorded, but other
than that I don't care."
I'd prefer 2), but would go for 1) if the majority thinks that's
better. Making progress is more important right now than endlessly
discussing subtle points like this.
Stefan
Received on 2010-03-31 14:21:56 CEST