← Back to team overview

dulwich team mailing list archive

Re: First steps towards object consistency and connectivity tests.

 

Hi Dave,

On Tue, Apr 06, 2010 at 09:29:26AM -0700, David Borowitz wrote:
> Do you think we should move this discussion to an archived mailing list?
> There's dulwich-users, but I'm not sure if development discussion should go
> there. (But maybe it should.)
That's a good point. We already happened to have a dulwich mailing
list, but just hadn't used it. I've invited you onto the dulwich
developers team, that should allow you to get the mailing list mail.

> Also, I noticed that you merged some of my patches. Just give me a heads up
> when you're ready for the next set.
I'm ready for them now; I hope to process the remaining three from
your last batch tonight.

> On Mon, Apr 5, 2010 at 18:10, Jelmer Vernooij <jelmer@xxxxxxxxx> wrote:

> > > -Tweak Protocol to allow for reads that don't block when we try to
> > > read past the end of the socket stream (protocol.py, server.py)
> > > -Verify pack files as they stream (pack.py, server.py)
> > > -Check packs/repos for connectivity (repo.py)
> > > -Rework thin pack completion to avoid some errors (pack.py)
> > > -Various style and python2.4 compatibility cleanups (everywhere)

> Just to be clear, the above are all patches I've already written.
Ah, ok - I hadn't realized that. 

> I have a different set of things that I hope to work on in the future
> (which probably overlaps somewhat with your plans):
> -Shallow clone support.
> -Server logging framework.
> -gc/repack
> -Large packfile support.

> > Here's mine:

> > * Parser for git-am-style patches
> > * .git/config parser/editor
> > * Performance, in particular:
> >  * Efficient (in terms of performance and size) delta generation for
> > packs
> >  * Generating an index file while a pack file is being received, rather
> > than after the transfer
> This sounds like it will conflict with some of my changes to the
> receive-pack code (which is coming in the third group of patches). I have an
> object that reads individual object headers from the pack stream, checking
> that it inflates to the correct size, there are the right number of objects,
> and the trailer records the correct checksum. That seems like the right
> place to generate a pack index as well.
That sounds interesting; I'll hold off on the pack work for now.

> > >         I seem to've missed the first line on some of your patches
> > >         when applying
> > >         them upstream, sorry about that (I'm still applying these
> > >         patches
> > >         manually until I finish the support in Dulwich for parsing Git
> > >         patch
> > >         emails).

> > > No worries about the commit messages. Does git am not work with the
> > > emails I send, or are you just trying to use Dulwich as much as
> > > possible?
> > My main branch is actually a Bazaar/Git repository, maintained with
> > Bazaar and then pushed with bzr-git (which uses Dulwich heavily). It

> Well, that would explain it. Is there another format that's more convenient,
> like pushing to my github fork? Although I can see how the inconvenience of
> manually applying patches motivates you to add this support to dulwich :)
I'm intentionally using Bazaar here, I like eating my own dogfood and
it's a good incentive to work on finishing that patch. :-) I have a script 
that pushes to a Bazaar branch, a github branch and to git.samba.org. 

Cheers,

Jelmer