[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. :)
-Hyrum
Received on 2010-12-13 16:42:55 CET