|
|
|
Failure recovery
-
What does BitKeeper do in the event of some failure? Will we have half-done work in BitKeeper?
It depends on the failure.
All of the common failures have been handled, but new users find
new and wonderful ways to make BitKeeper fail.
The most important thing to do if something goes wrong is to
create a "tarball" of the repository before you
try to figure out what went wrong.
Suppose you had a cloned copy in your home directory named
"my_work".
If something goes wrong do this:
 |
cd
tar czf BUG.tgz my_work
|
That way, if you can't fix it, you have something that you can ask
BitMover to unscramble.
We've successfully unscrambled problems that were quite
complicated and each time we do that, we put code into the system
to make sure the problem doesn't come back.
So please tell us about any problems you find.
If the machine has a failure, do a bk -r check -a
which will check the repository to make sure it's in a consistent
state.
If check reports errors, contact BitMover.
-
How do I complete a failed pull? I did a pull and had files checked out and the pull didn't complete. I noticed that a PENDING directory was created. Is there a way for me to complete the resolve without making another network connection?
The contents in the PENDING directory need to be rerun.
The pending directory will have one or more patch files that have
names made up of the data plus a sequence number.
Find the latest PENDING file and then run takepatch and resolve on
it.
For example:
|
bk takepatch -vvf PENDING/2000-09-19.01
bk resolve -a
|
-
What's the best way to recover from the following type of error?
|
docs/img/services/acct/top_back_bar.gif: 2 deltas
docs/img/services/acp/titles/scheduled.gif: 2 deltas
---------------------------------------------------------------------------
takepatch: saved entire patch in PENDING/2001-03-26.02
---------------------------------------------------------------------------
=================================== ERROR ====================================
takepatch: SCCS/s.ChangeSet is locked w/o writable gfile?
takepatch: patch left in PENDING/2001-03-26.02
==============================================================================
496746 bytes uncompressed to 1127864, 2.27X expansion
|
If you are doing a push, go to the parent tree;
if you are doing a pull, go to the client tree, and from that
directory type:
|
cd RESYNC;
bk unlock -p ChangeSet
|
-
Given the following situation, how do I continue the resolve?
box ``A'' holds a clone of a repository
box ``B'' is where I'm working
I had a resolve going on box ``A'', in an rxvt on box going until box ``B'' crashed. Now when I try to run resolve I get:
|
$ bk resolve
Using boxB:0.0 as graphical display
Verifying consistency of the RESYNC tree...
=======================================================================
check: arch/ppc/kernel/pmac_pci.c is locked but not checked out,
which usually means that a file was locked (via a "bk edit")
and then removed without being unlocked.
=======================================================================
{bk} {-r} {check} {-cR} failed. Resolve not even started.
resolve: RESYNC directory left intact.
=======================================================================
|
Try this:
|
cd to the RESYNC tree
bk unlock -p arch/ppc/kernel/pmac_pci.c
|
Alternatively, if you have not invested a lot of work in the
resolve process, you can always do a bk abort and
re-do the
bk pull.
-
I'm trying to do a fairly large clone remotely and because the connection appears quiet, the line is dropped and the clone then fails. What can I do to work around this?
To keep the line alive, and thus the clone, open a second window
and ping the repository every ten seconds or so.
-
I accidentally deleted a SCCS/s.* file in my cloned repository. To continue working, I scp'ed it from the parent repository. Is this the correct fix? Is there a better way?
That will always work as long as the parent is not ahead or behind
where you were when you lost the file.
If the parent is behind, you are out of luck.
If the parent is ahead, then you can actually strip it backwards
to make it match your environment.
Remember that you can always run bk -r check -a to
make sure BitKeeper is happy with the state of the repository.
-
I have gotten myself into trouble by doing some part of the checkout, edit, commit operation as root. Now when I try to push, I get:
|
bk push
----------------------- Sending the following csets -----------------------
1.336
---------------------------------------------------------------------------
---------------------------------------------------------------------------
takepatch: saved entire patch in PENDING/2001-03-06.07
---------------------------------------------------------------------------
=================================== ERROR ====================================
takepatch: SCCS/s.ChangeSet is locked w/o writable gfile?
takepatch: patch left in PENDING/2001-03-06.07
==============================================================================
|
What can I do about this?
Try:
|
bk -R unlock -p ChangeSet
|
| |
|
Home 
Documentation