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?
> 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.
Stefan
Received on 2010-03-30 18:15:23 CEST