| antoranz | http://www.pastebin.ca/1030503 | 00:00 |
|---|---|---|
| spiv | Ah, you need "from bzrlib.workingtree import WorkingTree" | 00:01 |
| antoranz | oh, ok | 00:02 |
| antoranz | let me try | 00:02 |
| antoranz | ok.... I got another error mesage... let's see where I get to. :-) | 00:03 |
| antoranz | OK.... I got the working tree.... how could I ask for added files? | 00:12 |
| jml | is there a "getting started with Bazaar" doc that I'm missing? | 00:13 |
| antoranz | in bazaar's docs you can see the five minute intro doc... which is a nice crash course | 00:13 |
| spiv | antoranz: maybe take a look at how bzrlib.status.show_tree_status is implemented, or how bzrlib.builtins.cmd_added is implemented. | 00:14 |
| antoranz | well.... that's quite reasonable.. let me see the show_tree_status | 00:15 |
| jml | is it possible to set the public_branch on a branch using the CLI? | 00:54 |
| mwhudson | jml: the help for bzr send claims that it will remember the public branch, i think | 00:55 |
| jml | mwhudson: it appears that my trunk has no public branch set. | 00:55 |
| mwhudson | jml: bzr send ../trunk http://whatever --remember | 00:56 |
| mwhudson | and then it will | 00:56 |
| mwhudson | if the docs are correct anyway :) | 00:56 |
| jml | mwhudson: so the public_branch arg to 'send' is the public_branch of the submit branch? | 00:56 |
| jml | not the public branch of the branch being sent? | 00:56 |
| mwhudson | jml: oh i see | 00:58 |
| mwhudson | i guess you can run send -o/dev/null in the trunk branch to set it | 00:58 |
| mwhudson | or maybe there's some more sensible way | 00:58 |
| antoranz | got it! | 01:06 |
| * jml does the up-thread; commit dance | 01:06 | |
| antoranz | but I worry about the way the working tree tells me about changed files | 01:06 |
| jml | antoranz: how so? | 01:07 |
| antoranz | Let me paste the code in the pastebin so you can see. | 01:07 |
| antoranz | http://www.pastebin.ca/1030550 | 01:10 |
| antoranz | I get the filename from an array | 01:11 |
| antoranz | I wonder if that structure changes often. I think an object would be more "elegant" | 01:12 |
| antoranz | jml: see what I mean? | 01:13 |
| jml | antoranz: kind of. | 01:13 |
| jml | antoranz: the return type doesn't change very often at all (grep NEWS for iter_changes) | 01:14 |
| spiv | antoranz: unfortunately, objects are considerably slower than tuples :( | 01:15 |
| jml | right. | 01:15 |
| antoranz | well... speed is a nice explanaition for it... the code is working though. :-) | 01:15 |
| jml | all things being equal, I'd use an object instead of a tuple. However, given that this is performance critical code, there'd need to be some obvious benefit for using an object. | 01:15 |
| antoranz | how's the code? A1? :-D | 01:16 |
| antoranz | considering it's my first python program | 01:16 |
| Odd_Bloke | OTOH, in Python 2.5 (I think), you can 'name' the fields of a tuple. So eventually, perhaps... :p | 01:16 |
| jml | antoranz: it's ok. | 01:17 |
| antoranz | ok | 01:17 |
| antoranz | will ./ work in windows? | 01:17 |
| jml | antoranz: if you bump into a really big file, you'll have memory problems. | 01:17 |
| antoranz | or is there a straight way to get the pwd? | 01:17 |
| jml | antoranz: os.getcwd() | 01:18 |
| antoranz | well.... file are not so big right now.... so I guess it's ok for the foreseeable future | 01:18 |
| jml | antoranz: also, you want to make sure you don't run convert2unix on binary files. | 01:18 |
| antoranz | if file start to grow, II'll change it to process line by line instead of loading the whole file into memory | 01:18 |
| jml | antoranz: there's no need for the exit(0) at the end also, | 01:18 |
| antoranz | is there a piece of information that tells me if the file is binary? | 01:19 |
| spiv | Odd_Bloke: 2.6 has collections.namedtuple | 01:19 |
| antoranz | I guess "kind".... but what are the possible values? | 01:21 |
| jml | antoranz: not that I know of. (but I'm pretty ignorant in this area) | 01:21 |
| spiv | antoranz: "kind" is for distinguishing files/directories/symlinks etc | 01:21 |
| antoranz | also, I shouldn't work on directories. | 01:22 |
| antoranz | it's cambio[6][1] | 01:22 |
| spiv | There's nothing in bzr at the moment that tracks if a file is meant to be "text" vs. "binary". igc is working on adding a feature like that, though. | 01:22 |
| antoranz | ok.... I'm working on text file for now... so I guess that's not a problem actually. | 01:23 |
| Odd_Bloke | spiv: Ah, perhaps that's what I meant. | 01:25 |
| Odd_Bloke | I just remember being given some code which used them and it not working for me. | 01:25 |
| Odd_Bloke | Which suggests that it wouldn't work in 2.5, now I reflect on it. | 01:25 |
| spiv | Odd_Bloke: :) | 01:25 |
| antoranz | how do you say "!=" in python? | 01:26 |
| spiv | Just like that. | 01:27 |
| antoranz | ok... the problem was that I'm forgetting about using ":" at the end of the conditional. | 01:28 |
| jml | antoranz: oh, that reminds me: use 'fileName is None' rather than 'fileName == None' | 01:31 |
| jml | for reasons that have long since escaped my mind. | 01:31 |
| antoranz | ok | 01:33 |
| spiv | Faster, more precise, less punctuation. | 01:33 |
| jml | spiv: thanks. | 01:34 |
| igc | poolie: any thoughts on whether filtering ought to be applied to .bzr* files? | 01:34 |
| spiv | (In particular, it's immune to a weird __eq__ or __cmp__ that might claim that a non-None object is equal to None) | 01:34 |
| igc | abentley asked in his review whether it ought to be skipped for .bzrignore | 01:35 |
| igc | I wonder whether Windows users would expect .bzrignore to have crlf or not | 01:35 |
| TheSheep | igc: make a compromise, use crlf every second line ;) | 01:40 |
| mwhudson | or go for the annoy everyone approach, and just use \r :) | 01:41 |
| igc | TheSheep, mwhudson: interesting ideas. That ought to maximise the confusion. Maybe we could combine those ideas ... | 01:42 |
| igc | and have lf, crlf, cr alternating | 01:42 |
| igc | or make it random at the end of each line - better still :-) | 01:43 |
| antoranz | guys, thanks 4 ur kind help | 01:43 |
| antoranz | C ya later! | 01:44 |
| poolie | igc, i would say it probably should be applied for consistency; if the user configures it to be broken it's their responsibility | 01:45 |
| poolie | uh, we should probably accept either separator in those files | 01:45 |
| poolie | spiv, just trying to wrap up here then will leave | 01:45 |
| * beuno waves | 01:47 | |
| beuno | hi everyone | 01:47 |
| mwhudson | hi beuno | 01:48 |
| beuno | LP code scanner still seems lagged | 01:49 |
| poolie | hello beuno | 01:49 |
| poolie | hello mwhudson | 01:49 |
| beuno | I wonder how big the branches that where added really are... | 01:49 |
| beuno | hello poolie | 01:50 |
| beuno | so... mwhudson... I've been thinking performance all day | 01:51 |
| beuno | aside from switching the templating engine, I've been thinking that, even if we improve the cost of rendering, it will still be rather expensive for some operations | 01:52 |
| beuno | so it got me thinking how we can avoid that cost | 01:52 |
| beuno | anyway, what do you think of adding a json generator, that we can can ask for via ajax, and refresh the screen's information with that? | 01:54 |
| beuno | we would only render the HTML once, and the client will render from then on | 01:54 |
| beuno | it can be added to the current code base, and used optionally (we would still be able to render all pages) | 01:55 |
| beuno | and cache the jsons on the client side, so once he retrieves a set of information, we can avoid as much as possible to hit the server again | 01:56 |
| jml | beuno: do you know that roundtrips are the main bottleneck? | 01:57 |
| beuno | and, if performance still is a bottle-neck for repeated request for the same screen, we can still implement a server side cache | 01:57 |
| beuno | jml, I have no information at all of what the real bottlenecks are, just guesses from playing around with the code | 01:58 |
| beuno | it's almost as expensive to render an annotated file than it is to annotate it with bzr | 01:58 |
| beuno | that seems like something we need to solve | 01:58 |
| beuno | (no information on LP, that is) | 01:59 |
| jml | beuno: sure. That said, it's worth spending some time profiling to be certain that you are solving the right problem. | 01:59 |
| beuno | jml, right, I have been profiling the code, and rendering *is* the main problem curently | 01:59 |
| beuno | just not what specifically is bashing the LP so hard | 02:00 |
| jml | ok. | 02:00 |
| beuno | so, while we may find a better templating engine, it will still be a cost we will pay | 02:01 |
| jml | *nod* | 02:01 |
| beuno | and we can generate json files without rendering them through it, and serve them (maybe even avoiding turbogears, and get one step closer to get rid of so many dependencies) | 02:02 |
| mwhudson | beuno: it's certainly an interesting idea :) | 02:07 |
| beuno | mwhudson, :) so, my next still is profiling with different templating engines, unless you have a different request | 02:09 |
| mwhudson | beuno: i think that's sensible yes | 02:10 |
| jml | what should I do to work around this? bzr: ERROR: Repository KnitPackRepository('file:///home/jml/Code/gtimelog/.bzr/repository/') is not compatible with repository SvnRepository('http://mg.pov.lt/gtimelog/svn') | 02:24 |
| jml | oh, I see, there's a Subversion repo format now | 02:25 |
| jml | has that always been there? | 02:26 |
| Peng | jml: bzr-svn? | 02:28 |
| jml | Peng: yes. | 02:28 |
| Peng | jml: I dunno. It's been there as long as I can remember, but that's only a few months. | 02:28 |
| rockstar | The Bazaar slogan should be "Make like a tree and branch" | 02:34 |
| spiv | jml: probably "bzr upgrade --rich-root-pack" | 02:35 |
| Peng | rockstar: Heh. | 02:40 |
| Peng | rockstar: I'm not sure that's a very good slogan, but I definitely like it. :) | 02:41 |
| rockstar | Peng, what's so bad about it? :) | 02:42 |
| Peng | Wait a minute. Slogans don't need to be a pile of information. Never mind about not thinking it's a good slogan. :) | 02:45 |
| Peng | But it could say more about bzr's focus. | 02:45 |
| jml | the error I get now is: http://pastebin.ubuntu.com/14954/ | 02:46 |
| jml | SubversionException: ("REPORT request failed on '/gtimelog/svn/!svn/vcc/default'", 0) | 02:47 |
| spiv | jml: random guess: retry | 02:49 |
| jml | spiv: it's happened 3/3 times | 02:51 |
| spiv | jml: bzr -Dtransport -Dhttp perhaps. | 02:53 |
| spiv | jml: but basically I think you're in bug report territory. | 02:53 |
| jml | ok. | 02:53 |
| jml | I'm using whatever bzr-svn that 'bzr branch lp:bzr-svn' gives me. Is there another branch I should be using? (maybe the one called 'trunk'?) | 02:54 |
| Peng | jml: Try using a release. (bzr revert -r tag:bzr-svn-0.4.10) | 02:55 |
| beuno | abentley, I sent a merge request which was rather large (1.7mb), and it seems BB hasn't picked it up yet. https://lists.ubuntu.com/archives/bazaar/2008q2/042455.html | 02:58 |
| spiv | jml: I strongly recommend sticking to released versions, or at least the "stable" branch. | 02:59 |
| jml | spiv: it's not clear what the "stable" branch is, looking at lp.net/bzr-svn | 03:00 |
| Peng | There isn't a stable branch, really. | 03:01 |
| jelmer | 0.4 is the stable branch | 03:01 |
| jelmer | (most of the time) | 03:01 |
| Peng | Yeah, but wasn't it unstable from 0.4.9 to 0.4.10? Like, for 6 weeks? | 03:02 |
| jelmer | yeah, it tends to regress from time to time | 03:02 |
| Peng | I run bzr.dev, but bzr-svn 0.4.10. | 03:02 |
| jelmer | at the moment, the 0.4 branch passes all tests though so it should be considered stable | 03:03 |
| jml | jelmer: does http://pastebin.ubuntu.com/14954/ | 03:10 |
| jelmer | jml: hmm, that is a regression | 03:12 |
| jelmer | I have a local clone of gtimelog here made with an earlier release of bzr-svn | 03:13 |
| jelmer | unfortunately the testsuite doesn't catch this as we don't test svn over http (because it requires setting up apache) | 03:13 |
| jelmer | that shouldn't matter as the subversion libraries promise one API for all three protocols, but there are subtle differences | 03:14 |
| jelmer | jml: please file a bug | 03:14 |
| jml | jelmer: will do. | 03:14 |
| === mwhudson__ is now known as mwhudson | ||
| chmac | Is there a trac equivalent for bazaar? I found the bzr-trac plugin, but I wondered if there was something different | 03:31 |
| poolie | chmac: there's also 'cart' | 03:55 |
| chmac | poolie: Sweet, thanks, I'll check it out | 03:56 |
| chmac | poolie: Any idea how far along it is? | 03:57 |
| uniscrip1 | given a .bzr repository, is it possible to find out what branches are in it? | 03:59 |
| Peng | uniscrip1: You can use the heads plugin to see the current heads. | 04:02 |
| uniscrip1 | Thanks for that. I notice that if I delete subdir branches from a repo they become dead | 04:12 |
| uniscrip1 | is there any way to revive them? | 04:12 |
| Peng | uniscrip1: Find the revid, and bzr branch -r revid:... | 04:13 |
| * igc lunch | 04:15 | |
| uniscrip1 | Peng: returns "ERROR: Not a branch" | 04:16 |
| Peng | uniscrip1: You need to do it from a branch. | 04:16 |
| uniscrip1 | and lists the path to where I want to put the new (old) branch under the repo | 04:16 |
| uniscrip1 | I have a repo with a bunch of dead branches how do I revive one (get it out into a full branch)? | 04:17 |
| uniscrip1 | if I have no branch how do I 'do it from a branch'? | 04:17 |
| bob2 | cd /repo ; bzr branch -r revid:23890174kj234h1k2j34hk1l24h12kj4123l47897 /somewhere/to/put/it | 04:19 |
| uniscrip1 | bzr branch -r revid:mhosken@sil-mh4-20080527025333-o3z49yp16xykkwg6 ../test_branch | 04:20 |
| uniscrip1 | bzr: ERROR: Not a branch: "/home/mhosken/Work/dev/shorts/repos/repo_test/test_branch/". | 04:20 |
| uniscrip1 | same if I change ../test_branch to fred | 04:20 |
| uniscrip1 | or . fred | 04:20 |
| uniscrip1 | bzr 1.3.1 btw | 04:21 |
| bob2 | oops | 04:22 |
| spiv | Ideally that should work. Probably worth a bug report. In the meantime, do it from any branch in the repo (even if you just create an empty one with "bzr init"). | 04:23 |
| uniscrip1 | OK. Thanks for that | 04:24 |
| abentley | beuno: Appears to have been caught by my spam filter. I don't get much legitimate email in spanish. | 04:45 |
| beuno | abentley, lol, understandable | 04:52 |
| abentley | beuno: I should have it processed in the next few hours | 04:52 |
| beuno | abentley, thanks | 04:53 |
| * igc pick up kids | 05:52 | |
| mwhudson | beuno: so i checked out the latest version of your branch, it looks fine | 05:55 |
| mwhudson | well, apart from using log._strip_NULL_ghosts | 05:56 |
| Rhamphoryncus | "bzr check" has been stuck in "checking versionedfile" for several hours. Should I leave it for a couple days? ;) | 07:21 |
| jamesh | Rhamphoryncus: how big a branch is it, and how are you accessing it? | 07:26 |
| Rhamphoryncus | previous step said 40000. Fairly large project | 07:27 |
| Rhamphoryncus | local files | 07:28 |
| Rhamphoryncus | oh, current step says 0/10727 | 07:32 |
| * igc dinner | 08:35 | |
| === yacc_ is now known as yacc | ||
| * gour likes --lightweight checkouts with treeless repo and using 'switch' to change working branches | 10:32 | |
| Jc2k | gour: is there a good description of that online somewhere? | 10:43 |
| gour | Jc2k: see paragraph in http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#checkouts section | 10:43 |
| Jc2k | gour: can this work like Gits branches? or is there still a directory for each branch? | 10:45 |
| gour | Jc2k: i created (for a test) shared repo (--no-trees), then one branch within it and then did some 'hacking' in another dir after checking out. created another 'feature' branch and then was able to 'switch' between the two. | 10:45 |
| gour | Jc2k: no idea. git is not on my todo list...i'm coming from darcs | 10:46 |
| luks | Jc2k: still one directory per branch, but you normally don't see those directories | 10:46 |
| gour | Jc2k: there is only one 'working' directory and bzr switch populates it with appropriate working tree | 10:46 |
| Jc2k | background here is that i'm wanting to extend the Bazaar/GNOME documentation, and Git people cite this as something important to them | 10:47 |
| Jc2k | luks: where would the directories be? | 10:47 |
| Jc2k | repo/branch1, repo/branch2, repo/working_copy ? | 10:48 |
| gour | repo/working can be anywhere | 10:48 |
| === weigon_ is now known as weigon | ||
| luks | Jc2k: anywhere under the shared repository | 10:49 |
| luks | Jc2k: you can put them to a dotted directory and never see them | 10:49 |
| Jc2k | so i could: | 10:50 |
| Jc2k | bzr init-repo . | 10:50 |
| Jc2k | bzr branch some/branch . | 10:51 |
| Jc2k | whoops | 10:51 |
| Jc2k | i meant | 10:51 |
| Jc2k | bzr branch some/branch .branches/trunk | 10:51 |
| Jc2k | bzr co --lightweight-command-foo .branches/trunk . | 10:51 |
| Jc2k | so the repo and working copy are in same folder | 10:51 |
| luks | you can do that, but it's probably not the best layout | 10:52 |
| luks | better to have the repo with branches outside of the working copy | 10:52 |
| gour | Jc2k: i'd keep working dir out of shared repo | 10:52 |
| Jc2k | i agree | 10:52 |
| Jc2k | the git people likely won't buy it, though :) | 10:53 |
| gour | Jc2k: you buy it ;) | 10:53 |
| Jc2k | it would be nice for jhbuild integration their way, though | 10:54 |
| gour | any news about emacs' adoption of bzr? | 10:55 |
| trepca | its integrated into it already ? | 11:01 |
| trepca | at least i can use it easily | 11:01 |
| trepca | well, except for diffs | 11:02 |
| jml | gour: nothing yet. I think they are waiting on savannah and a couple of specific performance improvements. | 11:02 |
| gour | jml: let's hope it will happen soon | 11:03 |
| jml | trepca: I use dvc in emacs with bzr and use it to get diffs all the time. | 11:03 |
| trepca | oh! | 11:05 |
| trepca | how did you install it | 11:05 |
| trepca | i use aquamacs | 11:06 |
| trepca | didn't manage to get it working | 11:06 |
| jml | trepca: I just dropped it into my load-path | 11:06 |
| trepca | damn | 11:07 |
| jml | (load-file "/home/jml/Code/dvc/++build/dvc-load.el") | 11:07 |
| jml | trepca: I just have that in my .emacs | 11:07 |
| jml | trepca: and followed whatever build instructions were in the tarball. | 11:07 |
| mwhudson | is aquamacs any good? | 11:08 |
| mwhudson | i've always been quite suspicious of it on principle | 11:08 |
| trepca | hm, there is not dvc-load in my tarball | 11:09 |
| trepca | aquamacs works great for me | 11:09 |
| trepca | jml: btw, where did you get the tarball ... seemed to me that you can only checkout the source form the DVC site | 11:11 |
| gour | hmm, i put: checkout=checkout --lightweight in ALIASES section of conf file. however, if i use bzr co it is not in effect although i might expect it to be? | 11:12 |
| jml | trepca: by "tarball", I meant "checkout" it appears. "bzr branch http://bzr.xsteve.at/dvc/" | 11:12 |
| trepca | mhm | 11:14 |
| jml | trepca: I just pulled the latest -- './configure; make' builds a dvc-load.el in the top-level directory for me | 11:16 |
| trepca | woohoo! works! | 11:25 |
| trepca | thanks! | 11:25 |
| trepca | jml: how do you view the log with dvc ? | 11:43 |
| jml | trepca: uhh, I don't generally. | 11:44 |
| trepca | ok | 11:44 |
| james_w | hey jml | 11:45 |
| jml | james_w: hi | 11:45 |
| james_w | did you get back ok? | 11:45 |
| jml | james_w: sorry I had to bolt before your set the other day | 11:45 |
| james_w | no problem. | 11:45 |
| jml | james_w: yeah, I got back fine. Had to fight a couple of bears to get past the checkin desk, but that's no big deal | 11:46 |
| trepca | jml: what about creating diffs with another revision...not head | 11:54 |
| jml | trepca: I use the command line for that too :) | 11:54 |
| jml | trepca: basically, both of those ops are outside my normal dev cycle. | 11:55 |
| jml | trepca: so I don't mind switching out of emacs | 11:55 |
| trepca | so what is the purpose of dvc then :) ? | 11:55 |
| === sabdf1 is now known as sabdfl | ||
| * gour is fetching emacs from bzr repo | 12:56 | |
| === Pilky_ is now known as Pilky | ||
| awilkins | Last night I asked about the Python installers for bzr/win32 : since I had most of the dependencies anyway I built my own ; would they be wanted/trusted for the downloads page? | 13:36 |
| james_w | awilkins: I'm not sure, though I don't see why not. | 13:55 |
| james_w | perhaps mailing to the list first would be a good idea. | 13:55 |
| lamalex | Hey guys, I'm trying to push to launchpad, but I keep getting a message about being unable to obtain a lock, and that it's help by me on "host vostok" | 14:02 |
| lamalex | how can I get rid of that lock, and why did that happen | 14:02 |
| bimberi | lamalex: bzr break-lock [LOCATION] | 14:08 |
| lamalex | merci beaucoup | 14:16 |
| lamalex | is there a way to check if it's locked? I just tried to push again and it still said it was locked | 14:32 |
| === kiko-afk is now known as kiko | ||
| james_w | lamalex: launchpad is a bit weird here | 14:44 |
| james_w | you probably need to run the break-lock command a few times. | 14:44 |
| james_w | and use sftp:// rather than bzr+ssh:// as well I believe. | 14:45 |
| * bimberi takes note - for next time :) | 14:47 | |
| lamalex | weird | 14:47 |
| lamalex | I'll try that | 14:47 |
| lamalex | it's not even showing up as locked in bzr info | 14:47 |
| lamalex | so just s/bzr+ssh/sftp | 14:48 |
| asabil | iirc you need to run break-lock twice | 14:49 |
| asabil | and it doesn't matter if using sftp or bzr+ssh | 14:49 |
| lamalex | Is that a bug? | 14:52 |
| asabil | don't know | 14:53 |
| lamalex | sounds like it | 14:53 |
| lamalex | there we go, it's pushing now. Thanks guys | 14:54 |
| * lamalex wants to kill bzr | 15:02 | |
| lamalex | It's telling me the branches have diverged, and to merge, but when I do a merge, it says nothing to do | 15:02 |
| Kinnison | Are the two branches public, can we see? | 15:03 |
| lamalex | the one branch is local on my hd | 15:04 |
| lamalex | do you want the output of bzr info or somethign? | 15:04 |
| Kinnison | It was more for me to try the pull/merge/diverge check | 15:05 |
| luks | are you sure you are merging from the same branch you are trying to push to? | 15:05 |
| Kinnison | can you please run 'bzr missing url-to-push-location' ? | 15:05 |
| lamalex | I fixed it, I don't know how this happened but it dropped /trunk off of the url | 15:05 |
| lamalex | pushed now :) thanks guys. I really love how helpful #bzr is, compared to many other freesoftware irc channels | 15:07 |
| igc | night all | 15:36 |
| === kiko is now known as kiko-phone | ||
| === kiko-phone is now known as kiko | ||
| visik7 | why I've to commit to use bzr upload -r <revnumber ?> | 16:08 |
| visik7 | make no sens | 16:08 |
| jelmer | visik7, please file a bug | 16:09 |
| visik7 | where ? | 16:09 |
| jelmer | https://launchpad.net/bzr-upload I think | 16:10 |
| beuno | visik7, well, there is a specific reason for that | 16:10 |
| beuno | ah, well, no | 16:10 |
| visik7 | why ? | 16:10 |
| beuno | not for -r | 16:10 |
| beuno | as jelmer says, file a bug, we'll get it fixed :) | 16:10 |
| beuno | my mistake, misread too fast | 16:10 |
| weigon | jelmer: I have a small problem with pushing into a svn-tree (bzr-svn 0.4.10) | 16:12 |
| weigon | bzr: ERROR: Tags not supported by SvnBranch(...) | 16:12 |
| weigon | $ bzr info | 16:13 |
| weigon | Standalone tree (format: dirstate-with-subtree) | 16:13 |
| jelmer | weigon: bzr-svn doesn't support tags | 16:13 |
| jelmer | (yet) | 16:13 |
| weigon | that's fine | 16:14 |
| visik7 | lp: use a specific port ? | 16:14 |
| weigon | but how can I move in from there ? | 16:14 |
| weigon | jelmer: looks like this happens at the end of the push | 16:15 |
| jelmer | weigon: you're trying to push a branch with tags into svn | 16:16 |
| weigon | yep, can I remove the tags somehow and get a successful push ? | 16:16 |
| jelmer | bzr tag --delete <name> | 16:19 |
| visik7 | could you get http://bazaar.launchpad.net/~bzr-upload-devs/bzr-upload/ working ? | 16:21 |
| visik7 | I can't | 16:21 |
| weigon | jelmer: thanks | 16:27 |
| beuno | visik7, loggerhead must be down again | 16:29 |
| beuno | oh, it's not: http://bazaar.launchpad.net/~bzr-upload-devs/bzr-upload/trunk/files | 16:30 |
| beuno | visik7, what are you trying to find? | 16:30 |
| visik7 | pull from http | 16:30 |
| visik7 | 'couse lp: is firewalled | 16:30 |
| visik7 | here | 16:30 |
| beuno | visik7, try: http://bazaar.launchpad.net/%7Ebzr-upload-devs/bzr-upload/trunk/ | 16:33 |
| visik7 | yes | 16:33 |
| beuno | visik7, did you get around to filing that bug? I can look at it after work if you do :) | 16:35 |
| visik7 | yes patch added | 16:36 |
| visik7 | check if it's correct | 16:36 |
| weigon | jelmer: $ for t in `bzr tags | awk '{print $1}'`; do bzr tag --delete $t; done does the trick | 16:36 |
| jelmer | weigon: :-) | 16:36 |
| visik7 | beuno: is ok ? | 16:38 |
| beuno | visik7, you rock :) | 16:39 |
| visik7 | :) | 16:39 |
| visik7 | it's damn easy with python and bzr | 16:39 |
| visik7 | combo killer | 16:39 |
| beuno | visik7, do you think you can use bzr send, so you can get attribution for you work? | 16:39 |
| visik7 | yes I maybe need to setup bzr for launchapd | 16:40 |
| luks | beuno: commit has an --author option exactly for this :) | 16:42 |
| visik7 | but anyway I'm behind a firewall that suck | 16:42 |
| visik7 | and doesn't work for lp: | 16:42 |
| beuno | luks, ah, right, thanks | 16:43 |
| beuno | visik7, I'll use that and make it easier for you | 16:43 |
| beuno | thanks a lot. You'll see it i trunk in a while | 16:43 |
| visik7 | thanks | 16:45 |
| visik7 | is there a way to commit into a branch only some files ? | 16:45 |
| visik7 | yes | 16:45 |
| visik7 | stupid me | 16:45 |
| awilkins | jelmer: Where bzr-svn has changed it's mind about file-id values is there a way of upgrading a branch to the new file-id mapping? | 16:49 |
| jelmer | awilkins: bzr-svn shouldn't change its mind about file ids, that would be a critical bug | 16:49 |
| Pilky | anybody know why when I commit a checkout to launchpad it doesn't update on the launchpad pages? (does update in loggerhead) | 16:49 |
| beuno | Pilky, code scanning is behind | 16:50 |
| beuno | so it will take a while for LP to pick it up | 16:50 |
| awilkins | jelmer: Well then, I think I may have hit a bug.... | 16:50 |
| awilkins | jelmer: What about revision-ids which is what aI actually meant ... | 16:50 |
| jelmer | awilkins: they shouldn't change either, unless you change the branching scheme or are branching from a different path | 16:51 |
| LarstiQ | which happens rather frequently | 16:51 |
| Pilky | beuno: well it's showing my last commit as revision 9, 3 days ago. I switched to using checkouts with revision 10 and it never updated, and I just commited revision 11 about 10 minutes ago | 16:51 |
| awilkins | jelmer: Ah, I changed the branching scheme, because the structure of the repo was confusing the auto-scheme code | 16:51 |
| Pilky | (revision 10 was committed 2 days ago) | 16:51 |
| awilkins | jelmer: Problem was that I had a vendor-branch folder, which itself was a container for a project/branch tree, as well as a root level project/branch hierarchy | 16:54 |
| === kiko is now known as kiko-fud | ||
| Chris12349 | will bzr let me replicate data between two bazaar servers? | 17:00 |
| Peng | Chris12349: Well, that's what "push" and "pull" are for, but they only operate on single branches. | 17:01 |
| Chris12349 | Peng: gotcha, thanks | 17:01 |
| beuno | Pilky, it will get fixed, don't worrk | 17:37 |
| beuno | *worry | 17:37 |
| === mw is now known as mw|food | ||
| === kiko-fud is now known as kiko | ||
| === mw|food is now known as mw | ||
| visik7 | beuno: good modification to my patch I would suggest it to you | 20:22 |
| beuno | visik7, you're fast :) | 20:23 |
| beuno | I thought it would be clearer | 20:23 |
| visik7 | good good | 20:23 |
| beuno | I hope I got your name right, it isn't very clear in LP | 20:24 |
| visik7 | CamelCase | 20:24 |
| visik7 | :) | 20:24 |
| beuno | yes, I guessed as much, but I wasn't sure if it was FirstnameLastname | 20:25 |
| beuno | or the other way around | 20:25 |
| visik7 | the other :P my fault | 20:25 |
| beuno | aaah, I suspected | 20:25 |
| beuno | thanks for the bug report/fix, btw | 20:26 |
| visik7 | you know I've never commited a bugreport/fix but with LP and python and bzr it's dead easy | 20:27 |
| visik7 | great tools | 20:27 |
| bratsche | Is there a way to find out the nearest ancestor branch for a branch you're working in? | 21:25 |
| bratsche | Like, I have branch A and then I create branch B from A. And later on inside B I want to do "bzr diff -r ancestor:A" | 21:27 |
| bratsche | I do this type of thing -all- the time, and I don't want to have to type in the URL for A. Is there an obvious way to get that URL from bzr? | 21:28 |
| radix | I do it all the time too, where "A" is something like "../otherbranch" | 21:29 |
| radix | so it doesn't seem so bad | 21:29 |
| bratsche | Mine is remote, and at the moment I just have a bash script setup to do "bdiff --repo-A" or something to tell it which repo to diff against. | 21:32 |
| bratsche | But I'd rather not even have to do that much by hand.. if I could get bzr to return the nearest ancestor branch then the script could figure out where to diff against for me. | 21:33 |
| radix | bratsche: "bzr info" shows the parent branch, btw | 21:33 |
| radix | I don't know how to get that out in a simple way to include on the command line | 21:33 |
| radix | or to include in `` or whatever | 21:33 |
| Jc2k | bratsche: bzr help revisionspec ? | 21:33 |
| bratsche | radix: It doesn't always show it. | 21:33 |
| bratsche | Oh, I want submit: | 21:34 |
| bratsche | I didn't know about that. Thanks. | 21:34 |
| bratsche | Oh, it doesn't seem to always work though. | 21:35 |
| Jc2k | np | 21:35 |
| Jc2k | you probably need to pull from the remote branch once | 21:35 |
| Jc2k | so that it stores the parent branch | 21:35 |
| Jc2k | i dont know why parent isnt set when you branch, tho | 21:35 |
| bratsche | bzr: ERROR: No submit branch available for branch "/home/bratsche/bzr/my-branch" | 21:35 |
| Jc2k | right. it says it falls back to parent branch. so is there a parent branch in bzr info? | 21:36 |
| bratsche | I'll play with this some more later and see if I can figure out why this is happening. | 21:36 |
| bratsche | No. | 21:36 |
| Jc2k | if not, you can set it with bzr pull --remember <remote-location> | 21:36 |
| bratsche | repository checkout root: . | 21:36 |
| bratsche | checkout of branch: sftp://path/to/branch/ | 21:37 |
| bratsche | shared repository: /home/bratsche/path/to/repo | 21:37 |
| Jc2k | good luck | 21:37 |
| bratsche | Okay thanks. | 21:37 |
| awilkins | jel | 21:50 |
| awilkins | mer | 21:50 |
| awilkins | Dang, he isn't here | 21:51 |
| halstead | Is there an easy way to export a read-only svn repository from a bzr branch? | 21:51 |
| awilkins | halstead: Not as far as I know | 21:53 |
| awilkins | halstead: You could try configuring a read-only empty repo and pushing branches to it, but I don't know how well that works. | 21:54 |
| * awilkins tries pushing to an empty SVN repo | 21:57 | |
| halstead | If I try to push to an empty repo I'm warned, ERROR: These branches have diverged. Try using "merge" and then "push" | 21:57 |
| awilkins | Hmmph, my error is more impressive than yours "tuple index out of range" | 21:58 |
| * awilkins updates to a more recent build of bzr-svn | 21:58 | |
| Jc2k | are you using bzr push or bzr svn-push? | 22:08 |
| awilkins | has I am running into different but no less annoying problems on a 1.5 / HEAD of 0.4 combo | 22:08 |
| halstead | I was using bzr push. I will try the other. | 22:08 |
| * Jc2k isn't sure when svn-push should be used tbh | 22:10 | |
| awilkins | Hmm. Trying to branch it in was less than successful ; I seem to have ended up with an SVN repo containing raw bits of bzr branch. | 22:10 |
| halstead | Hmm.. | 22:10 |
| halstead | It asks me to merge them first but then refuses to merge because they lack a common ancestor. | 22:11 |
| awilkins | halstead: I managed to push to an empty branch but ran into an error | 22:38 |
| halstead | awilkins, How did you? | 22:38 |
| awilkins | svn-push | 22:38 |
| awilkins | Target URI was a subfolder of an empty project-level folder | 22:39 |
| awilkins | It's running into an assertion when it tries to add a file. | 22:40 |
| beuno | mwhudson, ping | 22:41 |
| Peng | Is it just me, or is making 165 360-byte range requests for signatures.knit when making a branch kind of wasteful? | 22:41 |
| mwhudson | beuno: hi there | 22:41 |
| beuno | mwhudson, you wake up pretty early, don't you? | 22:41 |
| halstead | Thank you, I didn't try an empty sub directory. That works great for me. :) | 22:41 |
| awilkins | Peng: How big is signatures.knit? (small, I'll wager) | 22:42 |
| mwhudson | beuno: it's 09:41 here | 22:42 |
| mwhudson | beuno: so not really... | 22:42 |
| Peng | awilkins: Almost 60 KB. | 22:42 |
| beuno | mwhudson, oh? I thought you where in australia, but it seems you're not :) | 22:42 |
| awilkins | Peng: Ooooh, scary. Maybe they should just download all of it :-) | 22:42 |
| Peng | ...It would've used slightly less bandwidth if it downloaded the whole thing once. | 22:43 |
| mwhudson | beuno: no, new zealand | 22:43 |
| Peng | Or, I could upgrade to packs. ;) | 22:43 |
| mwhudson | Peng: which bzr version? | 22:43 |
| beuno | mwhudson, I'll have to add new zealand to my gnome-clock too then :p | 22:43 |
| Peng | mwhudson: Launchpad, so 1.3. | 22:43 |
| beuno | mwhudson, did you see the loggerhead file-view yet? | 22:43 |
| mwhudson | i have this recollection that some bugs in this area have been fixed | 22:44 |
| Peng | Yeah. | 22:44 |
| mwhudson | Peng: but this is a client thing | 22:44 |
| Peng | mwhudson: Launchpad was mirroring my branch. | 22:44 |
| mwhudson | Peng: oooh | 22:44 |
| mwhudson | yeah, we'll be upgrading soon... | 22:44 |
| mwhudson | beuno: yes! | 22:44 |
| mwhudson | beuno: basically fine, apart from: | 22:45 |
| mwhudson | 1) the drwxrwxrwx nonsense should be replaced with an icon for file, executable file, directory or symlink | 22:45 |
| mwhudson | 2) why have the link icons after the file name and revision number in the table? | 22:46 |
| mwhudson | 3) what does the clipboard icon do? | 22:46 |
| Peng | What are .bzr/branch/pull and x-pull? | 22:46 |
| Peng | Bwahaha. | 22:48 |
| beuno | mwhudson, 1) I agree, although out of the initial scope (it requieres programming). I can probably add that after we finish this. | 22:48 |
| Peng | Yeah, there have been major improvements since then. Now it downloads signatures.kndx again before downloading each range of signatures.knit! | 22:48 |
| beuno | 2) We're trying to be consistant with what is a link and what's not. So we added an icon to represent it. We can remove it if it's confusing rather than helpful | 22:49 |
| Peng | Actually, I don't know WTF it's doing. But it downloads revisions.kndx and signatures.kndx a hell of a lot. | 22:49 |
| beuno | mwhudson, 3) First attempt at an icon for "log". We also added a "Help" tab, which will explain all icons | 22:49 |
| mwhudson | tooltips for the icons would be good i guess | 22:50 |
| beuno | yeah, I'll make sure to make a note of that for the HTML/CSS stage | 22:50 |
| mwhudson | i guess for 2) i'd like to play with it before thinking to hard | 22:50 |
| mwhudson | it's not a difficult thing to change is it? | 22:51 |
| beuno | no, it's not. I can do it if you think it really makes a difference | 22:52 |
| mwhudson | let's leave it for now | 22:52 |
| beuno | we can (and will) always change it later on | 22:52 |
| beuno | as for the _strip_NULL_ghosts, which I can clearly see there is a comment saying "don't use it", it's a bit of a problem, as if I don't loggerhead blows up. I may have to take a different approach | 22:54 |
| mwhudson | yeah, would be good to get some proper advice here | 22:56 |
| mwhudson | i think loggerhead need it for the same reason log needs it though: to give stuff to merge_sort | 22:56 |
| beuno | yeap yeap, I'll send a mail to the list | 22:57 |
| beuno | we may have to change that whole block of code, but it seemed like an overkill at the time | 22:58 |
| mwhudson | yeah | 22:58 |
| libwilliam | I am sure every time I log into this channel everyone goes "sighhh".... I am trying to use the Inventory.entries() method to get a list of the versioned files. The API's description is "Return list of (path, ie) for all entries except the root. "... I understand how to use the C/Python API so I don't need any help on using it, but I need help with is what type of data the returned list contains. | 22:59 |
| libwilliam | It says it contains (path,ie) but I don't know if it those are elements are a set, tuple, list, etc | 22:59 |
| mwhudson | i did a little thinking about how you could do loggerhead without any ahead of time caching | 22:59 |
| mwhudson | i think the graph api is getting mostly there | 22:59 |
| === mark3 is now known as markh | ||
| james_w | libwilliam: path is a string | 23:00 |
| mwhudson | though i don't really see how you can do "page 102 of 300" of the changelog view efficiently without preserving some state | 23:00 |
| mwhudson | libwilliam: why not try it interactively? | 23:00 |
| james_w | libwilliam: ie is an InventoryEntry object | 23:00 |
| beuno | mwhudson, yeah, I have a few ideas floating around in my head too. I keep thinking the sqlite cache is evil | 23:01 |
| libwilliam | I figured it was a string, the part I am unsure on is it is returning a list of those two objects stuck together. What is the type that keeps the path and ie together? | 23:01 |
| mwhudson | beuno: eh, i don't think that's particularly relevant here? | 23:02 |
| libwilliam | like a list of sets, or list of tuples, I am very unfamiliar with python | 23:02 |
| mwhudson | phone, brb | 23:02 |
| james_w | libwilliam: it's a tuple | 23:02 |
| libwilliam | james_w: thank you! | 23:03 |
| beuno | mwhudson, well, yes and no. We're already caching with sqlite, and that *does* give as an overhead I think we can either, get rid of, or replace with a much better one | 23:03 |
| mwhudson | beuno: but the code we're talking about replacing is all about the relationship between revisions | 23:03 |
| mwhudson | what is cached is (mostly) data _about_ revisions | 23:03 |
| mwhudson | (i'm sure i said this yesterday :) | 23:04 |
| beuno | right, sorry for drifting away. I understood it, just mixed in something else I had in my head :) | 23:04 |
| mwhudson | :) | 23:04 |
| beuno | well, the latest graph work jam introduce seems to make it cheaper to do what we do now, so yes. I'd have to compare them, and, on the other hand, if showing the parent is costing us a lot, we may want to show just the revision info first, and fetch the rest if it's requested | 23:06 |
| beuno | I've been thinking about that behaviour a lot | 23:06 |
| jam | I have been summoned? | 23:06 |
| beuno | ah, jam, hello :) | 23:06 |
| beuno | well, since your here... want to talk graphs? | 23:07 |
| awilkins | halstead: Yay, I think I may have fixed the bug I was hitting. | 23:07 |
| halstead | awilkins, What was it? | 23:07 |
| awilkins | Part of the code wasn't passing a baton (basically a null pointer but SVN code team calls them "batons" because they get passed a lot) | 23:08 |
| beuno | mwhudson, if we could fetch through ajax the details of each revision, and not by default, browsing through logs will be much cheaper | 23:08 |
| jam | beuno: I would like nothing better, I guess | 23:08 |
| mwhudson | in fact, if you cached the data in a way that was less of an abuse of an rdbms you could do all sorts of interesting things... | 23:08 |
| awilkins | halstead: This is bzr 1.5 and the HEAD of the 0.4 branch of bzr-svn | 23:08 |
| mwhudson | beuno: perhaps | 23:08 |
| jam | beuno: the sqlite cache is evidence that we are doing something inefficiently | 23:08 |
| jam | certainly we should be able to have primary access through bzr | 23:09 |
| jam | *should* | 23:09 |
| mwhudson | beuno: but... emacs is 80000 revisions of mainline history | 23:09 |
| jam | if we can't then we need to think about why not | 23:09 |
| mwhudson | if you want to get revision 20000 ... | 23:09 |
| mwhudson | jam: the big inefficiency is files changed between revisions in a large tree | 23:09 |
| halstead | awilkins, I was having success with bzr 1.5 and bzr-svn 4.10. | 23:10 |
| awilkins | I don't think 0.4.10 is too far from the HEAD. | 23:10 |
| beuno | mwhudson, as I understand it, now, we're getting *all* revisions everytime we fire up loggerhead, so that clearly doesn't work well on deep-history repos | 23:10 |
| jam | mwhudson: does 'item_keys_introduced_by' work for you? | 23:10 |
| jam | or is the problem about deleted files | 23:11 |
| jam | which iirc don't show up there | 23:11 |
| beuno | if you accessed bzr directly, we would just grab what we're going to show | 23:11 |
| jam | certainly having to do a diff for 100 revisions to compute the changed files is a bit problematic | 23:11 |
| jam | But I think that shows something up in bzr itself that we should be dealing with | 23:11 |
| mwhudson | jam: maybe, i don't know what that is :) | 23:12 |
| jam | mwhudson: Reopository.item_keys_introduced_by is what we use for fetch | 23:13 |
| jam | you pass in a list of revision_ids | 23:13 |
| jam | and it returns (file_id, revision_id), or (inventory, revision_id) etc | 23:13 |
| * mwhudson is on the phone | 23:13 | |
| jam | :returns: An iterable producing tuples of (knit-kind, file-id, | 23:13 |
| jam | versions). knit-kind is one of 'file', 'inventory', 'signatures', | 23:13 |
| jam | 'revisions'. file-id is None unless knit-kind is 'file'. | 23:13 |
| jam | mwhudson: fine, run away :) | 23:13 |
| beuno | lol | 23:14 |
| jam | beuno: what is the graph question | 23:14 |
| beuno | jam, loggerhead was using deprecated methods, which I replaced for a new one | 23:14 |
| beuno | let me find the diff... | 23:14 |
| jam | beuno: get_revision_graph()? | 23:15 |
| beuno | right, loggerhead is currently unusable in LP | 23:15 |
| beuno | actually, repository.get_graph( | 23:15 |
| * mwhudson thinks perhaps multiple issues are getting confused here | 23:15 | |
| jam | beuno: repository.get_graph() shouldn't be deprecated | 23:16 |
| jam | it is the recommended route | 23:16 |
| jam | you just have to have a locked repo | 23:16 |
| jam | mwhudson: you were saying that getting the list of 'modified' is expensive, and for fetch() we use that function | 23:16 |
| jam | it may not be sufficient for what you want for 'log' | 23:16 |
| beuno | jam, no no, that's the one I replaced it with, sorry | 23:17 |
| mwhudson | jam: hm yes that does look interesting | 23:17 |
| beuno | yes, it was using get_revision_graph | 23:17 |
| jam | yeah, I think in dev get_revision_graph() was completely nuked by lifeless | 23:17 |
| jam | it was "evil" but it had its uses | 23:17 |
| jam | beuno: if you *need* to grab the whole revision graph, that is something to re-evaluate if possible | 23:18 |
| mwhudson | jam: right | 23:18 |
| beuno | jam, yes, that's what we are looking into | 23:18 |
| mwhudson | i think with the newer bzrlib apis there is less and less need to do whole history stuff when loggerhead starts up | 23:18 |
| beuno | loggerhead reloads this everytime you start it | 23:18 |
| jam | Unfortunately, I haven't found a way to do dotted revnos without the whole graph :* | 23:18 |
| jam | :( | 23:18 |
| mwhudson | yeah, i think we'll still need to cache revid_to_revno_map | 23:19 |
| jam | beuno: "on startup" or as part of looking at a branch, or what? | 23:19 |
| beuno | jam, on startup currently | 23:19 |
| jam | beuno: so it does it for all branches under its control or what? | 23:19 |
| mwhudson | yes | 23:19 |
| jam | mwhudson: yeah... I can think of ways to partition it to be somewhat more efficient than having 80k rows for every branch | 23:19 |
| beuno | I then do graph.iter_ancestry, but I'm forced to use _strip_NULL_ghosts, which has strong warnings not to use | 23:19 |
| jam | beuno: I don't know _strip_NULL_ghosts, but I can describe how iter_ancestry returns ghosts | 23:20 |
| jam | (entry, None) is a ghost | 23:20 |
| mwhudson | DEB [20080528-10:20:25.575] loggerhead.bzr_dev: Reload branch history... | 23:20 |
| mwhudson | /home/mwh/src/loggerhead/trunk/loggerhead/history.py:205: DeprecationWarning: bzrlib.repofmt.pack_repo.KnitPackRepository.get_revision_graph was deprecated in version 1.4. | 23:20 |
| mwhudson | self._revision_graph = branch.repository.get_revision_graph(self._last_revid) | 23:20 |
| mwhudson | INF [20080528-10:20:31.185] loggerhead.bzr_dev: built revision graph cache: 5.3389949798583984 secs | 23:20 |
| mwhudson | is what loggerhead/trunk says on startup, pointed at launchpad, currently | 23:21 |
| mwhudson | jam: i don't think we really care about stripping ghosts, per se | 23:21 |
| mwhudson | jam: we just want something we can safely feed to merge_sort | 23:22 |
| jam | mwhudson: just that passing ghosts to merge_sort causes graph cycle failures, right? | 23:22 |
| mwhudson | (which explodes if you give it a graph containing referencing ghosts) | 23:22 |
| mwhudson | yeah | 23:22 |
| beuno | well, we could probably skip them as we loop... | 23:22 |
| mwhudson | -containing | 23:22 |
| jam | beuno: _strip_NULL_parents should blow up for iter_ancestry | 23:23 |
| jam | because the node returns None for parents | 23:23 |
| mwhudson | i think for the short term maybe we should just duplicate _strip_NULL_ghosts in launchpad | 23:23 |
| jam | which isn't iterable | 23:23 |
| beuno | jam, I apply it after, and it doesn't | 23:23 |
| beuno | well, wait | 23:23 |
| jam | beuno: there *is* _old_get_graph() | 23:23 |
| beuno | I do something else | 23:23 |
| jam | which has the same warnings (I'm sure from robert) | 23:24 |
| beuno | parent_map = dict(((key, value) for key, value in graph.iter_ancestry([self._last_revid]) if value is not None)) | 23:24 |
| beuno | 3121 def _old_get_graph(repository, revision_id): | 23:24 |
| beuno | 3122 """DO NOT USE. That is all. I'm serious.""" | 23:24 |
| beuno | :) | 23:24 |
| jam | beuno: you could do | 23:24 |
| * mwhudson observes that the loggerhead instance running on launchpad is wedged yet again | 23:25 | |
| jam | well, you could reproduce the two fnuctions | 23:25 |
| jam | functions | 23:25 |
| jam | but you would essentially just be doing the same thing | 23:25 |
| jam | and just not re-using the bzr functions for it | 23:25 |
| beuno | yeah, I just thought that I was taking the wrong approach | 23:25 |
| mwhudson | well, we are | 23:25 |
| jam | beuno: if it makes you feel better 'bzr log' does exactly the same thing inline | 23:25 |
| mwhudson | whole-history operations are bad | 23:26 |
| beuno | heh, yes | 23:26 |
| jam | part of Robert's push to get rid of get_revision_graph | 23:26 |
| mwhudson | unfortunately...... | 23:26 |
| jam | without actually getting rid of it :) | 23:26 |
| jam | mwhudson: james_w and I talked about possibly doing a lazy merge_sort that doesn't require whole history | 23:26 |
| mwhudson | the issues loggerhead has to solve are very similar to the issues faced by log | 23:26 |
| jam | the difficulty is it still required an awful lot of history | 23:26 |
| beuno | mwhudson, from your experience, do you think getting the basic data we show currently on screen with the new set of APIs (not the expanded one) from bzr directly will decrease performance too much? | 23:27 |
| jam | mwhudson, beuno: If all you want is the revisions that are merged (as sort of a big set) I can give that to you | 23:27 |
| jam | graph.find_unique_ancestors(tip, [others]) | 23:27 |
| james_w | I wrote one that is about the same speed for full history, and to produce the first revision on the bzr branch, but lightning quick on the emacs one due to the linear history. | 23:27 |
| jam | However, if you want to *number* them, it gets tricky | 23:28 |
| Peng | Why does BzrError inherit from StandardError? | 23:28 |
| james_w | however, I didn't propose it as I wasn't confident that the behaviour would hold for all branches. | 23:28 |
| jam | james_w: did you get away from traversing the entire left-hand-history? | 23:28 |
| jam | or is that just the one that goes linearly backwards and ignores revnos | 23:28 |
| james_w | jam: yes, for linear history, but not if there was merges. | 23:28 |
| jam | Peng: what would you have it inherit from? | 23:28 |
| mwhudson | beuno: i think this is worth investigating | 23:29 |
| jam | james_w: I'm saying you worked a bit on lazy dotted revnos, I know you also worked on 'git-log' or whatever it was called | 23:29 |
| james_w | jam: and yes, this was without generating revnos, which was the other reason for not proposing it. | 23:29 |
| Peng | jam: Not sure. Exception, I think. | 23:29 |
| mwhudson | it will probably make things a bit slower | 23:29 |
| jam | Peng: is StandardError a problem for you somehow? | 23:29 |
| mwhudson | as jam says, numbering the revisions will be the the hard part | 23:29 |
| jam | Peng: class StandardError(Exception) | 23:29 |
| jam | | Base class for all standard Python exceptions that do not represent | 23:29 |
| jam | | interpreter exiting. | 23:29 |
| jam | seems reasonable to me | 23:29 |
| Peng | The library reference says "The base class for all built-in exceptions except StopIteration, [etc.]". | 23:30 |
| Peng | BzrError isn't built-in. | 23:30 |
| jam | Peng: so why not class BaseException(__builtin__.object) | 23:31 |
| jam | | Common base class for all exceptions | 23:31 |
| jam | Anyway, I don't know if poolie had a specific reason or not | 23:31 |
| beuno | mwhudson, I'd like to try it. If it's a bit slower, but scales well, then a static html cache may be better than a sql one | 23:31 |
| jam | It hasn't ever been an issue | 23:31 |
| jam | beuno: any problem with a simple squid proxy? | 23:31 |
| mwhudson | beuno: can we please stop talking about the sql cache? | 23:32 |
| jam | I suppose you could more easily determine when the cache was out of date | 23:32 |
| mwhudson | beuno: it's really a separate issue | 23:32 |
| beuno | jam, well, first, that would be a LP-specific solution, I think. Second, we want to start using revnos as URLs, which will change the content for the same URL | 23:32 |
| jam | beuno: well, rarely for most projects, but sure | 23:33 |
| jam | I don't really know how you tell squid when things are / are not changed | 23:33 |
| jam | or HTTP proxies in general | 23:33 |
| james_w | jam: yeah, the dotted revno stuff stalled as my algorithm produced different results to the existing one, and I couldn't exactly justify it, and I couldn't see an easy way to produce the same results | 23:34 |
| jam | james_w: I don't know if I mentioned it to you, but I had changed that specific case as well | 23:34 |
| jam | it is rather 'edge' and didn't seem like it had a valid counting either way | 23:34 |
| jam | The bigger problem is that it wouldn't really help emacs | 23:34 |
| james_w | let me dig up the mail to refresh. | 23:34 |
| jam | with 80,000 linear revisions | 23:34 |
| jam | my bigger issue with your work is that it wasn't "resumable" | 23:35 |
| james_w | ah, true. | 23:35 |
| jam | in that you could compute some numbers, but you couldn't then ask it to incrementally compute some more | 23:35 |
| jam | so something like 'log' | 23:35 |
| jam | which would like to find out some numbers, go back, find some more, etc. | 23:35 |
| jam | but if you can even get close to something that doesn't require searching all of history, that would be a start in the right direction | 23:36 |
| beuno | mwhudson, don't we reload the whole history at startup to make sure our current sql cache is correct? That said, I will leave it aside, sorry for the annoyance | 23:36 |
| mwhudson | beuno: no | 23:36 |
| mwhudson | well, there's the cron-like thing that fills the cache | 23:37 |
| mwhudson | but that's a bit different, and stupid | 23:37 |
| beuno | mwhudson, ok, I thought it did, hence my insistance. I'll drop it and go deeper in the code | 23:37 |
| mwhudson | (we should just fill the cache lazily like sensible people) | 23:37 |
| mwhudson | or, probably, drop the revision cache | 23:37 |
| mwhudson | and bully people in here to make the first call to get_revision a bit faster :) | 23:38 |
| awilkins | Heh, I'm just working out how to add a revision metadata cache to bzr-eclipse | 23:38 |
| jam | mwhudson: now what are you hinting at? | 23:39 |
| james_w | jam: yep, I was hoping to extend it in that direction after the basic algorithm was worked out, but I don't know if it would even have been possible. | 23:39 |
| awilkins | Because the way the Eclipse APIs call it calls "log" for each and every file that it views | 23:39 |
| mwhudson | jam: well i'm mostly paging in old neurons here | 23:39 |
| mwhudson | jam: but iirc, the first time you call get_revisions() on a locked launchpad repository it takes like 300 ms | 23:40 |
| jam | mwhudson: I would expect that repository.get_revisions() on a Pack repo to be considerably faster than a Knit repo | 23:40 |
| jam | because Knits had to load the whole list of revision_ids | 23:40 |
| mwhudson | hm, time to benchmark! | 23:40 |
| jam | (the full indexes) | 23:40 |
| mwhudson | jam: you seem to be right | 23:41 |
| mwhudson | well, in that case i think we can probably just dump the sql revision cache | 23:42 |
| jam | mwhudson: $ py -m timeit -c "from bzrlib import branch; b = branch.Branch.open('.')" "b.lock_read(); b.reposi | 23:42 |
| jam | tory.get_revisions([b.last_revision()]); b.unlock()" | 23:42 |
| jam | 10 loops, best of 3: 18.8 msec per loop | 23:42 |
| mwhudson | yeah | 23:42 |
| jam | mwhudson: on my much older server running knits: 10 loops, best of 3: 352 msec per loop | 23:43 |
| mwhudson | jam: and i think you want -s, not -c | 23:43 |
| jam | mwhudson: I think i do too, but it was working :) | 23:43 |
| mwhudson | jam: great, i like it when problems just evaporate | 23:43 |
| jam | mwhudson: with -s, it is now 15.3 msec per loop | 23:44 |
| jam | and the same on the slow host | 23:44 |
| mwhudson | hm so the revision cache makes 0.05 - 0.10 s per page difference | 23:51 |
| mwhudson | (on launchpad, a pretty big tree) | 23:52 |
| mwhudson | --> it should die | 23:52 |
| mwhudson | (but after we've got something more current running on launchpad) | 23:52 |
| jam | mwhudson: wow... I guess that's the way it goes | 23:52 |
| dlee | Not sure why I've never thought of this approach before, though I bet someone else has ny reason we shouldn't have a case-insensitivity (for file names/folder names) option within a repo, like we have for shared? I'm having mucho trouble with file/folder name casing under Windows Bazaar 1.5 (and back through 1.0). | 23:52 |
| jam | dlee: because a lot of people on other platforms have multiple files with the same name but different cases | 23:53 |
| jam | otherwise I would tend to agree with you | 23:53 |
| dlee | Yes but probably not for a repo where you'd *want* case insensitivity | 23:53 |
| jam | Makefile and makefile tends to be more common than you want | 23:53 |
| jam | dlee: the other problem is figuring out how to be 'case insensitive but preserving' | 23:53 |
| jam | which is what people really want | 23:53 |
| awilkins | The only trouble I have is that the client library has trouble renaming files in case only on *dows | 23:54 |
| jam | and when you do an "ls" you see different names than your stored list | 23:54 |
| dlee | In other words, I thought this would give everyone their cake--could even arrange for users to be able to set the option as a default. For me, the question is, can anyone think of a scenario where you'd want case sensitivity in only part of one repo. | 23:54 |
| awilkins | But that's a trivial fix - you just check for case-only differences and rename via an intermediate | 23:54 |
| dlee | I'm getting conflicts, extra "removed" files that still exist, etc. | 23:55 |
| beuno | mwhudson, so we can scrap sqlite? or are we caching anything else? | 23:55 |
| beuno | (I promise my questions will get less stupid as time goes by) | 23:55 |
| igc | morning | 23:56 |
| mwhudson | beuno: the file change cache still makes a big heap of difference | 23:56 |
| mwhudson | like 12s -> 1s | 23:56 |
| dlee | I tried both a Unix host and a Windows host, both using bzr serve, in case that matters. I'm not sure it does. | 23:56 |
| mwhudson | but maybe we can do something about that using more modern bzr apis too... | 23:56 |
| beuno | ok, good, this is looking better | 23:57 |
| mwhudson | indeed :) | 23:58 |
| beuno | so, my ToDo right now is: benchmark Genshi, and if it doesn't make a big different, a different templating engine. Then, get rid of the revision cache, then, look into performance with newer bzrlib APIs for files changed | 23:58 |
| beuno | sound sane? | 23:58 |
| beuno | s/different/difference | 23:59 |
| mwhudson | beuno: yes, very | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!