On Wed, May 19, 2010 at 12:47:42PM +0200, Johan Corveleyn wrote:
> On Tue, May 18, 2010 at 5:42 PM, <stsp_at_apache.org> wrote:
> > Author: stsp
> > Date: Tue May 18 15:42:57 2010
> > New Revision: 945708
> >
> > URL: http://svn.apache.org/viewvc?rev=945708&view=rev
> > Log:
> > On the 1.6.x-issue3469 branch, fix issue #3469 "tree conflict inside of
> > directory external causes assertion to fail".
> > * subversion/libsvn_wc/entries.c
> > (svn_wc__walk_entries_and_tc): Don't give up right away if a directory
> > cannot be locked. Try retrieving a lock for the parent directory instead,
> > and only give up if that fails, too. Prevents 'svn resolved -R' from
> > silently skipping tree-conflicted externals.
>
> Sorry if this is a stupid question (I have no clue of how this is
> done), but I just wondered: will looking only at the parent directory
> (and not further up the hierarchy) also be sufficient to handle tree
> conflicts inside sub-sub-... directories of externals?
Subdirectories of externals are handled just like subdirectories of
any working copy. The problem described here manifests itself only at
the boundary between the parent working copy and the external.
Recall that in 1.6.x, tree conflict data is stored within the .svn directory
of the parent of the TC victim. This is because the child might be missing
altogether. For instance, if a directory was deleted some time back in the
history of a merge target, it simply won't be present in the WC.
For directories which aren't present at all, there is no .svn directory to
put TC data into. Therefore we decided to always use the parent directory.
(This will be different in WC-NG but this fix is for 1.6.x only).
Thus, if the external itself is a TC victim, 1.6.x stores TC data in the
parent directory of the external. Externals are very much like a working
copy dropped into a subdirectory of another working copy. A lot of the
data structures (e.g. the locks) are disjoint. The resolved code didn't
consider that the victim of a tree conflict could be part of a different
working copy than its parent. E.g. any locks the code holds for the
parent WC aren't valid for the external WC and vice versa.
The problem was that while reverting a conflicted external, svn failed
trying to lock the external as part of its set of locks for the parent
(each lock is per .svn dir, so you have a set of locks related to one WC).
It then ended up treating the external as an unversioned obstruction
and skipped it.
So svn resolved -R will now look into the parent of the external,
and resolve the tree conflict flagged for it in the parent WC,
rather than skipping the external.
Note that the above problem is not the same as the assertion failure.
The assertion failed because of similar parent/external boundary issues.
The above problem showed up once the assertion failure was fixed.
Stefan
Received on 2010-05-19 15:06:09 CEST