/srv/irclogs.ubuntu.com/2007/10/05/#bzr.txt

jelmerlifeless: git fetches within the minute, bzr with packs was still over 10 minutes last time I checked (about two weeks ago)12:05
lifelessinitial or incremental?12:05
jelmerinitial12:05
jelmerhaven't tried incremental12:05
fullermdI 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:06
jelmerthis is with rsync for git IIRC12:07
lifelessjelmer: well, you can rsync with bzr too12:07
=== jelmer ocmpares again with current versions
lifelessjelmer: my experiments with packs were about 20% slower than pure rsync12:08
lifelesswithout tree building12:08
lifelessand without the smart server12:08
jelmerhow fast would the smart server be with packs? same as without?12:09
jelmerlifeless: rsyncing is not the default though, requires a plugin and has a bunch of constraints12:09
lifelessjelmer: as many ops fall back to the VFS, packs will help12:10
jelmerlifeless: I understand what you mean, but people will compare them the way I do now12:10
lifelessjelmer: ok, so I need to know what you are doing :)12:11
=== 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
lifelesspoolie_phone: I have more reviews up :)12:50
=== 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
poolie_phonejelmer, lifeless, hi12:52
=== poolie_phone is now known as poolie
lifelessI'm going to try and merge Knit1 and Knit3 Repository classes today12:52
=== schierbeck [n=daniel@dasch.egmont-kol.dk] has joined #bzr
pooliejelmer, that is disappointing but thanks for letting us know12:53
pooliejelmer, do you know what the deciding factors were of git compared to hg?12:54
=== beuno [n=beuno@44-111-231-201.fibertel.com.ar] has joined #bzr
pooliegood idea01:00
poolielifeless, call?01:01
lifelessshure fing guv01:01
schierbeckhi guys01:02
jelmerlifeless: how fast should a local clone of a packs branch be?01:09
jelmerpoolie: hg didn't really seem to have any advantages over01:10
jelmergit01:10
jelmerslower, written in Python (a couple of us only know C), no submodules/nested trees afaik01:11
poolieright01:11
=== 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
lifelessjelmer: hg has 'forests'01:31
poolienot built in iirc01:43
=== orospakr_ [n=orospakr@bas4-ottawa23-1088826851.dsl.bell.ca] has joined #bzr
lifelesspoolie: right01:46
lifelesspoolie: I will come a-visiting I think01:46
poolieok01:46
lifelessI'm down to 2 methods01:47
lifelessabentley: ping01:48
lifelessabentley: whats the difference between inventory.revision_id and inventory.root.revision ?01:48
=== jkakar [n=jkakar@204-174-36-45.dhcp802.dsl.ucc-net.ca] has joined #bzr
abentleyIn rich-root trees, inventory.root.revision doesn't changes.  Inventory.revision_id is the revision_id of the inventory.01:53
abentleys/changes/change01:53
lifelessok01:53
lifelessso inv.revision_id is always the version of the inventory01:54
lifelessshould deserialise_inventory be asserting on that ?01:54
abentleyIt's not set in all inventory formats.  Some format 5, all 6 and 7.01:54
lifelessok01:54
lifelessI'm combining the Repository1 and 3 classes01:55
lifelessby pushing the variation out into the instance objects, and the xml serialiser01:55
lifelessthis makes it easier to do a new physical storage - packs - that has both non-and-rich-root variations01:55
abentleyThat seems confusing to me.01:55
abentleyBecause then you don't have a one-to-one relationship between formats and repository classes.01:56
lifelessI never intended that there should be a 1:101:56
abentleyWell, I certainly expect it.01:56
lifelessoh01:56
lifelesswell  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 definitions01:57
lifelessas well as being ugly IMO01:57
lifelessright 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:58
lifelesswhich 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 responsibilities01:59
abentleyWell, 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
lifelesshmm, if I change __repr__ to note the serializer that might make it more clear01:59
abentleyPartly is is because of my fear of dirstate.02:00
lifelessso if you saw KnitRepository(URL, xml5) and KnitRepository(URL, xml7) would that be clear enough?02:00
lifelesshmm, maybe not. I'll send up a draft patch for disucssion shortly02:00
lifelessabentley: thats a reasonable fear, I'm afraid and sorry02:00
lifelessdirstate is not my bestest code sample02:01
=== abentley is sorry for slacking.
lifelesswhat does xml6 add?02:01
abentleyShowing the serializer would certainly help.02:01
lifelessrich roots or subtrees?02:01
abentleyRich roots.02:01
lifelessok, down to one method02:02
lifeless+ test fallout02:02
lifelessok, class deleted.02:08
lifelessnow I bet things will break02:08
spivpoolie: heading off to your place now.02:11
poolieok02:13
lifelessok, full test running02:14
lifelesslooking good02:22
lifelessjelmer: so, is packs still 10 minutes?02:23
lifelessjelmer: got the repo up somewhere? how big is it?02:23
=== jrydberg__ [n=Johan@c80-216-246-123.bredband.comhem.se] has joined #bzr
lifelessah foo02:26
lifelessbasis xml creation is erroring :)02:26
lifelesscorrectly I think. hmm02:26
=== mw is now known as mw|out
=== jml_ [n=jml@ppp108-61.static.internode.on.net] has joined #bzr
lifelessabentley: why does workingtree2/3 use xml7? I didn't think they could handle its extra info02:44
lifelessspecifically they are trying to serialise an inventory with no root revision in xml7 format, and thats invalid02:44
lifeless(for their basis revision)02:44
abentleyThey don't use it for their main inventory, because that would store data they can't handle.02:45
abentleyAll inventory-based working tree formats use the same inventory format.02:47
abentleyFor the basis.02:47
=== pete__c [n=pete@015-850-358.area5.spcsdns.net] has joined #bzr
abentleyAt one point, there was a WorkingTree4 that was inventory-based, and it used xml7, and supported subtrees.02:47
lifelessok02:48
abentleySo all of the other basis-inventory formats were moved over to format 7.02:48
lifelessI'm off to catch a train02:48
lifelessI'll figure out whats going on on the train02:48
lifeless35 tests failed02:48
lifelesswhich is 7 per format02:48
lifelessso not a huge fraction02:49
abentleyAnd you want to know why more didn't fail? >:)02:49
lifelessbbiab02:49
lifelesswell02:49
lifelessI want a thread to start pulling on :)02:49
lifelessoh02:49
lifelesshave you thought about log-journaled inventories ?02:49
lifelessas a way to cheaply get smaller-io-during-commit, and remove the xml diff step02:49
abentleyThey're totally cache, so you can switch to a different format, if you like.02:50
lifelessbye for now!02:50
jelmerlifeless:03:11
jelmerBranched 13034 revision(s).03:11
jelmerPYTHONPATH=/usr/local/lib/svn-python LD_LIBRARY_PATH=/usr/local/lib =  branch  653,49s user 6,35s system 90% cpu 12:06,01 total03:11
=== 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
PengOkay, 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:18
lifelessPeng: yes04:24
lifelessjelmer: thats pack to pack ?04:25
lifelessjelmer: or knit to pack ?04:25
lifelessjelmer: if its pack to pack, I'm betting its our object validation04:27
lifelesswe're ungzipping the header of each thing we copy04:27
lifelessPeng: it should now feel quite a bit faster than knits to do things with04:30
=== orospakr [n=orospakr@bas4-ottawa23-1177562062.dsl.bell.ca] has joined #bzr
lifelessabentley: I had tests that were cheating a bit much04:33
=== 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
lifeless-Devil FTW05:56
ubotuNew bug: #149254 in bzr "diff creates inventory objects" [Undecided,New]  https://launchpad.net/bugs/14925406:06
lifelesstime to fix index parsing to do bisection06:54
lifelessshould shave 16% off incremental commits06:54
=== herzel104 [i=herzel@gateway/tor/x-7839520ec1bbe791] has joined #bzr
=== AfC [n=andrew@m610f36d0.tmodns.net] has left #bzr []
ubotuNew bug: #149270 in bzr "revisionspec in_history calls fetch, which requires the branch to be writable" [Medium,Confirmed]  https://launchpad.net/bugs/14927007:51
=== 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
mkanatWhat's a good bzr repo browser for the web?08:54
=== Mez [n=Mez@ubuntu/member/mez] has joined #bzr
spivmkanat: loggerhead09:16
mkanatspiv: Better than bazaar-webserve?09:16
spivmkanat: launchpad uses it, e.g. http://codebrowse.launchpad.net/~bzr/bzr/trunk/changes09:17
spivmkanat: I think so; the UI is a little more straightforward I think.09:17
mkanatspiv: Yeah, I saw that.09:17
mkanatspiv: I'm concerned because it hasn't had a release in so long.09:17
=== vila [n=vila@lec67-4-82-230-53-244.fbx.proxad.net] has joined #bzr
spivbazaar-webserve hasn't had a release recently either, afaik.09:18
=== g0ph3r [n=g0ph3r@p57A08CC6.dip0.t-ipconnect.de] has joined #bzr
spivBut loggerhead is actively being improved.  Just use trunk.09:18
spivmwhudson: ^ you should pester robey into doing a loggerhead release09:19
mkanatspiv: Okay, so if trunk is okay to use, that sounds good.09:19
mwhudsonspiv: releases are for wimps09:20
mwhudson:)09:20
spivmkanat: I believe it is.  Double-check with mwhudson, who looks after the launchpad system that uses it.09:20
spivAh, here he is, right on cue :)09:20
mwhudsonmkanat: this is the code that runs on launchpad now: https://code.edge.launchpad.net/~mwhudson/loggerhead/production09:21
mkanatmwhudson: Is that a modified branch, or just a branch from a particular point of loggerhead trunk?09:21
mwhudsoni'd definitely recommend using this code09:21
=== Mez [n=Mez@ubuntu/member/mez] has joined #bzr
mwhudsonif by trunk you mean robey's devel branch, then yes it has some changes robey hasn't merged yet09:22
mkanatmwhudson: Okay.09:22
mwhudsonin particular, it uses sqlite for its caches, not bdb09:23
mkanatmwhudson: Oh, awesome.09:23
mwhudsonwhich means it crashes far less often :)09:23
mkanatYeah. SQLite is love.09:23
mkanatAnd BDB is not love. :-D09:23
mwhudsonright09:24
mwhudsoni have a couple more things i want to do with loggerhead, then yeah, probably time for a release, indeed09:29
mwhudsonmkanat: how big are the branches you want to show?09:29
mkanatmwhudson: Oh, not that big.09:29
mkanatmwhudson: At least, not right now. No more than 6000 revisions.09:30
mkanatmwhudson: But most of them have 100 or so.09:30
mwhudsonprobably don't need the cache at all then09:31
mwhudsonthough that more depends on tree size than history size by now09:31
mkanatmwhudson: Is there an example config anywhere for hosting directly from Apache instead of by proxying to the TurboGears webserver?09:34
mwhudsonhow would that work?09:35
mwhudsonloggerhead is a turbogears app (for now, anyway)09:35
mkanatmwhudson: 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.09:35
=== fog [n=fog@debian/developer/fog] has joined #bzr
mwhudsonwell, i'm afraid i don't know either :)09:36
mkanatmwhudson: Okay. :-)09:36
mwhudsonwe run it via ProxyPass09:36
mkanatOkay, looks like that's the only good way to run it.09:40
mkanatI could run it through flup, but that'd be really complicated.09:40
mkanatThough probably faster or more stable.09:40
=== 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
mkanatmwhudson: Where does loggerhead.conf go?10:02
mwhudsonnext to loggerhead.conf.example10:03
mkanatmwhudson: Um, in the directory that I installed *from*?10:04
mwhudsonoh, you installed it? :)10:04
mkanatmwhudson: Ha, I figured it was Python, so...10:04
mwhudsoni've never done that, just run it from the checkout directory10:04
mkanatSo it just looks for it in whatever directory you run things from, I take it.10:05
mwhudsonmost likely10:05
mwhudsoni've not looked at this area of the code at all, sorry10:05
mkanatmwhudson: That's fine. :-)10:05
=== mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr
=== Zindar [n=erik@h188n1fls12o803.telia.com] has joined #bzr
mkanatmwhudson: Any idea what's up with "TurboGears requires autoreload.package to be set."?10:18
=== keir__ [n=keir@206-248-134-79.dsl.teksavvy.com] has joined #bzr
mwhudsonnope10:19
mwhudsonmkanat: what version of tg do you have?10:20
mkanatmwhudson: 1.0.110:20
=== 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
lifelessmwhudson: bzr is for wimps then10:32
mwhudsonlifeless: probably!10:32
=== sevrin [n=sevrin@ns1.clipsalportal.com] has joined #bzr
mwhudsonthere probably should be a loggerhead release fairly soon10:32
mwhudsonbut just not yet10:32
=== keir [n=keir@206-248-133-246.dsl.teksavvy.com] has joined #bzr
mkanatGreat, as soon as I connect to loggerhead it crashes.10:40
mkanatOh, no.10:40
mkanatBut something is wrong.10:40
mkanatI'll figure it out.10:40
mkanatAudagsdgkljdfa. Proxy doesn't work under SELinux. Have to find the right setting.10:47
mkanatYay, it's working. :-)10:53
mkanathttp://bzr.everythingsolved.com/browse/10:53
mkanatThere will be other things there, at some point.10:53
=== gabe [n=gabriel@91.84.56.254] has joined #bzr
mwhudsonmkanat: cool :)10:55
mkanat:-)10:55
mkanatmwhudson: Is there any way to make it actually overlap with the repo itself?10:55
mkanatmwhudson: So that you can check out from the same address you browse from?10:55
mwhudsonthat's an apache question really10:55
mwhudsonit should be possible10:55
mkanatYeah.10:55
mkanatI'm just trying to think of some reliable way to do it.10:55
mwhudsonserve .bzr off the filesystem, proxy everything else to loggerhead10:56
mkanatYeah.10:56
mkanatMaybe just FilesMatch.10:56
mwhudsoni'm sure we have a bug open on doing the same thing for launchpad10:58
mwhudsonbut i can't find it10:58
mwhudsonah https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/13755110:59
ubotuLaunchpad bug 137551 in launchpad-bazaar "code browsing should share url space with code hosting" [High,Confirmed] 10:59
mkanatAh, yeah, I could do it with rewrite, maybe.10:59
mkanatI could do it with Location, I just have to remember what the PCRE for "not" is.11:01
mkanatAh, (?!)11:03
mkanatI wonder if that'll work.11:03
mkanatYeah, no.11:05
=== jrydberg_ [n=Johan@c80-216-246-123.bredband.comhem.se] has joined #bzr
mkanatAnd now it's mysteriously stopped working. Wonderful.11:11
mkanatmwhudson: Any idea why it might start just fine but not take its port?11:15
lifelesswas the port not cleanly shutdown11:19
mwhudsonmkanat: look in the log file?11:19
mkanatlifeless: Yeah, that's possible. But netstat doesn't show anything holding it.11:19
lifelesstcp has this lovely behaviour of sitting in shutdown for a while11:19
lifelessnetstat -an ?11:19
mkanatmwhudson: Log file doesn't show anything about it.11:19
mkanat[root@control vhosts] # netstat -an | grep 808011:19
mkanat[root@control vhosts] #11:19
=== siretart [i=siretart@tauware.de] has joined #bzr
mkanatlifeless: Oh, maybe that was it, though.11:21
mkanatlifeless: Because now it seems to be working, I think...11:21
mkanatlifeless: Ahhh, yeah. :-)11:21
=== sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr
mkanatUm, and now the pid file disappeared. I assume this is why I had a TCP port in a bad state.11:22
mkanatBut the server's still running.11:22
mwhudsonthe whole startup/shutdown thing is a bit flaky tbh11:23
mwhudsonwhen testing i always run it ./start-loggerhead -f11:23
mkanatOkay.11:24
mkanatYeah, that's what I'm doing now.11:24
=== mvo_ [n=egon@p54A65B9A.dip.t-dialin.net] has joined #bzr
acusterlaunchpad.net's search function for "java" returns two copies of Sears12:04
acusterand several other projects...hmmm12:05
acusterlimewire-project12:06
acusterand12:06
acusterlimewire-client12:06
acusterbut from the ui they look the same12:06
=== Zindar [n=erik@stockholm.ardendo.se] has joined #bzr
=== jelmer_ [n=jelmer@157pc196.sshunet.nl] has joined #bzr
=== jelmer_ is now known as jelmer
jelmerlifeless: yes, that's packs to packs12:20
=== luks [n=lukas@unaffiliated/luks] has joined #bzr
mkanatmwhudson: Okay, weird bug!12:22
mkanatmwhudson: http://bzr.everythingsolved.com/12:22
mkanatmwhudson: Click on "trunk" for vci, and then "trunk" for bugzilla.12:22
mkanatmwhudson: 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
mkanatmwhudson: But add a / after "trunk" on bugzilla, and it works just fine.12:22
=== 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
lifelessjelmer: you might like to profile it and see where the time is going01:45
lifelessjelmer: especially if thats local disk01:45
=== 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
jelmerlifeless: yes, it is local disk02:02
jelmerlifeless: will do02:02
=== 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
salty-horseis there a web interface for the official bzr.dev repos?02:33
=== keir [n=keir@206-248-152-46.dsl.teksavvy.com] has joined #bzr
phanaticsalty-horse: check out on launchpad02:35
salty-horsegood idea. thanks02:35
phanaticsalty-horse: http://codebrowse.launchpad.net/~bzr/bzr/trunk/files02:36
salty-horsethanks02:36
=== mw|out is now known as mw
salty-horseI 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?02:40
=== mrevell-lunch is now known as mrevell
quicksilversalty-horse: unicode is a character numbering system02:43
quicksilversalty-horse: utf8 is a particular way of encoding that into bytes02:43
quicksilversalty-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 them02:43
salty-horseso 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:44
salty-horseback soon. answer at will :) (thanks)02:45
mwhudsonis it possible that bzr 0.91 disregards .ssh/config where bzr 0.90 did not?02:48
mwhudsonit does look rather that way :/02:53
mwhudsonhm, only a bit actually02:55
mwhudsonit seems to be ignoring the Port option only02:56
fullermdThat's known.02:57
mwhudsonok02:57
mwhudsonis there a bug report?02:58
fullermdI think so.  Just remember it being discussed last weekish.02:58
mwhudsonhttps://bugs.edge.launchpad.net/bzr/+bug/14671502:58
ubotuLaunchpad bug 146715 in bzr "bzr+ssh broken for non standard ports." [High,Triaged] 02:58
=== keir_ [n=keir@206-248-159-98.dsl.teksavvy.com] has joined #bzr
=== fog [n=fog@debian/developer/fog] has joined #bzr
lifelesssalty-horse: converting from bytes to unicode and back is slow03:26
lifelesssalty-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 parsing03:27
lifelesstreating bytes that are not unicode as unicode causes a slow implicit upcast in python 2.x03:28
salty-horsewhat 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
lifelessand 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:29
lifelessgenerally in our api's we either accept unicode strings, or we accept utf8 byte sequences but not both03:30
lifelessit depends on the api whether it is a character centric api or a byte centric api03:30
lifelessfor instance, transport.get_bytes is byte centric, so it returns bytes03:31
lifelessbut WorkingTree.commit(message='string here')03:31
lifelessthat string is expected to be unicode03:31
lifelessthis is another way of saying - we are using the built in python data types.03:31
salty-horseand the revision_id in the same function is expected to be utf803:31
salty-horsesee http://codebrowse.launchpad.net/~bzr/bzr/trunk/annotate/pqm%40pqm.ubuntu.com-20071005032619-b6c99y625rawducb?file_id=osutils.py-20050309040759-eeaff12fbf77ac86#L93603:31
jelmersalty-horse: all revision ids are expected to be byte strings - that's consistent throughout the code03:32
salty-horsejelmer, 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-horseI thought revision id's are TEXT strings, not binary data -- after all, they are printed as text in bzr log --show-ids03:34
jelmersalty-horse: afaik they can only contain ascii characters, nothing fancy but lifeless can probably correct me on that03:35
salty-horsejelmer, I think that's unlikely. why use utf8 instead of regular "binary data" str?03:36
=== sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr
jelmersalty-horse: ascii != utf803:37
lifelesssalty-horse: performance is the key reason03:37
jelmerlifeless: is it ascii or utf8?03:37
lifelessjelmer: revision ids are utf8 strings, with some limitations (no \n's for example)03:37
salty-horsejelmer, I'm well aware of that :)03:37
lifelesssalty-horse: are you writing a gui perchance ?03:38
salty-horselifeless, no. fixing deprecation warnings in the tailor bzr backend03:38
lifelessok03:38
lifelesswell, any revision id bzr generates is utf803:38
lifelessand will never be upcast to unicode by bzr itself03:38
lifelessany revision id you ask bzr to use must be utf803:39
salty-horsemy fix was this:03:39
salty-horsehunk ./vcpx/repository/bzr.py 28903: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
lifelessis tailor generating its own revision ids ?03:39
salty-horseyes. the last part you don't see is hexlify(rand_bytes(8))03:39
salty-horse(yes, *I think*) :)03:40
lifelessany reason not to use the bzrlib function to do this? :)03:40
=== salty-horse cheks
salty-horsec03:40
lifelessanyhow, in the limited context of fixing the deprecation warning, yes that fix is fine03:40
lifelessI don't know why tailor would need to generate revision ids though03:40
lifelessif you are committing, bzr will generate a revision id for you03:40
salty-horseI'll check with them to see if there's any reason -- I just starting hacking after seeing the warnings03:41
=== sabdf1 [i=sabdfl@nat/canonical/x-02b1fcf733789f05] has joined #bzr
jelmerlifeless: profile on local packs copy finished03:43
jelmerlifeless: appears _find_file_ids_from_xml_inventory_lines() is very expensive03:43
jelmerif I'm reading the output correctly03:43
jelmerlifeless: interested in the callgrind file?03:44
=== sabdf1 is now known as sabdfl
=== keir_ [n=keir@206-248-130-59.dsl.teksavvy.com] has joined #bzr
lifelessjelmer: hmm, its meant to be fast; yes I am.04:04
salty-horselifeless, 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 :)04:07
=== bitmonk [n=justizin@adsl-75-55-127-69.dsl.sfldmi.sbcglobal.net] has joined #bzr
fullermdPresumably it would also inject the current date, too.04:10
=== asak [n=alexis@201-26-52-53.dsl.telesp.net.br] has joined #bzr
salty-horsefullermd, seems like it uses the original commit timestamp04:15
=== beuno [n=beuno@44-111-231-201.fibertel.com.ar] has joined #bzr
=== mvo_ is now known as mvo
jelmerlifeless: sent04:26
=== 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
james_wit 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?07:52
=== 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
jelmerjames_w: no - but that should be done by the backend, anyway08:17
james_wjelmer: so there is no function I can call to check this for me?08:26
=== cypherbios [n=cyr@ubuntu/member/cypherbios] has joined #bzr
jelmerjames_w: imho knits should escape where necessary because these restraints are knit/weave-specific08:31
james_wjelmer: 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.08:37
=== 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
lifelessjames_w: what do you need?11:38
lifelessjames_w: the escape code is in bzrlib.store.*11:42
lifelessbut generally its a mistake to name backend files after user supplied data11:43
=== Demitar [n=demitar@c-212-031-182-147.cust.broadway.se] has joined #bzr

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!