In addition to setting up a "real" repository for a client, I've set
up a test repository where I've been playing with doing all sorts of
dumb things.
One of the dumb things I tried today was killing a very long commit
halfway through. The result was rather bad, as I'll explain.
1) I did a copy of a huge file set not with
svn cp url1 ur2
but instead with
svn cp localpatha localpathb
and then tried to commit it.
The operation started to take a VERY long time. (This probably
should not be the case, but never mind that.
2) I decided to kill the thing after about 20 minutes. After all,
that's what some user might do. kill -9 did the trick well.
3) The post commit script got called, and mail got sent out noting the
files that were updated in the (partial!) commit, with the "new
revision number", but without the commit message and with the
Subject: of the message missing. Really weird!
4) An svn log does NOT reveal the new revision was actually committed,
unless I explicitly list the new revision number.
5) An svnadmin verify DOES show the new revision number.
6) The local copy of the repository is in this awful state. svn status
reveals lots of files that are listed as "L", which isn't
documented. (I'm guessing that means "locked" or something like
that, but the manual should explain.)
So, I'm worried that I now have a committed partial transaction
(which should not be possible!), plus all sorts of other possible hell.
I'm somewhat worried about the local copy, too, because a developer
might foolishly do something to curdle it while his valuable,
uncommitted code is in it and it gets nuked.
It isn't entirely clear how to recover from this state of affairs, but
it probably shouldn't be possible to get into this state in the first
place. Yes, I was deliberately trying to do something dumb, but
largely because I expect users may soon be doing dumb things to the
production repository and I want to know what sort of failure modes to
expect...
--
Perry E. Metzger perry@piermont.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 24 21:20:28 2004