I am going to assume that the mismatching IP addresses in your post are just something related to your networking config.
That bkd is probably running in a directory containing all of your repositories so the URL you want to be using on the bk command line is something like: bk://10.205.6.21:5562/REPO (see ‘bk help url’ for info about that)
It might help to point a web browser at this port. It should give you a web interface that lets you browse those repositories.
Yeah, that 10.205.6.21 was a mistake. The target host is at 192.168.0.191. There are restrictions on flow of traffic such that I’m not able to hit, via a web browser.
Where you have “REPO” in the URL that you listed, I’m guessing I should replace that with system or system-alpha or one of the other strings that appear int the ps output that I sent over (system or system-alpha or eng-dev.d or client-dev.d). At any rate, everything that I’ve tried to put in, after the “:5562” has generated the following error:
ERROR-BAD CMD: cd is disabled for this bkd using -x
Here’s one of the calls that I attempted:
$ bk clone -sALL bk://192.168.0.191:5562/system
I’d like to just clone all of the repos, in one shot, if that’s possible.
I looked at the url man page, earlier, and it didn’t really make any sense to me, where all of this is concerned. I am not at all familiar with bitkeeper and have no idea how to “figure out where that bkd is running”, aside from what I’ve already found out: it’s running on the 192.168.0.191 host that I’ve referenced and “ps -ef” shows it listening no the ports that I listed.
You wrote of copying the files with rsync, but you also mentioned doing a “bk clone”. I figured the latter would be preferable, because it would allow me to clone the repos off to a different host, ahead of trying to upgrade bk on 192.168.0.191, without having to stop the daemons. On these old hosts that I’m working with, I’ve had trouble with some things not coming up properly, after being stopped.
But, I’ll try just stopping the daemons, anyway, just rsync’ing over the entire “/var/local/bitkeeper” folder, and restarting.
I rsync’d the data over, but on the new host, there is no “/etc/init.d/bitkeeper”. Will it be ok to just copy that script over from the old host? Is there anything else that I should grab, besides that?
Look inside that script to see how it runs. Sometimes people hardwire the stuff in the script but sometimes there is an external file that it reads and you would need that too.
Ok, I took a look at the script. As far as variables getting set goes, it has only that “read user dir opts” line and “VAR=/var/local/bitkeeper”. The rest is pretty much the case statement that I’m guessing is there, by default.
I’m having a little trouble with getting the daemons started. “/etc/init.d/bitkeeper start” gives me:
tibor:(12:05:35):/etc/init.d/bitkeeper start /usr/local/bk7.3.2
/etc/init.d/bitkeeper: line 15: cd: /big1/bk/system: No such file or directory
/etc/init.d/bitkeeper: line 15: cd: /big1/bk/system-alpha: No such file or directory
/etc/init.d/bitkeeper: line 15: cd: /big1/bk/eng-dev.d: No such file or directory
/etc/init.d/bitkeeper: line 15: cd: /big1/bk/client-dev.d: No such file or directory
This bit, from the script, I don’t (the “read user dir opts”, part, more precisely) understand:
“while read user dir opts” …
I only got “/var/local/bitkeeper”, with my rsync. I understood what you said about there possibly being an external file, but don’t see where this entire “/big1/bk/…” tree is referenced. I could certainly rsync over that tree, but can’t place it at “/big1”, because “/” is read-only on this nfsroot’d host.
Is there a bk configuration file of some sort that I can modify, such that instead of “/big1/bk/…”, the files under that tree reside in and are looked for in, say, “/var/local/bitkeeper”?
Here the thing. That script isn’t part of a BitKeeper install. We can only guess what is in it. It was likely created by copying and modifying the example in the ‘bkd’ man page (‘bk help bkd’).
The default script has a file called /var/bitkeeper/repositories that contains the list of pathnames where a bkd should be started. It appears your file will be found at /var/local/bitkeeper/repositories.
You should be able to copy that big1 directory to another location and then edit that file to point to the new location.
In this case, you appear to have one bkd per repository and all of them read-only. Given what I see here I would have started a single bkd at the /big1/bk directory and have the user add the repository name to the URL, but given that you are trying to replicate the machine and change as little as possible I guess you should leave that part alone.