[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. :) -Hyrum
