Fwd: nuclear lauchcodes and nuclear waste

[Martin Pool]

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).

-- 
Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060110/9f661c34/attachment.pgp