Bazaar experimental branch removal (repost)

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

To me it sounds like a good use case for lightweight checkouts of
branches stored on another machine.

For example, at home I have a shared repository on my server "juju", and
then on my desktop I can do:

bzr co --lightweight bzr+ssh://juju/srv/bzr/branch_a

To create a new branch on the server, I can use push or branch, such as:
bzr branch bzr+ssh://juju/srv/bzr/branch_a \
  bzr+ssh://juju/srv/bzr/branch_b

'switch' is a command to select where a checkout points, and it has been
taught about using "short" names. So if you are in the above checkout,
you can do:

bzr switch branch_b

And it will update your tree to point to bzr+ssh://juju/srv/bzr/branch_b
along with updating the working files to be current with that tip.
(preserving uncommitted changes).

Anyway, by using a lightweight checkout, only the build files and the
working files are stored locally. None of the history. Instead, you can
have all of your history stored on another machine which has more disk
space.

You need that anyway with "shallow" branches. The main difference is
that *all* revisions would be stored elsewhere. So stuff like "bzr log"
is going to be a little bit slower. If you are on the local network,
though, I wouldn't expect this to have a large impact.

John
=:->

Guido Ostkamp wrote:
> 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
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFILh7EJdeBCYSNAAMRAqheAJsGsPiAC+ULOJVC2rjDk9c7gyjLngCgvbw3
SIx9J9DU112YG6RKWSVgFVI=
=LU20
-----END PGP SIGNATURE-----