Re: bzr repository ready?

[Jason Earl]

"Stephen J. Turnbull" <address@hidden> writes:

> Jason Earl writes:
>
>  > On the one hand you chide me for adding a slight change to the bzr
>
> I did not.  I criticized you for adding a pile of vocabulary without
> explaining it.

I have re-read my responses and you are absolutely correct.  Heck, even
if you weren't correct I should have been more civil.  Please forgive
me.

>  > If the criticism of bzr is that it doesn't have colocated branches
>  > requiring several instances of "make bootstrap" then here is how
>  > you solve it.
>
> No.  It's a *warning* that dVCS fans, of whom there are several on
> this list, often *will* recommend a naive and inefficient "bzr branch"
> as the first step in any workflow.  Óscar Fuentes in a related
> subthread admits to doing exactly in a different context (cloning a
> remote branch vs remote file copying a tarball), and the wiki still
> does so.  That is a bad idea for many tasks, which really should use
> alternative workflows.  But they *are* alternative workflows, and are
> *not* explained on the Emacs wiki.

That makes sense.  I have certainly experimented with enough
pathologically bad bzr workflows.  Using the right workflow can make a
big difference, and I would be the first to admit that the "proper" bzr
workflow might not be readily apparent.

> The rest of your post is very much what I was looking for.  Well done!

You are welcome.

> One quibble:

Fah, like I said, I re-read my posts.  You are being generous here.

>  > On the other hand if you really like git's colocated branches bzr
>  > can be easily set up to approximate them.
>
> No, it is *not* easy, unless you use a definition of "approximate"
> that will be unacceptable to many git fans.  Agreed, the "lightweight
> checkout plus bzr switch" workflow has similar efficiency properties
> for most tasks, but there's a lot more to the git model than just fast
> "git checkout".

I think it goes without saying that git fans are unlikely to ever think
too highly of bzr.  Once you have learned how to use git effectively
everything else is a step down.  The bzr or hg devs probably have some
arguments to the contrary, but generally speaking git's weakness is that
it is hard to learn to use.

Personally, I think that git's insistence on colocated branches is a
large part of what makes it hard to learn.  Learning to juggle branches
in git certainly confused the heck out of me.  It is somewhat ironic to
me that I have come full-circle and I now tend to do my work in a
lightweight checkout that I point at the right branch with bzr switch.
In at least one project that workspace isn't even inside the repository.
My workspace is at ~/project-name and my repository full of branches is
tucked away at ~/repos/project-name/branches .

A fancy aliasing plugin for bzr that automatically mapped commands like
"bzr switch foo" to "bzr switch $HIDDENREPO/project-name/foo" would get
me even closer to approximating git's colocated branches.  The truly
scary thing (to me anyway) is that I now can see *why* git has the UI
that it does.

Now that I have learned to use bzr, I could probably wrap my head around
git :).

Jason