Dulwich on Launchpad

[Jelmer Vernooij]

Hi Russel,

On Wed, 2010-03-03 at 10:09 +0000, Russel Winder wrote:
> 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.
Nothing has changed in that regard - it still will if your version of
Subversion doesn't support revision properties. If you do have a newer
version of Subversion it'll indeed use revision properties.

> > > 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.
That's not true. What I was saying in that email was that I sometimes
run "bzr push" to a Bazaar branch before I've stripped out the
Git-unrepresentable data as a side-effect of running "bzr dpush".

If I had consistently run "bzr dpush" before "bzr push" and never the
other way around you would never have to run "bzr pull --overwrite".

> [ . . . ]
> > 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"?
Yes, that would be the ideal solution - a somewhat specialized database
based on Bazaar standard file formats - but it would require a bit more
effort to implement than either SQLite or TDB.

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/687bb6e4/attachment.pgp