Fwd: nuclear lauchcodes and nuclear waste

[John A Meinel]

Martin Pool wrote:
> On Mon, 2006-01-09 at 23:05 +0100, Denys Duchier wrote:
>> Aaron Bentley <aaron.bentley at utoronto.ca> writes:
>>
>>> I think that in addition to this functionality, we may well want the
>>> ability to re-do a particular revision, but leave the changes introduce
>>> by later revision.  This operation would, naturally, produce new
>>> revision-ids.
>>>
>>> e.g.
>>>
>>> $ bzr status
>>> $ bzr do-over -r 100
>> I completely agree... but doesn't it feel very much like some sort of "patch
>> queue management" functionality?  i.e. you revert to an earlier revision, but
>> (in some sense) also load a patch queue with all the changesets associated with
>> reverted revisions.  Then replay the patch queue, possibly modifying things a
>> bit here and there.
> 
> If you want to manage patches as first-class objects which have their
> own history then you do want something like hct/quilt/stgit/etc.  But
> possibly there's a different use for the rare case of just wanting to
> rarely go back and fix a mistaken commit (as Jeff said).
> 

Well, on one hand, you would have the idea of reverting back to a point,
and creating entirely new revisions. Possibly nuking the old history,
and hoping that other people don't have those revision ids yet.
On the other hand you have the concept of replacing the revisions
somewhat 'in-place'. Where the new ids are somehow marked that they
should be preferred.

I think the former process, where you generate all new revisions, which
are only vaguely related to the other ones (because they have similar
contents), is pretty easy to support. The latter is quite a bit more
difficult. At least under the bzr model.


John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060109/2f39547f/attachment.pgp