[Bitkeeper-users] Porting(pulling) a specific changeset from one repository to another

[Ahmed A]

--- "Eric D. Mudama" <edmudama at gmail.com> wrote:

> On 8/29/07, Ahmed A <ahmedcali at yahoo.com> wrote:
> > Hello,
> >
> > I am runnning bk version 4.0.2.  I have two
> repository
> > (repo1 and repo2), one is basically a branch of
> > another.  Changes have been pushed into both repo
> over
> > time.
> >
> > I have cloned both of them.  I made some changes
> to
> > repo1, made a changeset (lets call it cs1).  I
> would
> > like to pull ONLY "cs1" into repo2.
> >
> > I have read the man page for "bk pull", and it
> states:
> >
> > bk pull [-iqRsTu] [-r<rev>] [-E<env>=<var>]
> [-c<n>]
> > [<parent> ...]
> >
> > -r<rev>       Pull up to and including this
> revision,
> > but exclude later changes.  (Or key or  changeset
> > revision.  See  bk  help terms under 'rev
> argument')
> >
> > I have read the documentation of "rev argument".
> >
> > Basically, I want to ONLY pull "cs1" from repo1 to
> > repo2, and not up to and including "cs1".
> >
> > Can someone please help me with the syntax?
> 
> This is not an official answer, and I am not
> currently a BK user, but
> I thought I might be helpful til Larry or someone
> else chimes in:
> 
> cs1 in repo1 depends on all the changes that
> occurred up to the cs1 in
> repo1.  All your test data, integration data, etc.
> 
> To pull cs1 by itself, without all those
> dependencies, would
> effectively make cs1 a fresh delta, which is
> basically how BK treats
> it.
> 
> You can pull "everything up to a point" into another
> repo, but you
> cannot cherry pick, because that would give you a
> "perceived"
> reproducability that doesn't actually exist.
> 
> Ultimately, I think you'll have to export it as a
> GNU patch or
> equivalent and apply it to repo2.  I don't believe
> there's any
> built-in way to cherrypick a changeset from one repo
> to another
> without including the ancestor changesets.
> 
> This is a good thing, by the way, but frustrating
> until you're used to
> working around it.  It definitely leads to a very
> different workflow
> than with most other tools.
> 
> --eric
> 
> PS: Given this restriction on cherry-picking, one
> way to solve it is
> to base all development for both mainline and the
> branch on the
> branching changeset.  This way all new development
> is a child of the
> same node, and can be pulled into either mainline or
> the branch.
> 



       
____________________________________________________________________________________
Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
http://farechase.yahoo.com/