On Mon, Dec 13, 2010 at 10:41 AM, Hyrum K. Wright <hyrum_wri...@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 <s...@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 <b...@qqmail.nl> wrote: >>> > >>> > >>> >> -----Original Message----- >>> >> From: hy...@hyrumwright.org [mailto:hy...@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
