Short, task-based bzr doclets for real-world use cases.

[Paul Moore]

2009/1/17 Brian de Alwis <bsd at cs.ubc.ca>:
>> (The hugely over-used example of needing a shared
>> repo for performance, rather than a standalone branch, which is the
>> "obvious" approach, is the canonical example here; your example above
>> is another).
>
> I think Paul makes a good point here -- we trivialize repositories by using
> them only for speed.  I think they're fantastic and should be treated by the
> documentation as first class objects.  I've been saved from having used a
> repository on three different occasions after mistakenly blowing away a
> branch too early (steps to recovery: 1. 'bzr heads --dead' and determine the
> right revid,  2.  'bzr init recovery-branch', and 3. 'bzr pull -r revid:...
> .' to recover the branch)

I ought to say that I have no issue with repositories per se. But
tying them to the filesystem directory structure makes them hugely
irritating for me - I do *not* structure my work by project, so having
to have all my bzr/python/whatever work under a "project" directory
(the shared repo) is unsuitable for me.

Maybe if a branch could simply have a "pointer" to a repository which
was kept somewhere else, that would do the trick.

Paul.