> -----Original Message-----
> From: philip_at_tigris.org [mailto:philip_at_tigris.org]
> Sent: woensdag 25 april 2012 10:57
> To: issues_at_subversion.tigris.org
> Subject: [Issue 4168] New - "no such table: revert_list" for nested wc in
sparse
> wc
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=4168
> Issue #|4168
> Summary|"no such table: revert_list" for nested wc in
sparse w
> |c
> Component|subversion
> Version|1.7.x
> Platform|All
> URL|
> OS/Version|All
> Status|NEW
> Status whiteboard|
> Keywords|
> Resolution|
> Issue type|DEFECT
> Priority|P3
> Subcomponent|libsvn_wc
> Assigned to|issues_at_subversion
> Reported by|philip
>
>
>
>
>
>
> ------- Additional comments from philip_at_tigris.org Wed Apr 25 01:57:27
-0700
> 2012 -------
> svnadmin create repo
> svn mkdir -mm file://`pwd`/repo/A
> svn co --depth empty file://`pwd`/repo wc
> svn co --depth empty file://`pwd`/repo/A wc/A
> svn up --set-depth infinity wc
>
> The update reports a conflict but not a tree conflict:
>
> Updating 'wc':
> Skipped 'wc/A' -- An obstructing working copy was found
> At revision 2.
> Summary of conflicts:
> Skipped paths: 1
>
> We add a not-present row for A in wc (I suppose ideally we should add the
> normal
> node and a tree-conflict) so status just shows:
Too bad that we can't do that :(
This is a limitation of just referencing a working copy node and a working
copy with a single absolute path. (It was no problem with the old access
batons)
If we would install a tree conflict, it would be a tree conflict on the
unrelated/second working copy.
(Or it would be a tree conflict that is stored in the outer db and never
shown to the user, because the apis would look at the other working copy)
The best we can do is what we do now: update notes that it sees the working
copy and then adds the not-present node to make sure it knows the node is
skipped when processing the next update.
Once you remove the obstructing working copy the missing information is
pulled in on the next update.
>
> $ svn st wc
> ? wc/A
This is how we would report any working copy inside a parent working copy:
an unversioned node.
>
> and now revert does not work properly:
>
> $ svn revert wc
> svn: E200030: sqlite: no such table: revert_list
This looks like a different issue than the skip in the update.
svn revert wc should just try to revert the root of the inner working copy
Bert
Received on 2012-04-25 14:51:25 CEST