[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bitkeeper-users
Subject:    [Bitkeeper-users] how to generate a (chronological) set of patches
From:       "Robert P. J. Day" <rpjday () mindspring ! com>
Date:       2004-10-05 12:13:47
Message-ID: Pine.LNX.4.60.0410050749220.3390 () localhost ! localdomain
[Download RAW message or body]


   ok, after digging around in the docs and "bk helptool", i'm still 
not sure how i'd pull off the following (and i'm quite prepared to be 
told, oh, that's *so* easy, what is your problem? :-P)

   there's a bk-managed kernel source tree to which i have no 
modification access -- i can clone and pull and that's it.  if i want 
to submit changes to the tree, i have to create the appropriate 
unified-diff patch and send it in to the moderator/mailing list, and 
eventually (if all goes well), the change gets adopted and i'll 
eventually see it coming back as part of a future "bk pull".  so far, 
so good.

   i want to submit a fairly sizable change, but i'd rather not do it 
all at once.  instead, i'd like to do it in bite-size pieces, so that 
no one patch would be overwhelming in size.  in addition, i'd like 
each patch to add/change just a little bit more and be independently 
testable.  so the patches could be applied one at a time as the 
maintainer gets the time, but they *would* be chronologically related 
-- they'd have to be applied in the order i sent them in, as each one 
would build on the work/changes that came before.

   so the process:  i start with a cloned tree, make the first set of 
changes, generate a patch file (defined as some local changeset?), 
submit that, get back to work.

   without waiting for that patch to be incorporated, i start making 
the next set of changes/additions (i can't control when the maintainer 
gets around to looking at my patches, and i don't want to be held up 
before moving onto the next set of changes).  eventually, i would 
generate patch 2, which would be defined WRT my patch 1 already being 
applied.  submit that, back to work, etc .

eventually, i have some set of chronologically-related patches in the 
maintenance pipeline, and in a perfect world, eventually, they start 
to be applied, and i see them coming back to me in future "bk pull"s.
so, what's the ideal way to generate these patches such that:

1) they each build on the accumulated set of what came before?

2) i can, at any time, make other changes to the source tree for 
strictly local benefit that shouldn't be part of *any* patch

3) if, down the road, i get a note from the maintainer telling me that 
the patch he's looking at from me at the moment has a problem, i can 
quickly go back to that patch, make a quick change to my local repo, 
recreate the patch, and resubmit it.  and we both hope that it doesn't 
cause hideous problems with all of the subsequent patches that are 
already in the pipeline.

4) eventually, as the patches get committed to the tree and they come 
back to me with later "bk pull"s, of course they shouldn't cause 
resolution or conflict problems with my local tree which already has 
those changes in it.

5) other changes to the main repo will also be pulled down and will 
hopefully not cause conflict problems (shouldn't be a problem as i'm 
working in an area that no one else should be messing with anyway so 
merging should be fairly straightforward).

   am i making life overly difficult here?  or, a better question, does 
this represent a work pattern that makes sense?  thoughts?

rday
_______________________________________________
Bitkeeper-users mailing list
Bitkeeper-users@bitmover.com
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.
[prev in list] [next in list] [prev in thread] [next in thread]