On Mon, Dec 13, 2010 at 10:41 AM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> [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
> easier.
>
>>
>> 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. :)
Since this is the one 1.7 roadmap item we are deferring, does it make
sense for it to have it's own issue?
Paul
Received on 2011-02-04 00:17:09 CET