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

Re: Conflict storage in 1.7

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Mon, 13 Dec 2010 09:41:15 -0600

[Apologies to Bert if my earlier comments were a bit pointed.]

On Sat, Dec 11, 2010 at 8:33 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Fri, Dec 10, 2010 at 01:14:25PM -0800, Hyrum K. Wright wrote:
>> On Fri, Dec 10, 2010 at 12:07 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>> >
>> >
>> >> -----Original Message-----
>> >> From: hyrum_at_hyrumwright.org [mailto:hyrum_at_hyrumwright.org] On Behalf Of
>> >> Hyrum K. Wright
>> >> Sent: vrijdag 10 december 2010 17:11
>> >> To: Subversion Development
>> >> Subject: Re: Conflict storage in 1.7
>> >>
>> >> Hearing no objections, I'm going to mark this as DONE.
>> >
>> > I don't think we can properly mark unversioned obstructions with just the
>> > current datastore. We need that storage to allow an update to complete
>> > regardless of obstructions.
>> > (And we can't keep the original behavior of 1.6 of unversioned obstructions
>> > as an unversioned directory obstructing a different directory wouldn’t be
>> > noticed with a single db).
>> Why can't we keep the original behavior of 1.6?  Is there a behavior
>> regression (in which case, it wouldn't be the original behavior of
>> 1.6)?  Could you elaborate on the case you mention about?  Or better
>> yet, author a test case to illustrate it?
> Some observations:
> In 1.7, you get a tree conflict if a directory obstructs an addition
> of another directory during update:
> $ svn up
> Updating '.' ...
>   C foo
> At revision 3.
> Summary of conflicts:
>  Tree conflicts: 1
> $ svn st
> ?     C foo
>      >   local unversioned, incoming add upon update
> Summary of conflicts:
>  Tree conflicts: 1
> IIRC we once decided that obstructions should not cause tree conflicts.
> Only versioned item should cause tree conflicts, and obstructions should
> be skipped. Apparently, this decision has not been enforced consistently
> throughout the code since we still have an "unversioned" tree conflict reason.
> 1.6 behaved as follows:
> $ svn up
> subversion/libsvn_wc/update_editor.c:2335: (apr_err=155000)
> svn: Failed to add directory 'foo': an unversioned directory of the same name already exists
> I like the current 1.7 behaviour better than the 1.6 behaviour because the
> update isn't instantly aborted when an obstructing directory is found.
> But maybe 1.7 should skip adding the directory instead of flagging a
> conflict? I don't really care, except that the behaviour in obstruction
> cases should be consistent (either skip, or flag conflict).

Agreed. Do we have a matrix somewhere of the various combinations of
state and what the current and/or expected behaviors should be? Such
a document would make testing, as well as ensuring, consistency much

> Another scenario:
> Update brings in a change for a file within a directory which has been
> replaced without telling svn about this (rm -rf dir; mkdir dir):
> 1.7 restores missing files inside the directory:
> $ svn up
> Updating '.' ...
> Restored 'epsilon/zeta'
> U    epsilon/zeta
> Updated to revision 3.
> 1.6 errors out like this:
> $ svn up
> subversion/libsvn_wc/lock.c:947: (apr_err=155005)
> svn: Directory 'epsilon/.svn' containing working copy admin area is missing
> I suppose Bert would like 1.7 to error out (or skip the directory, or
> flag a tree conflict), instead of assuming the directory was versioned.
> FWIW, mercurial (another "single-db" system) behaves like 1.7 in this case.
> So the current behaviour isn't necessarily bad or something people won't
> expect. Then again, unlike Subversion, mercurial and git explicitly don't
> treat directories as versioned objects.
> I suppose the most important question here is whether we can change this
> behaviour later without breaking backwards compat if we released 1.7 as is.
>> > I would really like to see more of the enhanced conflict storage model in
>> > 1.7.
>> Will you then commit to implementing this behavior in a timely manner,
>> so as to not further delay 1.7?
>> > And until we get the code to a proper atomic behavior in the more common
>> > code paths (which I would call a show stopper) this can be implemented in
>> > parallel just fine.
>> >
>> >
>> > And I don't understand how you call something that hasn't been implemented
>> > 'DONE'. Maybe 'postponed' or something like that, but certainly not 'done'.
>> The bits about moving conflict information to the victim is done.  Of
>> course there is always future work to be done, but my intent was to
>> call the bits required for 1.7 as DONE (particularly on roadmap.html).
> Just to make sure I understand your point: Moving TC data to the victim
> node should address the upgrade problem Bert described in
> http://svn.haxx.se/dev/archive-2010-08/0554.shtml, right?
> Is this what you are talking about?

Yes. Since we've put conflict information on the victim nodes
themselves, we can do future updates (such as coalescing all columns
into one) in a much more granular manner. My goal with the recent
changes was essentially to get the conflicts storage out from in front
of the 1.7 bus.

>> I'm really just trying to get a better handle on what *needs* to be
>> done before a 1.7 branch, and a notes file which was written months
>> ago, but hasn't received much attention since then certainly feels
>> like something which can be punted on.
> It seems that as of r879655 1.7 doesn't use files in the file system
> as conflict markers anymore. This is very good because checking for
> such marker files for every node would slow us down forever
> (see bottom of http://svn.haxx.se/dev/archive-2010-08/0554.shtml).
> As long as all the conflict information used by 1.7 is somewhere within
> the db, we can provide an upgrade path to better conflict storage model
> at any time without unnecessary backward-compat burden.
> Last and quite probably least, svn patch does not persist conflict
> information in the wc.db. I've been waiting assuming that a new conflict
> store would magically appear and svn patch could be made to use it.
> Arguably this detail isn't worth holding up the 1.7 release for.
> We could also add a temporary hack such as a new column in ACTUAL_NODE
> to describe and persist a patch reject. This could be used until more
> of the new conflict storage design has been implemented.

As long as we've got a forward compatible implementation in place, I'm
inclined to punt stuff toward 1.8, especially if little or no current
work is being done on it. I don't claim to have a perfect sense of
what everybody is doing, but my spidey senses tell me not much has
happened on the conflict storage front lately. :)

Received on 2010-12-13 16:42:55 CET

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.