http://github.com/durin42/dulwich now has two branches: d42-send-fix: the send-pack fix along with some already-passing compat tests, for 0.6.0 d42-refactor-clients: the larger client refactor, for after 0.6.0, pending discussion
Peace, Augie On Thu, May 20, 2010 at 4:11 PM, Augie Fackler <[email protected]> wrote: > > On May 20, 2010, at 4:08 PM, Jelmer Vernooij wrote: > >> On Thu, 2010-05-20 at 15:33 -0500, Augie Fackler wrote: >>> >>> On May 20, 2010, at 3:16 PM, Jelmer Vernooij wrote: >>>> >>>> On Thu, 2010-05-20 at 13:07 -0500, Augie Fackler wrote: >>>>> >>>>> On Thu, May 20, 2010 at 12:13 PM, Jelmer Vernooij >>>>> <[email protected]> wrote: >>>>>> >>>>>> On Wed, 2010-05-19 at 20:12 -0500, Augie Fackler wrote: >>>>> >>>>> Wow, that was *totally* undocumented. Plus, the class hierarchy >>>>> totally implies something different. >>>> >>>> Yeah, it's bad it's not very well documented. All the more reason to >>>> be >>>> prudent in this area. :-) I'd also like to get it right this time, not >>>> end up having to change it for the next release again. >>> >>> Fair enough, I'll split those changes off into their own branch. FWIW, >>> the existing semantics of how you use any of the concrete GitClient >>> subclasses remains the same (although you *can* reuse the concrete >>> connections now and they'll behave rather than potentially crashing in >>> strange ways) - only the implementation details are different. The >>> refactor was motivated so that all of the protocol bits were in a >>> single place so it'll be trivial to write a non-compat mock-using test >>> for the client layer. >> >> Ok, that sounds reasonable. I'm not particularly tied to the current way >> in which bzr-git hooks in alternative SSH clients such as Paramiko as >> long as we can keep it working. >> >>>>> Yes please - I'm not terribly comfortable relying on dulwich at the >>>>> moment, since its development and release cycle has been fairly >>>>> opaque >>>>> (and things that break hg-git sometimes land without warning). >>>> >>>> Which things in particular have done this? I've tried to be careful >>>> about not breaking the important APIs or at least deprecating public >>>> APIs before removing them completely so I'd like to hear if we break >>>> things in hg-git. We've only broken bzr-git once since 0.4.0. >>> >>> Most recently the change from Tag.get_object to Tag._get_object broke >>> hg-git (I don't think that's released yet, but I only found it because >>> rctay send me a patch). >> >> That one was unfortunate; the recommended way of accessing that sort of >> information is through the property - in this case Tag.object; that >> property is implemented using _get_object. Tag.get_object was never >> intended to be public. That particular change was made for dulwich 0.3.0 >> though, a bit over a year ago. >> >> I think we've been a fair bit better about it since then. Generally we >> try to document API breakages in the commonly-used public APIs in the >> NEWS file. But again, please mention if you notice unexpected breakages >> - we do care about API compatibility. >> >>> Could be hg-git shouldn't have used that >>> function, but it'd be nice to have more warning that a release is >>> upcoming so that I can test it. I may also be mixing dulwich breakage >>> in my head with Mercurial breakage - I don't yet have a buildbot to >>> test hg-git against dulwich master continuously. >> >> Right, I'll make sure to announce that I'm going to do a release a some >> time before so other people have the opportunity to test. I might also >> do release branches so that trunk can stay open for more risky changes. > > Sounds great! > >> >>> To be completely fair, some of this is my fault for being a terrible >>> maintainer of hg-git, but I'm progressively getting more and more >>> frustrated with that codebase and am experimenting with alternative >>> approaches. >> >> I'm not sure I follow; alternatively approaches in what way ? > > Trying to have hg directly manipulate .git and not convert everything to > revlogs before allowing the user to get work done. In theory it'll work > great! > >> >>>>> Also, dulw...@lists doesn't count as public to my mind - almost >>>>> nobody >>>>> can see that, and membership is closed (I'm not even on it). I'd much >>>>> prefer either that list was open, or we conduct discussions on a >>>>> public list that everyone can see. >>>> >>>> I'm happy to do those sorts of announcements on dulwich-us...@. FWIW >>>> the >>>> archive for dulwich@ is open, it's just the team membership that is >>>> moderated. >>> >>> Why is the team membership moderated? What's the value in that?[0] It >>> seems like the ideal place to have development discussions without >>> doing so on the -users list (although at this point I'm not sure there >>> are users that aren't hacking on dulwich so maybe -users is fine). >> >> The dulwich team is the owner of the Dulwich project on Launchpad, and >> its members get notified individually when security bugs are reported, >> they can set the location of the main branch, purge bugs, upload ubuntu >> packages, etc. I've deactivated its mailing list for now in favor of the >> dulwich-users@ list. >> >>> I must have missed the list archives in the confusing UI of Launchpad. >> >> See the "View archive" link on http://launchpad.net/~dulwich. >> >> Cheers, >> >> Jelmer > > _______________________________________________ Mailing list: https://launchpad.net/~dulwich-users Post to : [email protected] Unsubscribe : https://launchpad.net/~dulwich-users More help : https://help.launchpad.net/ListHelp
