Demonstration Help.

[Talden]

>> 1. Shared Repositories
>>
>> I know you're focusing on centralised but if you cover local branches
>> consider the following
>>
>> 2. Keeping a clean mirror of upstream
>>
>> If your devs want to separate the area of their drive for upstream
>> mirrors and local branches from the work areas then talk about
>> tree-less branches, no-trees in repositories and switching between
>> branches in lightweight checkouts.
>
> I apologize for my noobyness, I'm still new to bzr.

So am I.  Our organisation uses Subversion, I've gone to some effort
to test my work needs with bazaar and so far it's looking very bad for
Subversion.

> I'm unfamiliar with
> this, what exactly is upstream in this context, and how do shared repos help
> keep it clean? I started doing more research into shared repos after you
> mentioned them, I thought they were more or less just a way to minimize file
> system resources, is this correct?

As some have noted already,  Shared Repositories help reduce
duplication of revisions - if you just had a bunch of branches with
common ancestry but without a shared repository then you must have
downloaded the content multiple times and you've used more disk-space.
keeping them all in the Shared Repository means only one copy of each
revision.

Having a clean mirror provides an easy way of ensuring you always have
pulled all revisions relevent to the trunk without having to think
about how they've diverged.  Also, you ensure that the history is
identical and therefore revision numbering is identical when looking
though history.


I have something like the following

c:\dev\  (a tree-less shared repo)
    remote\
       trunk...  (This is a clean branch of the central trunk that I
pull to keep up to date. I only pull from the central trunk into here)
       releaseX... (This is a clean branch of the central releaseX
branch that I pull to keep up to date.  I only pull from the central
releaseX into here)
       davesFeatureY... (This is a clean branch of daves featureY
branch that he's asked for help with, I only pull from dave into here)
    local\
       myBranch1... (this is a branch taken from ..\remote\trunk)
       myBranch2... (this is a different branch taken from
..\remote\trunk - it could be from a different branch point in trunks
history)
       featureYtweak1... (this is a branch taken from
...\remote\davesFeatureY - I'll send a bundle to dave to merge when
I'm done)
   work/  (A checkout of whatever I'm working on at the time, any one
of my branches)
   merging/ (A checkout of the central trunk.  I use this to deliver
my branches back to the central store by merging branch into trunk)

Note that the repository is tree-less and so there are no working
trees on the remote branches or local branches.

I switch the work checkout between local branches to do work (and
sometimes remote branches or trunk for single commit fixes).

I update the merging checkout before merging, merge a branch in, check
changes and then commit.  Because I mirror the central trunk, updating
this is quite fast as I will have all or most of the revisions in the
shared repo.

Note that these checkouts are not lightweight.  I'd only use
lightweight if, for some reason, I wanted to separate the folders
containing the branches and repository from the work areas or did not
want any history locally at all - however I'm happy to keep them
inside the shared repo.

Note that the 'merging' checkout is a checkout of the central trunk.
This means commits will go straight to the central trunk.  If this
were a lightweight checkout elsewhere this would mean I have none of
the revisions locally but sinces it's heavyweight and in the shared
repo it actually very cheap.

> One question coming from that tutorial. Regarding, "Shared Repositories
> Without Trees" - I got the impression from this section that shared repos
> without trees allow users with write access to the server to modify and
> commit things from the server? Is this correct?

All the repo without trees does is allow you to have branches without
the cost of working files.  I need only have a small number of trees
but have all the history and all the branches at my fingertips.

BTW, Subversion causes more pain than just a lack of local history.
Our trunks working tree is 550MB+ on disk (NTFS 4kb) and has 14,000
files and 2,500 folders.  A Subversion checkout of this  is over 1.1GB
on disk and has 47,000 files and nearly 23,000 folders.  Those extra
files and folders have a massive impact on system performance - and I
have between 5 and 10 working copies at a time because there are no
local branches and I'm not always connected.

In Bazaar, if I have 2 working trees that's 1.1GB.  If history is
1.5GB or smaller I've broken even with 5 Subversion working copies.
History would need to exceed 9GB before I reach the cost of 10
Subversion working copies.

The only thing I don't like about shared repos is that garbage
collection is awkward.  If you delete half the branches and want all
revisions that only belonged to those branches to be stripped away you
need to create a new shared repo and move all the branches you want to
keep there before removing the old repo - ~double the space and ten
times the effort (and unless I'm missing something, there's a lot of
matching up push and pull locations again).

--
Talden