Re: Porting(pulling) a specific changeset from one repository to another

--- "Eric D. Mudama" <[email protected]> wrote:

> On 8/29/07, Ahmed A <[email protected]> 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>=3D<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?
>=20
> 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:
>=20
> cs1 in repo1 depends on all the changes that
> occurred up to the cs1 in
> repo1.  All your test data, integration data, etc.
>=20
> To pull cs1 by itself, without all those
> dependencies, would
> effectively make cs1 a fresh delta, which is
> basically how BK treats
> it.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> --eric
>=20
> 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.
>=20



      =20
_________________________________________________________________________=
___________
Looking for a deal? Find great prices on flights and hotels with Yahoo! F=
areChase.
http://farechase.yahoo.com/