[RFC] "Working plan" for BitKeeper usage for the ALFS team (long)

Kevin P. Fleming kpfleming at linuxfromscratch.org
Fri Apr 16 08:36:55 PDT 2004


This plan would result in the following services being available to the 
team and the general public:

A) a bkd (BitKeeper daemon) available to the public for clone/pull 
operations (read-only)
B) ssh access to bkd for team members to have full read/write access in 
the ALFS area of the BK file system structure
C) BK/Web access to the BK repositories for anyone to be able to browse 
the repos, look at changesets, etc. (like CVSWeb)

Steps to reach this point:

1) Install bk-3.0.4 on belgarath.
2) Create a "bk" user/group, with home directory /home/bk.
3) Set up a system startup script to run "bk bkd -d -xpush" as user bk 
with current directory of /home/bk. This provides read-only access to 
anyone who wants to clone/pull repos with BitKeeper. It also provides 
BK/Web services.
4) Open up belgarath's firewall to allow incoming TCP connections to 
port 14690 (the bkd port).
5) Create an ALFS subdirectory under /home/bk, owned by bk:cvsalfs, with 
the group sticky bit set.
6) Add a DNS alias for "bk.linuxfromscratch.org" to point to 
"belgarath.linuxfromscratch.org".

With that done, any ALFS team member can set up a new master repo by 
opening an ssh session to belgarath, cd'ing to /home/bk/ALFS, and using 
"bk setup foo" to create a repo named foo. Note that this would not 
happen often, as we only need a master repo for each of our products, 
currently only four. We would need to decide on a structure for the 
repos, although following what we have in CVS now would be a decent 
starting point. However, it might be wise to move nALFS into a "tools" 
directory, so we can easily have repos for other tools should they be 
needed. Something like:

/home/bk/ALFS
           +---tools
           |      +---nALFS
           |      +---...
           +---profiles
           |      +---LFS
           |      +---BLFS
           |      +---BELFS
           +---docs
                  +---syntax_guide
                  +---hackers_guide
                  +---nALFS_users_guide


Let's assume that /home/bk/ALFS/nALFS has been created, and contains the 
current CVS HEAD for nALFS.

Anyone who wants to clone the nALFS repo can use:

bk clone bk://bk.linuxfromscratch.org/ALFS/nALFS

to get a local clone called "nALFS" in their current directory.

Team members can get read-write clones by ensuring that they have ssh 
set up properly and use:

bk clone ssh://bk.linuxfromscratch.org:/home/bk/ALFS/nALFS

If their local username and their belgarath username do not match, then:

bk clone ssh://username@bk.linuxfromscratch.org:/home/bk/ALFS/nALFS

Team members can then edit their clone, using "bk ci" and "bk commit" to 
store their changes and change comments locally. When they are ready to 
send up to belgarath, "bk push" will send the changes. If the repo on 
belgarath has been changed in the meantime, "bk pull" first will pull 
down the changes and merge, like "cvs update" does.

BK/Web access would work like this:

http://bk.linuxfromscratch.org:14690/ALFS/nALFS

to browse this master repo. If we go this direction we will need to 
produce some scripts to generate some basic pages that people can be 
directed to to list all the available repos; BK/Web does not do that on 
its own. To play around with what this looks like, go to:

http://jeeves.homelinux.org:14690/LFS/post-LFS

to see a repo on my home server. There's not much in it, but you can see 
what the interface looks like.

"Branching" would be handled by creating a clone of the master repo at 
the desired point (BK does not handle branches within a repo, they are 
unnecessary). For example, to create a branch for nALFS-1.3 from nALFS 
(in an ssh session on belgarath):

cd /home/bk/ALFS
bk clone nALFS nALFS-1.3

This would create the nALFS-1.3 branch, with BK remembering that nALFS 
is its parent, so push/pull operations can still be performed between them.

We would need to come up with some "trigger" scripts to send commit 
messages to alfs-log, but I'm sure asking on bitkeeper-users would 
provide a good starting point for that.

Comments?



More information about the alfs-discuss mailing list