setting up tracking/work/merge repos

   once upon a time, i asked about the best way to keep track of a 
bk-managed repo, while being able to make my own local changes, and 
merge changes in both.  based on the responses i got, this is what i 
understand is the best way -- corrections welcome.

   the repo is for a bkbits-managed constantly-changing linux 2.6 
kernel source tree, so here's my strategy, with a few questions:

step 1:
-------

"bk clone" the bkbits-managed repo -- call this the "tracking" repo -- 
which i have no permission to change at the source.  (i might 
informally submit patches, but i have no developer access so, for the 
purpose of this exercise, it's read-only).

no need to check out anything in this cloned repo, i won't be doing 
any work in it.  and, every so often, i'll do a pull on it to bring it 
up to date.

 	NET --> tracking repo

step 2:
-------

"bk clone" tracking repo to "work" repo, where i'll do all my own 
changes.  so, currently, the tracking repo will be the parent of the 
work repo.

 	NET --> tracking repo --> work repo

step 3:
-------

one more time, "bk clone" to create what i'll call the "merge" repo, 
which is where i'll try to merge the changes from both of the above:

 	NET --> tracking repo --> work repo
 			     \--> merge repo

so merge repo is also a child of tracking repo, and all contents are 
identical for now.  now, where to from here?

   at this point, what's the best approach?  as i see it, every so 
often, i'll just do a "bk pull" on the tracking repo to bring it up to 
date, but that alone won't affect my work repo -- i'll just do it for 
the fun of it to see what's changed.

   i'll make all my local changes in the work repo and, occasionally, 
i'll want to bring my work repo up to date from changes in the 
tracking repo.

   as i see it, what i'll want to do is, from the merge repo, pull all 
changes from both the tracking repo and the work repo (have to do a 
reparent there, obviously).  if all goes well, turn around and pull 
from the merge repo back to the work repo.  if there are conflicts, i 
have to fix them in the merge repo before pulling all those changes 
back into the work repo.

   is this reasonable?  it guarantees that:

1) the tracking repo only ever represents *some* version of the bkbits 
stuff, none of my changes.

2) the work repo is the only place where local changes are made.

3) the merge repo is transient (doesn't have to exist all the time), 
and represents where the possibly messy merging gets done, so that if 
i screw up the merge, i haven't done any damage to my work repo.

   is this overkill?  is there an accepted technique for what must be a 
common task?  thanks.

rday

_______________________________________________
Bitkeeper-users mailing list
[email protected]
http://bitmover.com/mailman/listinfo/bitkeeper-users
To unsubscribe from this list, go to the above URL, follow instruction at the bottom of the web page.