[MERGE/RFC] Userdoc Driven Design on the Bazaar 2.0 UI

[Christophe TROESTLER]

On Fri, 17 Apr 2009 02:47:00 +0200, Jelmer Vernooij wrote:
> 
> Christophe TROESTLER wrote:
> > Right but it seems to me that "bzr branch --stacked; bzr bind $URL"
> > has all the capabilities and advantages of checkout plus the ability
> > of local commits if one needs so.  Is there a senario for which
> > checkout --lightweight would be superior?  (The same question holds
> > for a heavyweight checkout versus a bound branch.)
> >   
> A stacked branch "gathers dust". The repository along with which it is
> created contain more and more data as the branch is used (e.g. a pull
> will cause new revisions to end up in the stacked branch too).

So is there a way of having a branch with a limited revision history
that evolves over time (as I naively thought stacked branches were
for)?  Say I want to contribute to a large project (without write
access to its main repository) over a period of a few years.  I would
be keen just to have the last 20 revisions (and to be able to commit,
diff,... locally and more generally play with these revisions locally)
and, as I pull more revisions, the old ones (including my locally
committed ones that were accepted in the main project repository)
could be garbage collected so that the local history horizon stays
about the same.  IMHO, this would be a nice setting to contribute to a
large project such as Emacs without having a local repository which
size increases much over time.

Cheers,
ChriS