How to pull/merge selective changesets

[Bruce Frederiksen]

On Wed, Aug 19, 2009 at 9:03 PM, Douglas Philips <dgou at mac.com> wrote:

> On or about 2009 Aug 19, at 4:33 PM, Abderrahim Kitouni wrote:
> > I suggest that you make a third repository for 'common' changesets,
> > and:
> > * if change belong to release_1, commit to release_1
> > * if change belong to dev, commit to dev
> > * if change belong to both, commit to 'common', and pull/merge to
> > every one.
> > (you should probably find a better name than common ;-))
>
> I've been on the cusp of doing that several times, but always found a
> way to keep one tree a subset of the other. ;)
>
> I'd prefer a third common tree over some of the merge gymnastics, just
> because it is more intention-revealing more than anything else.
>

This seems workable at first, but doesn't seem to scale well.  What happens
when you add another release?

For example, suppose you have rel_1, rel_2 and dev.  You might want to make
changes to:

   1. just rel_1
   2. rel_1 and rel_2
   3. just rel_2
   4. rel_2 and dev
   5. rel_1 and rel_2 and dev
   6. just dev

Do you then need rel_1_and_2, rel_2_and_dev, and rel_1_2_and_dev repos in
addition to rel_1, rel_2 and dev?  If so, this is O(n^2) on the number of
primary repos.  It would go from 6 to 10 when you add rel_3, and 10 to 15
when you add rel_4.

-Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20090819/097fbba7/attachment.htm