Dulwich on Launchpad

[Russel Winder]

John, Jelmer,

On Tue, 2010-03-02 at 18:30 -0600, John Arbash Meinel wrote:
[ . . . ]
> Jelmer does his work in a Bazaar branch. However, he also maintains an
> exact copy of the history in git. However, 'bzr-git' supports pulling
> but not pushing (it can convert git => bzr, but bzr=>git recreates the
> commits 'from scratch' in git).
> 
> So you can't 'bzr push git://...'. You *can* 'bzr dpush git://...' which
> recreates all of your commits into the git repo (rebase), and then pulls
> that data back into your Bazaar branch.
> 
> Basically:
> 
>  a) Jelmer codes in a bzr branch, but
>  b) the git rebased mirror is actually the 'official' trunk and
>  c) he mirrors that trunk back into his working bzr branch, which he
>  d) pushes to launchpad (or to the public bzr branch which is then
>     mirrored to lp)

Perhaps I am missing something, but this strikes me as very reminiscent
of the situation with bzr-svn a couple of years ago.  I pushed (!) for
Jelmer to add dpush for using Bazaar as a Subversion client -- I now
consider this to have been a mistake.  dpush was a lossy mechanism and
meant the Bazaar branches were only Subversion clients.  Jelmer then
fixed the way that Bazaar metadata was stored in the client and,
effectively, dpush became redundant -- I should have voted for this
action instead of implementing dpush in the first place.  Bazaar
branches can now push to a Subversion store with equanimity since all
needed metadata is present and the Subversion repository mbecomes a peer
in the Bazaar branch network.  This turns out to be the single biggest
thing in Bazaar's favour -- you can evolve a Subversion-based workflow
into a Bazaar-based workflow without having to have a revolution.

From the above (but this is my interpretation), Bazaar <-> Git is not
currently a function, it is, in effect, using the git-svn approach to
using Git as a Subversion client.  The git svn fetch/git svn dcommit
mechanism allows Git to be a Subversion client but does not allow for
that Git repository to be used sensibly in a peer group because of the
enforced rebase.  Git has not done what Jelmer has done for Bazaar
regarding Subversion, which leaves Bazaar in a unique position, a huge
USP.

I had thought that Dulwich was providing a bridge Bazaar <-> Git that
enabled a one-to-one relationship between Bazaar branches and branches
in a Git repository.  Clearly this is not entirely true or the rebasing
would not be necessary.

As a user, as soon as there is enforced rebasing, the perceived utility
of the product drops to zero -- experience from Bazaar<->Subversion.
Add to this the problem Linux has with mmap over NFS which means any
product using TDB is effectively useless (*) and it seems I must switch
back to using Git as my client for Git repositories (**).  I'll probably
leave the creating of Bazaar branches from Git repositories in place
where I am using it, and will report any problems as previously, but I
won't be actively using them.  Sorry.
  

(*) This is not fundamentally a problem for TDS, it is a Linux problem
that no-one in the Linux community seems bothered about -- perhaps
Canonical could redirect some effort into solving this blocking,
brickwall problem that has been around for ages.  As a user though I
don't care whose actual fault it is, it just means TDS is unusable in my
context (**).

(**) Whilst I suffer the hassles of having to avoid (***) the mmap/NFS
problem for using Bazaar when a Subversion store is involved because
Bazaar beats Subversion hands down for project version control, I am not
really willing to suffer this to use Bazaar with Git.  The rebasing
issue is just the "straw that broke the camel's back".  Sorry guys.

(***) The biggest problem is "bzr qlog".  With Git I can do "gitk --all"
and I have a incredibly useful display (despite looking appalling due to
the graphics toolkit in use) of the branch system and all remote
tracking branches.  This is the single biggest feature that makes Git
usable for managing a project, especially the display of the supposed
current state of remote tracking branches.  Bazaar has no concept of
remote tracking branches -- which is a real problem for me with Gant and
GPars -- but at least "bzr qlog" can give me a good rendering of a
shared repository.  Except that because on of the branches is the mirror
bound to the Subversion or Git remote repository, it takes about 2-4
hours or so for "bzr qlog" to render things -- except that on my laptop
it takes about 20s.  For the problem refer to (*).


Sounds a bit like a whinge, sorry.  Hopefully there are some positive
things for Bazaar to come out of this.

-- 
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel at russel.org.uk
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:russel.winder at ekiga.net
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder
-------------- 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/20100303/8be2854c/attachment-0001.pgp