Dulwich on Launchpad

[Russel Winder]

Jelmer,

On Wed, 2010-03-03 at 10:50 +0100, Jelmer Vernooij wrote:
[ . . . ]
> 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.

Originally bzr-svn used properties that got reported for each push
leading to potentially infinite commit reports.  This was then changed
to using properties that didn't get reported so all the Bazaar metadata
was handled silently.  From that moment on I used push and avoided
dpush.

[ . . . ]
> 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 need to reflect on this a bit as I am not instantly following your
point.  My problem I suspect.

[ . . . ]
> Dulwich has nothing to do with Bazaar. It is just a Python
> implementation of the Git protocols/file formats.

Apologies, I over-inferred the role of Dulwich.

> > 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?

It means that a simple "bzr pull" no longer works because the branches
have diverged.  I agree that "bzr pull --overwrite" does the job but it
seems overly heavy-handed.  Also it means that any local branching and
checking out from the branch is totally disrupted because the DAG
structure has changed.  Unless I am missing something . . . which is a
distinct possibility.

[ . . . ]
> 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.

SQLite has the problem of failing to allow multiple concurrent
conenctions to the same Subversion (or Git?) repository -- which is why
TDB in the first place.  I guess I should remove TDB and see what
happens.  (I guess the first connection will take hours for the creation
of the SQLite caches.)

You mention Bazaar packs, which indicates there may be a "third way"?

Thanks.

-- 
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/3d26cc31/attachment-0001.pgp