Dulwich on Launchpad

[Jelmer Vernooij]

Hi Russel,

On Wed, 2010-03-03 at 06:36 +0000, Russel Winder wrote:
> 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.
I'm not sure what change in the way bzr-svn metadata is stored you are
referring to - this hasn't changed in a while, and certainly hasn't
changed since dpush was introduced. If you're referring to revision
properties, these were supported before but require you to have a fairly
recent version of Subversion.

> 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 think you're confusing the workflow of keeping everything on mainline
that you use "bzr rebase" for with what "bzr dpush" is actually doing.
The first time you use "bzr dpush" it will strip out the metadata that
can not be represented in Git natively. After this, any calls to "bzr
dpush" will not change that particular revision since it's already lost
all non-Git-representable data. This doesn't prevent you from working
together with other people. 

> 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.
Dulwich has nothing to do with Bazaar. It is just a Python
implementation of the Git protocols/file formats.

> As a user, as soon as there is enforced rebasing, the perceived utility
> of the product drops to zero -- experience from Bazaar<->Subversion.
What about the enforced rebasing is so problematic?

> 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 (**).
I think it makes more sense to invest in alternative cache storing
mechanisms, e.g. using Bazaar packs etc. You can also use the SQLite
cache backend.

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20100303/879c9f0e/attachment.pgp