[12:05] <jelmer> lifeless: git fetches within the minute, bzr with packs was still over 10 minutes last time I checked (about two weeks ago)
[12:05] <lifeless> initial or incremental?
[12:05] <jelmer> initial
[12:05] <jelmer> haven't tried incremental
[12:06] <fullermd> I don't look to packs for the win there.  A carefully tuned layout on a dumb server will still get creamed by a reasonably competent smart server.
[12:07] <jelmer> this is with rsync for git IIRC
[12:07] <lifeless> jelmer: well, you can rsync with bzr too
=== jelmer ocmpares again with current versions
[12:08] <lifeless> jelmer: my experiments with packs were about 20% slower than pure rsync
[12:08] <lifeless> without tree building
[12:08] <lifeless> and without the smart server
[12:09] <jelmer> how fast would the smart server be with packs? same as without?
[12:09] <jelmer> lifeless: rsyncing is not the default though, requires a plugin and has a bunch of constraints
[12:10] <lifeless> jelmer: as many ops fall back to the VFS, packs will help
[12:10] <jelmer> lifeless: I understand what you mean, but people will compare them the way I do now
[12:11] <lifeless> jelmer: ok, so I need to know what you are doing :)
=== fog [n=fog@debian/developer/fog]  has left #bzr [] 
=== Mez [n=Mez@ubuntu/member/mez]  has joined #bzr
=== Mez [n=Mez@ubuntu/member/mez]  has joined #bzr
=== mwhudson [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk]  has joined #bzr
=== beuno [n=beuno@44-111-231-201.fibertel.com.ar]  has joined #bzr
[12:50] <lifeless> poolie_phone: I have more reviews up :)
=== beuno [n=beuno@44-111-231-201.fibertel.com.ar]  has joined #bzr
=== beuno [n=beuno@44-111-231-201.fibertel.com.ar]  has joined #bzr
=== beuno [n=beuno@44-111-231-201.fibertel.com.ar]  has joined #bzr
[12:52] <poolie_phone> jelmer, lifeless, hi
=== poolie_phone is now known as poolie
[12:52] <lifeless> I'm going to try and merge Knit1 and Knit3 Repository classes today
=== schierbeck [n=daniel@dasch.egmont-kol.dk]  has joined #bzr
[12:53] <poolie> jelmer, that is disappointing but thanks for letting us know
[12:54] <poolie> jelmer, do you know what the deciding factors were of git compared to hg?
=== beuno [n=beuno@44-111-231-201.fibertel.com.ar]  has joined #bzr
[01:00] <poolie> good idea
[01:01] <poolie> lifeless, call?
[01:01] <lifeless> shure fing guv
[01:02] <schierbeck> hi guys
[01:09] <jelmer> lifeless: how fast should a local clone of a packs branch be?
[01:10] <jelmer> poolie: hg didn't really seem to have any advantages over
[01:10] <jelmer> git
[01:11] <jelmer> slower, written in Python (a couple of us only know C), no submodules/nested trees afaik
[01:11] <poolie> right
=== poolfool [n=poolfool@techsat21.itnes.com]  has left #bzr [] 
=== orospakr [n=orospakr@CPE001c1019cfc4-CM0011ae034e04.cpe.net.cable.rogers.com]  has joined #bzr
=== jml [n=jml@203-113-250-169-static.TAS.netspace.net.au]  has joined #bzr
=== mthaddon [n=mthaddon@canonical/launchpad/mthaddon]  has joined #bzr
=== abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca]  has joined #bzr
[01:31] <lifeless> jelmer: hg has 'forests'
[01:43] <poolie> not built in iirc
=== orospakr_ [n=orospakr@bas4-ottawa23-1088826851.dsl.bell.ca]  has joined #bzr
[01:46] <lifeless> poolie: right
[01:46] <lifeless> poolie: I will come a-visiting I think
[01:46] <poolie> ok
[01:47] <lifeless> I'm down to 2 methods
[01:48] <lifeless> abentley: ping
[01:48] <lifeless> abentley: whats the difference between inventory.revision_id and inventory.root.revision ?
=== jkakar [n=jkakar@204-174-36-45.dhcp802.dsl.ucc-net.ca]  has joined #bzr
[01:53] <abentley> In rich-root trees, inventory.root.revision doesn't changes.  Inventory.revision_id is the revision_id of the inventory.
[01:53] <abentley> s/changes/change
[01:53] <lifeless> ok
[01:54] <lifeless> so inv.revision_id is always the version of the inventory
[01:54] <lifeless> should deserialise_inventory be asserting on that ?
[01:54] <abentley> It's not set in all inventory formats.  Some format 5, all 6 and 7.
[01:54] <lifeless> ok
[01:55] <lifeless> I'm combining the Repository1 and 3 classes
[01:55] <lifeless> by pushing the variation out into the instance objects, and the xml serialiser
[01:55] <lifeless> this makes it easier to do a new physical storage - packs - that has both non-and-rich-root variations
[01:55] <abentley> That seems confusing to me.
[01:56] <abentley> Because then you don't have a one-to-one relationship between formats and repository classes.
[01:56] <lifeless> I never intended that there should be a 1:1
[01:56] <abentley> Well, I certainly expect it.
[01:56] <lifeless> oh
[01:57] <lifeless> well  I'm happy to tackle it a different way, but its very awkward at the moment without multiple inheritance, which is problematic as most methods have base class definitions
[01:57] <lifeless> as well as being ugly IMO
[01:58] <lifeless> right now the only difference from knit 1 to 3 in the repository class is - self._serializer, self._commit_builder_class, and the two methods 'serialise_inventory' and 'deserialize_inventory'
[01:59] <lifeless> which is why it seemed clean to me to just make the first two things be passed to the constructor, and the latter two look like serializer responsibilities
[01:59] <abentley> Well, I don't want to interfere with you accomplishing things.  I've been slacking on getting rid of the need to hide rich roots.
[01:59] <lifeless> hmm, if I change __repr__ to note the serializer that might make it more clear
[02:00] <abentley> Partly is is because of my fear of dirstate.
[02:00] <lifeless> so if you saw KnitRepository(URL, xml5) and KnitRepository(URL, xml7) would that be clear enough?
[02:00] <lifeless> hmm, maybe not. I'll send up a draft patch for disucssion shortly
[02:00] <lifeless> abentley: thats a reasonable fear, I'm afraid and sorry
[02:01] <lifeless> dirstate is not my bestest code sample
=== abentley is sorry for slacking.
[02:01] <lifeless> what does xml6 add?
[02:01] <abentley> Showing the serializer would certainly help.
[02:01] <lifeless> rich roots or subtrees?
[02:01] <abentley> Rich roots.
[02:02] <lifeless> ok, down to one method
[02:02] <lifeless> + test fallout
[02:08] <lifeless> ok, class deleted.
[02:08] <lifeless> now I bet things will break
[02:11] <spiv> poolie: heading off to your place now.
[02:13] <poolie> ok
[02:14] <lifeless> ok, full test running
[02:22] <lifeless> looking good
[02:23] <lifeless> jelmer: so, is packs still 10 minutes?
[02:23] <lifeless> jelmer: got the repo up somewhere? how big is it?
=== jrydberg__ [n=Johan@c80-216-246-123.bredband.comhem.se]  has joined #bzr
[02:26] <lifeless> ah foo
[02:26] <lifeless> basis xml creation is erroring :)
[02:26] <lifeless> correctly I think. hmm
=== mw is now known as mw|out
=== jml_ [n=jml@ppp108-61.static.internode.on.net]  has joined #bzr
[02:44] <lifeless> abentley: why does workingtree2/3 use xml7? I didn't think they could handle its extra info
[02:44] <lifeless> specifically they are trying to serialise an inventory with no root revision in xml7 format, and thats invalid
[02:44] <lifeless> (for their basis revision)
[02:45] <abentley> They don't use it for their main inventory, because that would store data they can't handle.
[02:47] <abentley> All inventory-based working tree formats use the same inventory format.
[02:47] <abentley> For the basis.
=== pete__c [n=pete@015-850-358.area5.spcsdns.net]  has joined #bzr
[02:47] <abentley> At one point, there was a WorkingTree4 that was inventory-based, and it used xml7, and supported subtrees.
[02:48] <lifeless> ok
[02:48] <abentley> So all of the other basis-inventory formats were moved over to format 7.
[02:48] <lifeless> I'm off to catch a train
[02:48] <lifeless> I'll figure out whats going on on the train
[02:48] <lifeless> 35 tests failed
[02:48] <lifeless> which is 7 per format
[02:49] <lifeless> so not a huge fraction
[02:49] <abentley> And you want to know why more didn't fail? >:)
[02:49] <lifeless> bbiab
[02:49] <lifeless> well
[02:49] <lifeless> I want a thread to start pulling on :)
[02:49] <lifeless> oh
[02:49] <lifeless> have you thought about log-journaled inventories ?
[02:49] <lifeless> as a way to cheaply get smaller-io-during-commit, and remove the xml diff step
[02:50] <abentley> They're totally cache, so you can switch to a different format, if you like.
[02:50] <lifeless> bye for now!
[03:11] <jelmer> lifeless:
[03:11] <jelmer> Branched 13034 revision(s).
[03:11] <jelmer> PYTHONPATH=/usr/local/lib/svn-python LD_LIBRARY_PATH=/usr/local/lib =  branch  653,49s user 6,35s system 90% cpu 12:06,01 total
=== herzel104 [i=herzel@gateway/tor/x-0bf3a7d288d96448]  has joined #bzr
=== bitmonk [n=justizin@adsl-76-212-10-56.dsl.pltn13.sbcglobal.net]  has joined #bzr
=== yminsky [n=yminsky@user-0cevcqv.cable.mindspring.com]  has joined #bzr
=== bigdo2 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net]  has joined #bzr
[04:18] <Peng> Okay, so I just upgraded my copy of the pack branch to the new format, and I had to work around the bzr.dev index error. I branched bzr.dev as knits, upgraded to packs, and branched the repository branch from the web, and it worked. Was it supposed to?
[04:18] <Peng> (bzr.dev as in my local copy of it)
[04:24] <lifeless> Peng: yes
[04:25] <lifeless> jelmer: thats pack to pack ?
[04:25] <lifeless> jelmer: or knit to pack ?
[04:27] <lifeless> jelmer: if its pack to pack, I'm betting its our object validation
[04:27] <lifeless> we're ungzipping the header of each thing we copy
[04:30] <lifeless> Peng: it should now feel quite a bit faster than knits to do things with
=== orospakr [n=orospakr@bas4-ottawa23-1177562062.dsl.bell.ca]  has joined #bzr
[04:33] <lifeless> abentley: I had tests that were cheating a bit much
=== bitmonk_ [n=justizin@adsl-75-62-126-241.dsl.pltn13.sbcglobal.net]  has joined #bzr
=== jml_ is now known as jml
=== bitmonk_ is now known as bitmonk
=== mthaddon [n=mthaddon@canonical/launchpad/mthaddon]  has joined #bzr
=== AfC [n=andrew@m610f36d0.tmodns.net]  has joined #bzr
=== mvo [n=egon@p54A67E6B.dip.t-dialin.net]  has joined #bzr
[05:56] <lifeless> -Devil FTW
[06:06] <ubotu> New bug: #149254 in bzr "diff creates inventory objects" [Undecided,New]  https://launchpad.net/bugs/149254
[06:54] <lifeless> time to fix index parsing to do bisection
[06:54] <lifeless> should shave 16% off incremental commits
=== herzel104 [i=herzel@gateway/tor/x-7839520ec1bbe791]  has joined #bzr
=== AfC [n=andrew@m610f36d0.tmodns.net]  has left #bzr [] 
[07:51] <ubotu> New bug: #149270 in bzr "revisionspec in_history calls fetch, which requires the branch to be writable" [Medium,Confirmed]  https://launchpad.net/bugs/149270
=== keir_ [n=keir@206-248-133-65.dsl.teksavvy.com]  has joined #bzr
=== jml [n=jml@ppp121-44-215-97.lns1.hba1.internode.on.net]  has joined #bzr
=== hdima [n=hdima@idealer.cust.smartspb.net]  has joined #bzr
=== allenap [n=allenap@87-194-166-60.bethere.co.uk]  has joined #bzr
=== mkanat [n=mkanat@c-71-202-202-106.hsd1.ca.comcast.net]  has joined #bzr
[08:54] <mkanat> What's a good bzr repo browser for the web?
=== Mez [n=Mez@ubuntu/member/mez]  has joined #bzr
[09:16] <spiv> mkanat: loggerhead
[09:16] <mkanat> spiv: Better than bazaar-webserve?
[09:17] <spiv> mkanat: launchpad uses it, e.g. http://codebrowse.launchpad.net/~bzr/bzr/trunk/changes
[09:17] <spiv> mkanat: I think so; the UI is a little more straightforward I think.
[09:17] <mkanat> spiv: Yeah, I saw that.
[09:17] <mkanat> spiv: I'm concerned because it hasn't had a release in so long.
=== vila [n=vila@lec67-4-82-230-53-244.fbx.proxad.net]  has joined #bzr
[09:18] <spiv> bazaar-webserve hasn't had a release recently either, afaik.
=== g0ph3r [n=g0ph3r@p57A08CC6.dip0.t-ipconnect.de]  has joined #bzr
[09:18] <spiv> But loggerhead is actively being improved.  Just use trunk.
[09:19] <spiv> mwhudson: ^ you should pester robey into doing a loggerhead release
[09:19] <mkanat> spiv: Okay, so if trunk is okay to use, that sounds good.
[09:20] <mwhudson> spiv: releases are for wimps
[09:20] <mwhudson> :)
[09:20] <spiv> mkanat: I believe it is.  Double-check with mwhudson, who looks after the launchpad system that uses it.
[09:20] <spiv> Ah, here he is, right on cue :)
[09:21] <mwhudson> mkanat: this is the code that runs on launchpad now: https://code.edge.launchpad.net/~mwhudson/loggerhead/production
[09:21] <mkanat> mwhudson: Is that a modified branch, or just a branch from a particular point of loggerhead trunk?
[09:21] <mwhudson> i'd definitely recommend using this code
=== Mez [n=Mez@ubuntu/member/mez]  has joined #bzr
[09:22] <mwhudson> if by trunk you mean robey's devel branch, then yes it has some changes robey hasn't merged yet
[09:22] <mkanat> mwhudson: Okay.
[09:23] <mwhudson> in particular, it uses sqlite for its caches, not bdb
[09:23] <mkanat> mwhudson: Oh, awesome.
[09:23] <mwhudson> which means it crashes far less often :)
[09:23] <mkanat> Yeah. SQLite is love.
[09:23] <mkanat> And BDB is not love. :-D
[09:24] <mwhudson> right
[09:29] <mwhudson> i have a couple more things i want to do with loggerhead, then yeah, probably time for a release, indeed
[09:29] <mwhudson> mkanat: how big are the branches you want to show?
[09:29] <mkanat> mwhudson: Oh, not that big.
[09:30] <mkanat> mwhudson: At least, not right now. No more than 6000 revisions.
[09:30] <mkanat> mwhudson: But most of them have 100 or so.
[09:31] <mwhudson> probably don't need the cache at all then
[09:31] <mwhudson> though that more depends on tree size than history size by now
[09:34] <mkanat> mwhudson: Is there an example config anywhere for hosting directly from Apache instead of by proxying to the TurboGears webserver?
[09:35] <mwhudson> how would that work?
[09:35] <mwhudson> loggerhead is a turbogears app (for now, anyway)
[09:35] <mkanat> mwhudson: I'm not sure, really. :-) I don't know anything about TurboGears, but I'd assume that it could be run through WSGI or something.
=== fog [n=fog@debian/developer/fog]  has joined #bzr
[09:36] <mwhudson> well, i'm afraid i don't know either :)
[09:36] <mkanat> mwhudson: Okay. :-)
[09:36] <mwhudson> we run it via ProxyPass
[09:40] <mkanat> Okay, looks like that's the only good way to run it.
[09:40] <mkanat> I could run it through flup, but that'd be really complicated.
[09:40] <mkanat> Though probably faster or more stable.
=== bialix [n=chatzill@77.109.23.75]  has joined #bzr
=== acuster [n=acuster@89.7.90.220]  has joined #bzr
=== pbor [n=urk@79.1.87.42]  has joined #bzr
=== jrydberg_ [n=Johan@c80-216-246-123.bredband.comhem.se]  has joined #bzr
=== fog [n=fog@debian/developer/fog]  has left #bzr [] 
=== keir__ [n=keir@206-248-133-30.dsl.teksavvy.com]  has joined #bzr
[10:02] <mkanat> mwhudson: Where does loggerhead.conf go?
[10:03] <mwhudson> next to loggerhead.conf.example
[10:04] <mkanat> mwhudson: Um, in the directory that I installed *from*?
[10:04] <mwhudson> oh, you installed it? :)
[10:04] <mkanat> mwhudson: Ha, I figured it was Python, so...
[10:04] <mwhudson> i've never done that, just run it from the checkout directory
[10:05] <mkanat> So it just looks for it in whatever directory you run things from, I take it.
[10:05] <mwhudson> most likely
[10:05] <mwhudson> i've not looked at this area of the code at all, sorry
[10:05] <mkanat> mwhudson: That's fine. :-)
=== mrevell [n=matthew@canonical/launchpad/mrevell]  has joined #bzr
=== Zindar [n=erik@h188n1fls12o803.telia.com]  has joined #bzr
[10:18] <mkanat> mwhudson: Any idea what's up with "TurboGears requires autoreload.package to be set."?
=== keir__ [n=keir@206-248-134-79.dsl.teksavvy.com]  has joined #bzr
[10:19] <mwhudson> nope
[10:20] <mwhudson> mkanat: what version of tg do you have?
[10:20] <mkanat> mwhudson: 1.0.1
=== pbor [n=urk@host42-87-dynamic.1-79-r.retail.telecomitalia.it]  has joined #bzr
=== keir_ [n=keir@206-248-134-140.dsl.teksavvy.com]  has joined #bzr
[10:32] <lifeless> mwhudson: bzr is for wimps then
[10:32] <mwhudson> lifeless: probably!
=== sevrin [n=sevrin@ns1.clipsalportal.com]  has joined #bzr
[10:32] <mwhudson> there probably should be a loggerhead release fairly soon
[10:32] <mwhudson> but just not yet
=== keir [n=keir@206-248-133-246.dsl.teksavvy.com]  has joined #bzr
[10:40] <mkanat> Great, as soon as I connect to loggerhead it crashes.
[10:40] <mkanat> Oh, no.
[10:40] <mkanat> But something is wrong.
[10:40] <mkanat> I'll figure it out.
[10:47] <mkanat> Audagsdgkljdfa. Proxy doesn't work under SELinux. Have to find the right setting.
[10:53] <mkanat> Yay, it's working. :-)
[10:53] <mkanat> http://bzr.everythingsolved.com/browse/
[10:53] <mkanat> There will be other things there, at some point.
=== gabe [n=gabriel@91.84.56.254]  has joined #bzr
[10:55] <mwhudson> mkanat: cool :)
[10:55] <mkanat> :-)
[10:55] <mkanat> mwhudson: Is there any way to make it actually overlap with the repo itself?
[10:55] <mkanat> mwhudson: So that you can check out from the same address you browse from?
[10:55] <mwhudson> that's an apache question really
[10:55] <mwhudson> it should be possible
[10:55] <mkanat> Yeah.
[10:55] <mkanat> I'm just trying to think of some reliable way to do it.
[10:56] <mwhudson> serve .bzr off the filesystem, proxy everything else to loggerhead
[10:56] <mkanat> Yeah.
[10:56] <mkanat> Maybe just FilesMatch.
[10:58] <mwhudson> i'm sure we have a bug open on doing the same thing for launchpad
[10:58] <mwhudson> but i can't find it
[10:59] <mwhudson> ah https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/137551
[10:59] <ubotu> Launchpad bug 137551 in launchpad-bazaar "code browsing should share url space with code hosting" [High,Confirmed] 
[10:59] <mkanat> Ah, yeah, I could do it with rewrite, maybe.
[11:01] <mkanat> I could do it with Location, I just have to remember what the PCRE for "not" is.
[11:03] <mkanat> Ah, (?!)
[11:03] <mkanat> I wonder if that'll work.
[11:05] <mkanat> Yeah, no.
=== jrydberg_ [n=Johan@c80-216-246-123.bredband.comhem.se]  has joined #bzr
[11:11] <mkanat> And now it's mysteriously stopped working. Wonderful.
[11:15] <mkanat> mwhudson: Any idea why it might start just fine but not take its port?
[11:19] <lifeless> was the port not cleanly shutdown
[11:19] <mwhudson> mkanat: look in the log file?
[11:19] <mkanat> lifeless: Yeah, that's possible. But netstat doesn't show anything holding it.
[11:19] <lifeless> tcp has this lovely behaviour of sitting in shutdown for a while
[11:19] <lifeless> netstat -an ?
[11:19] <mkanat> mwhudson: Log file doesn't show anything about it.
[11:19] <mkanat> [root@control vhosts] # netstat -an | grep 8080
[11:19] <mkanat> [root@control vhosts] #
=== siretart [i=siretart@tauware.de]  has joined #bzr
[11:21] <mkanat> lifeless: Oh, maybe that was it, though.
[11:21] <mkanat> lifeless: Because now it seems to be working, I think...
[11:21] <mkanat> lifeless: Ahhh, yeah. :-)
=== sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl]  has joined #bzr
[11:22] <mkanat> Um, and now the pid file disappeared. I assume this is why I had a TCP port in a bad state.
[11:22] <mkanat> But the server's still running.
[11:23] <mwhudson> the whole startup/shutdown thing is a bit flaky tbh
[11:23] <mwhudson> when testing i always run it ./start-loggerhead -f
[11:24] <mkanat> Okay.
[11:24] <mkanat> Yeah, that's what I'm doing now.
=== mvo_ [n=egon@p54A65B9A.dip.t-dialin.net]  has joined #bzr
[12:04] <acuster> launchpad.net's search function for "java" returns two copies of Sears
[12:05] <acuster> and several other projects...hmmm
[12:06] <acuster> limewire-project
[12:06] <acuster> and
[12:06] <acuster> limewire-client
[12:06] <acuster> but from the ui they look the same
=== Zindar [n=erik@stockholm.ardendo.se]  has joined #bzr
=== jelmer_ [n=jelmer@157pc196.sshunet.nl]  has joined #bzr
=== jelmer_ is now known as jelmer
[12:20] <jelmer> lifeless: yes, that's packs to packs
=== luks [n=lukas@unaffiliated/luks]  has joined #bzr
[12:22] <mkanat> mwhudson: Okay, weird bug!
[12:22] <mkanat> mwhudson: http://bzr.everythingsolved.com/
[12:22] <mkanat> mwhudson: Click on "trunk" for vci, and then "trunk" for bugzilla.
[12:22] <mkanat> mwhudson: For some reason, the second produces a 404 in loggerhead (which then causes Apache to do weird things, but that doesn't matter).
[12:22] <mkanat> mwhudson: But add a / after "trunk" on bugzilla, and it works just fine.
=== AfC [n=andrew@mb70736d0.tmodns.net]  has joined #bzr
=== dennda [n=dennda@ubuntu/member/dennda]  has joined #bzr
=== arjenAU_ [n=arjen@ppp215-29.static.internode.on.net]  has joined #bzr
=== keir [n=keir@206-248-132-60.dsl.teksavvy.com]  has joined #bzr
=== gabe [n=gabriel@91.84.56.254]  has joined #bzr
=== cprov-out is now known as cprov
=== NamNguyen [n=namnt@cm38.delta196.maxonline.com.sg]  has joined #bzr
=== fog [n=fog@debian/developer/fog]  has joined #bzr
=== EtienneG [n=etienne@ubuntu/member/EtienneG]  has joined #bzr
[01:45] <lifeless> jelmer: you might like to profile it and see where the time is going
[01:45] <lifeless> jelmer: especially if thats local disk
=== mrevell is now known as mrevell-lunch
=== cfbolz_ [n=cfbolz@p54AB9246.dip0.t-ipconnect.de]  has joined #bzr
=== phanatic [n=phanatic@dsl5400C551.pool.t-online.hu]  has joined #bzr
=== cfbolz_ is now known as cfbolz
=== mw|out [n=mw@189.146.12.253]  has joined #bzr
[02:02] <jelmer> lifeless: yes, it is local disk
[02:02] <jelmer> lifeless: will do
=== niemeyer [n=niemeyer@200-138-54-64.ctame705.dsl.brasiltelecom.net.br]  has joined #bzr
=== salty-horse [n=ori@pdpc/supporter/active/salty-horse]  has joined #bzr
[02:33] <salty-horse> is there a web interface for the official bzr.dev repos?
=== keir [n=keir@206-248-152-46.dsl.teksavvy.com]  has joined #bzr
[02:35] <phanatic> salty-horse: check out on launchpad
[02:35] <salty-horse> good idea. thanks
[02:36] <phanatic> salty-horse: http://codebrowse.launchpad.net/~bzr/bzr/trunk/files
[02:36] <salty-horse> thanks
=== mw|out is now known as mw
[02:40] <salty-horse> I don't understand the warning here: http://codebrowse.launchpad.net/~bzr/bzr/trunk/annotate/pqm%40pqm.ubuntu.com-20071005032619-b6c99y625rawducb?file_id=osutils.py-20050309040759-eeaff12fbf77ac86#L936 - why pass a string that is then converted to unicode? why not allow unicode strings? also, why the difference between "Unicode" and "utf8"? .cache_utf8 converts between them, but why?
=== mrevell-lunch is now known as mrevell
[02:43] <quicksilver> salty-horse: unicode is a character numbering system
[02:43] <quicksilver> salty-horse: utf8 is a particular way of encoding that into bytes
[02:43] <quicksilver> salty-horse: I believe that, behind the scenes, python uses some variant of utf16 for 'unicode' strings, but ideally the programmer doesn't need to know how it's storing them
[02:44] <salty-horse> so why not accept python's generic unicode as a data type, and then convert it to whatever? why accept an 'str' type? (which is more restrictive, language-wise)
[02:45] <salty-horse> back soon. answer at will :) (thanks)
[02:48] <mwhudson> is it possible that bzr 0.91 disregards .ssh/config where bzr 0.90 did not?
[02:53] <mwhudson> it does look rather that way :/
[02:55] <mwhudson> hm, only a bit actually
[02:56] <mwhudson> it seems to be ignoring the Port option only
[02:57] <fullermd> That's known.
[02:57] <mwhudson> ok
[02:58] <mwhudson> is there a bug report?
[02:58] <fullermd> I think so.  Just remember it being discussed last weekish.
[02:58] <mwhudson> https://bugs.edge.launchpad.net/bzr/+bug/146715
[02:58] <ubotu> Launchpad bug 146715 in bzr "bzr+ssh broken for non standard ports." [High,Triaged] 
=== keir_ [n=keir@206-248-159-98.dsl.teksavvy.com]  has joined #bzr
=== fog [n=fog@debian/developer/fog]  has joined #bzr
[03:26] <lifeless> salty-horse: converting from bytes to unicode and back is slow
[03:27] <lifeless> salty-horse: we have to serialise at some point, and often we are serialising the same strings, so we cache the serialised result, and vice verca for parsing
[03:28] <lifeless> treating bytes that are not unicode as unicode causes a slow implicit upcast in python 2.x
[03:29] <salty-horse> what you do internally is fine - cache the conversions at will. my worry is the type of the passed argument. why insist on utf8 strings instead of the built-in python datatype? (or did I misunderstand your explanation somehow?)
[03:29] <lifeless> and this is bad when we want to write some exact representation to disk (which we need to do as we're exchanging data with different machines, so we need to be able to get the data back even if they are using code pages)
[03:30] <lifeless> generally in our api's we either accept unicode strings, or we accept utf8 byte sequences but not both
[03:30] <lifeless> it depends on the api whether it is a character centric api or a byte centric api
[03:31] <lifeless> for instance, transport.get_bytes is byte centric, so it returns bytes
[03:31] <lifeless> but WorkingTree.commit(message='string here')
[03:31] <lifeless> that string is expected to be unicode
[03:31] <lifeless> this is another way of saying - we are using the built in python data types.
[03:31] <salty-horse> and the revision_id in the same function is expected to be utf8
[03:31] <salty-horse> see http://codebrowse.launchpad.net/~bzr/bzr/trunk/annotate/pqm%40pqm.ubuntu.com-20071005032619-b6c99y625rawducb?file_id=osutils.py-20050309040759-eeaff12fbf77ac86#L936
[03:32] <jelmer> salty-horse: all revision ids are expected to be byte strings - that's consistent throughout the code
[03:34] <salty-horse> jelmer, to me it feels unintuitive to convert my strings from unicode to utf8 str's (the conversion is never lossy) just because you prefer one over the other (for the moment, it works, but with a deprecation warning)
[03:34] <salty-horse> I thought revision id's are TEXT strings, not binary data -- after all, they are printed as text in bzr log --show-ids
[03:35] <jelmer> salty-horse: afaik they can only contain ascii characters, nothing fancy but lifeless can probably correct me on that
[03:36] <salty-horse> jelmer, I think that's unlikely. why use utf8 instead of regular "binary data" str?
=== sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl]  has joined #bzr
[03:37] <jelmer> salty-horse: ascii != utf8
[03:37] <lifeless> salty-horse: performance is the key reason
[03:37] <jelmer> lifeless: is it ascii or utf8?
[03:37] <lifeless> jelmer: revision ids are utf8 strings, with some limitations (no \n's for example)
[03:37] <salty-horse> jelmer, I'm well aware of that :)
[03:38] <lifeless> salty-horse: are you writing a gui perchance ?
[03:38] <salty-horse> lifeless, no. fixing deprecation warnings in the tailor bzr backend
[03:38] <lifeless> ok
[03:38] <lifeless> well, any revision id bzr generates is utf8
[03:38] <lifeless> and will never be upcast to unicode by bzr itself
[03:39] <lifeless> any revision id you ask bzr to use must be utf8
[03:39] <salty-horse> my fix was this:
[03:39] <salty-horse> hunk ./vcpx/repository/bzr.py 289
[03:39] <salty-horse> -        revision_id = "%s-%s-%s" % (email, compact_date(timestamp),
[03:39] <salty-horse> +        revision_id = "%s-%s-%s" % (email.encode('utf8'), compact_date(timestamp),
[03:39] <lifeless> is tailor generating its own revision ids ?
[03:39] <salty-horse> yes. the last part you don't see is hexlify(rand_bytes(8))
[03:40] <salty-horse> (yes, *I think*) :)
[03:40] <lifeless> any reason not to use the bzrlib function to do this? :)
=== salty-horse cheks
[03:40] <salty-horse> c
[03:40] <lifeless> anyhow, in the limited context of fixing the deprecation warning, yes that fix is fine
[03:40] <lifeless> I don't know why tailor would need to generate revision ids though
[03:40] <lifeless> if you are committing, bzr will generate a revision id for you
[03:41] <salty-horse> I'll check with them to see if there's any reason -- I just starting hacking after seeing the warnings
=== sabdf1 [i=sabdfl@nat/canonical/x-02b1fcf733789f05]  has joined #bzr
[03:43] <jelmer> lifeless: profile on local packs copy finished
[03:43] <jelmer> lifeless: appears _find_file_ids_from_xml_inventory_lines() is very expensive
[03:43] <jelmer> if I'm reading the output correctly
[03:44] <jelmer> lifeless: interested in the callgrind file?
=== sabdf1 is now known as sabdfl
=== keir_ [n=keir@206-248-130-59.dsl.teksavvy.com]  has joined #bzr
[04:04] <lifeless> jelmer: hmm, its meant to be fast; yes I am.
[04:07] <salty-horse> lifeless, when having bazaar generate the id's, it will inject the email of the repository converter (tailor user), which may have nothing to do with the converted project. but there's no problem with that on #tailor, so it will be automatic :)
=== bitmonk [n=justizin@adsl-75-55-127-69.dsl.sfldmi.sbcglobal.net]  has joined #bzr
[04:10] <fullermd> Presumably it would also inject the current date, too.
=== asak [n=alexis@201-26-52-53.dsl.telesp.net.br]  has joined #bzr
[04:15] <salty-horse> fullermd, seems like it uses the original commit timestamp
=== beuno [n=beuno@44-111-231-201.fibertel.com.ar]  has joined #bzr
=== mvo_ is now known as mvo
[04:26] <jelmer> lifeless: sent
=== keir__ [n=keir@206-248-174-243.dsl.teksavvy.com]  has joined #bzr
=== keir__ is now known as keir
=== mthaddon [n=mthaddon@adsl-71-132-150-141.dsl.pltn13.pacbell.net]  has joined #bzr
=== mwhudson [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk]  has joined #bzr
=== AfC [n=andrew@ip67-91-236-171.z236-91-67.customer.algx.net]  has joined #bzr
=== g0ph3r [n=g0ph3r@p57A09EB0.dip0.t-ipconnect.de]  has joined #bzr
=== cprov is now known as cprov-lunch
=== p4tux [n=p4tux@189.169.95.23]  has joined #bzr
=== gabe [n=gabriel@91.84.56.254]  has joined #bzr
=== orospakr [n=orospakr@132.213.238.4]  has joined #bzr
=== herzel104 [i=herzel@gateway/tor/x-241d986b1bd4d5df]  has joined #bzr
=== cfbolz_ [n=cfbolz@p54AB9246.dip0.t-ipconnect.de]  has joined #bzr
=== michelp [n=michelp@166.129.16.112]  has joined #bzr
=== cprov-lunch is now known as cprov
=== Vernius [n=tomger@p508AE8FC.dip.t-dialin.net]  has joined #bzr
=== Mez [n=Mez@ubuntu/member/mez]  has joined #bzr
=== p4tux [n=p4tux@189.169.95.23]  has joined #bzr
[07:52] <james_w> it looks like safe_file_id doesn't check the characters contained within. Is there a check that the file-id is safe to use as a filename somewhere?
=== salty-horse [n=ori@pdpc/supporter/active/salty-horse]  has left #bzr ["Leaving"] 
=== BasicOSX [n=BasicOSX@216-250-187-201.static.iphouse.net]  has joined #bzr
=== BasicOSX [n=BasicOSX@216-250-187-201.static.iphouse.net]  has joined #bzr
=== cfbolz_ is now known as cfbolz
=== AfC [n=andrew@pool-70-22-178-205.bos.east.verizon.net]  has joined #bzr
=== marianom [n=marianom@ubuntu/member/marianom]  has joined #bzr
=== tchan1 [n=tchan@c-24-13-84-219.hsd1.il.comcast.net]  has joined #bzr
[08:17] <jelmer> james_w: no - but that should be done by the backend, anyway
[08:26] <james_w> jelmer: so there is no function I can call to check this for me?
=== cypherbios [n=cyr@ubuntu/member/cypherbios]  has joined #bzr
[08:31] <jelmer> james_w: imho knits should escape where necessary because these restraints are knit/weave-specific
[08:37] <james_w> jelmer: thanks. I am writing code that will put files on disk, so I wanted to know if there was something I could reuse. I can't find it for knits, but I'll keep looking.
=== schierbeck [n=daniel@dasch.egmont-kol.dk]  has joined #bzr
=== bitmonk [n=justizin@adsl-69-226-226-14.dsl.pltn13.pacbell.net]  has joined #bzr
=== p4tux is now known as gorozco-chauer
=== Gwaihir [n=Gwaihir@ubuntu/member/gwaihir]  has joined #bzr
=== AfC [n=andrew@pool-70-22-178-205.bos.east.verizon.net]  has joined #bzr
=== sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl]  has left #bzr [] 
=== michelp [n=michelp@69-30-72-119.dq1sf.easystreet.com]  has joined #bzr
=== cfbolz [n=cfbolz@p54AB9246.dip0.t-ipconnect.de]  has joined #bzr
=== gorozco-chauer is now known as gorozco
=== tchan1 is now known as tchan
=== Aninhumer [n=Barbara@87.113.14.26.plusnet.pte-ag1.dyn.plus.net]  has joined #bzr
=== hsn_ [n=chatzill@234.114.broadband5.iol.cz]  has joined #bzr
=== niemeyer [n=niemeyer@200-138-54-64.ctame705.dsl.brasiltelecom.net.br]  has joined #bzr
=== AfC [n=andrew@mc65f36d0.tmodns.net]  has joined #bzr
=== bitmonk [n=justizin@adsl-75-55-127-69.dsl.sfldmi.sbcglobal.net]  has joined #bzr
[11:38] <lifeless> james_w: what do you need?
[11:42] <lifeless> james_w: the escape code is in bzrlib.store.*
[11:43] <lifeless> but generally its a mistake to name backend files after user supplied data
=== Demitar [n=demitar@c-212-031-182-147.cust.broadway.se]  has joined #bzr