Yes, that seems seems to fix the empty changegroup issue.

Patch in stable:
changeset:   10616:65b178f30eae
branch:      stable
parent:      10612:30553ac3e355
user:        Benoit Boissinot <benoit.boissinot@ens-lyon.org>
date:        Tue Mar 09 20:38:23 2010 +0100
summary:     bundle: fix bundle generation for empty changegroup

Yep, it's a different issue, if not changes are found, then it will bundle 
everything.

My original test case is not fixed in 1.5.

$ hg glog --template '{node}\n'
@  eea5c5f957377a9a16284e028970ac1a9a7863c7
|
| o  9be61c4aaa5fbec031d9f21acff2b437d71ddb62
|/
o  fc0d1d00ead60a630f7788872b2e3b098fe4304d

$ hg --debug bundle --base 9be61c4aaa5fbec031d9f21acff2b437d71ddb62 x.hg
1 changesets found
list of changesets:
eea5c5f957377a9a16284e028970ac1a9a7863c7

# Correct, but now let's try specifying both heads:

$ hg --debug bundle --base 9be61c4aaa5fbec031d9f21acff2b437d71ddb62 --base
eea5c5f957377a9a16284e028970ac1a9a7863c7 x.hg
3 changesets found
list of changesets:
fc0d1d00ead60a630f7788872b2e3b098fe4304d
9be61c4aaa5fbec031d9f21acff2b437d71ddb62
eea5c5f957377a9a16284e028970ac1a9a7863c7

# Oops, sent everything! Expected zero changesets.

See http://hg.intevation.org/mercurial/crew/rev/bb508b312359
(bundle: exclude csets given in --base, unless they are in --rev (issue1910))

See http://hg.intevation.org/mercurial/crew/rev/bb508b312359
(bundle: exclude csets given in --base, unless they are in --rev (issue1910))

changeset:   10476:ba339ba4dbe0
branch:      stable
tag:         tip
parent:      10474:601a9d67825a
user:        Benoit Boissinot <benoit.boissinot@ens-lyon.org>
date:        Mon Nov 16 16:10:05 2009 -0500
summary:     bundle: exclude csets given in --base, unless they are in --
rev (issue1910)

Submitted a slightly modified patch which also issues a warning when
creating an empty bundle. Not clear to me whether it is best to proceed in
this case, or return a special status code, or both.

This bug is about a --base which happens to be a head - an edge condition -
whereas the scenario Issue1704 involves a --base which is not a head. I
don't pretend to know what is going on in the patch for Issue1704; my grasp
of the internal functions is not that strong, and they do not seem to be
documented.

At any rate, the test cases I lay out here fail with current crew (just like
in 1.3.1) but succeed with my patch applied. There may well be a better
patch to correct the issue. I simply followed the data flow in the unpatched
sources and it looked wrong in two pretty simple ways that the patch
directly addresses:

1. bundle() has a 'has' set for things it should not bundle, and it checks
everything against this set except for repo heads (or --rev args if any are
passed). This looks like an oversight; there is no apparent reason why those
revisions should be exempted.

2. changegroupsubset() uses 'if not bases' in a way that looks like it was
expecting bases to either be None or a nonempty list. When an empty list is
passed, it behaves counterintuitively. Again this looks like an oversight.
Whether producing an empty changegroup is the best behavior is another
question - perhaps bundle() should just abort with a friendly message and
some special exit code if the node list is empty.

In msg10988 your base is one of the two descendants of a cset. This is what 
issue1704 is about. Before the fix, bundle would simply use all parents of 
base csets as "known" nodes, assuming all descendants of these known nodes to 
be unknown. Thus, your base suddenly became unknown.

Issue1704 looks different to me.

Sorry, hadn't seen your patch and test. Assuming this is against current 
crew.

Have you tried with crew tip? I would think that the fix for issue1704 has 
addressed this as well:

$ hg bundle --base tip^ /tmp/b.hg
1 changesets found

Note that in Issue76, it is suggested that

  hg --base $r --rev $r

be used to generate a bundle containing just $r. Interesting but this is
inconsistent with the documentation of --base, and the general consensus in
that issue that --base should not be included in the bundle. With the fix
for this issue, the above command will generate an empty changegroup, as I
believe it should. If you wanted just $r you could use

  hg --base $r^ --rev $r

(add --base $r^2 if it was a merge).

Using 1.3.1, 'hg bundle' fails to exclude nodes named by --base from the result:

$ hg glog --template '{node}\n'
@  08b7fb7c6d6c10bf4e7f71f21e21e82d4aad2f81
|
| o  2548b3e93606c1e024b16f5e920038bbf13166b8
|/
o  d9e5b562e4efdb762d4a11271f2a6f3bcc5cc3b1

$ hg --debug bundle --base 2548b3e93606c1e024b16f5e920038bbf13166b8 x.hg
2 changesets found
list of changesets:
2548b3e93606c1e024b16f5e920038bbf13166b8
08b7fb7c6d6c10bf4e7f71f21e21e82d4aad2f81
$ hg --debug bundle --base 2548b3e93606c1e024b16f5e920038bbf13166b8 --base
08b7fb7c6d6c10bf4e7f71f21e21e82d4aad2f81 x.hg
2 changesets found
list of changesets:
2548b3e93606c1e024b16f5e920038bbf13166b8
08b7fb7c6d6c10bf4e7f71f21e21e82d4aad2f81

Clearly this contradicts the docs for the bundle command:

"the destination is assumed to have all the nodes specified by one or more
--base parameters"

There seem to be two problems:

1. Heads are not excluded in bundle(...).

2. Even if #1 is fixed, if the result is an empty list,
changegroupsubset(...) treats bases==[] like bases=[nullid] and so the
command works as if --all had been specified!

Both problems are easy to fix. I am not sure whether any regression is
possible from fixing #2, i.e. whether some code actually passes bases==[]
expecting it to be like omitting this parameter. At any rate, "all the nodes
that are descendents of any of the bases and ancestors of any of the heads"
implies that passing bases==[] should result in an empty changegroup (docs
do not specify what bases==None means).