Bazaar experimental branch removal (repost)

[Guido Ostkamp]

On Fri, 16 May 2008, Ian Clatworthy wrote:
> Revisions are stored very efficiently so it's not a practical issue for 
> most people. Your case could be different though - you seem to be 
> versioning some very large (binary?) files, yes?
>
> Keep in mind as well that Bazaar doesn't ship around whole repos (like 
> Git does) - it ships around just the branches you ask it too. If you 
> never push/pull that crazy-idea branch elsewhere, it's revisions won't 
> take up space in anyone's repo except yours.

Thanks for responding, Ian.

My use case might indeed be somewhat special. Let me explain briefly:

I am developing Unix/Linux software in $large_company; as everyone I'm 
bound to company rules and thus I must live with a Windows-box on my desk 
(sigh!). So local development is impossible, we have to do everything on 
Solaris servers in our testlab, which are used for a rather long time, and 
diskspace there is very expensive (a replacement for a Sun server HD even 
with low capacity compared to todays standards can cost a huge amount of 
money). So we are all bound to restrictive disk quotas, some of us have to 
live with just a few Gigabytes (meaning 2-8 GB). I know, this sounds 
ridiculous low, compared to nowadays disk capacities for new PCs, but it 
is as it is, we have to live with it. With ClearCase you only have to 
store compilation results and checked out files locally, everything else 
meaning all history and top-level files are stored in the special 
ClearCase filesystem not under the quota.

I'm using DVCS as a secondary VCS for quick development as branching in 
ClearCase is not an option. Still, I want to have history at my fingertips 
in DVCS, thus I don't create a fresh repo from current version, but keep a 
shadow DVCS repo in sync with ClearCase at least for the mainline.

As you have already guessed correctly, we also have some large files in 
the repo. Sometimes things are only available as binary, but need to be 
packaged and delivered by us or are used in our productions.

So, space consumption really matters, when I create branches and when I no 
longer need them.

> That's right. FWIW, Robert Collins is working on "stacked branches" that 
> *might* be just what you want. If not, it will be the basis of "shallow 
> branches" that might be as well. :-)

Hm. I tried to understand what it is through reading historic articles on 
the list; however I'm not sure I understood it correctly.

Some of the stuff appears to deal with downloading history records in the 
background while providing a working tree for a clone immediately. I don't 
see how this could help me.

This would be different, if I could have a branch, where changes are 
committed locally, while the earlier history remains where it was - in the 
branch it was cloned from.

Regards

Guido