Question about features

[Scott Aubrey]

I know this is long dead, but i thought I'd add my idea just for the  
sake of completeness.

One (albeit quite longwinded) way to remove features and produce a log  
that isn't littered with 'removed feature B' is to merge in the  
undo's, then 'uncommit' to before that revision, then either commit is  
all back as one revision, or shelve and unshelve, e.g.:

$ bzr init test
Created a standalone tree (format: 2a)
$ cd test/
[HACKETY HACK]
$ bzr ci -m "Feature A"
Committed revision 1.
[HACKETY HACK]
$ bzr ci -m "Feature B"
Committed revision 2.
[HACKETY HACK]
$ bzr ci -m "Feature C"
Committed revision 3.
[HACKETY HACK]
$ bzr ci -m "Feature D"
Committed revision 4.
$ bzr merge ./ -r2..1
[WT is now without feature B]
All changes applied successfully.
$ bzr ci -m "remove Feature B"
Committed revision 5.
$ bzr uncommit -r1
     2 Scott Aubrey	2009-11-05
       Feature B

     3 Scott Aubrey	2009-11-05
       Feature C

     4 Scott Aubrey	2009-11-05
       Feature D

     5 Scott Aubrey	2009-11-05
       remove Feature B
YES
[WT now is at revision one, with feature C and D uncommitted]
$ bzr shelve
[Shelve Feature D]
Changes shelved with id "1".
$ bzr ci -m "Feature C"
Committed revision 2.
$ bzr unshelve
Unshelving changes with id "1".
All changes applied successfully.
$ bzr ci -m "Feature D"
Committed revision 3.
$ bzr log
------------------------------------------------------------
revno: 3
committer: Scott Aubrey <scott at aubrey.org.uk>
branch nick: test
timestamp: Thu 2009-11-05 17:04:00 +0000
message:
   Feature D
------------------------------------------------------------
revno: 2
committer: Scott Aubrey <scott at aubrey.org.uk>
branch nick: test
timestamp: Thu 2009-11-05 17:03:46 +0000
message:
   Feature C
------------------------------------------------------------
revno: 1
committer: Scott Aubrey <scott at aubrey.org.uk>
branch nick: test
timestamp: Thu 2009-11-05 16:59:16 +0000
message:
   Feature A

Hey presto...though it takes a while and is fiddley, but the history  
looks nicer, and feature B isn't there!

- Scott

P.S. I don't do this mysqlf, but it was the way that came to me to  
achieve this problem.

On 5 Nov 2009, at 16:50, John Arbash Meinel wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Daniel Carrera wrote:
>> John Arbash Meinel wrote:
>>> Well, you could always do:
>>>
>>>  bzr commit
>>>  bzr push [--overwrite?] / bzr upload
>>>  bzr uncommit
>>>
>>> So you copy across a tracked revision, and just overwrite it later  
>>> when
>>> you have a different one.
>>
>> This is how I use Darcs, and it was my first instinct. But this goes
>> right back to the beginning of the thread and how bzr doesn't let you
>> alter the "history" (and as Stephen just pointed out, the notion of
>> "history" is not shared by Darcs users).
>>
>> Daniel.
>>
>
> Well, for some definitions of 'altering history'. We certainly let you
> remove recent revisions. darcs lets you remove 3 commits-ago without
> removing the last 2 commits. And *that* we don't support.
>
> So in bzr, if you have commits:
>  a => b => c => d
>
> You can always go back to a, b, c, or d, but you can't remove 'c'
> without also removing d.
>
> John
> =:->
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkrzAlQACgkQJdeBCYSNAAP0pQCcCqlFi7z8/vmFONYihmR5TMHS
> vd0AnjjlhXM5MArufrChzqdFacAkHPWP
> =lzQn
> -----END PGP SIGNATURE-----
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20091105/d25a4518/attachment-0001.htm