Concerning Re: svn copy breaks on svn update
Stefan Sperling wrote on 27 Aug 2009, 19:41, at least in part:
> It sounds like a serious problem. But to fix it, we need to isolate
> the cause, and to isolate it, we need more information, and the only
> person on this planet capable of digging for more information about
> this problem is you. Unless someone else shows up who is also seeing
> this problem.
Definitely. I hope I have some information which might tell you
more than it does to myself, and probably even a clue.
> Can you reproduce the problem on a copy of the repository which is
> causing trouble? Can you identify what revision has caused this?
Yes, that's easy (-r1000 for simplicity). IIRC it also was the head
rev. when trouble started while updating wc2. wc2 might have been
at rev. 999 or a bit earlier, but not much. Update obviously broke
when adding the files copied (and edited) to "common" folder as
committed from wc1 in rev. 1000. At this time the source files
(foox.php) already had been updated to rev. 1000, too.
> Have you run svnadmin verify on a copy of the repository?
> What does it have to say?
successful for rev. 1000 (actually checked revs. 995:HEAD, then at
1005, if necessary I can run full verification over the weekend).
Also I could checkout rev. 1000 w/o issues.
Next I did
svn co -r999 (no issues);
svn up (fails, wc locked, should do cleanup); <= on fresh checkout?
svn cleanup (successful);
svn up (successful to rev. 1005, so it seems my fear of ending up
with a repository which would not return revs. 1000+ was
unnecessary).
Also an update of wc1 worked. Dito I was able to update the
"common" folder in another wc, then the wc itself w/o issues. This
wc had no pending modifications (also see below).
> Can you try with a 1.6.x client instead of a 1.5.x one just to see if
> it makes a difference?
Next steps:
completely removed the "common" folder in one of the broken
working copies (wc3) and run svn up. This failed once more in
"common" after adding some of the old files in the folder (but not
all) *and* some of the files copied into per rev. 1000, leaving behind
a couple of the by now well-known triplets *.mine/*.copied/*.rxxx
and the error message "Can't open file ... System can't find file".
Removed "common" once more and did
svn-1.6.4 up (fails, locked)
svn-1.6.4 cleanup (successful)
svn-1.6.4 up (successful)
So the 1.6 client might make a difference indeed. However, here's
probably a clue:
On closer inspection all the working copies broken during update in
the "common" folder had pending modifications and some of these
raised conflicts in the source files (foox.php). This is a factor I did
not try in the test case script.
These errors were expected and resolved using incoming "theirs"
as of rev. 1000. Actually the coincidence of several users working
on non-conflicting parts of foox.php with the necessity to do each
modification in a number of almost identical siblings lead to the
minor refactoring leading to the whole issue of working copies
broken on update.
Can it be this? An issue solved in 1.6? Or just hidden by chance
and apt to raise its head again in the future?
> The most important thing, of course, is don't panic :)
Well, we simply don't have the time to panic ;)
> Even if there is a broken revision in there somewhere, you can still
> restore the repository to a sane state by dumping it incrementally and
> fixing revisions as you go along.
>
> And you do have backups, right?
Every commit is dumped incrementally and appended to a dump
file. After a specific number of revisions the dump file is stored
away, and after a few such dump file cycles another one is done for
the whole range, sometimes additionally even in-between. Of
course, in case the revision of a refactoring is corrupted it might be
very difficult to impossible to re-do that in a way the later revisions
can be loaded.
Looks like the users here have to get used to the commandline
client. They are used to TSVN, but I am told the developer dropped
W2K with 1.6 and will drop XP with 1.7. We never saw any
necessity to go for XP except for one machine (BIOS/hardware
prevents W2K from full operation) and definitely will not go for Vista.
Or do any copy-rename-edit operations only when all working
copies have been committed. Just as we never switch anymore
but checkout another wc ... checkout takes time once, switch the
same amount, but every time.
Thanks for your time, Stefan!
JH
---------------------------------------
Freedom quote:
It is not my intention to do away with government.
It is rather to make it work -- work with us, not over us;
stand by our side, not ride on our back.
Government can and must provide opportunity, not smother it;
foster productivity, not stifle it.
-- Ronald Reagan,
First Inaugural Address, January 20, 1981
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2388301
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-28 17:06:31 CEST