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

poolielifeless, what has regressed00:04
pooliejam-laptop, hi00:04
jam-laptophi00:04
jam-laptoppoolie: 'bzr update' in a checkout00:04
pooliethe error for trying to commit to a readonly branch?00:04
lifelesspoolie: no00:04
pooliewhat jam said00:04
lifeless'bzr checkout http://people.ubuntu.com/~robertc/pack-repository.knits', wait while I push a new rev, 'bzr update' && boom00:05
lifelessI know you looked at this00:05
poolieiirc there is still a bug open on it00:05
pooliei haven't fixed it00:05
lifelessoh, ok.00:05
lifelessipso facto I was confusedo00:05
poolieit may have been working at some time in the past00:05
pooliebut, it wasn't tested :)00:05
pooliei have written some format docs on packs00:06
pooliewill send them shortly00:06
poolieand have done the non-structural review cleanups00:06
pooliei am going to see whether the structural cleanups i wanted can be done easily or not00:06
poolieif not easy, they can just be turned into todos or bugs or forgotten maybe00:07
pooliejam-laptop, ll may have already suggested it, but00:07
dashoh. is --forget-merges not in 0.91 either? :(00:07
pooliemaybe you would look at making interpack fetch make sure that the text delta basis is in the destination00:07
nDuff...odd, initial incremental commit is acting like it isn't using the C extension -- massive amounts of CPU time used while collecting changes.00:08
pooliedash, it'll be in 0.9200:08
dashi guess I can just write my own script for now00:09
lifelessrevno 2000 merged support for --lightweight with http checkouts00:09
dash=/00:09
lifelessdash: heh, sorry :)00:09
lifelessand 2019 claimed to fix it for heavyweight checkouts :(00:10
lifelessok no its right00:10
lifelessthere have been no commits that claim to make heavyweight checkout updates work over http00:10
lifeless2088 did that for lightweight, so I'd say it was a 'just worked' thing initially00:11
dashhuh. after "bzr revert" i'm not seeing a pending merge. i guess that's sufficient.00:12
lifelessjam-laptop: what do you think of a dirstate iterator which _sha_from_stat advances, in commit ?00:12
lifelessdash: you'll also have lost your changes ...00:12
dashlifeless: which is OK00:13
nDufflifeless: 15m52s wall-clock for first incremental, 15m27s of that being user time.00:13
lifelessnDuff: that really is suspect isn't it.00:13
lifelessdo we list the C extensions anywhere yet ?00:13
=== mw is now known as mw|out
lifelessnDuff: when it went faster before, how fast was it ?00:14
lifelesspoolie: call ?00:15
pooliein 5m?00:15
lifelesssure00:15
nDufflifeless: out of my scrollback buffer right now, sadly, and I didn't record it. that said, recommit (of the same thing that just took ~16min) is completing in 1m52s.00:18
lifelessgrah00:18
lifelessthe only thing that makes sense to me is the C extensions not being picked up00:18
lifelessperhaps we should make that a nag00:19
nDuff...hmm. seems odd that it would happen only on initial incremental commit and not on recommit. Is there significant work done (prone to throwing an exception based on tree state) while the module is first being loaded?00:20
* nDuff looks at the code, and yeah -- looks like only an ImportError should result in fallback.00:24
nDuffwould trace.mutter() append to .bzr.log under normal conditions, or should I be doing something else to instrument?00:25
* nDuff looks in trace.py, and decides that warning() is more appropriate to the case anyhow.00:26
nDuff1m11s initial commit; 12.2s status w/ bad cache (and new files unknown), 7.6s status with good cache (and new files unknown), 25.4s to add unknowns, 12.1s/9.9s initial/subsequent status after adding unknowns... and now the 15min incremental commit isn't reproducing itself.00:36
igcmorning all00:37
jam-laptoplifeless: would you use a full iterator, or just another "this was the last cached lookup" like you just added00:40
lifelessnDuff: trace.mutter does to th elog00:41
lifelessjam-laptop: I'm thinking a full generator. Basically lsprof is claiming 10% in _get_entry00:42
jam-laptoplifeless: I would wonder if it could actually keep exactly in sync with commit00:42
jam-laptop(partial commits, etc have an effect here)00:42
lifelessjam-laptop: an alternative would be an equivalent of inventory.iter_entries_by_dir(specific_file_ids=XXX)00:42
lifelesswith yield_parents=True00:43
jam-laptopiter_entries_by_dir() seems like a good route to me00:47
nDuff...hrm, cancel that; still a 15 minute commit, and none of the logging directives I put in in case of an ImportError on the C modules triggered. Time for a callgrind run, I suppose.00:48
nDuffappears to get slower near the end of the change-collection process, incidentally.00:58
lifelessjam-laptop: the iter_entries_by_dir will need to return the disk data; thats really the disconnect we're dealing with.01:00
lifelessjam-laptop: I don't think this is a 2-day piece of code; particularly with win32 sadness.01:00
lifelessjam-laptop: so I'll send a mail right now01:00
jam-laptopwell, the _sha_sum... do you honestly think that would be reasonable?01:00
jam-laptopIt just seems like it is iterating at a very different layer01:01
jam-laptopand you are expecting it to stay in sync01:01
jam-laptopI suppose if you pass in the path01:01
jam-laptopand you know you are always "incrementing" in path01:01
jam-laptopthen it can fast forward until it finds what you need01:01
lifelesswell01:01
jam-laptopBut we don't have plain python generators that take more data01:01
lifelesswe don't need one01:02
jam-laptop(until 2.5 or later)01:02
jam-laptopI guess _sha_... could do the fast forwarding01:02
lifelessiter_entries_by_dir on inventory returns inventory objects01:02
lifelesswe need one that returns the key fields and the path_content_summary details01:02
lifelesshmm01:03
lifelessI'll test doing a cache lookup; one second01:03
lifelessjam-laptop: hmm, do I need to update the _id_index in my update_basis patch ?01:08
lifelessjam-laptop: I'm just building a dict of all the stats01:14
lifelessjam-laptop: won't be so hot for partial commits, but ...01:14
lifelesspossibly a threshold of lookups to trigger changing form01:15
lifelessnDuff: commit feedback is per-dir, if you have larger dirs at the end that would explain the apparent slowdown, or it may be list accumulation overhead01:16
lifelessstill, its two seconds faster on incremental commits01:17
lifelessinitial commit down to 1m2901:21
lifelesswall clock :001:21
nDufflifeless: I've got a .callgrind file; anywhere particular you'd like it uploaded?01:30
lifelessmail me or give me a url01:30
lifelessthey gz well01:30
nDufflifeless: in the mail.01:34
lifelessthanks!01:34
jam-laptoplifeless: I don't think you want to try to update _id_index, since there is too much stuff going on (some entries will be in the removed parents, etc)01:39
jam-laptoplifeless: But you probably should reset it01:39
jam-laptopI think self._id_index = None is fine01:39
lifelessnDuff: holy fuck. is_inside_any is taking 90% time01:47
lifelessnDuff: what parameters did you give commit ?01:47
nDufflifeless: bzr arguments: [u'--lsprof-file', u'../upstream-portage-tree.current.first_incremental_commit.callgrind', u'commit', u'-m', u'first incremental commit', u'--quiet']01:48
lifelessnDuff: do you have many deleted paths ?01:48
nDuffprobably; let me check.01:48
lifelessthats likely it01:49
lifelessis_inside_any is not that cheap; my strategy to date has been to avoid calling it as much as possible.01:49
lifelesslooks like we need a smarter structure than linear searching. e.g. bithection01:49
lifelessbrb, food time01:49
lifelessjam-laptop: another dirstate patch for your consideration :)01:50
nDufflifeless: 8045 removes, 35597 adds, 24211 modifications.01:52
lifelessnDuff: that will be it01:52
lifelesswe could make this a list01:52
lifelessdeletes[bisect_left(deletes, path)].starts_with(path)01:53
lifelessor a dict matching the tree structure01:53
lifelessjam-laptop: ^ I think bisect is probably good enough, or possibly even best.01:53
lifelesswe're going to have to do 100K lookups into this01:53
poolielifeless, pack doc sent01:54
lifelessanother thing is we know when we're going to have to lookup again - when we add a delete, or when we change directory01:54
lifelessnDuff: Anyhow, I a) know where the problem lies, b) can definately fix it.01:54
nDuffnifty!01:54
lifelessnDuff: its the number of deletes that you have in your tree during the commit.01:54
lifelessthank you for the callgrind01:54
nDuffnp. thank *you* for putting up with all my fumbling around.01:55
nDuffknow when you might have a chance to address this one? if it'll be a while, I'd like to open a ticket so I can get notice after it's happened.01:57
lifelessplease open a ticket01:57
lifelessit may not be a while01:58
lifelessbut its worth noting01:58
lifelessI've put the stat cache improvements into pack-repository.knits too, revno....01:58
lifeless285301:59
AfCIn my Darcs days, this sort of thing would trigger the Red Giant bug, but since it was exponential you could usually get around it be making smaller commits with less files/deletes/whatever. Would that be the case here?01:59
AfC[Not that you really want to bandy that about]01:59
lifelessAfC: nah, I'll just fix it01:59
lifeless:)02:00
nDufflifeless: https://bugs.launchpad.net/bzr/+bug/15649102:05
ubotuLaunchpad bug 156491 in bzr "bzr-packs: commit with many deletes spends much time in is_inside_any" [Undecided,New]02:05
fullermdThat's no fun.  It's hard to feel like your software is working hard, if you don't have to occasionally pander to it.02:05
spivfullermd: ah, so you recommend that our tool should be so bad it causes stockholm syndrome? :)02:06
fullermdWell, there are people still using arch...   _you_ connect the dots   :p02:07
nDufflifeless: btw, I'm curious, if the explanation is accessible to folks who don't know the codebase -- why is this case hit only on an initial commit, but not on a recommit or other operations which need to determine what is scheduled to be committed/deleted/etc (ie. status)?02:07
ubotuNew bug: #156491 in bzr "bzr-packs: commit with many deletes spends much time in is_inside_any" [Undecided,New] https://launchpad.net/bugs/15649102:10
pooliespiv, hi02:11
spivpoolie: good morning02:13
lifelessnDuff: well, its hit on the first incremental case02:13
lifelessnDuff: when both FOO and all the children of FOO are deleted, we like to report only 'FOO deleted'02:14
lifelessthats a significant factor in this02:14
lifelessnDuff: I'm going to review a patch then do the changes review asked for in one of my patches02:16
lifelessthen I'll see what I can do about this02:16
nDuffgraci02:17
* nDuff wanders off to do some clustering work.02:17
pooliespiv, wow, you're right02:29
pooliei thought i'd checked that this revision was referenced by its own inventory but in fact it is not02:29
* lifeless grins02:29
pooliewhich is why it's good to check02:30
spivpoolie: yeah.  That had me confused for while :)02:30
spivI'd assumed that if its own inventory didn't refer to it, then no others could.02:31
lifelessspiv:  in theory that is right.02:31
lifelessspiv: I suggest making 'bad' into a fulltext for now,02:32
lifelesswith inventory reassembly in the future.02:32
spivlifeless: right.  But reconcile of course is dealing with broken files...02:32
lifelessthis is oooold data02:32
spivlifeless: ah, that's a clever idea.02:32
spivinventory reassembly is going to be very slow without a fair bit of effort I fear :/02:32
lifelessright02:32
lifelessnot to mention hard02:33
spivHmm, I think I can see how to do it reasonably efficiently.02:33
poolieso just making it a fulltext is not, by itself, going to totally exclude this problem02:34
poolieas we talked about on the phone02:34
spivBut it's not a trivial amount of work...02:34
spivpoolie: why's that?02:35
pooliecall one of the revisions that references it "bad"02:36
poolieum, "dependant" (typo)02:37
pooliesuppose the destination already has the revision "bad"02:37
poolieit probably won't have known to pull that text version02:37
pooliethen, when it comes to pull "dependent" it will think it doesn't need to pull the text version02:37
spivI see.02:38
lifelesspoolie: but ifi t has bad already, then it has the text already.02:39
spivYou're now doing checks when pulling to make sure the parent is available, though?02:39
lifelesspoolie: *if it has bad already*.02:39
spivSo this would only happen if the repo was constructed before you added those checks?02:39
lifelessIMO yes02:39
poolielifeless, are you sure it will have detected to copy this text when pulling 'bad', even though it's not apparently modified?02:41
pooliei guess this is easy to test02:42
lifelessI guess we're talking slightly different corner cases.02:42
lifelessWhat I'm trying to say is 'if andrew makes the text a full text we will not encounter headaches with bzr.dev'02:42
pooliewell, that would be good for now02:44
poolieeven if it may not cover every case02:44
lifelessgarh bloody lawn mowers02:45
lifelessjam-laptop: good call on the parent swap test; found a bug02:47
lifelessjam-laptop: ping though02:48
lifelesspoolie: doco reviewed02:51
pooliethanks!02:53
pooliere your last point about the pack-names file02:53
lifelessigc: can yu review 'use a dict to access stat cache' ?02:54
pooliethe requirement is that, every pack listed there must exist02:54
lifelessigc: also, what part of commit are you hacking on at the moment, so we don't collide.02:54
lifelesspoolie: yes, every pack in that file must exist. Every pack that exists *may* be in that file.02:54
pooliebut it is possible to have a window where about-to-be-removed packs are present but not listed02:54
igclifeless: I'll review that soon02:54
lifelesspoolie: also during insert, we put the pack before we add to the names list.02:54
poolieso, you could recreate it, but this might be reintroducing redundant copies of the file02:54
poolieoh i was going to mention the file sizes too02:55
lifelesspoolie: but in that case its arguable that we should add them if we were to notice.02:55
igcI'm currently working on bug 11560102:55
ubotuLaunchpad bug 115601 in bzr "no clean abort after bzr+ssh:// connection timeout. ERROR: exceptions.AssertionError: end of file reading from server." [High,Confirmed] https://launchpad.net/bugs/11560102:55
igcas requested by poolie02:55
lifelessigc: coolio :)02:55
igccode done - just the tests to do now02:55
lifelesspoolie: You might also be introducing inconsistent data in a post-reconcile scenario02:55
lifelesspoolie: or data that is being deliberately removed.02:55
lifelesspoolie: so I'd really encourage the concept that 'the pack-names file is authoritative, precious, and not reconstructable'02:56
pooliesure02:57
pooliethat's just the kind of thing i want to capture02:57
pooliei guess for the iix it is graph parents first too, then compression base02:57
poolielike for tix?02:58
lifelessyes02:58
lifelessI should have been more explicit02:58
poolienp02:58
pooliejust brain slippage, i had seen them in the other order02:58
=== kiko is now known as kiko-zzz
* igc food03:30
poolielunch for me too.03:46
spivGood idea.03:50
* spiv -> food03:50
=== mneptok is now known as mnepette
=== mnepette is now known as mneptok
indravenihi all05:41
lifelesshi05:41
indravenii have configured the loggerhead as per my bzr branch05:41
indravenibut now i am not knowing how i can view it through the browser05:41
indravenihow to configure it in apache web server05:42
i386http://dharmatech.onigirihouse.com/atari-forth.jpg05:45
poolielifeless, i'm not so sure that having unlock raise an error if a write group is underway is the best thing, as i said in my review05:46
pooliei have another reason which is that it tends to hide errors05:46
poolieto raise exceptions from things expected to be called from finally blocks05:47
lifelesspoolie: fair enough, I can buy that, though its good from a correctness point of view05:48
lifelessperhaps a debug option or smething05:48
poolieor a warning, which can be caught by -Werror05:49
igclifeless: I'll review the 'dict to access stat cache' patch now05:52
indravenii need help in setting up loggerhead05:57
poolieindraveni, is there really no documentation?05:57
lifelessis there documentation is loggerhead itself?05:57
indravenipoolie, i couldn't find any good document05:58
poolieindraveni, mwh is the new maintainer, he should be online in a bit05:58
indraveniexcept the commented content in the conf file05:58
indraveniok05:58
lifelesstheres no README? or INSTALL?05:58
indravenilifeless, there is a README which says05:59
indravenithat everything is similar to Tubergears05:59
indraveniand i dont have experience with tubergears05:59
indraveniand for apache conf some steps are given, but i am not able to udnerstnad how it works05:59
lifelesswell06:02
lifelessAIUI turbogears can run as its own webserver or as a fastcgi script06:02
lifelessyou can probably find out more via google06:02
* nDuff is generally familiar with turbogears.06:03
nDufftypically, you've got a file start-<yourproject>.py, and a config file with all your installation-specific settings06:04
nDuff...so starting the server is along the lines of running "start-<yourproject>.py foo.cfg"06:04
nDuffcan't say anything about loggerhead specifically, though.06:04
nDuffif you're running through apache, of course, it gets more complicated (unless you're doing it the easy way and using mod_proxy).06:05
nDufflifeless: hmm, just tried pushing from my local (packs-based) tree to a "bzr serve" instance on the LAN (working against a packs-based shared repo). bzr: ERROR: Could not understand response from smart server: ('error', "<bound method GraphKnitRepository.leave_lock_in_place of GraphKnitRepository('chroot-47750944724688:///.bzr/repository/')>")06:08
lifelessnDuff: oh, looks like bad marshalling.06:09
nDufffull stack trace from the server at http://pastebin.com/d26bd26fa06:09
lifelessplease file a bug06:09
lifelessit won't be hard to fix, the problem is that this is an optional method, and one that packs don't support06:09
lifelessbecause they don't use the previous locking model.06:10
nDufflifeless: https://bugs.launchpad.net/bzr/+bug/15654606:14
ubotuLaunchpad bug 156546 in bzr "unable to push to packs-based smart server" [Undecided,New]06:14
lifelessthanks!06:15
ubotuNew bug: #156546 in bzr "unable to push to packs-based smart server" [Undecided,New] https://launchpad.net/bugs/15654606:21
lifelessspiv: ^06:25
lifelessok, think I have the pieces put back together again.06:27
lifelessone more run then onto nDuff's performance issue06:27
lifelesspoolie: spiv: I think it would be nice to have some way to be sure the remote server handles optional protocols (like leave_lock_in_place) correctly06:28
pooliedo you mean a way to test it?06:38
=== jkakar_ is now known as jkakar
sabdflmorning all06:48
pooliehi sab06:49
lifelesshi sabdfl06:50
igchi sabdfl06:51
igclifeless: review sent to the list now06:53
lifelesspoolie: is it ok to merge the stat lookup via dictionary patch ?06:56
lifelesspoolie: thats the 5 second win on incremental commit06:57
* poolie looks06:57
pooliei'd like to merge the pack branch with the small changes, then put the larger ones up for separate review06:58
poolieok?06:58
lifelesswell this is a trivial change06:58
lifelessnot packs per se06:58
igcand I've reviewed it poolie06:58
lifeless''trivial'' conceptually, code wise its something like 20 lines06:58
lifelessright, I'm asking you with your RM hat.06:59
poolieit looks ok to me06:59
pooliesure06:59
lifelesspoolie.hats().switch("RM")06:59
lifeless:)06:59
lifelessbbiab07:04
pooliepacks branch sent up07:06
lifelessto pqm ?07:08
poolieyes07:09
lifelessawesome07:09
vila_tada !07:09
poolieindeed07:09
lifelesssabdfl: ^^^ :)07:09
spivWoo!07:09
* vila_ send some champagne07:10
lifelesspoolie: does it have the same disk format string ?07:11
=== vila_ is now known as vila
poolieyes, still the same07:11
poolieand still just called 'experimental'07:11
lifelessok07:12
poolieis there any test framework support for checking that an assertion other than a deprecationwarning is raised?07:12
poolie(obviously the format and name needs to be changed)07:12
sabdfl*pop* goes the champagne :-) great work lifeless et al07:14
pooliehm that kind of sucks, the python warning module does not make it very easy to catch them07:15
lifelessI'll wait till friday for the champagne :)07:15
poolieqantas champagne?07:15
lifelessno, but we're all together friday night07:15
lifelessFSVO friday :)07:15
lifelessalso I don't think we get champagne in economny class :(07:16
igchi hi hooray lifeless - well done07:24
ubotuNew bug: #156557 in bzr "Bazaar does not obey setgid on Linux" [Undecided,New] https://launchpad.net/bugs/15655707:25
lifelesscurrent figures are stable - 1m31 wall initial commit, 0m15 incremental, 0m10 partial07:29
EzeeGuyhello07:31
lifelesshello07:33
=== jamesh_ is now known as jamesh
lifelesspoolie: you forgot kthxbye on your commit message :)07:48
poolieheh07:48
pooliei should have07:48
lifelesslooks like it's copacetic though, deep in the ascii tests07:48
pooliehuh?07:49
lifelessit looks like it will land and not bounce07:49
pooliehttp://en.wikipedia.org/wiki/Copasetic07:50
lifelessyes, thats the definition07:53
lifelessrighto, I forgot I was going out tonnight07:53
lifelessciao07:53
pooliebye07:54
lifelessactually cancelled08:01
lifelesstoo tired08:01
igcreviewing the lp-login patch currently08:03
lifelesswoot?! has it landed?!08:04
indravenimwh, hi, are u tehre08:09
lifelessyou want mwhudson08:10
indraveniyes lifeless08:11
indravenii need help in loggehead, yesterday he was helping me08:11
mdkemorning / evening lifeless08:13
mdkesvn-import finished successfully yesterday :)08:13
lifelessmdke: excellent08:14
mdkebut now I just have .bzr directories, I can't see the files anywhere...08:14
mdkeis there another step I need to do?08:14
lifelessmdke: you can get a working tree in any branch by doing 'bzr checkout .'08:14
lifelessor you can make new branches from these and treat the current directly like a cvs or svn repository08:14
mdkerighty ho08:14
mdkeso bzr branch /local/url new/branch?08:15
lifelessmdke: yup that will work08:17
lifelessmdke: then bzr push /local/url to push back to /local/url08:18
lifelessmdke: or you can do 'bzr checkout /local/url new/tree/' which will make it work like svn - when you commit /local/url gets the changes08:18
mdkeaha, clever08:20
mdkelifeless: thanks. I will branch then push the branches to LP, once I'm done with that I'll abandon /local/url08:20
vilawikipedia says: 'Copacetic may be a descendant of the Hebrew phrase "hakol beseder"', which I read 'How cool bzr' is :)08:28
vilawell, you have to read bzr with a french accent though, but wikipedia also says that one possible origin is creole, so I think I'm ok :)08:29
=== meuh_ is now known as meuh
=== lifeless changed the topic of #bzr to: The Bazaar Version Control System | http://bazaar-vcs.org/ | The packs have landed | Bazaar 0.91 is out - http://bazaar-vcs.org/Download | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d
PengCool!08:32
sabdfla tour de force, lifeless. very well done indeed.08:33
poolieindraveni, mwh should be awake soon08:34
indravenipoolie, thankyou08:34
indravenipoolie, will wait for him08:34
lifelesssabdfl: thanks!. And boy do we have ideas to improve on this improvement.08:35
lifelesssabdfl: though as I said a while pack, the very core disk layout is now solid IMO (the pack disk format itself).08:36
igcpack on the brain eh lifeless - s/pack/back/ :-)08:37
lifelessindeed08:37
mwhudsonindraveni: hello08:39
indravenimwhudson, hi08:40
indravenimwhudson, good morning08:40
indravenimwhudson, i have edited the loggerhead conf file accordingly but now i am struck with how to make it acess with apache08:41
indraveni?08:41
indravenii have apache installled and i have a vhost entry for my bzr repo08:41
Lo-lan-dohttp://bazaar-vcs.org/BazaarFormats doesn't mention packs...08:43
AfCLo-lan-do: so add it08:43
lifeless:)08:43
Lo-lan-doI'd gladly paste from the output of bzr help formats, but even that doesn't mention them.08:43
lifelessthey are still considered experimental08:44
AfCLo-lan-do: so write a patch adding documentation for it.08:44
lifelesswe have a small amount of work to do to make them be exposed08:44
AfCLo-lan-do: in other words, chill, dude.08:44
mwhudsonindraveni: you need to use ProxyPass or similar08:44
indravenimwhudson, yes, i saw about it in my README file08:44
lifelesswell, I like the enthusiasm08:45
Lo-lan-doAfC: I'm totally chilled (especially now jelmer helped me fix my bzr-svn problem), I'm just looking for info on this new shiny format that everyone seems so excited about :-)08:45
indravenibut how do i need to access it through browser ?08:45
lifelessLo-lan-do: if you want to play, or add docs to the wiki, if you look at my mails to the list about dogfooding they are still valid08:45
mwhudsonindraveni: here's what we (will) use for testing: http://rafb.net/p/1PMHGs81.html08:45
lifelessLo-lan-do: its just that you don't need anything other than bzr.dev to experiment08:45
mwhudsonyou need to have "127.0.0.88 codebrowse.launchpad.dev" in your /etc/hosts file08:46
indravenimwhudson, but in this where is the info about the bazaar repo ?08:47
mwhudsonindraveni: there isn't08:47
indravenimwhudson, then how does the apache know where os bazaar08:48
indravenimwhudson, even there is ocnf related to loggerhead location08:48
mwhudsonindraveni: um08:48
mwhudsonindraveni: loggerhead runs an http server, listening on some port or other, 8080 by default08:48
mwhudsonthe conf file i pasted above tells apache to forward requests for codebrowse.launchpad.dev to this loggerhead process08:49
lifelessLo-lan-do: in bzr.dev08:50
indravenibut where is loggerhead folder in that case in ur system08:50
mwhudsonindraveni: it doesn't matter!08:50
lifelessthere is a new doc - doc/developers/index lists it, which describes packs.08:51
indravenimwhudson, how does apache know where is loggerhead ?08:51
Lo-lan-dolifeless: Thanks, I'll read up on that.08:51
lifelessnp08:52
mwhudsonindraveni: why does it need to?08:53
mwhudsonit's not running as a cgi script08:53
indravenimwhudson, when i give bzr.indraveni ( which is my servername in apahce file) its showing nothing09:00
indravenii am not understanding how loggerhead, apache and bazaar are related09:01
mwhudsonindraveni: what are you actually trying to acheive here?09:01
indravenimwhudson, when i configure my apache file with vhost like http://pastebin.ca/74769109:02
mwhudsonare you trying to show your branches to the wider internet, just to a few people in your team, just browse them yourself?09:02
indravenimwhudson, i am able to see the bazaar repos content in browser, using bzr.indraveni as url09:02
indraveniand now , i want to use loggerhead GUI to view the bazaar repo content09:02
indravenimwhudson, i want to show to some people in team, if it works well then wider in internet09:04
mwhudsonindraveni: ok09:04
mwhudsonso if you start loggerhead and browse to localhost:8080, does it work?09:05
indravenimwhudson, oops i forgot to start loggerhead09:07
indravenimwhudson, and now statring loggerhead, is showing an error message09:08
indravenimwhudson, this is the erorr when i am starting loggerhead http://pastebin.ca/74769709:09
mwhudsonindraveni: you need to install turbogears09:11
indravenimwhudson, is it must ?09:11
mwhudsonindraveni: yes, for now09:12
indravenimwhudson, ok, from source i need to install ?09:12
Lo-lan-doHm.  Can I switch a lightweight checkout to another branch?09:12
mwhudsonyou don't have to install it system wide, i think09:12
mwhudsonindraveni: what OS are you running on?09:12
Lo-lan-doI did bzr bind $otherbranch, but bzr info still tells me about the old one in "repository checkout root"09:12
indravenimwhudson, debian09:12
mwhudsonindraveni: apt-get install turbogears should work then09:13
indravenimwhudson, there is not such file, there is only, python-turbogears09:13
indravenishall i install that /09:13
mwhudsonyes09:13
Lo-lan-doErm.  bzr complains it can't acquire a lock, because it's held by the very same bzr process?09:17
igcnight all09:28
poolienigth09:32
poolieigc, thanks for the ssh bugfix09:32
=== sabdf1 is now known as sabdfl
igcpoolie: np. I thinks it's pretty low risk so I'll merge it if you like once it's reviewed09:35
lifelessLo-lan-do: on the smart server ?09:36
pooliei have some tweaks09:36
igccool09:36
Lo-lan-doNope, local branches stored in a shared repo on the same disk09:36
Lo-lan-doBut I removed the branch and checked it out again, seems to be over.09:36
Lo-lan-doAh, no, it happens again.09:43
=== ajmitch_ is now known as ajmitch
Lo-lan-doDamn, this time it even survives an rm -rf + checkout :-(09:49
lifelessLo-lan-do: do you know about bzr break-lock ?09:52
* Lo-lan-do tries that09:52
lifelessLo-lan-do: also, it is possible for the same process to mutual-exclude in bzr, so its likely the specific operation you are doing09:52
Lo-lan-dobzr break-lock gives me a backtrace ending in "RuntimeError: maximum recursion depth exceeded in cmp"09:53
lifelessgrah?!09:53
Lo-lan-doAnd the specific operation I was attempting to perform was a "bzr pull" from another local branch09:54
lifelessthat definately should not mutual exclude because the source is only readlocked09:54
lifelessthe only way I know that thsi can be confused is if the tree you are in is a symlink/lightweight checkout of the source branch09:54
Lo-lan-dohttp://paste.debian.net/4052009:56
lifelessso its trying to lock /home/roland/debian/bzr-repo/gforge/09:57
Lo-lan-do"find -name lock | xargs ls" tells me there are two files called */lock/held in the repo, in .bzr/repository/lock and debian/sid/.bzr/branch/lock09:57
lifelessright09:57
lifeless'bzr break-lock /home/roland/debian/bzr-repo/gforge/'09:57
lifelessshould clear the locks09:57
Lo-lan-doIf I ^C, the lock files disappear09:58
lifelessif it doesn't, please file a bug, because this is an important command (which is well tested, so I'm not seeing why ..)09:58
lifelesshmm09:58
Lo-lan-dobreak-lock doesn't do anything (since the files aren't there after a ^C)09:59
fullermdDidn't we just have one of those bugs reported?09:59
lifelesswhat is 'bzr info /home/roland/debian/bzr-repo/gforge/upstream-svn/trunk/' ?09:59
Lo-lan-dohttp://paste.debian.net/4052110:00
fullermdIt's a lightweight co of a branch in the .../bzr-repo/gforge/ repo, ans the branch trying to be pulled from is also in that repo?10:00
indravenimwhudson, now i getting this error while running loggerhead after installing turbogers10:00
indravenimwhudson, http://pastebin.ca/74772110:00
Lo-lan-dofullermd: Yes10:01
indravenimwhudson, I dont know anything about pythob10:01
sabdfllifeless: hi, have some initial pack feedback for you!10:01
lifelesscool10:01
indravenimwhudson, are u there ?10:02
mwhudsonindraveni: one moment10:02
indraveniok10:03
Lo-lan-doHmm.  If I try to merge/commit instead of pulling, I get another error: http://paste.debian.net/4052210:03
mwhudsonindraveni: apt-get python-sqlite should fix that i think10:04
mwhudsonindraveni: but it's a bit bad of me, you don't need sqlite bindings unless you're using the caches10:04
mwhudsonso it should work without them installed10:05
* mwhudson files a bug10:05
fullermdOh ho.  Circular binding.10:05
fullermdThat could be the source of the initial trouble...10:06
Lo-lan-doStrangely, other branches stored in the same repo and whose parent is also upstream-svn/trunk do behave properly.10:08
fullermdYes, but the problem is in that debian/sid branch.10:08
Lo-lan-doBut whatever.  How can I fix that?10:08
fullermdGo into it and 'bzr unbind'10:08
fullermdThen pull and all should get back to working normally.10:09
Lo-lan-doYay, it works :-)10:09
Lo-lan-doNow how do I prevent that from happening again?10:10
fullermdDon't make branches that are checkouts of themselves   ;)10:10
Lo-lan-doErm, I generated that checkout with "bzr checkout --lightweight /home/roland/debian/bzr-repo/gforge/debian/sid/ gforge-sid"10:10
fullermdNono, the problem wasn't the gforge-sid checkout.  It was the debian/sid branch, which considered itself a [heavyweight] checkout of the debian/sid branch.10:11
Lo-lan-doI see.10:11
Lo-lan-doMaybe I caused that when I was trying to switch a lightweight checkout from one branch to another.10:12
Lo-lan-doI did play a bit with bind and unbind at that time.10:12
Lo-lan-do(And didn't find a working process...)10:12
fullermdWell, it's all path based.  So if you made a heavy checkout of debian/sid somewhere, then just mv'd it over to debian/sid...10:12
fullermdBut you could have pulled it off manually with bind too; probably the more likely case.10:13
Lo-lan-doProbably.10:14
Lo-lan-doIs there a proper way to switch a lightweight checkout across branches then?10:14
lifelessbzr switch10:15
mwhudsonLo-lan-do: bzrtools defines a 'switch' command10:15
Lo-lan-doAh, I need to install bzrtools again then.10:15
Lo-lan-doApparently a bzr.dev installed in ~ doesn't use the plugins installed system-wide :-/10:15
fullermdlifeless: How could I easily tell whether bzr was sucking in celementtree?10:18
lifelessfullermd: do you mean finding it ?10:18
lifelessfullermd: I think it goes in bzr.log10:19
fullermdMmm.  Doesn't seem to...10:20
bialixpacks have landed! w00t! I don't believe to my eyes10:26
bialixwill try on win32 tonight!10:27
bialixlifeless: congrat!10:27
lifelessthanks bialix10:27
bialix:-)10:28
indravenimwhudson, in loggerhead.conf, do we need to mention the branch path or the main central repo path ?10:32
mwhudsonbranch path10:35
indravenimwhudson, now i am getting a message like, port not free10:36
indraveniwhen i am starting loggerhead10:36
indraveniwhere as i have only apache running in 8080 and no other10:36
indraveniwhich port dows loggerhead use ?10:36
mwhudson8080 by default10:39
indravenimwhudson, i have apache running in that port10:40
indravenihttp://pastebin.ca/74774110:40
indravenimwhudson, http://pastebin.ca/74774110:40
mwhudsonwell, change the port loggerhead runs on then10:40
mwhudsonit can be done in the config file10:40
indravenimwhudson, got it10:41
indravenimwhudson, but the content is not propely displayed in the web browser10:44
indravenimwhudson, i have some more content in the my_project folder which are created using bzr add, and commited, but those are not visible in this10:45
mwhudsonindraveni: well, i'm not sure how i can help you with that10:48
indravenimwhudson, ok i will try to reosolve this10:48
indravenimwhudson, i think my branch and conf file need some thing to be done10:49
mwhudsonif you have specific questions i can answer them, but i don't know what your directory layout is like10:49
mDufflifeless: as a general rule, should I be assigning packs-related bugs I file to you?10:59
lifelessnDuff: no, but please tag them packs10:59
lifelessthe ones I work on I'll assign to me, but its not a one-person effort, so assigning to me would be a net negative10:59
mDuffthank you -- I was previously unaware launchpad's tagging support.11:01
lifelessnp11:05
mDuffIs there an existing syntax for having a single string specify both a repository URL and a revnum or revid?11:23
fullermdTo what?11:24
sandrotso...what's the best way to distribute in a distributed model? =)11:25
mDufffullermd: I'm looking to fully qualify the path to a specific revision of a piece of code -- both where to contact the server, and what to ask it for. I could just pass the URL and the revision specifier space-separated, but I'm wondering if there's another preexisting, recognized method.11:25
fullermdsandrot: Broadly.11:25
sandrotheh11:26
fullermdmDuff: For bzr?  No.  I'm sure there are URL templates for loggerhead or bzr-webserve...11:26
sandrotI'm working with a small team used to svn, in general I think a central server works pretty well for pushing and pulling updates, is that recommended?11:27
fullermdWell.  I would say that what's "recommended" is what works best for your situation.  You have a range from everybody working lockstep on a single branch, out to everybody working in individual branches merging full-mesh, and a lot of spots in between.11:28
lifelessmDuff: we have planned one but not implemented iot11:29
lifelessmDuff: url;revno=xxxx11:29
lifelessand url;revid=xxxx11:29
sandrothmm11:30
lifelesssandrot: you can work just like you do in svn11:31
lifelesssandrot: and experiment as you grow familiar with the available tools and processes that bzr offers11:31
fullermdsandrot: Usually, the 'best' answer for a given case is somewhere in the middle.11:31
sandrotover http?11:31
lifelessbzr+http is a little tricksy; but you can pull and update over http11:31
lifelessbzr+ssh or sftp will work just fine11:32
sandrotyeah, I'd like the make the transition for my designer as easy as possible11:32
lifelessmDuff: I expect a fix for your deletes-during-commit bug tomorrow11:32
fullermdlifeless: Incidentally, did I read that bzr+ssh is going to be suffering relative to sftp for packs?11:32
sandrotcurrently I just bzr init locally and push it to my server...then branch and pull on my laptop11:32
lifelessfullermd: yes, right now it doesn't work :)11:32
lifelessnight all11:32
mDufflifeless: graci.11:33
mDuff...and g'night.11:33
fullermdAh.  Minor details...11:33
sandrotwill bzr+ssh always prompt for password unless public key is on the server?11:36
LeoNerdIt'll just do the same SSH login as any other ssh into the machine11:37
sandrotthanks11:37
LeoNerd(Given as.. er.. it is ssh.. and doesn't have any choice but to...)11:38
sandrotin the centralized workflow doc it states that commits happen both locally and remotely. how does bzr know that the working tree is in a centralized environment? is it because of the shared repo?11:43
mDuffsandrot: if you use "bzr checkout" instead of "bzr pull", that creates a bound branch, which has the behavior in question.11:44
fullermdNo, because you're working in a dir created by 'checkout' rather than 'branch' (not _quite_ precisely right, but close enough)11:44
sandrothuh...11:45
LeoNerd'checkout' == 'branch' + 'bind'11:45
sandrotneato!11:45
LeoNerdA 'bound' branch is simply one that atomically pushes every commit upstream, when committed locally11:45
* fullermd drives an extra stake through the heart of 'bind', just to be sure.11:45
sandrotI've been using branch all along (Which is good for being able to commit whenever I want) and then pushing...11:45
sandrotbut you're saying I could have substituted branch with checkout and been bound11:46
LeoNerdYa.. or just 'bzr bind' it now11:46
LeoNerdSame effect11:46
sandrotyou can unbind as well right11:46
sandrotso you could checkout, unbind for a bit, bind again11:46
LeoNerdIndeed11:46
LeoNerdYou can also  'bzr commit --local ...' if you want to do a one-off local commit to a bound branch11:46
LeoNerdThen push it later.11:46
LeoNerd(e.g. useful for sometimes-offline laptops)11:46
sandrotinteresting11:46
sandrotand if you're working with a simple bzr init (no shared repo), then every checkout has a full history of the commits?11:47
sandrotsorry, every branch11:47
fullermdWell, every branch has the full history whether you're using a shared repo or not.11:47
fullermdIt's just that if they're in a shared repo, they...   well, share it, instead of individually storing the same info.11:48
sandrotso if branch1 and branch2 have similar info they share it in shared repo?11:48
fullermdRight.  Saves space (and I/O copying stuff around).11:49
sandrotHmm, I currently don't have a layout...just trunk which I host on my server...but I could bzr init a project with a trunk/ branches/ tags/ layout which then would be appropriate for using a shared repo?11:52
LeoNerdEr...11:52
LeoNerdThat's more of a SVN way of thinking..11:52
LeoNerdA 'tag' in bzr is just a friendly name for a revision.. it's not a separate filesystem entity11:52
sandrothmm, thought that's how svn used them =)11:53
LeoNerdNo11:53
LeoNerdIn SVN everything is just a cheap referential copy11:53
LeoNerdBranches, tags, renames... don't exist11:53
LeoNerdThey're just copies11:53
fullermdLet's not discuss how svn uses them.  I'm planning to eat soon...11:53
sandrotlol11:53
LeoNerdIn bzr, a tag is just a friendly human name for a revision11:54
LeoNerdThe same way that a hostname is just a friendly human name for an IP address11:54
sandroteverything is a branch =)11:54
LeoNerdA revision is just a point on a branch.11:54
sandrotya11:54
LeoNerdA branch is just an ordered list of revisions11:54
sandrotso can I migrate a current branch into a shared repo?11:55
mDuffsandrot: yes.11:55
mDuffsandrot: just push it into the repository, and there it is.11:55
sandrotwouldn't my branch still be carrying around all it's repo data in branch/.bzr11:56
fullermdNo, when you push/pull/branch/etc a branch into a repo, it stores the data in the shared repo, not a per-branch repo.11:57
sandrotvery cool11:57
sandrotso turning my project into a "checkout commit" system is as simple as pushing my branch into a shared repo =)11:57
fullermdOf course, you could have a standalone branch that you 'mv' into a repo, and it will still store everything locally (since when it was created, it didn't know about any repos)11:57
fullermdThere doesn't have to be a shared repo involved to checkout a branch.11:58
mDuffsandrot: you don't strictly need to do that; it's more of a space-efficiency thing.11:58
LeoNerdUmm... a "shared repo" only makes any use if you take multiple branches of something...11:58
Lo-lan-doLeoNerd: Um?  I thought a branch was also able to store diverged-then-merged revisions?11:58
LeoNerdYes it is..11:58
LeoNerdBut I mean, unless you actually _do_ that, a shared repo doesn't buy you anything in space savings11:58
mDuffsandrot: if you have multiple branches, a shared repository prevents duplicate storage -- but you can do checkouts and all that from a standalone tree.11:59
Lo-lan-doThen it's not quite an ordered list of revisions, is it?11:59
LeoNerdIf you have 10 different separate branches with 10 revisions in each, you have 100 revisions in the repo.11:59
sandrotOkay, yeah, thanks, I understand that the shared repo is really just a nice extra11:59
LeoNerdLo-lan-do: Yes... because it's only the merge point that matters... Two diverged branches are still just an ordered list.12:00
LeoNerdLo-lan-do: When one is merged into the other, the target branch gets a special 'merged' revision, that contains sub-revisions of the changes that were merged12:00
Lo-lan-doAh, I see.  I thought these sub-revisions were stored too, so you'd have a DAG with only a partial order.12:01
Lo-lan-doBut if they're collapsed... then yes, it makes sense.12:01
sandrotOn a filesystem level, where should I store my branches on my server. Currently they're in /home/me/Code/bzr but should I be worried about having multiple users reading in my home directory?12:01
sandrotfullermd: thanks for bringing up the standalone branch 'mv' thingie...that was a concern I had12:02
LeoNerdThe subrevisions are stored as well, yes... they retain their individual identity in the stored data...12:02
fullermdLo-lan-do: I think you're trying to read _WAY_ too much precision into an offhand statement   :p12:02
LeoNerdI keep mine in /var/bzr/$user12:02
LeoNerd(so I can point a webserver at them easily too)12:03
Lo-lan-dofullermd: Possibly, but since I thought I finally understand how pulling and merging work, I'd rather not have that understanding shattered.12:03
=== cprov-out is now known as cprov
sandrotLeoNerd: so a user does an sftp://yourserver/var/bzr/$user ?12:03
Lo-lan-doIt's currently shaken, not shattered, but I'll think about it some more.12:04
indravenimwhudson, is there any default structure for the bazaar branch /12:04
indraveni?12:04
mwhudsonindraveni: i don't understand12:05
fullermdLo-lan-do: Technically, a branch is just a set of revisions; the revs themself describe the ordering.  More technically, it's just a pointer to ONE revision, since each rev describes the whole set of revs leading up to itself.  But it's simpler to give a taste by saying 'a branch is a series of revisions'.12:06
LeoNerdYes.. admittedly I hadn't considered merges when I made that statement12:06
Lo-lan-doSo I wasn't mistaken, yay! *phew*12:06
LeoNerdI was just considering a simple linear branch12:07
indravenimwhudson, i have my bazaar branch created ni the path12:07
Lo-lan-doOne rev can have multiple parents, right?  Like in hg?12:07
indraveni/opt/bazaar_samples/my_project12:07
* fullermd nods at Lo-lan-do.12:08
* Lo-lan-do dances the joy-dance of understanding12:09
=== mrevell is now known as mrevell-lunch
indravenimwhudson, and my directory structure is like this12:09
* fullermd quickly searches for some random tidbit to totally shatter Lo-lan-do's understanding.12:09
Lo-lan-doDon't you dare.12:10
sandrotso if my branch is not bound than bzr update tries updating with itself?12:10
indravenimwhudson, my direcory structure and loggerhead.conf file is here http://pastebin.ca/74780112:10
fullermdLo-lan-do: So, if we define each rev of the tree to be a quantum superposition, see...12:10
indravenimwhudson, is my configuartion correct or not ?12:10
LeoNerdsandrot: Indeed.. otherwise it wouldn't know what to "update" from12:11
fullermdsandrot: 'update' updates your working tree to be up to date with its branch.  It doesn't much matter whether that working tree is colocated with the branch in a standalone tree, or separate from teh branch as a checkout.12:11
Lo-lan-dofullermd: You define revs as you like.  I'll use the old analogy, as long as it keeps working for me :-)12:11
mwhudsonindraveni: the folder= line should give the path to a bazaar branch12:12
mwhudsonit looks like you've given the path to a folder containing folders which contain bazaar branches12:12
mwhudsonindraveni: ls -lAR would be better, perhaps12:13
indravenimwhudson, http://pastebin.ca/74780412:14
indravenimwhudson, yes, so my bazaar branch is /opt/bazaar_samples/my_project, so what i wrote in conf is correct ?12:16
mwhudsonindraveni: oh, yes then12:17
mwhudsonindraveni: so, what is going wrong?12:18
sandrotthanks everyone, super helpful! Earlier I was going to setup a svn repo and export my bzr to svn to make things easy on my designer...not anymore!12:20
sandrotbzr is easy enough on it's own =)12:20
indravenimwhudson, what abt the other fields?12:23
AfCSomeone should grab that and use it as a quote on a website somewhere12:23
indraveniwhe I typed, localhost:8090 in browser12:24
mwhudsonindraveni: they're not very important, cosmetic stuff only12:24
indraveniit opened up a page which has a link to bzr.dev12:24
indraveniand when i clicked that, it shows a page12:25
indraveniThe path '/branches/bazaar/bzr_dev' was not found.12:25
mwhudsonoh, one moment12:25
mwhudsonindraveni: server.webpath = 'http://localhost:8220/branches' <- this seems wrong12:25
mwhudsonthis should be the path you type into your web browser12:26
mwhudsonso probably localhost:8090 in your case12:26
indravenimwhudson, sorry ,, i am accessing with localhost:822012:26
indraveniso thats right12:26
mwhudsoni still think you want to remove the "/branches"12:27
indravenimwhudson, got it12:28
indravenimwhudson, now it worked12:29
mwhudsonindraveni: hooray12:29
indravenimwhudson,thankyou12:30
indravenimwhudson, is it like, only one branch can be pointed for one loggerhead ?12:30
mwhudsonindraveni: no12:30
indravenimwhudson, in the first page its showing like, bzr.dev on clikcing which shows me the summary of prev revisions12:31
mwhudsonindraveni: you can have any number of top level sections (e.g. "[bazaar]") and inside each of these any number of branches (e.g. "[[bzr.dev]]")12:32
indravenimwhudson, but here in my case, in the inital page itself ts  showing bzr.dev12:33
indraveniwhere as my bazaar branch name is my_project12:33
mwhudsonindraveni: that's because it's inside a section called [[bzr.dev]]12:34
mwhudsonchange that to [[my_project]] or something12:34
indravenimwhudson, tell me one thinf12:34
indraveniwhats the difference between [xxx] and [[xxx]]12:35
mwhudson[project]12:36
mwhudson[[branch]]12:36
mwhudsonas i said above12:36
lifelessjelmer: ping12:55
jelmerlifeless, pong12:56
lifelesspacks are in bzr.dev12:56
jelmerlifeless: nice, thanks for let me know12:56
lifelesstheres an additional commit performance patch in my repository branch12:56
jelmerok - the one just discussed on the list?12:57
lifelessyes, the 'native dirstate update basis ...'12:57
lifelessjelmer: UDS and all hands are coming up12:59
lifelessjelmer: but if there is *anything* I can do to help the samba guys make the right choice :)12:59
lifelessI'd be delighted to e.g. meet up with samba folk in boston12:59
jelmerlifeless: Jerry, the driving force behind the git adoption, will be at UDS I think12:59
lifelessJerry who?13:00
jelmerGerald Carter13:00
lifelessperhaps you could mail him and poolie and I13:00
lifelessor even a general note to the samba list, I don't know - do what you think will have the best effect13:01
jelmerI'll bring it in in the internal discussions about git13:05
jelmerbut I'll keep you informed13:05
jelmerwhen's UDS exactly?13:05
lifelesswiki.ubuntu.com has all the details13:06
lifelessbasically though I'm in boston from friday till the 10th13:06
lifelessok later13:10
lifelessmDuff: I think there is quite a simple fix for your performance bug; we currently maintain a set of deleted paths.13:10
jelmerlifeless: ok13:10
lifelessmDuff: but if we change this to a list, and trim paths from it when we move past them in the loop13:11
lifelessmDuff: then the list won't get 1000's of entries long, and in fact will in principle only ever be a single item long.13:11
indravenimwhudson, if i am forgetting to stop loggerhead and again trying to start the loggerhead13:16
indravenimwhudson, its syaing port not free13:16
indraveniand when i am seeing the processes, i dont find any loggerhead prcess running13:16
indravenii am not able to kill the processs13:17
indraveniinstead i am changing the port to anyother, which is  a bad practoce13:17
indraveniso, how can i kill the loggerhead processes ?13:17
niemeyerWould anyone know how to prevent the error bzr: warning: unsupported locale setting?13:17
lifelessok damn that was easy13:19
lifelessniemeyer: set your locale correctly.13:19
niemeyerlifeless: You're brilliant13:19
niemeyerI wonder how I didn't think of that before13:19
niemeyerlifeless: Ok.. now, how do I do that?13:19
lifelessthe LANG and LC_ variables IIRC13:20
niemeyer[niemeyer@burma ..ent/bound/trunk]% echo $LANG13:20
niemeyeren_US.UTF-813:20
niemeyerThey're all like that13:21
lifelessthe probable cause is missing language resources then IIRC13:21
lifelessuhm13:21
niemeyerWhich means ...13:21
mwhudsonindraveni: ./stop-loggerhead.py should kill the process13:21
indravenimwhudson, its not killing13:22
indravenimwhudson, i am forcely killing the processes,13:22
indravenimwhudson, now it worked fine13:22
lifelessniemeyer: is this in the DC ?13:22
niemeyerlifeless: No, locally13:22
lifelesshmm13:22
mwhudsonthe starting and stopping scripts are not amazingly robust13:22
fullermdniemeyer: The "right answer" probably varies by the particular system.  'locale -a' might list all the available options...13:22
indravenimwhudson, i have two more doubts on this loggerhead, could u please bear with me for 10 more mins13:23
lifelessniemeyer: you might try locale-gen13:23
=== mw|out is now known as mw
niemeyer[niemeyer@burma ..ent/bound/trunk]% locale -a | grep en_US13:23
niemeyeren_US.utf813:23
niemeyerlifeless: Cool, will try it13:23
fullermdWell, there you go; it's just spelt a little differently than you have it.13:24
niemeyerSays "up-to-date", and still same problem13:24
lifelessniemeyer: basically in python terms we're trying to do 'str.encode('en_US.utf8')'13:24
fullermdI set $LANG in my shell .rc file...  you can probably override there.13:24
lifelessand python is throwing an error13:24
fullermdOh, no.  You're trying to str.encode('en_US.UTF-8'); that's why the error.13:24
niemeyer>>> print "áéíóú".decode("UTF-8").encode("UTF-8")13:24
niemeyeráéíóú13:24
indravenimwhudson, what is the difference b/w [xxx] and [[xxx]]13:25
fullermdniemeyer: Your system supports "en_US.utf8", and you're trying to tell it you're using "en_US.UTF-8", so it's flibbering all over itself.13:25
mwhudsonindraveni: i've explained that twice13:25
lifelessniemeyer: thats UTF-813:25
lifelessniemeyer: you have en_US.UTF-813:25
lifelessniemeyer: which is different13:25
lifelesstry13:26
luksen_US is not an encoding :)13:26
niemeyerfullermd: I don't think there is a difference..13:26
niemeyerfullermd: "UTF-8" and "utf8" should work the same way13:26
niemeyerfullermd: And I get the error both ways13:26
lifelessniemeyer:13:26
lifeless>>>13:26
fullermdNot if your system only has a locale def for "en_US.utf8" and you're trying to point it at "en_US.UTF-8".13:26
lifelessimport locale13:26
niemeyerlifeless: en_US shouldn't be used in a Python decode/encode statement13:26
luksniemeyer, but python is probably missing the en_US.utf8 -> en_US.UTF-8 alias13:26
lifelesslocale.getpreferredencoding()13:26
indravenimwhudson, is it, sorry, i dint check, will check now13:26
fullermdYou get the error with your LANG set to the proper value?13:27
niemeyer[niemeyer@burma ..ent/bound/trunk]% python -c 'import locale; print locale.getpreferredencoding()'13:27
niemeyerUTF-813:27
niemeyerfullermd: My lang *is* set to the proper value, as far as I know13:27
luksLANG=en_US.utf8 bzr something13:27
fullermdIf locale -a doesn't list the setting your have for LANG, it's not the proper one.13:27
lifelesson a machine that has the glitch for me, I get:13:27
niemeyerfullermd: It's an alias..13:27
niemeyerluks: Yes, fails the same way13:28
lifeless $ python -c 'import locale;locale.getpreferredencoding()'13:28
lifelessTraceback (most recent call last):13:28
lifeless  File "<string>", line 1, in ?13:28
lifeless  File "/usr/lib/python2.4/locale.py", line 417, in getpreferredencoding13:28
lifeless    setlocale(LC_CTYPE, "")13:28
lifeless  File "/usr/lib/python2.4/locale.py", line 381, in setlocale13:28
lifeless    return _setlocale(category, locale)13:28
lifelesslocale.Error: unsupported locale setting13:28
lifelessniemeyer: what about13:29
lifelesspython -c 'import bzrlib.osutils; bzrlib.osutils.get_user_encoding()'13:29
luksniemeyer, is en_US.UTF-8 also in LC_ALL?13:29
niemeyerlifeless: Shows nothing13:29
luksor LC_*13:29
lifelessniemeyer: then its not erroring13:29
niemeyerluks: It is, all of them13:30
lifelessdo you have an alias for bzr or something ?13:30
niemeyerlifeless: Nope13:30
niemeyerlifeless: It's a bzr update command.. does it make a difference?13:30
indravenimwhudson, got it, thankyou13:30
lifelesswell, an alias could be overwriting an env variable13:30
niemeyerlifeless: Over bzr+ssh.. may I be getting errors from the remote side?13:31
lifelessniemeyer: oh yes, that is coming from the remote side13:31
lifelessniemeyer: which I bet is the DC13:31
niemeyerlifeless: It's from chinstrap, yes13:31
niemeyerThat's.. hmm.. weird :(13:31
lifelessniemeyer: /win 5213:31
niemeyerlifeless: Hm!?13:32
lifelessmistype13:32
niemeyerGetting a locale error due to a setting from the remote repository is super strange13:33
lifelessstderr is displayed locally by openssh13:33
niemeyerlifeless: Right.. I'm speaking from a user perspective13:34
lifelessright13:34
lifelessand I agree13:34
lifelessbut it seems undesirable to hide it13:35
niemeyerI definitely desire it :)13:35
niemeyerOr at least change the wording of what's shown in these cases13:35
fullermdIt would be nice to have some sort of indicator that "Hey, this is from the other side, silly!"13:35
lifelessyou could file an RT ticket :)13:35
lifelessfullermd: indeed; that means intercepting stderr and selecting() rather than just reading etc etc.13:36
fullermdWell, we could just make nothing ever go wrong, if that's easier  ;)13:36
niemeyerOk.. thanks for the help guys13:38
Lo-lan-doIs there a way to remove a branch from a shared repo?14:44
fullermdrm -rf, generally.14:44
LeoNerdYou can rm it, but that'll not remove the individual revisions from the store14:44
LeoNerdThis won't matter, except in disk space14:44
Lo-lan-doExactly :-)14:44
Lo-lan-doSo... no garbage collector to clean the unused versions?14:46
LeoNerdNot that I know of currently.. You can 'push' each branch to a new shared repo, then 'mv' swap them though14:47
fullermdI think lifeless hacked up something once upon a time that did some GC'ing.14:47
LeoNerd'bzr vacuum' or something like that?14:47
fullermdBut there's no standard, supported thing to do it, no.14:47
Lo-lan-dohttp://doc.bazaar-vcs.org/latest/developers/repository.html does mention GC, but rather vaguely14:50
Lo-lan-dolifeless: ^^^ anything you feel I should know? :-)14:52
jelmerwe discussed a garbage collect command at the sprint this summer15:00
jelmerbut afaik nothing like that has been implemented yet15:00
Lo-lan-doOkay.  I'll keep my temporary branches out of my shared repository then.15:05
fullermdSounds like more trouble than it's worth, unless you start checking in ISO's or something.15:07
Lo-lan-doDead files eating space on my disk make me uncomfortable.  And since it's actually simpler to start a local branch than put it in a repo than get a lightweight checkout of it, I see it as a net positive.15:09
Lo-lan-doLess trouble, *and* less discomfort.15:10
* fullermd shrugs.15:11
fullermdI've got dead revs all over the place, from abandoned branches, or uncommit's.  I'm not gonna worry very much about a few hundred k of wasted space...15:11
fullermdI probably burn more space holding backup copies of scripts I wrote for use on systems that haven't existed in 10 years.15:12
Lo-lan-doWell, as you like, but I don't like institutionalised cruft.  It's like a memory leak, except permanent.15:15
=== bigdo1 is now known as bigdog_
Lo-lan-doAm I running into problems if I have a working tree that's both a lightweight checkout of a branch stored in a shared repo *and* a checkout of an SVN branch?15:36
Lo-lan-doI guess only the branch (in the repo) is bound to SVN, and the working tree is just something that happens to be a checkout of that branch, but I'd like a confirmation from the masterz :-)15:37
=== cprov is now known as cprov-lunch
Lo-lan-do(If I'm not going to run into problems, then that's probably the setup I'm likely to use)15:45
jelmerI see no reason why that shouldn't work, if I understand the setup correctly15:45
Lo-lan-doGreat15:47
Lo-lan-doYou'll probably hear about it if it doesn't :-)15:48
Lo-lan-doQuite soon, even: I've just received a patch form the BTS, which I'm going to try and merge right now.15:49
Lo-lan-doYay, it  seems to be working!15:57
Lo-lan-doI committed a patch in sid (pure bzr, light checkout), then pulled it into trunk (the one which is a light checkout of the branch bound to SVN).15:58
Lo-lan-doNo error, and svn update in an svn checkout includes the patch.15:58
Lo-lan-doYay yay yay :-)15:59
Lo-lan-doHm.  Would it be possible to do without the SVN properties, or to keep them short?  The commit emails we get include the properties, and they're getting crowded...16:00
Enquesthow do I put a directory on an ignore list?16:29
EnquestI want a certain directory not to be loaded.16:29
Enquestupdate16:29
datoEnquest: can you give an example of what you want?16:30
Enquestsomething lik bzr ignore www/uploads/16:31
Enquesthow do I do this?16:31
datoother way than `bzr ignore www/uploads` ?16:31
Enquestwhen I type bzr add ... It starts to add all files. I don't want a directory included16:33
datoEnquest: is "www" at the same level as ".bzr" ?16:34
datoif it isn't, `bzr ignore www/uploads` will not work16:34
Enquestwww is deeper16:35
Enquestdev/.bzr16:35
Enquestdev/www/upload16:35
fullermdActually, I think ignore canonicalizes the path as necessary.  Not sure (I always just hand-edit .bzrignore)16:36
=== cprov-lunch is now known as cprov
=== weigon__ is now known as weigon
jam-laptopfullermd: it does not (yet), I thought there was a bug asking for this sort of thing, though.18:06
jam-laptopI think part of it is that you probably don't want to canonicalize: bzr ignore "*.foo"18:06
mdkelifeless: seeking your advice with something. Could you look at https://lists.ubuntu.com/archives/ubuntu-doc/2007-October/009758.html which sets out the naming scheme intended to be used for our project's branches on Launchpad. The question is, should we include all the svn revision history (now imported into bzr) in each branch, or just start new branches afresh, maybe keeping revision history from svn around in one of the branches to use if we need it. Uploa18:55
* mdke hopes his irc client doesn't cut the end of long lines, the last word there should be "solution"18:55
mwhudsonmdke: nope18:56
mwhudson"we need it. Uplo" was as far as we got18:56
mwhudsonmdke: i should apologise for not replying to your emails, btw18:57
jam-laptopmdke: How much history are you talking about?18:57
jam-laptop(how many files, how many revisions, etc)18:57
jam-laptopI generally would keep history unless there is a real reason not to18:57
jam-laptopOh, and lifeless is usually not for another couple of hours18:57
jam-laptop(.au time, I've seen him on in an hour, but that is about 5am his time)18:58
mdkemwhudson: that's ok.18:59
mdkejam-laptop: i think it's 3500 revisions19:00
mdkemwhudson: I wasn't expecting an instant response :)19:00
jam-laptopmdke: doesn't seem like too many, Bazaar has 14,51919:00
mwhudsonmdke: i'll try to have a sensible reply by the morning19:00
mdkejam-laptop: well, uploading the first branch took about 3-4 hours this morning, and there will be something like 15 branches...19:00
jam-laptopThough at the moment we scale a little bit better with num revisions than we do with num files19:00
jam-laptopmdke: uploading from where? And were you using "sftp://bazaar.launchpad..." or "bzr+ssh://bazaar.launchpad"19:01
jam-laptopThe latter has much better latency characteristics19:01
mdkejam-laptop: from my home. The latter19:01
jam-laptop(sftp:// requires 3 round trips, etc)19:01
jam-laptopmdke: well, if you want, I can "pre-seed" some branches for you19:01
jam-laptopIf you have one uploaded, I can push it into neighboring ones19:02
jam-laptopfrom a much closer location19:02
jam-laptopAnd then your future pushes of the other branches should be fairly fast19:02
fullermdYeah, I wish LP let you do that, if not actually support repos...19:02
mdkejam-laptop: that sounds really helpful. I'm still a bit concerned about the amount of downloading people would have to do to get multiple branches though.19:02
jam-laptopfullermd: there is quite a bit of discussion of server side branching, shallow branches, and what we might do for shared repos19:02
mdkeStill, that may be solved by advising people not to download revision history19:03
jam-laptopmdke: If they have a shared repository (recommended) it won't copy everything19:03
jam-laptopJust the first time19:03
jam-laptopbut not 1x per branch19:03
mdkejam-laptop: I understood that LP didn't support that. We're planning to use LP as a central server with a relatively centralised workflow19:04
jam-laptopmdke: LP doesn't have shared repositories on *its* side. It has nothing to do with letting you use them on your own machine19:04
jam-laptop(So you can't tell LP to share the repository between ~user/project/branch1 and ~user/project/branch2, but on your local machine you can.)19:05
mdkeright... and that wouldn't affect a "bound branches" workflow?19:05
jam-laptopmdke: correct19:05
mdkevery interesting19:05
jam-laptop"shared repositories" is just an optimization for how data is stored19:05
jam-laptopit doesn't change much else19:05
mdkeright, I'll have to explore that definitely and look into the docs19:05
jam-laptopmdke: you might read http://bazaar-vcs.org/Tutorials/CentralizedWorkflow19:06
jam-laptopor even19:06
mdkewill do19:06
jam-laptophttp://bazaar-vcs.org/Workflows19:06
mdkejam-laptop: as for your kind offer to do the pushing, I'm very interested. I'll have to explain a bit more the structure19:06
jam-laptopmdke: can you give me the URL so I can start downloading?19:07
jam-laptop(Oh, and if you have troubles, you can always ask questions in IRC)19:07
mdkejam-laptop: https://code.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy19:08
mdkejam-laptop: so the plan is to make xubuntu-hardy, kubuntu-hardy and edubuntu-hardy from that, and then make some amendments to those.19:08
jam-laptopI *think* I can register them under my name, and then assign rights to them to the ubuntu-core-doc group19:09
jam-laptopIf not, can I get added to the ubuntu-core-doc group?19:09
mdkesure19:10
mdkejam-laptop: then we hope to do the same thing with each of the branches from the svn repository, ubuntu-gutsy, kubuntu-gutsy and so forth (I haven't pushed an equivalent19:10
mdke... branch for those to Launchpad yet, but they share the revision history of the existing branch up there, as I understand it19:10
jam-laptopWell, it took 1m36s to download the 210MB from a very nearby server19:10
Lo-lan-doDo you guys keep every Ubuntu package under bzr?19:10
jam-laptopLo-lan-do: not yet19:11
jam-laptopI believe things are being migrated over19:11
jam-laptopbut it certainly isn't 100% of all packages19:11
mdkethat's my understanding too19:11
Lo-lan-doOkay.19:11
mdkejam-laptop: added to ubuntu-core-doc19:11
jam-laptopmdke: (jameinel, right?)19:11
mdke:)19:11
Lo-lan-do(I'm manually keeping a bazaar branch for my package, and I was wondering whether I was duplicating work)19:12
jam-laptopso you want an ubuntu, xubuntu, kubuntu, and edubuntu for all of -hardy, -gutsy,19:12
jam-laptopmdke: what are the specific permutations, so I'll get them all19:12
mdkeLo-lan-do: see https://wiki.ubuntu.com/BzrMaintainerHowto19:12
jam-laptop(my basic plan is just to write a simple bash for loop, and do some pushing)19:12
Lo-lan-domdke: Oh, but I am already keeping my package in bzr, it's the Ubuntu ones I track (in bazaar) by hand.19:13
mdkejam-laptop: the thing is, the ubuntu-hardy branch comes from the svn trunk. The plan is to add branches for each svn branch (so not the same material). As I understand it, they will all have the same revision history19:14
jam-laptopmdke: if they were branched around in svn they will likely share some history19:14
jam-laptop(probably not 100%)19:14
jam-laptopSo am I right with (ubuntu, xubuntu, kubuntu, edubuntu) and (hardy, gutsy, feisty, edgy, dapper) ?19:15
mdkejam-laptop: ah, so the bzr history will be different?19:15
mdkeI used svn-import to import the whole repository19:15
jelmermdke: That means you'll have a shared repository already, locally19:15
mdkeexactly19:15
jam-laptopJust that I would expect ubuntu-gutsy to have fewer revisions than ubuntu-hardy19:15
mdkeI have to leave you for a bit, sorry to be rude19:16
jam-laptopand maybe a couple extra that -hardy doesn't have19:16
jam-laptop(well, assuming they aren't 100% the same code base, they can't have 100% the same revisions :)19:16
jam-laptopmdke: np19:16
jam-laptopLo-lan-do: is your "official" source in Bazaar, or is it svn/cvs?19:19
Lo-lan-dojam-laptop: Upstream is in CVS, but I work on the packaging in bzr19:19
jam-laptopLo-lan-do: k, you may want to register your project with vcs-import, and Launchpad will maintain a conversion from cvs => Bazaar for you (for at least the 'trunk' branch.)19:20
jam-laptopThough if you just register your project19:20
jam-laptopand push up your Bazaar branch as trunk19:20
jam-laptopyou can use that too19:20
Lo-lan-doUh, sorry, s/CVS/SVN/19:21
Lo-lan-doBut I'm just asking, don't mind me.19:22
Lo-lan-doI'm quite satisfied with my branches so far, I was wondering if you had a branch for the package (so I could keep a copy and/or merge from it) or not.19:23
jam-laptopLo-lan-do: what is the package ?19:30
Lo-lan-dogforge19:31
jam-laptopeither way, if you read https://wiki.ubuntu.com/BzrMaintainerHowto it gives a pretty good description of how to integrate things with Launchpad19:31
jam-laptopLo-lan-do: I don't see a 'gforge' project registered19:32
Lo-lan-doIt's all right then.19:33
jam-laptopLo-lan-do: so is gforge sort of like Trac?19:41
Lo-lan-doBroadly19:41
Lo-lan-doIt's more like Sourceforge, actually, since it started as a fork of it19:42
mdkejam-laptop: ok, back. I've done a little explanation of what I have in my svn import (as a shared repository), and what I'd like to create on Launchpad, so that it's clearer. I think from what you said earlier that I actually have to upload one branch from here for each distribution, and you can't do all the work for me :)19:45
mdkehttp://paste.ubuntu-nl.org/41964/ <-- explanation19:45
jam-laptopmdke: what I *can* do is upload a fake branch for each one, which has all of the ubuntu-hardy revisions19:46
jam-laptopso that your future pushes only have to push the new/different data19:46
jam-laptopand not all of the common ones19:46
mdkebut the ubuntu-hardy won't have the ubuntu-feisty revisions, is that right?19:47
jam-laptopmdke: it will have the ones that are in common19:47
mdkeI'd previously assumed that bzr used the same revision history (from the shared repository) for them all19:47
mdkeright19:47
jam-laptopwhen you make a commit in ubuntu-feisty that will not be in the ubuntu-hardy ancestry19:47
jam-laptopmdke: are the files on your home machine somewhere that I could access them?19:47
mdkeI haven't made any commits since doing the svn-import19:48
mdkeyes, I'd have to setup ssh though, give me a bit19:48
jam-laptopmdke: when you do "bzr push" from a shared repository, we don't push 100% of the revisions, only the ones in the ancestry of the branch you are pushing19:48
mdkejam-laptop: ok, it's cleverer than I thought, all clear19:48
jam-laptopSo if you have a project with 10 revisions next to one with 10,00019:48
jam-laptopyou don't push 10,010 revisions for just a 10 revision branch19:49
mdkewould the "fake branch" solution be complicated by having revisions in ubuntu-hardy that aren't present in ubuntu-feisty? I.e. would me pushing the real ubuntu-feisty branch just result in those revisions being removed?19:49
jam-laptopmdke: they won't be removed, but they will stop being referenced19:50
jam-laptopso when someone downloads from the new ubuntu-feisty branch19:50
mdkeis that acceptable?19:50
jam-laptopthey won't get the superfluous ubuntu-hardy ones19:50
jam-laptopmdke: generally it is fine19:50
mdkei see19:50
jam-laptopI do it all the time here19:50
mdkeI'll give you access and then I'm happy to be guided by you on that19:50
mdkelemme just tweak the router19:50
jam-laptopI personally use 1 shared repository for all of my Bazaar and plugin work19:51
jam-laptop(and a different one for other projects)19:51
jam-laptopmdke: so am I correct in saying you want a branch for all the permutations of (ubuntu, xubuntu, kubuntu, edubuntu) versus (hardy, gutsy, feisty, edgy, dapper) ?19:52
mdkejam-laptop: yes19:53
jam-laptopk19:53
mdkejam-laptop: although tell me if that doesn't make sense as a workflow too19:53
jam-laptopI'm not sure I understand why you want a separate branch for all of (ubuntu, xubuntu, kubuntu, ..)19:54
mdkethey are separate packages and we want to store the debian directory for each in the same place in the directory structure. It will also allow us to remove unnecessary directories for each package19:55
jam-laptopSo I'm a little concerned about disk storage consumption, since it is approx 200MB x 4 releases x 4 os's = 3.2GB on Launchpad20:10
jam-laptop(that is also one reason why LP is looking into how to have LP-side shared repositories.)20:11
mdkeright20:11
jam-laptopDo you need the full set of permutations?20:11
jam-laptopOr would it be reasonable to just do 1 branch for edgy and dapper?20:11
fullermdSo, are you saying we should get all those branches pushed up ASAP, in order to bump the priority of the LP-side repo feature?   ;)20:12
mdkejam-laptop: yes, we could do one branch for everything except hardy and see how it goes, maybe create more if we think it would be very helpful. Is storage spac a problem on Launchpad?20:12
jam-laptopI don't know that storage space is super critical20:13
jam-laptopbut it is my understanding that if LP tried to host all of the LP branches on itself20:13
jam-laptopit would run out of disk pace20:13
jam-laptopspace20:13
jam-laptopbut LP is developed in a very distributed fashion20:13
jam-laptopso there are *lots* of branches20:13
mdkeshould I talk to someone about this?20:13
mdkemwhudson, for example?20:14
jam-laptopWell, we can summon him by name, but he may have gone home already20:14
mdkeindeed20:14
mdkeit was more of a general question20:14
jam-laptopyeah, but I think he might be someone who knows20:15
jam-laptopmaybe spiv20:15
datojam-laptop: (you mean storing all personal branches of people with commit access to launchpad itself? re the running out of space bit)20:15
mdkejam-laptop: an alternative would be to upload the derivative branches without revision history, i suppose20:16
mdkethat might be preferable to not having derivative branches at all20:16
mdkealthough I suppose the disk space would gradually build up20:16
jam-laptopdato: right20:17
jam-laptopmdke: well, is the disk space usage because you have lots of history, or because you have a big tree?20:17
jam-laptop(If you have 100MB in a checkout, then the history cost is actually pretty small)20:18
datojam-laptop: with trees, you mean? otherwise I'm having trouble grasping the idea.20:18
mdkeif it's the latter, then we'll be pruning the derivative branches so they have much less overlap20:18
jam-laptopdato: LP stores an independent repository for each branch20:18
mdkea recent svn checkout of svn trunk is 39MB20:19
jam-laptopdato: and 1 lp repository is 400MB20:19
datojam-laptop: ah, right20:19
datojam-laptop: I must be still sleeping, since that piece of information was said right before :)20:19
jam-laptopdato: which is one of the reasons on the checklist for why to do some sort of shared repositories20:19
jam-laptopmdke: so I'm going ahead and making all of the -hardy ones20:20
jam-laptopAnd I have some stubs (with 10 revisions) for a bunch of them20:20
mdkewhat does that mean?20:20
jam-laptophttps://code.launchpad.net/ubuntu-doc20:21
jam-laptopI created the permutations through feisty20:21
jam-laptopbut only pushed 10 revisions20:21
jam-laptopnow I'm going back and pushing the full history for *-hardy20:21
jam-laptopand then I'll push 1 for ubuntu-*20:21
mdkeah, the 10 revision thing is on purpose? it's not a problem?20:22
mdkephew20:22
jam-laptopmdke: right, I just wanted to get them started20:22
mdkehang on a sec20:22
mdkelet's take this tree vs revision history thing further20:22
mdkea recent svn checkout of svn branches/gutsy is over 700MB...20:22
mdkeso that would suggest the tree is very large20:23
mdkeI don't know where all that is coming from20:23
mdkeit may be that we can sort this out and have all the permutations, eliminate overlap in terms of tree size, and so cut down the disk space used20:24
jam-laptopwell, SVN always creates 2 copies of your working tree20:24
jam-laptop(1 pristine copy is stored in the .svn/ directories)20:25
mdkeI'm going to do an export to check20:25
mdkei.e. without the .svn directories20:25
mdkedamn this slow computer20:26
mdkeok, gutsy is about 317MB in a clean export. That would be cut down to about 200MB in the kubuntu and ubuntu branches, and very small for edubuntu and xubuntu20:32
mdkejam-laptop: I don't mind what we do with dapper/edgy/feisty for now, let's just do what we can. I already have taken too much of your time20:33
jam-laptopWell, right now your total .bzr/repository is about 200 MB20:33
jam-laptopAlso, I'm not sure that you can break it up quite that easily20:33
jam-laptopJust because in the past the branches had "X" which means that a conversion may preserve that20:33
mdkeI don't follow that, can you give me an example?20:34
jam-laptopIf I: bzr branch ...bzr.dev local; cd local; rm -rf lots of files; bzr commit -m "remove those files"20:34
jam-laptopwhen I 'bzr branch' this new branch with lots of removed files20:35
jam-laptopI still get the history for all the files which used to exist20:35
jam-laptop(since you can "bzr revert -r -10" and have it work)20:35
mdketrue20:35
mdkeso doing "bzr rm" will transfer the disk space from the tree to the history :)20:36
jam-laptopwell, bzr rm won't remove it from history20:36
jam-laptopjust the tree20:36
jam-laptop(it doesn't really "transfer" anything)20:36
jam-laptopSo is the plan to reorganize all your branches?20:36
mdkewhat you're saying is that bzr rm directory won't save space, right?20:36
jam-laptopSo that instead of having the "gutsy/ubuntu"20:37
jam-laptopyou would end up with just "ubuntu-gutsy" ?20:37
mdkeso if I go to the ubuntu-hardy branch and remove the "kubuntu" and "xubuntu" directories, then there won't be a space saving20:37
jam-laptopmdke: It only saves space in the Working Tree20:37
mdkeok, I'm following now20:37
mdkeso we have a space problem still20:37
jam-laptopnow this *might* be a reason to switch to a history-less conversion20:37
jam-laptopsince you are doing some major restructuring20:37
mdkewell, it's more of a split. The people working on kubuntu-hardy might want access to the revision history20:38
jam-laptopjust fyi, your full conversion is 684MB20:38
mdkebut I think the revision history is more of a luxury than a necessity, we can ditch it if it's important20:39
jam-laptopso there seems to  be a lot of stuff in branches/gutsy20:39
jam-laptopthat isn't in trunk20:39
mdkecorrect, translations20:39
mdkethese get added at the end of the release cycle for each branch20:39
jam-laptopto be clear, 470 MB of stuff :)20:39
mdkeyes20:39
jam-laptopwell, that may not be all in gutsy20:39
jam-laptopI suppose it could be the others as well20:39
mdke319MB is a clean gutsy export20:40
mdkecompare that with 16MB for trunk20:40
jam-laptopwhich should compress a bit, when it is stored in a repository20:41
jam-laptopbut still, a rather large difference20:41
mdkein 6 months time, hardy gets the same bump up20:41
jam-laptopAny chance it will be approximately the same data as in gutsy?20:43
mdkejam-laptop: sure, a lot of it. Not exactly files though20:43
jam-laptop(I'm just guessing that you are creating new files, when they are closer to copies from the other branch)20:43
mdkethe translations vary according to how much the original text varies from release to release20:44
mdkebut broadly the majority of the text is likely to be present in both20:44
mdkejam-laptop: so, what's your recommendation? :)20:47
jam-laptopmdke: well, right now I'm going to batch upload your conversion to a machine that is closer to LP using a tarball20:48
jam-laptopYour 'ubuntu-hardy' branch isn't huge yet20:49
jam-laptopso I would get it cleaned up quickly20:49
jam-laptop(split into the actual sub-projects)20:49
jam-laptopso that when you go to add the big files20:49
jam-laptopyou end up doing it in only the sub-projects20:49
jam-laptopIs there any development going on on the -gutsy/-feisty/etc branches?20:49
lifelessmoin20:50
jam-laptopmorning lifeless20:50
mdkeI'll be updating translations, and possibly fixing any serious bugs if we find some20:50
mdkehi lifeless20:50
mdkejam-laptop: so yeah, we'll be touching the -gutsy/-feisty branches, but it wouldn't be the end of the world to just have a single permutation for them (since that is what we do in svn now)20:51
jam-laptopmdke: so I would probably go with that20:57
jam-laptopleave pre -hardy branches alone20:57
jam-laptop(having 1 branch for all versions)20:57
jam-laptopand then start the split at -hardy20:57
jam-laptopmdke: by the way, you weren't kidding P-III 600MHz20:58
mdkejam-laptop: alright20:58
jam-laptop(*my* server is a dual P-III *700*MHz)20:58
mdkejam-laptop: yeah, my laptop is broken, I had to dig this one out as an emergency measure20:58
mdkehave to run Gnome on it and all21:00
bialixhi, have the question about dogfooding packs21:14
jelmer'evening Alexander21:15
bialixhi Jelmer21:15
bialixI don't see any instructions about packs in bzr.dev21:15
bialixI know it's hidden21:16
mDuffbialix: --experimental on init or init-repo21:16
bialixaha21:16
bialixwhat's the fuzz about reconcile?21:16
bialixcheck don't suggest it for my non-bzr.dev repos21:16
bialixmDuff: branch into pack repo will do conversion w/o problem?21:18
jelmerbialix: yep21:18
bialixhmm, it seems that branch works blazingly fast21:19
lifelessbialix: cool21:19
bialixhi, our white mage21:19
bialixlifeless: have any suggestions what I should check on win32 (except running selftest)?21:20
lifelesslet see, what things generally give headaches?21:20
lifelessbzr-svn stuff has long file ids21:20
lifelessif our minimum index read is too short that could fail21:20
bialixI don't use svn, can;t check21:20
lifelesswhat else21:21
lifelessis it better at being in deep directories/handling long paths/caps paths21:21
bialixwill try21:22
bialixlifeless: may I ask you comment on this: https://lists.ubuntu.com/archives/bazaar/2007q4/033058.html21:23
jelmerlifeless: so far, packs work really well here. The only thing that I've hit so far is NoSuchFile exceptions when I was doing heavy writing to a repository /and/ reading from it21:25
jelmerbut that was to be expected I guess, since it's moving files around21:25
jelmerto obsolete_packs21:25
lifelessjelmer: cool21:30
bialixlifeless: about deep directories/handling long paths/caps paths: I'm not sure what to test here, because knit file name is shorter that my very long file name for test (I create 127-symbol long filename, but in repository/knits there is 59 chars filename)21:32
lifelessbialix: reading it21:32
lifelessbialix: then it should be fine21:32
bialixlifeless: pack name is 37 chars long. so you win 59+3-37=25 chars21:34
bialixbut for obsolete_packs directory this win is smaller by 10 chars21:36
bialixI don't see why packs should change situation for bzr itself. may be for bzr-svn... but I never used it, can't say anything21:36
bialixtomorrow I'm planning to run the whole test suite21:37
lifelessvery cool21:38
bialix(it will take more than hour on my hardware, so I better do it on fast machine)21:40
* mDuff hasn't found any new issues with packs since yesterday (other than some slightly different server-mode exceptions when running commands other than push).21:40
lifelessmDuff: I am working on that delete bug; we iterate directory-at-a-time so I need a little care (a simple string comparison isn't enough to trim the array of deleted items)21:41
bialixlifeless: my biggest performance problem with bz 0.91 and before is slow machine (CPU <1GHz). The slowest is first run (cold cache I think), and during branch  build phase takes a lot of time21:43
jam-laptopI had some work that improved text extraction time (for build_tree)21:46
jam-laptopIt sort of conflicts with what lifeless has been doing21:46
jelmerLarstiQ: Hi21:46
jelmerLarstiQ, can you still reproduce bug 128496?21:47
ubotuLaunchpad bug 128496 in bzr-svn "Unable to open native working tree with non-ascii filenames" [Medium,Triaged] https://launchpad.net/bugs/12849621:47
bialixlifeless: I think we should say now not simply "packs", but: "packs!(TM)" :-)21:47
lifelessbialix: :)21:48
lifelessjam-laptop: I've largely finished with knits, the only remaining change I have planned there is to decouple 'parents' and 'compression components'21:49
bialixguys, I'd like to make new windows standalone installer (with packs) for earlier adopters. any objections?21:50
lifelessjam-laptop: I'd *like* to make it arbitrary so we can do the sort of crazy stuff we sketched on the list21:50
lifelessbialix: I think that would be nice21:50
bialixok21:51
lifelessjam-laptop: that will though impact fetching so we need some care that performance does not go out the window.21:51
bialixdone21:56
jam-laptoplifeless: I was pretty close to getting the parents list into the data portion of packs21:57
lifelessjam-laptop: that and the noeol indicator would be good too21:58
jam-laptopThe internal API changes aren't bad, but figuring out the implications to all the copying code will be a bit tricy.21:58
jam-laptoptricky21:58
lifelessI do think we should keep the cached index data21:58
lifelessabout this21:58
jam-laptopsure, but make it redundant21:58
jam-laptoprather than precious21:58
lifelessright21:58
bialixpacked repo is slightly bigger then knitted one22:01
lifelessthats unusual; we drop annotations and the indices are pretty close22:02
lifelessperhaps you have something in .bzr.backup, or already have .bzr/repository/obsolete-packs ?22:02
bialixwell after initial branch from knits to pack I have 5038KB vs 5076KB for my own biggest repo22:03
bialixit's the size of .bzr/repository directory22:04
lifelessinteresting22:04
bialixno, obsolete dir is empty22:04
bialixafter initial branch I have only one pack with the size 4277KB22:05
lifelesshmm22:05
bialixand 818KB of indices22:06
lifelessoh, are you reporting apparent size or used disk size ?22:06
lifelessI did mos of my comparisons on used disk size, which includes wasted space in allocated block/clusters/inodes/whatever22:06
lifelesss/mos/most/22:06
bialixit's the size that I see in my FAR22:06
bialixusually it's real size22:07
lifelessright22:07
lifelessin which case yes I think this is a reasonable result22:07
bialixin my old knit repo size of directory .bzr/repository/knits is 3227KB22:07
bialixand inventor.knit 1250KB22:08
bialixif annotations should be dropped then packed repo should smaller?22:08
bialixshould be smaller, typo22:09
lifelessso22:09
lifeless3227 + 1250 + revision.knit + signature.knit ?22:09
lifeless3227 + 1250 is 4470KB, which is larger than the .pack file :)22:10
lifelessadd in revisions and it should be a bigger difference still22:10
bialixoh! just ran 'bzr check' in source branch and got: 1824 inconsistent parents22:12
bialixI need to run reconcile?22:12
lifelessif its not bzr.dev, it will probably run ok without reconcile22:12
lifelessif it is bzr.dev, you won't be able to branch from the pack version to another pack version.22:13
bialixno, it's my own repo22:13
lifelessI wouldn't worry about reconcile until andrew gets the additional fix done22:13
lifelessthen push all your data to knits format, reconcile it there, and make a clean pack repo22:13
bialixbut '1824 inconsistent parents' is scare me22:13
lifelessits likely that they are [A,B] vs [B,A] as at one point we didn't guarantee ordering.22:14
lifelessin bzr.dev we have worse22:14
bialixit scares me because I have 672 versioned entries and 942 revisions22:15
lifelessits per-file22:15
bialixah22:15
bialixwhat's the simplest way to obtain real file size via python?22:19
lifelessos.lstat(path).st_size22:19
lifelesshmm, what module to put this in22:19
lifelessI'm writing a little object to handle deletes; it will be given every path, and given new deletes22:20
lifelesswhen a path is such that one of the deletes it's seen can not be a parent of any future path, it will drop it22:20
jam-laptoplifeless: did you see my possible alternate that used a dictionary?22:21
jam-laptopotherwise is_inside_any is an osutils function, IIRC22:21
lifelessjam-laptop: no. Just path split and walk a tre ?22:21
jam-laptoplifeless: basically22:21
jam-laptopmost paths get rejected quite early22:22
lifelesshave you tested this? is there a patch ?22:22
jam-laptoplifeless: no, it was just a suggestion22:22
lifelessso is_inside_any is osutils22:22
bialixlifeless: ok, so sum total of all knit files in old repo is 460131022:22
lifelessI guess if I make a replacement is_inside_any osutils is the right place; I was thinking of a alongside-helper.22:23
jam-laptoplifeless: where where is it being used?22:23
jam-laptopIn commit?22:23
lifelessyes22:23
bialixand pack has size 437986722:23
lifelessbug 15649122:23
lifeless100K commit, 8K deleted files, == 15 minutes to commit22:24
bialixpack smaller, but the whole repo slightly bigger22:24
ubotuLaunchpad bug 156491 in bzr "commit with many deletes spends much time in is_inside_any" [Undecided,New] https://launchpad.net/bugs/15649122:24
bialixfirst error with packs: bzr: ERROR: Must end write groups before releasing write locks.22:26
bialixwhen I try to `bzr branch` second branch from knit to pack22:26
bialixif I clone treeless branch into shared-repo with trees enabled, it should work?22:27
bialixbranch w/tree has the same error during clone22:29
lifelessit should; either something was using the write group api directly, or you had an exception occur somewhere that is missing a try:except:else:22:29
lifelessif you change that exception that is being raised to be a 'pass', you should see the real exception22:29
bialixsent to list22:36
lifelessbialix: right, you need to change the excpetion raise to a pass temporarily to debug22:39
lifelessbialix: it raises an exception because data loss can occur22:39
bialixwhere to change?22:39
bialixmay be it's important detail: second branch is subset of first branch, i.e. all data is already cloned by first branch22:40
lifelesspack_repo.py 153822:40
bialixPermissionDenied then22:42
lifelessright, thats the bug then :)22:43
lifelesscould you please file a bug in lp, tagged packs, with the backtrace you got this time ?22:43
bialixok22:43
bialixwait22:45
bialixthis time it's error in raise error agin22:46
lifelessPermissionDenied sounds like a file system issue though?22:46
lifelessoh! I bet its the transaction cleanup. We have to close the file before removing.22:46
lifeless=== modified file 'bzrlib/repofmt/pack_repo.py'22:47
lifeless--- bzrlib/repofmt/pack_repo.py 2007-10-24 05:17:39 +000022:47
lifeless+++ bzrlib/repofmt/pack_repo.py 2007-10-24 21:48:01 +000022:47
lifeless@@ -274,6 +274,7 @@22:47
lifeless     def abort(self):22:47
lifeless         """Cancel creating this pack."""22:47
lifeless         self._state = 'aborted'22:47
lifeless+        self.write_stream.close()22:48
lifeless         # Remove the temporary pack file.22:48
lifeless         self.upload_transport.delete(self.random_name)22:48
lifeless         # The indices have no state on disk.22:48
bialixhttp://pastebin.com/m7ed4075c22:48
bialixlifeless: ^22:48
lifelesstry that patch please22:48
lifelessif it fixes the problem, revert your other changes and just send it in :)22:49
lifeless(to pqm I mean - +1 from me and you should do it )22:49
bialixerror 32 on windows it's: 32 The process cannot access the file because it is being used by another process.  ERROR_SHARING_VIOLATION22:50
lifelessbialix: yes, I think my patch will fix it22:51
bialixlet me a couple of seconds22:52
bialixyeah, clone is successfull now22:53
bialix(when you linux guys teach yourself to close files explicitly?)22:53
lifelesshey now22:54
lifelessI used to be a core cygwin guy22:54
lifelessits taken me years to forget about files22:54
bialix:-D22:54
bialixso you want me to send this patch to PQM?22:56
lifelessthat one liner yes please22:58
lifelessits trivially correct, and the test suite on windows will fail without it22:58
bialixok, will do22:58
bialixanybody know is 'Linus Torvalds on Git' talk is available as text somewhere in the net?23:00
datobialix: google "google video torvalds git"23:02
bialixI have video, I'd like to have plain text because I'm not very good in english23:02
datobialix: aah, sorry. I missed the "as text" in your line, sorry.23:03
bialixit's nice talk, and I really like this guy, he talk very much about distributed system in generals, not about git tiny details23:04
tchanhttp://git.or.cz/gitwiki/LinusTalk200705Transcript23:05
tchangoogle search for "linus torvalds git transcript" and that URL pops up as the first response23:05
bialixtchan: wow, thank you, you save my day. I owe you beer23:06
bialixwho this guy Andrew, who speaks first 10 secs?23:07
tchanthe Google employee that arranged for Linus to give the lecture23:07
bialixthanks23:09
tchanperhaps its "Andrew Morton" also a kernel hacker god ?23:09
bialix"where is Linus, why hasn't he merged my tree -- he does not love me anymore". :-) probably23:10
hendrixskianybody have problems with pushing a bzr branch into an ftp server?23:14
lifelesshendrixski: probably your server does not support REST/APPE23:14
hendrixskiI'm on version .15 (standard from ubuntu feisty because the one on the bazaar-vcs didn't want to work)23:14
lifelesshendrixski: you might try bzr.dev which has a new format you can use (currently labelled '--experimental') and this works much better on FTP23:15
hendrixskilifeless, oh... so just because I can ftp into it, doesn't mean I can push stuff on it?23:15
lifelesshendrixski: some FTP servers disable parts of the protocol23:15
lifelesshendrixski: for FTP, bzr 0.15 requires the REST/APPE commands to work23:15
hendrixskiI C. and that's only fixed in the current dev branch?23:16
lifelessthats right23:16
lifelessnew disk format that does not need the ability to append data to an existing file.23:16
hendrixskican I just FTP my folder with the bzr information using ftp and then can people can branch from that?23:16
lifelesssure23:16
lifelessthat will work fine23:16
lifelessthough you may get errors from your client23:16
lifelessfor the same reason -23:17
hendrixskiwith a standard ftp send?23:17
lifelessyes, because bzr changes the content of files, and your client will need to know to delete the file at the remote end and upload the new one23:18
hendrixskiah.. you mean for when I over-write changes in the future23:19
lifelessyes23:19
lifelessnDuff: I think I have your fix.23:19
hendrixskiI C23:20
lifelessnDuff: just profiling to make sure its not a regression in the common case23:20
lifelessnDuff: which it is somewhat23:27
ddaajelmer: hello23:44
ddaajelmer: I need your help as buddy for a bug in svn 1.4.423:45
lifelessnDuff: ok, its fixed, pushing it in a second23:45
ddaanDuff: hey nDuff23:45
ddaa(that was redundant...)23:45
jelmerddaa: Hi23:46
ddaajelmer: come to #svn?23:46
ddaaI exposed my problem there, but nobody seemed to care enough to reproduce it :/23:47
lifelessnDuff: its revno 2856 in the same branch you've been testing with23:51
lifelessnDuff: I'm popping out for a few minutes, its just reannotating into knit format at the moment.23:51
patternare there any tools or docs that could help me migrate projects from RCS to bazaar?23:54
ddaao.O RCS, as in /usr/bin/co ?23:55
mlhwhere's the best place to browse bzr source?  it's not obvious (to me) how to do it in launchpad23:55
ddaamlh: https://code.edge.launchpad.net/~bzr/bzr/trunk23:56
patternddaa: yep :)23:56
mlhah nevermind, found it23:56
ddaathen click on "Browse code"23:56
mlh"code" tab23:56
patterni never bothered to learn cvs... so all my personal projects are in RCS23:57
patternso now that i'm starting to get with the times, i'd like to migrate them to bazaar, if possible23:57
ddaalooks like you'll have to write your own conversion tool23:58
ddaaeven Tailor does not appear to support RCS23:58
pattern**sigh**23:58
mlhpattern: you can convert from rcs with cvs2svn, then use bzr-svn23:58
ddaamaybe you can find something to convert RCS->CVS, then use Tailor?23:58
patternwell, can't say i'm surprised23:58
patternah yeah, that's a good idea, mlh23:59
patternboth of you :)23:59
mlhrcs is close enough to cvs that you can just put some (empty) cvs crap to convince tools that your rcs is actually cvs23:59
mlhthere are howtos floating around somewhere23:59

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