Martin Pool wrote:
> Thanks for the patch Tim.
>
> I'm not convinced that missing should be settitng the parent implicitly:
> it's a logically readonly command and so should probably not have side
> effects. So I'm inclined to just remove that section. We would also
> need to document the removal in NEWS, and add some tests for missing
> between two readonly branches.
I don't think I really agree with that. For example, bzr send is
logically readonly, but actually
- - does a fetch of the remote last_revision, so that it can determine a
common ancestry locally
- - sets the submit branch
- - sets the public branch
If logically readonly commands can't do write at all, then generating a
bundle becomes more expensive, and we never get to set the submit branch
or submit branch.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin Pool wrote:
> Thanks for the patch Tim.
>
> I'm not convinced that missing should be settitng the parent implicitly:
> it's a logically readonly command and so should probably not have side
> effects. So I'm inclined to just remove that section. We would also
> need to document the removal in NEWS, and add some tests for missing
> between two readonly branches.
I don't think I really agree with that. For example, bzr send is
logically readonly, but actually
- - does a fetch of the remote last_revision, so that it can determine a
common ancestry locally
- - sets the submit branch
- - sets the public branch
If logically readonly commands can't do write at all, then generating a
bundle becomes more expensive, and we never get to set the submit branch
or submit branch.
Aaron
-----BEGIN PGP SIGNATURE----- enigmail. mozdev. org
nu1YWqI0RAhR2AJ 0e5o1zidxADVYAz +SUI5+EpAHCkQCa Atgs Pew93zSg=
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://
iD8DBQFGrh0d0F+
WAF9VCMfVBVn7dG
=Lb2x
-----END PGP SIGNATURE-----