[BUG] apply_changeset / generate_changeset use wrong base

Aaron Bentley aaron.bentley at utoronto.ca
Wed Sep 28 17:14:02 BST 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John A Meinel wrote:
>>>> There needs to be some way to get the complete changeset of the entire
>>>> history.
>>
>>
>>
>> Sure.
> 
> 
> So how would you do this, other than a 'null:' => last_patch() changeset?

I don't have a problem with generating a 'null:' => last_patch()
changeset.  The question is, when is it appropriate to apply it?

>> My feeling is that branches that only have null: in common aren't really
>> related.  It usually wouldn't make much sense to apply a changeset for
>> bzrtools to bzr, for example.  So I don't think we should do that by
>> default.
> 
> 
> But what about publishing your archive as a changeset. Somehow you have
> to get started.

It is absolutely fine to produce a changeset whose base is 'null:'
Let's not confuse the changeset base with the changeset application base.

> I agree it doesn't make much sense to merge bzrtools
> into bzr (though I would argue that it would be nice to be able to merge
> distinct branches together in case the project itself merges, I've had
> to do it manually for some things.)

I only said 'not by default'.  I think it's reasonable to require a flag
for this special case, just as we require the user to manually specify a
base when merging two unrelated branches.

> What makes more sense, though, is being able to apply_changeset() my
> tree into a blank branch. If we are accepting the idea that merge and
> branch can be supplanted by changesets (in the case that someone is
> unable to publish their branches), then there needs to be a way to
> bootstrap that process.

Yes, that does seem reasonable, though it would also be possible to do
bzr create-from-changeset $CHANGESET $NONEXISTANTDIR for this case.

> I'm not asking to be able to merge two branches that only share 'null:'
> (though I'm asking that separately, perhaps with a flag to not do it by
> accident), I'm asking for being able to recreate the first commit.

So, is this what we're saying?
1. Any changeset can be applied to a blank branch
2. By default, unrelated changesets cannot be applied to a branch
3. If you specify a flag, you can apply an unrelated changeset to a branch.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDOsFK0F+nu1YWqI0RAhxuAJ9ROzNJ4HLxFeR6mS+//xLk/kK05gCfWs/P
qZniK11d4SywVHLWao9T/Fw=
=f7em
-----END PGP SIGNATURE-----




More information about the bazaar mailing list