> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: dinsdag 30 maart 2010 18:15
> To: Bert Huijben
> Cc: dev_at_subversion.apache.org
> Subject: Re: allowing multiple conflicts in storage (Re: svn commit:
> r928806 - /subversion/trunk/notes/wc-ng/conflict-storage)
>
> On Tue, Mar 30, 2010 at 05:55:00PM +0200, Bert Huijben wrote:
> >
> >
> > > -----Original Message-----
> > > From: Stefan Sperling [mailto:stsp_at_elego.de]
> > > Sent: dinsdag 30 maart 2010 16:30
> > > To: dev_at_subversion.apache.org
> > > Cc: commits_at_subversion.apache.org
> > > Subject: allowing multiple conflicts in storage (Re: svn commit:
> r928806 -
> > > /subversion/trunk/notes/wc-ng/conflict-storage)
> > >
> > > On Mon, Mar 29, 2010 at 03:37:51PM -0000, rhuijben_at_apache.org
> wrote:
> > > > Author: rhuijben
> > > > Date: Mon Mar 29 15:37:50 2010
> > > > New Revision: 928806
> > > >
> > > > URL: http://svn.apache.org/viewvc?rev=928806&view=rev
> > > > Log:
> > > > * notes/wc-ng/conflict-storage
> > > > Update schema to have some global information that applies to
> all
> > > > conflict data. Remove this data from the individual locations
> as it
> > > > can't differ between these locations anyway (or the node would
> have
> > > > been skipped). Finally add unversioned obstructions as a
> conflict
> > > > class.
> > >
> > > > -Text conflicts
> > > > ---------------
> > > > +Common conflict data
> > > > +--------------------
> > > >
> > > > -Text conflicts only exist on files. The following information
> > > > -is stored if there is a text conflict on the node:
> > > > +Some information is shared for all conflict data that applies to
> a
> > node. E.g.
> > > > +when a node has a combination of text and property conflicts
> these were
> > > > +always caused by the same operation. (Any later operation will
> skip the
> > > node
> > > > +unless the conflicts are resolved)
> > > >
> > >
> > > I'm still not sure that I agree with this.
> > >
> > > I don't think it's smart to restrict the conflict storage layer
> > > to accept only a single set of conflicts for a node, all of which
> > > belong together to the point where you cannot do anything to the
> > > node unless you have resolved *all* conflicts.
> > >
> > > I'd like the storage layer to allow for resolving each type of
> conflicts
> > > separately from the other types. Higher-level operations can then
> decide
> > > whether it is safe to do something to the partially-conflicted
> node.
> > > E.g. if a file has only property conflicts, why should a merge skip
> > > merging changes into the file itself? If a directory is tree
> conflicted,
> > > why should I not be allowed to merge some content into a file below
> > > the tree-conflicted directory if doing so helps me to resolve the
> tree
> > > conflict?
> >
> > I intended to allow resolving only some parts of the conflict; but we
> can't
> > allow operations that can introduce conflicts on their own.
>
> Sure.
>
> > You can't apply a merge/update/switch/patch on a node that has a
> > text/property/obstruction/patch conflict, because a can cause a
> conflict
> > with the conflict state (How would you describe that?). You can't
> trust the
> > in-wc state if you have a conflict.
> >
> > In 1.6 the way to resolve a text conflict is to edit the in-wc text
> with all
> > the information provided and then mark it resolved.
>
> Yes, and it's a pain that I can't just do:
>
> svn merge ^/blah/foo.c_at_2 ^/blah/foo.c_at_3 bar.c
>
> as part of my local edits.
>
> And (speaking from a user perspective who doesn't know how svn works
> internally
> for a minute) why doesn't svn let me do this merge if bar.c is a tree
> conflict victim, but has not text conflicts recorded on it?
>
> I know that it may be impossible for us to figure out what the merge
> really does before we carry out the merge. We might not know if the
> merge is safe. But why design the storage layer around this assumption?
> It's easy enough to enforce the same restriction at a higher layer.
>
> > The same applies to properties: You read the '.prej' file and decide
> what
> > the new property value(s) must be and you mark all resolved. (Or just
> one
> > with the new storage).
>
> Why force users to resolve property conflicts before they can e.g.
> merge
> additional content into a file using 'svn merge'?
> 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.
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)
Same applies for 'svn patch'. That will allow updating properties (maybe not
in 1.7, unless it applies autoprops on new files. (Does it?))
>
> > But that doesn't make it possible to introduce new conflicts on top
> of
> > existing conflicts; that is +- impossible.
>
> 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.
(update and switch just skip any conflicted node and merge tries to do some
things, but I don't know if your mergeinfo is correct if you merge over a
conflict)
Bert
>
> Stefan
Received on 2010-03-31 09:51:22 CEST