"Perry E. Metzger" <perry@piermont.com> writes:
> 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.
Okay. Probably you killed the client after the commit had already
gone in (you don't say what repository acces method you were using).
> 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!
What does it mean that the commit was "partial"? Were some things
supposed to be committed that weren't?
So far this looks like a hook mailer bug. Is there any evidence that
the commit is actually incomplete in the repository?
> 4) An svn log does NOT reveal the new revision was actually committed,
> unless I explicitly list the new revision number.
This is an unrelated problem. You should run
$ svn log -rHEAD
(as you noticed), or else 'svn update' the current working copy, and
then log will show you the new revision. It's just running log on the
base revision of '.', that's why you don't see the new commit without
updating or specifying -r explicitly.
> 5) An svnadmin verify DOES show the new revision number.
As it should, good.
> 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.)
You don't have a local copy of the repository :-), but you do have a
working copy. If you run
$ svn cleanup
in there, does it fix these problems? (Note that it is *not* the same
as 'svn revert' -- it won't lose your local changes.)
> 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 doubt you committed a partial txn, but we'll need concrete details
to know for sure.
> 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.
Subversion works pretty hard to avoid destroying uncommitted changes,
so don't worry about this just because you see some 'L'ocked files and
dirs.
> 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...
Agreed -- it's a great experiment!
We have the 'svn cleanup' command precisely because we don't/can't
always prevent the working copy from getting into a bad state. To be
completely clear: there are some cases where it does get into that
state but shouldn't (i.e., we have a bug). There are other cases
where it's impossible -- as far as we can tell -- to avoid getting
into the state (for example, the power going out while the client is
in the process of tweaking the lock metadata). So the 'svn cleanup'
command will probably never go away. However, we hope to make it
rarely needed.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 24 22:27:42 2004