[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: allowing multiple conflicts in storage

From: Bert Huijben <bert_at_qqmail.nl>
Date: Wed, 31 Mar 2010 11:48:22 +0200

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: dinsdag 30 maart 2010 19:34
> To: Julian Foad
> Cc: Bert Huijben; dev_at_subversion.apache.org
> Subject: Re: allowing multiple conflicts in storage
>
> On Tue, Mar 30, 2010 at 05:56:54PM +0100, Julian Foad wrote:
> >
> > > Conflict meta data storage in wc-ng
> > > ===================================
> > >
> > > Conflict meta data is stored in the ACTUAL_NODE table, within the
> > > 'conflict_data' column. The data in this column is a skel containing
> > > conflict information, or NULL (meaning no conflict is present).
> >
> > Is storing a record in ACTUAL OK even for a node that (apart from the
> > conflict descripition) has no BASE and no ACTUAL in the WC? E.g.
> > because it wasn't there and an incoming delete cause a tree conflict.
> > What values would the rest of the ACTUAL_NODE columns have in this
> case?
>
> Not sure right now. I guess I don't know the schema well enough yet to
> answer this question. Anyone?

All columns in ACTUAL (except wc_id, local_relpath and parent_relpath) are
optional (default=NULL), so this is not an issue.

You have exactly the same thing when you would apply a changelist on a path
and then remove it.

The only special case is that you can have tree conflicts on nodes that are
neither in WORKING nor in BASE. (That is why we stored them on the parent
directory in 1.6)

We can just allow that case in WC-NG, by enumerating over the nodes in
ACTUAL in svn_wc__db_read_conflict_victims(), while
svn_wc__db_read_children() doesn't look at ACTUAL.

(svn_wc__db_read_conflict_victims() currently fakes this behavior by reading
ACTUAL and the parents ACTUAL, parsing the old conflict data)

        Bert
Received on 2010-03-31 11:49:02 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.