You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Johan Corveleyn <jc...@gmail.com> on 2012/03/28 13:40:29 UTC
svn 1.7: how to recover from a lost pristine file
For some reason, I lost a pristine file [*] in a 1.7 working copy. I'm
trying to recover from this without having to throw away my entire
working copy. So far I'm unsuccessful. Any help is appreciated.
svn-1.7 is SlikSVN 1.7.4 (On Windows 7, 64bit):
[[[
C:\Work\WC-root>svn-1.7 update -r0 the\file\with\missing\pristine.java
svn: E155037: Previous operation has not finished; run 'cleanup' if it
was interrupted
C:\Work\WC-root>svn-1.7 cleanup the\file\with\missing
svn: E155004: Working copy 'C:\Work\WC-root\the\file\with\missing' locked.
svn: E155004: 'C:\Work\WC-root' is already locked.
svn: E155037: Previous operation has not finished; run 'cleanup' if it
was interrupted
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
C:\Work\WC-root>svn-1.7 cleanup
svn: E720002: Can't open file
'C:\Work\WC-root\.svn\pristine\6d\6d6e0892990e945b03a15b8e518dbef26848dc75.svn-base':
The system cannot find the file specified.
]]]
(the fact that the working copy is locked to begin with, was because a
normal 'svn update' failed because of the missing pristine, with "svn:
E155004: There are unfinished work items in 'C:\Work\WC-root'; run
'svn cleanup' first.", which is why I first found out about the
problem)
Anything I can do to investigate further?
Any repair actions I can take? The only thing I can think of is
checkout out C:\Work\WC-root\the\file\with\missing in a new working
copy, and copying the pristine file from there to my corrupted
pristine store.
[*] The pristine got lost after trying out a 'case-only' rename
through IntelliJ (Java IDE), which uses svnkit 1.7.4 snapshot version
r9054_v20120321_1804 (which should support this usecase). So that may
be another issue in svnkit, or in the way IntelliJ drives it (or some
random accident because I'm experimenting a bit too much with
pre-release software). It's too early to tell right now. Regardless,
it would be interesting to know what to do when a pristine gets lost
...
--
Johan
AW: svn 1.7: how to recover from a lost pristine file
Posted by Markus Schaber <m....@3s-software.com>.
Hi, Martin,
> Von: Philip Martin
> Johan Corveleyn <jc...@gmail.com> writes:
> > [Missing or broken pristines]
> > Is this a situation from which svn could ultimately become self-healing?
>
> I suppose it might get fixed as a side-effect of somebody implementing
> "optional pristine" but generally wq items are not supposed to fail.
I'd see it the other way: Having a working "fetch missing pristines" implementation is a precondition (and not a side-effect) of things like "optional pristines" and "shared pristine storage".
It is needed to return whatever working copy into the "old" self-contained state. If that functionality is not provided from the beginning, existing users will be _very_ alienated.
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: svn 1.7: how to recover from a lost pristine file
Posted by Philip Martin <ph...@wandisco.com>.
Johan Corveleyn <jc...@gmail.com> writes:
> Thanks for your help, Philip.
>
> $ sqlite3 .svn/wc.db "select * from work_queue"
> 1|(file-install trunk/rootdir/the/file/with/missing/pristine.java 1 0 1 1)
>
>> These may show something:
>>
>> sqlite3 wc/.svn/wc.db "select * from nodes where local_relpath = '/the/file/with/missing/pristine.java'"
>>
>> sqlite3 wc/.svn/wc.db "select * from nodes where checksum like '%6d6e0892990e945b03a15b8e518dbef26848dc75'"
>
> Both of the above show the same:
> 1|the/file/with/missing/pristine.java|0|the/file/with/missing|1|trunk/rootdir/the/file/with/missing/pristine.java|176219|normal|||file|(svn:eol-style
> native)||$sha1$6d6e0892990e945b03a15b8e518dbef26848dc75||175563|1332375850493000|username|56722|1332709446087164||
>
>> sqlite3 wc/.svn/wc.db "select * from pristine where checksum like '%6d6e0892990e945b03a15b8e518dbef26848dc75'"
>
> That shows nothing.
That really is broken. By the time the file-install wq item exists
there should be a pristine row with the checksum as well as the pristine
file. So just adding the missing file would not be enough, you need to
add the pristine row as well.
You might be able to restore the missing file. Probably easiest to
checkout a temporary copy of the parent using --depth=empty, then update
the one file required. Now in the temporary wc
sqlite3 .svn/wc.db "select * from pristine"
should show the required row. In the broken wc
sqlite3 .svn/wc.db "insert into pristine values (sha1, null, size, 1, md5)
then copy/move the pristine file itself from the temporary wc to the
broken wc.
>> Depending on what the work_queue shows you may be able to further
>> corrupt your working copy and then recover by doing this:
>>
>> sqlite .svn/wc.db "delete from work_queue"
>> svn up -r0 file
>>
>> IMPORTANT! Deleting the work_queue does generally make the working copy
>> invalid, it is then up to you to ensure it returns to a valid state.
>
> Heh :-). I'll give it a try (I'll wait a while, in case you have
> something more to add given my feedback ...).
You have the checksum in the nodes row, so you will probably need to
delete that nodes row as well.
> Is this a situation from which svn could ultimately become self-healing?
I suppose it might get fixed as a side-effect of somebody implementing
"optional pristine" but generally wq items are not supposed to fail.
--
Philip
RE: svn 1.7: how to recover from a lost pristine file
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel@gmail.com]
> Sent: woensdag 28 maart 2012 17:25
> To: Daniel Shahaf
> Cc: Bert Huijben; Philip Martin; users@subversion.apache.org
> Subject: Re: svn 1.7: how to recover from a lost pristine file
>
> On Wed, Mar 28, 2012 at 5:06 PM, Daniel Shahaf <d....@daniel.shahaf.name>
> wrote:
> > Johan Corveleyn wrote on Wed, Mar 28, 2012 at 16:38:41 +0200:
> >> Thanks both for your help. Maybe this will help others running in the
> >> same situation ...
> >
> > Do you know what cause the pristine to disappear in the first place?
>
> No, not yet. When I have some more time I'll try to reproduce it.
>
> In the meantime, I experimented a bit more with '--set-depth exclude',
> just to see what happens when you do this on a modified file. It's
> interesting (but maybe this is all normal, can't say ... just
> interesting :-)):
>
> [[[
> C:\WC>echo test >> build.properties
>
> C:\WC>svn-1.7 st
> M build.properties
>
> C:\WC>svn-1.7 up --set-depth exclude build.properties
> D build.properties
>
> C:\WC>svn-1.7 st
> ? build.properties
>
> C:\WC>svn-1.7 up build.properties
> Updating 'build.properties':
> C build.properties
> At revision 176270.
> Summary of conflicts:
> Tree conflicts: 1
>
> ### argh, a tree conflict. Panic! :-)
>
> C:\WC>svn-1.7 st
> D C build.properties
> > local unversioned, incoming add upon update
> Summary of conflicts:
> Tree conflicts: 1
>
> ### let's try to recover from this.
>
> C:\WC>svn-1.7 resolve --accept=working build.properties
> Resolved conflicted state of 'build.properties'
Don't assume that svn resolve --accept=<anything> makes much sense for tree
conflicts. Sorry.
We accept this format as a way to accept the tree conflict, but it assumes
that you did the actual resolving yourself.
> C:\WC>svn-1.7 st
> D build.properties
>
> ### hm, how do I get it back as un-deleted without losing my mods
We don't have obstruction conflicts (yet), so an incoming file that is
blocked by something unversioned is marked as deleted.
This should really be some kind of obstruction conflict to make sure
Subversion doesn't try to change the local file on other operations.
Currently [D]eleted is the only state with that behavior.
> C:\WC>svn-1.7 add build.properties
> A build.properties
This adds a replacement over your deleted file. So I would expect this
> C:\WC>svn-1.7 st
> RM build.properties
And I think your settings automatically applied properties here. (The M is
for properties modified)
> ### cool! I've never seen 'RM' before. Anyway, this is not what I wanted
:-(
Bert
Re: svn 1.7: how to recover from a lost pristine file
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Mar 28, 2012 at 5:06 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Johan Corveleyn wrote on Wed, Mar 28, 2012 at 16:38:41 +0200:
>> Thanks both for your help. Maybe this will help others running in the
>> same situation ...
>
> Do you know what cause the pristine to disappear in the first place?
No, not yet. When I have some more time I'll try to reproduce it.
In the meantime, I experimented a bit more with '--set-depth exclude',
just to see what happens when you do this on a modified file. It's
interesting (but maybe this is all normal, can't say ... just
interesting :-)):
[[[
C:\WC>echo test >> build.properties
C:\WC>svn-1.7 st
M build.properties
C:\WC>svn-1.7 up --set-depth exclude build.properties
D build.properties
C:\WC>svn-1.7 st
? build.properties
C:\WC>svn-1.7 up build.properties
Updating 'build.properties':
C build.properties
At revision 176270.
Summary of conflicts:
Tree conflicts: 1
### argh, a tree conflict. Panic! :-)
C:\WC>svn-1.7 st
D C build.properties
> local unversioned, incoming add upon update
Summary of conflicts:
Tree conflicts: 1
### let's try to recover from this.
C:\WC>svn-1.7 resolve --accept=working build.properties
Resolved conflicted state of 'build.properties'
C:\WC>svn-1.7 st
D build.properties
### hm, how do I get it back as un-deleted without losing my mods
C:\WC>svn-1.7 add build.properties
A build.properties
C:\WC>svn-1.7 st
RM build.properties
### cool! I've never seen 'RM' before. Anyway, this is not what I wanted :-(
C:\WC>copy build.properties build.properties.bak
1 file(s) copied.
C:\WC>svn-1.7 revert build.properties
Reverted 'build.properties'
C:\WC>svn-1.7 st
? build.properties.bak
C:\WC>copy build.properties.bak build.properties
Overwrite build.properties? (Yes/No/All): y
1 file(s) copied.
C:\WC>svn-1.7 st
? build.properties.bak
M build.properties
### phew, that's better
]]]
So then I remembered there is a --force option for 'svn update'. That
works out better:
[[[
C:\WC>echo test >> build.properties
C:\WC>svn-1.7 st
M build.properties
C:\WC>svn-1.7 up --set-depth exclude build.properties
D build.properties
C:\WC>svn-1.7 st
? build.properties
C:\WC>svn-1.7 up --force build.properties
Updating 'build.properties':
E build.properties
Updated to revision 176272.
C:\WC>svn-1.7 st
M build.properties
]]]
--
Johan
Re: svn 1.7: how to recover from a lost pristine file
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Wed, Mar 28, 2012 at 16:38:41 +0200:
> Thanks both for your help. Maybe this will help others running in the
> same situation ...
Do you know what cause the pristine to disappear in the first place?
Re: svn 1.7: how to recover from a lost pristine file
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Mar 28, 2012 at 4:27 PM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Johan Corveleyn [mailto:jcorvel@gmail.com]
>> Sent: woensdag 28 maart 2012 15:47
>> To: Philip Martin
>> Cc: users@subversion.apache.org
>> Subject: Re: svn 1.7: how to recover from a lost pristine file
>>
>> On Wed, Mar 28, 2012 at 3:08 PM, Johan Corveleyn <jc...@gmail.com>
>> wrote:
>> > On Wed, Mar 28, 2012 at 2:12 PM, Philip Martin
>> > <ph...@wandisco.com> wrote:
>> >> Johan Corveleyn <jc...@gmail.com> writes:
>> >>
>> >>> For some reason, I lost a pristine file [*] in a 1.7 working copy. I'm
>> >>> trying to recover from this without having to throw away my entire
>> >>> working copy. So far I'm unsuccessful. Any help is appreciated.
>> >>>
>> >>> svn-1.7 is SlikSVN 1.7.4 (On Windows 7, 64bit):
>> >>> [[[
>> >>> C:\Work\WC-root>svn-1.7 update -r0 the\file\with\missing\pristine.java
>> >>> svn: E155037: Previous operation has not finished; run 'cleanup' if it
>> >>> was interrupted
>> >>>
>> >>> C:\Work\WC-root>svn-1.7 cleanup the\file\with\missing
>> >>> svn: E155004: Working copy 'C:\Work\WC-root\the\file\with\missing'
>> locked.
>> >>> svn: E155004: 'C:\Work\WC-root' is already locked.
>> >>> svn: E155037: Previous operation has not finished; run 'cleanup' if it
>> >>> was interrupted
>> >>> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
>> >>>
>> >>> C:\Work\WC-root>svn-1.7 cleanup
>> >>> svn: E720002: Can't open file
>> >>> 'C:\Work\WC-
>> root\.svn\pristine\6d\6d6e0892990e945b03a15b8e518dbef26848dc75.svn-
>> base':
>> >>> The system cannot find the file specified.
>> >>> ]]]
>> >>>
>> >>> (the fact that the working copy is locked to begin with, was because a
>> >>> normal 'svn update' failed because of the missing pristine, with "svn:
>> >>> E155004: There are unfinished work items in 'C:\Work\WC-root'; run
>> >>> 'svn cleanup' first.", which is why I first found out about the
>> >>> problem)
>> >>>
>> >>> Anything I can do to investigate further?
>> >>
>> >> Use the sqlite3 utility
>> >>
>> >> sqlite3 .svn/wc.db "select * from work_queue"
>> >
>> > Thanks for your help, Philip.
>> >
>> > $ sqlite3 .svn/wc.db "select * from work_queue"
>> > 1|(file-install trunk/rootdir/the/file/with/missing/pristine.java 1 0 1
> 1)
>> >
>> >> These may show something:
>> >>
>> >> sqlite3 wc/.svn/wc.db "select * from nodes where local_relpath =
>> '/the/file/with/missing/pristine.java'"
>> >>
>> >> sqlite3 wc/.svn/wc.db "select * from nodes where checksum like
>> '%6d6e0892990e945b03a15b8e518dbef26848dc75'"
>> >
>> > Both of the above show the same:
>> >
>>
> 1|the/file/with/missing/pristine.java|0|the/file/with/missing|1|trunk/rootdi
> r/t
>> he/file/with/missing/pristine.java|176219|normal|||file|(svn:eol-style
>> >
>> native)||$sha1$6d6e0892990e945b03a15b8e518dbef26848dc75||175563|1332
>> 375850493000|username|56722|1332709446087164||
>> >
>> >> sqlite3 wc/.svn/wc.db "select * from pristine where checksum like
>> '%6d6e0892990e945b03a15b8e518dbef26848dc75'"
>> >
>> > That shows nothing.
>> >
>> >> Depending on what the work_queue shows you may be able to further
>> >> corrupt your working copy and then recover by doing this:
>> >>
>> >> sqlite .svn/wc.db "delete from work_queue"
>> >> svn up -r0 file
>> >>
>> >> IMPORTANT! Deleting the work_queue does generally make the working
>> copy
>> >> invalid, it is then up to you to ensure it returns to a valid state.
>>
>> Hm, no luck:
>>
>> [[[
>> $ sqlite3 .svn/wc.db "delete from work_queue"
>>
>> $ sqlite3 .svn/wc.db "select * from work_queue"
>> <nothing>
>>
>> C:\Work\WC-root>svn-1.7 up -r0 the/file/with/missing/pristine.java
>> svn: E155004: Working copy 'C:\Work\WC-root\the\file\with\missing' locked.
>> svn: E155004: 'C:\Work\WC-root' is already locked.
>> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
>>
>> C:\Work\WC-root>svn-1.7 cleanup
>>
>> <yay! this time 'svn cleanup' completes, let's try again>
>>
>> C:\Work\WC-root>svn-1.7 up -r0 the/file/with/missing/pristine.java
>> Updating 'the\file\with\missing\pristine.java':
>> svn: E720002: Can't open file
>> 'C:\Work\WC-
>> root\.svn\pristine\6d\6d6e0892990e945b03a15b8e518dbef26848dc75.svn-
>> base':
>> The system cannot find the file specified.
>>
>> <at this point, a work-queue item has been created again>
>>
>> $ sqlite3 .svn/wc.db "select * from work_queue"
>> 2|(file-install the/file/with/missing/pristine.java 1 0 1 1)
>>
>> ]]]
>>
>> Any other suggestions?
>
> Maybe 'svn up --set-depth exclude X' instead of -r0.
> And then a 'svn up X'
Cool! That actually worked. Well, after I cleared the work_queue again
first, and ran cleanup. So the full recovery sequence was:
$ sqlite3 .svn/wc.db "delete from work_queue"
$ svn cleanup
$ svn up --set-depth exclude X
$ svn up X
Thanks both for your help. Maybe this will help others running in the
same situation ...
--
Johan
RE: svn 1.7: how to recover from a lost pristine file
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel@gmail.com]
> Sent: woensdag 28 maart 2012 15:47
> To: Philip Martin
> Cc: users@subversion.apache.org
> Subject: Re: svn 1.7: how to recover from a lost pristine file
>
> On Wed, Mar 28, 2012 at 3:08 PM, Johan Corveleyn <jc...@gmail.com>
> wrote:
> > On Wed, Mar 28, 2012 at 2:12 PM, Philip Martin
> > <ph...@wandisco.com> wrote:
> >> Johan Corveleyn <jc...@gmail.com> writes:
> >>
> >>> For some reason, I lost a pristine file [*] in a 1.7 working copy. I'm
> >>> trying to recover from this without having to throw away my entire
> >>> working copy. So far I'm unsuccessful. Any help is appreciated.
> >>>
> >>> svn-1.7 is SlikSVN 1.7.4 (On Windows 7, 64bit):
> >>> [[[
> >>> C:\Work\WC-root>svn-1.7 update -r0 the\file\with\missing\pristine.java
> >>> svn: E155037: Previous operation has not finished; run 'cleanup' if it
> >>> was interrupted
> >>>
> >>> C:\Work\WC-root>svn-1.7 cleanup the\file\with\missing
> >>> svn: E155004: Working copy 'C:\Work\WC-root\the\file\with\missing'
> locked.
> >>> svn: E155004: 'C:\Work\WC-root' is already locked.
> >>> svn: E155037: Previous operation has not finished; run 'cleanup' if it
> >>> was interrupted
> >>> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
details)
> >>>
> >>> C:\Work\WC-root>svn-1.7 cleanup
> >>> svn: E720002: Can't open file
> >>> 'C:\Work\WC-
> root\.svn\pristine\6d\6d6e0892990e945b03a15b8e518dbef26848dc75.svn-
> base':
> >>> The system cannot find the file specified.
> >>> ]]]
> >>>
> >>> (the fact that the working copy is locked to begin with, was because a
> >>> normal 'svn update' failed because of the missing pristine, with "svn:
> >>> E155004: There are unfinished work items in 'C:\Work\WC-root'; run
> >>> 'svn cleanup' first.", which is why I first found out about the
> >>> problem)
> >>>
> >>> Anything I can do to investigate further?
> >>
> >> Use the sqlite3 utility
> >>
> >> sqlite3 .svn/wc.db "select * from work_queue"
> >
> > Thanks for your help, Philip.
> >
> > $ sqlite3 .svn/wc.db "select * from work_queue"
> > 1|(file-install trunk/rootdir/the/file/with/missing/pristine.java 1 0 1
1)
> >
> >> These may show something:
> >>
> >> sqlite3 wc/.svn/wc.db "select * from nodes where local_relpath =
> '/the/file/with/missing/pristine.java'"
> >>
> >> sqlite3 wc/.svn/wc.db "select * from nodes where checksum like
> '%6d6e0892990e945b03a15b8e518dbef26848dc75'"
> >
> > Both of the above show the same:
> >
>
1|the/file/with/missing/pristine.java|0|the/file/with/missing|1|trunk/rootdi
r/t
> he/file/with/missing/pristine.java|176219|normal|||file|(svn:eol-style
> >
> native)||$sha1$6d6e0892990e945b03a15b8e518dbef26848dc75||175563|1332
> 375850493000|username|56722|1332709446087164||
> >
> >> sqlite3 wc/.svn/wc.db "select * from pristine where checksum like
> '%6d6e0892990e945b03a15b8e518dbef26848dc75'"
> >
> > That shows nothing.
> >
> >> Depending on what the work_queue shows you may be able to further
> >> corrupt your working copy and then recover by doing this:
> >>
> >> sqlite .svn/wc.db "delete from work_queue"
> >> svn up -r0 file
> >>
> >> IMPORTANT! Deleting the work_queue does generally make the working
> copy
> >> invalid, it is then up to you to ensure it returns to a valid state.
>
> Hm, no luck:
>
> [[[
> $ sqlite3 .svn/wc.db "delete from work_queue"
>
> $ sqlite3 .svn/wc.db "select * from work_queue"
> <nothing>
>
> C:\Work\WC-root>svn-1.7 up -r0 the/file/with/missing/pristine.java
> svn: E155004: Working copy 'C:\Work\WC-root\the\file\with\missing' locked.
> svn: E155004: 'C:\Work\WC-root' is already locked.
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
details)
>
> C:\Work\WC-root>svn-1.7 cleanup
>
> <yay! this time 'svn cleanup' completes, let's try again>
>
> C:\Work\WC-root>svn-1.7 up -r0 the/file/with/missing/pristine.java
> Updating 'the\file\with\missing\pristine.java':
> svn: E720002: Can't open file
> 'C:\Work\WC-
> root\.svn\pristine\6d\6d6e0892990e945b03a15b8e518dbef26848dc75.svn-
> base':
> The system cannot find the file specified.
>
> <at this point, a work-queue item has been created again>
>
> $ sqlite3 .svn/wc.db "select * from work_queue"
> 2|(file-install the/file/with/missing/pristine.java 1 0 1 1)
>
> ]]]
>
> Any other suggestions?
Maybe 'svn up --set-depth exclude X' instead of -r0.
And then a 'svn up X'
Bert
Re: svn 1.7: how to recover from a lost pristine file
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Mar 28, 2012 at 3:08 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Wed, Mar 28, 2012 at 2:12 PM, Philip Martin
> <ph...@wandisco.com> wrote:
>> Johan Corveleyn <jc...@gmail.com> writes:
>>
>>> For some reason, I lost a pristine file [*] in a 1.7 working copy. I'm
>>> trying to recover from this without having to throw away my entire
>>> working copy. So far I'm unsuccessful. Any help is appreciated.
>>>
>>> svn-1.7 is SlikSVN 1.7.4 (On Windows 7, 64bit):
>>> [[[
>>> C:\Work\WC-root>svn-1.7 update -r0 the\file\with\missing\pristine.java
>>> svn: E155037: Previous operation has not finished; run 'cleanup' if it
>>> was interrupted
>>>
>>> C:\Work\WC-root>svn-1.7 cleanup the\file\with\missing
>>> svn: E155004: Working copy 'C:\Work\WC-root\the\file\with\missing' locked.
>>> svn: E155004: 'C:\Work\WC-root' is already locked.
>>> svn: E155037: Previous operation has not finished; run 'cleanup' if it
>>> was interrupted
>>> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
>>>
>>> C:\Work\WC-root>svn-1.7 cleanup
>>> svn: E720002: Can't open file
>>> 'C:\Work\WC-root\.svn\pristine\6d\6d6e0892990e945b03a15b8e518dbef26848dc75.svn-base':
>>> The system cannot find the file specified.
>>> ]]]
>>>
>>> (the fact that the working copy is locked to begin with, was because a
>>> normal 'svn update' failed because of the missing pristine, with "svn:
>>> E155004: There are unfinished work items in 'C:\Work\WC-root'; run
>>> 'svn cleanup' first.", which is why I first found out about the
>>> problem)
>>>
>>> Anything I can do to investigate further?
>>
>> Use the sqlite3 utility
>>
>> sqlite3 .svn/wc.db "select * from work_queue"
>
> Thanks for your help, Philip.
>
> $ sqlite3 .svn/wc.db "select * from work_queue"
> 1|(file-install trunk/rootdir/the/file/with/missing/pristine.java 1 0 1 1)
>
>> These may show something:
>>
>> sqlite3 wc/.svn/wc.db "select * from nodes where local_relpath = '/the/file/with/missing/pristine.java'"
>>
>> sqlite3 wc/.svn/wc.db "select * from nodes where checksum like '%6d6e0892990e945b03a15b8e518dbef26848dc75'"
>
> Both of the above show the same:
> 1|the/file/with/missing/pristine.java|0|the/file/with/missing|1|trunk/rootdir/the/file/with/missing/pristine.java|176219|normal|||file|(svn:eol-style
> native)||$sha1$6d6e0892990e945b03a15b8e518dbef26848dc75||175563|1332375850493000|username|56722|1332709446087164||
>
>> sqlite3 wc/.svn/wc.db "select * from pristine where checksum like '%6d6e0892990e945b03a15b8e518dbef26848dc75'"
>
> That shows nothing.
>
>> Depending on what the work_queue shows you may be able to further
>> corrupt your working copy and then recover by doing this:
>>
>> sqlite .svn/wc.db "delete from work_queue"
>> svn up -r0 file
>>
>> IMPORTANT! Deleting the work_queue does generally make the working copy
>> invalid, it is then up to you to ensure it returns to a valid state.
Hm, no luck:
[[[
$ sqlite3 .svn/wc.db "delete from work_queue"
$ sqlite3 .svn/wc.db "select * from work_queue"
<nothing>
C:\Work\WC-root>svn-1.7 up -r0 the/file/with/missing/pristine.java
svn: E155004: Working copy 'C:\Work\WC-root\the\file\with\missing' locked.
svn: E155004: 'C:\Work\WC-root' is already locked.
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
C:\Work\WC-root>svn-1.7 cleanup
<yay! this time 'svn cleanup' completes, let's try again>
C:\Work\WC-root>svn-1.7 up -r0 the/file/with/missing/pristine.java
Updating 'the\file\with\missing\pristine.java':
svn: E720002: Can't open file
'C:\Work\WC-root\.svn\pristine\6d\6d6e0892990e945b03a15b8e518dbef26848dc75.svn-base':
The system cannot find the file specified.
<at this point, a work-queue item has been created again>
$ sqlite3 .svn/wc.db "select * from work_queue"
2|(file-install the/file/with/missing/pristine.java 1 0 1 1)
]]]
Any other suggestions?
--
Johan
Re: svn 1.7: how to recover from a lost pristine file
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Mar 28, 2012 at 2:12 PM, Philip Martin
<ph...@wandisco.com> wrote:
> Johan Corveleyn <jc...@gmail.com> writes:
>
>> For some reason, I lost a pristine file [*] in a 1.7 working copy. I'm
>> trying to recover from this without having to throw away my entire
>> working copy. So far I'm unsuccessful. Any help is appreciated.
>>
>> svn-1.7 is SlikSVN 1.7.4 (On Windows 7, 64bit):
>> [[[
>> C:\Work\WC-root>svn-1.7 update -r0 the\file\with\missing\pristine.java
>> svn: E155037: Previous operation has not finished; run 'cleanup' if it
>> was interrupted
>>
>> C:\Work\WC-root>svn-1.7 cleanup the\file\with\missing
>> svn: E155004: Working copy 'C:\Work\WC-root\the\file\with\missing' locked.
>> svn: E155004: 'C:\Work\WC-root' is already locked.
>> svn: E155037: Previous operation has not finished; run 'cleanup' if it
>> was interrupted
>> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
>>
>> C:\Work\WC-root>svn-1.7 cleanup
>> svn: E720002: Can't open file
>> 'C:\Work\WC-root\.svn\pristine\6d\6d6e0892990e945b03a15b8e518dbef26848dc75.svn-base':
>> The system cannot find the file specified.
>> ]]]
>>
>> (the fact that the working copy is locked to begin with, was because a
>> normal 'svn update' failed because of the missing pristine, with "svn:
>> E155004: There are unfinished work items in 'C:\Work\WC-root'; run
>> 'svn cleanup' first.", which is why I first found out about the
>> problem)
>>
>> Anything I can do to investigate further?
>
> Use the sqlite3 utility
>
> sqlite3 .svn/wc.db "select * from work_queue"
Thanks for your help, Philip.
$ sqlite3 .svn/wc.db "select * from work_queue"
1|(file-install trunk/rootdir/the/file/with/missing/pristine.java 1 0 1 1)
> These may show something:
>
> sqlite3 wc/.svn/wc.db "select * from nodes where local_relpath = '/the/file/with/missing/pristine.java'"
>
> sqlite3 wc/.svn/wc.db "select * from nodes where checksum like '%6d6e0892990e945b03a15b8e518dbef26848dc75'"
Both of the above show the same:
1|the/file/with/missing/pristine.java|0|the/file/with/missing|1|trunk/rootdir/the/file/with/missing/pristine.java|176219|normal|||file|(svn:eol-style
native)||$sha1$6d6e0892990e945b03a15b8e518dbef26848dc75||175563|1332375850493000|username|56722|1332709446087164||
> sqlite3 wc/.svn/wc.db "select * from pristine where checksum like '%6d6e0892990e945b03a15b8e518dbef26848dc75'"
That shows nothing.
> Depending on what the work_queue shows you may be able to further
> corrupt your working copy and then recover by doing this:
>
> sqlite .svn/wc.db "delete from work_queue"
> svn up -r0 file
>
> IMPORTANT! Deleting the work_queue does generally make the working copy
> invalid, it is then up to you to ensure it returns to a valid state.
Heh :-). I'll give it a try (I'll wait a while, in case you have
something more to add given my feedback ...).
Is this a situation from which svn could ultimately become self-healing?
--
Johan
Re: svn 1.7: how to recover from a lost pristine file
Posted by Philip Martin <ph...@wandisco.com>.
Johan Corveleyn <jc...@gmail.com> writes:
> For some reason, I lost a pristine file [*] in a 1.7 working copy. I'm
> trying to recover from this without having to throw away my entire
> working copy. So far I'm unsuccessful. Any help is appreciated.
>
> svn-1.7 is SlikSVN 1.7.4 (On Windows 7, 64bit):
> [[[
> C:\Work\WC-root>svn-1.7 update -r0 the\file\with\missing\pristine.java
> svn: E155037: Previous operation has not finished; run 'cleanup' if it
> was interrupted
>
> C:\Work\WC-root>svn-1.7 cleanup the\file\with\missing
> svn: E155004: Working copy 'C:\Work\WC-root\the\file\with\missing' locked.
> svn: E155004: 'C:\Work\WC-root' is already locked.
> svn: E155037: Previous operation has not finished; run 'cleanup' if it
> was interrupted
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
>
> C:\Work\WC-root>svn-1.7 cleanup
> svn: E720002: Can't open file
> 'C:\Work\WC-root\.svn\pristine\6d\6d6e0892990e945b03a15b8e518dbef26848dc75.svn-base':
> The system cannot find the file specified.
> ]]]
>
> (the fact that the working copy is locked to begin with, was because a
> normal 'svn update' failed because of the missing pristine, with "svn:
> E155004: There are unfinished work items in 'C:\Work\WC-root'; run
> 'svn cleanup' first.", which is why I first found out about the
> problem)
>
> Anything I can do to investigate further?
Use the sqlite3 utility
sqlite3 .svn/wc.db "select * from work_queue"
These may show something:
sqlite3 wc/.svn/wc.db "select * from nodes where local_relpath = '/the/file/with/missing/pristine.java'"
sqlite3 wc/.svn/wc.db "select * from nodes where checksum like '%6d6e0892990e945b03a15b8e518dbef26848dc75'"
sqlite3 wc/.svn/wc.db "select * from pristine where checksum like '%6d6e0892990e945b03a15b8e518dbef26848dc75'"
Depending on what the work_queue shows you may be able to further
corrupt your working copy and then recover by doing this:
sqlite .svn/wc.db "delete from work_queue"
svn up -r0 file
IMPORTANT! Deleting the work_queue does generally make the working copy
invalid, it is then up to you to ensure it returns to a valid state.
--
Philip