[Openais] Misc Corrections

Daniel Stodden stodden at cs.tum.edu
Wed Oct 27 17:52:03 PDT 2004


On Wed, 2004-10-27 at 15:34 -0700, Steven Dake wrote:
> Daniel,
> 
> It looks like you know more about bk then I do :) 
> 
> You ask an excellent question...
> 
> I propose we formalize your suggestion for submitting patches:
> 
> 1. Developers create diff -uNr against some baseline so it may be
> reviewed on the mailing list.
> 
> 2. Comments are resolved until final diff is approved.
> 
> 3. Once final diff is approved, bk sendpatch is used to send a patch to
> the mailing list.
> 
> 4. Patch creater requests this patch is the final patch to be applied
> and matches the diffs.
> 
> 5. Maintainer of service (or me) applies patches.  Any merge problems
> that cannot be resolved may require patch creator's involvement.
> 
> All changes even by maintainers should be posted on the mailing list. 
> If there are issues with the changes they will either not be applied or
> a bug can be opened to resolve the remaining issues later. (we have done
> something like this for logging which isn't quite complete, but its much
> better now to have something then to be perfect).

okay, this is good. i've started on a bitkeeper howto in order to
explain how this is supposed to work in bk terms.

ideally, we'd get a copy on the homepage or somewhere similar. this
should make things a little easier for anyone to join.

this won't get finished tonight, though :P. see below.


======================================================================
                   OpenAIS BitKeeper HOWTO
======================================================================

1. Getting the source

To get the OpenAIS source through bitkeeper, create a clone of the
OSDL bitkeeper repository:

	cd ~/src
	bk clone bk://bk.osdl.org/openais ais-upstream

This creates a new directory 'ais-upstream' in your current working
directory. Your naming may vary.

If you just intend to build from the head of the official bk tree,
proceed to step 3.


2. Preparing for changes

Working with BitKeeper is all about separating changes by issue. For
each item you are going to work on, create another clone of your
original clone.

	# Hunt the crasher
	bk clone -l ais-upstream ais-bugfixes

	# Implement another service
	bk clone -l ais-msg ais-msg

	# Stuff nobody besides me will ever use
	bk clone -l ais-upstream ais-privatehacks

The '-l' option makes BK use hard links where possible in order to
save disk space.

Conceptually, this leaves you with a tree of interconnected
repositories like the one below:

                  ais-upstream
                   /   |   \
                  /    |    \
                 /     |     \
   ais-privatehacks ais-msg  ais-bugfixes

When receiving updates later on, one advantage of such a setup is that
you need to pull from the OSDL parent only once. Other repositories
are fed from their immediate, local parent.

# FIXME: steal some more stuff from linux-bk-howto

3. Where are the files?

After cloning, your tree still looks empty.

If you just want to build and/or install, the simplest way to do so is

	make GET="bk get"

This will enable GNU make to checkout all the files it needs
automagically (including the missing Makefile). Note that this turns all
source files into intermediate targets, so the source will be removed
after the build process is finished with them, leaving you with a few
object files and executables afterwards.

If you want to browse the tree instead (or have use a make without
builtin SCCS support) issue the following command:

	bk -r co

This checks out all the files like you are probably used to.


4. Hacking the source

The 'co' command leaves you with read-only copies. In order to edit
a file, try

	bk edit <filename>

Alternatively, a

	bk -r edit

will check out all the entiry tree in read/write mode. Be careful not
to mix changes which do not belong into the same category.


5. Creating a ChangeSet

If you're finished with a respective piece of work, create a
changeset. A changeset is a collection of changed files. The simple
way to collect these files is by issuing

	bk citool

This starts up a graphical tool showing all the files you've changed
so far. Comment all the individual changes to files
('deltas'). Acceptance of your patch will depend on thorough
comments. Once all the desired deltas are commented and selected for
commit, you should add a ChangeSet comment. Press 'Commit' to complete
the process. More information on how to work with citool is provided
with the BitKeeper documentation:
	
	bk help citool

6. Updating your tree

Depending on the time spent between steps 4. to 5., there may be
pending changes at the official repository other developers applied
concurrently. Use

	bk pull ... 			# FIXME

to apply these changes. The 'bk pull' command will only proceed on a
 clean tree bla bla bla...


7. Seeking review

...
	bk -r diffs -u			# FIXME

	bk rset .. | bk diffs -		# FIXME

...

8. Submit

...

	bk send  openais at lists.osdl.org   #FIXME

...



suggestions not just welcome but begged for.

regards,
daniel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.linux-foundation.org/pipermail/openais/attachments/20041028/49aefb5a/attachment-0001.pgp


More information about the Openais mailing list