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).
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?
> 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.
Stefan
Received on 2010-12-11 15:34:03 CET