On Thu, Aug 27, 2009 at 07:38:31PM +0200, Jan Hendrik wrote:
> Concerning Re: svn copy breaks on svn update
> Stefan Sperling wrote on 27 Aug 2009, 15:15, at least in part:
> > On Thu, Aug 27, 2009 at 01:35:35PM +0200, Jan Hendrik wrote:
> > > > Can you provide a script that starts with an empty repository and
> > > > ends with this error?
> > >
> > > Well, here is a script which should be close enough, except that it
> > > does not produce yesterday's experience. IOW with this things work
> > > as one would expect. Besides the test file "foo.php" attached.
> > I don't understand. The script does not reproduce the problem at all?
> > What do you want people to do with foo.php?
> I don't understand either what is going on. Definitely I cannot
> update any working copy anymore without breaking it the moment
> update hits that "common" folder. Yet I can't reproduce it either
> with the script.
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
> As far as I can tell the script reproduces what the user did, with
> respect to what he had to do, what he says he did, and what the
> log tells:
There must be something different. Else it would just work.
Can you reproduce the problem on a copy of the repository which is
causing trouble? Can you identify what revision has caused this?
Have you run svnadmin verify on a copy of the repository?
What does it have to say?
Can you try with a 1.6.x client instead of a 1.5.x one just to see
if it makes a difference?
> As things like that usually hit at the worst moment we can't fool
> around endlessly. So I manually copied the changes into the other
> users' working copies, and when they tell me they are ready to
> commit I copy their changes back into the original user's working
> copy and commit (as this is the only working copy knowing about
> those files copied to "common"). In our small team this has to
> work for the next few days. However, I suppose that we'll find that
> the repository has been rendered unusable and therefore lost with
> all history.
The most important thing, of course, is don't 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?
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-27 20:42:10 CEST