Are squashed commits and discarded branches possible in bzr?

[Stephen J. Turnbull]

Todd A. Jacobs writes:
 > On Mon, May 10, 2010 at 03:59:23PM +0900, Stephen J. Turnbull wrote:
 > 
 > > If you mean GC of dangling revisions, IIUC this happens when a branch
 > > is repacked, and certainly when it is cloned.
 > 
 > I'm not sure this is right.

I stand corrected, GC and pruning only happens on clone ('bzr branch').

 > Let's say I have a shared respository with trunk, feature-one, and
 > feature-two. I do:
 > 
 >     cd trunk
 >     bzr merge ../feature-one
 >     bzr revert --forget-merges
 >     bzr commit -m 'Some squashed commit msg.'
 >     rm -rf ../feature-one
 >     cd /tmp/foo
 >     bzr clone /path/to/trunk
 > 
 > and I will get a history that wasn't going to include feature-one
 > anyway, since it wasn't actually merged in any real sense. But if I do:

Of course it was merged in a real sense, and now trunk *does* include
the revision content of feature-one, does it not?  But after the
merge, you explicitly removed the history, just as surely as if you
used git-filter-branch to do it in git.  This is the only way to do it
in any of the history-DAG-based VCSes.

 >     cd trunk
 >     bzr merge ../feature-one
 >     bzr commit -m 'Some commit msg.'
 >     rm -rf ../feature-one
 >     cd /tmp/foo
 >     bzr clone /path/to/trunk
 > 
 > I would expect that the DAG still references the feature-one branch,
 > since that's where the merge came from.

Nor does it work any differently in Mercurial, Monotone, Darcs, or
git!  But the DAG doesn't "reference" the *branch*, it *contains*
(copies of) the *commits* that constituted the branch.  These commits
are accessible from the tip of the DAG, and therefore are integral
components of it.  In fact, it's the other way around: branches are
references to the DAG, although in Bazaar that fact is quite deeply
buried most of the time.

 > But if that's actually what I want (e.g. to discard a local branch
 > that hasn't been pushed elsewhere), is there actually any way to do
 > that within a shared repository?

You discard the *branch* by deleting the directory tree at .bzr (and
usually the containing workspace as well).  This saves a lot more
space in Bazaar than it does in git<wink>, but functionally, it's
identical: you've discarded a ref, not the data it refers to.  You
cannot discard the historical revision data without discarding the
history[1], ie, rewinding the branch to the premerge state as you do
in your first example workflow.


Footnotes: 
[1]  In Darcs you sometimes can, but that's because Darcs is based on
a patch dependency DAG, not on a history DAG.