Naive questions re hard-linking repositories

[Robert Collins]

On Wed, 2009-04-15 at 17:26 +1000, Ian Clatworthy wrote:
> 
> > Early versions of bzr took the approach that a directory holds a
> > working tree, a branch pointer, and a repository with the history of
> > that branch.  This concept is still in bzr's dna and the defaults
> are
> > oriented towards it.  However, the actual recommended mode at the
> > moment is: make a shared repository, then make branch directories in
> > there, typically all with working trees.
> 
> Right. Defaults matter because they say a lot about how a tool is
> expected to be used in the common case. I rarely prefer git's UI over
> ours but, going back to the root problem, I think their choice of
> two separate commands - clone vs branch - is a wise one. The reality
> is that Doing The Right Thing varies IMO w.r.t. "branching" from a
> remote location vs branching from a local one. For remote, you nearly
> always mean "get me my own copy of history" while local
> branching is all about "start me a new line of development". The
> yet-another-complete-copy-of-history in the local case *by default* is
> somewhere between worthless and harmful (cause it consumes unnecessary
> time & resources).

clone in git is 'copy an entire repository' - it is radically different
from clone in bzr. I'm not against us having two commands for different
things, but I don't think the difference of 'get content vs edit branch'
is what drives git having two commands.

*if* we had a semantic repository [and we may need one to solve the root
issues] then having a command to copy the whole repository separately
from adding a branch within it makes a great deal of sense. 

> Just like pull vs merge vs update, the *intention* is different so
> it's
> arguably good to have separate commands. For 2.0, perhaps "branch"
> ought
> to always stack by default and "clone" ought to not stack, rather than
> just be an alias for branch?

stacking is a bad idea except when pushing with a trunk that will be
cared for. With partitioned data things get massively more complex and
we really don't want to be doing that by default.

> We can always stick with a single command, giving branch an option
> something like --stack-if-local (and making that the default mode).
> But I typically prefer explicit over implicit and I think it will help
> new users to think about clone vs branch as achieving different
> things.

If they were different - see above - then I'd agree. I think though that
we're looking at this waaaay to high up the stack. Our complexity in
this area is an emergent property; Martins analysis of how we got here
is spot on insofar as it examines the original concept and where we have
held onto it vs letting go to accomdate more use cases. We need to be
asking the 5 whys and diving deep to get a good answer on where the
issues are arising.

> > Whether you prefer one or the other, the fact that bzr is still
> > oriented towards a mode of operation that isn't what we generally
> > recommend is a problem.  I think this lies behind complaints that
> > there are too many ways to use bzr.
> 
> And equally importantly, just using the tool in the simple, obvious
> way performs terribly and chews disk space unnecessarily.

Right. 


> Right. So the usability goals needs to be:
> 
> 1. working well straight-out-of-the-box
> 
> 2. retaining our adaptability *but* improving the UI for getting to
>    and changing between commonly used workspace models.
> 
> Easy. :-)

May I add

1a. removing workspace models that can be replaced with better
alternatives and thus not needing to change.

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090416/95937dfd/attachment.pgp