[00:02] jam: ping [00:03] abentley: re smart server conflicts - good; [00:03] abentley: I don't know re: 1.0 -> .dev, what patches are they ? [00:04] 1. the plan merge thing you reviewed 2. The warning for criss-cross. + docs [00:05] yeah merge those to .dev [00:05] and I'd mail martin once they land with revnos to merge to 1.0 [00:05] .dev is open AFAIK [00:05] Yeah, it's just more complicated later if we merge 1.0 into dev. [00:06] And it reduces the visibility of the merge requests for Martin. [00:06] OTOH once they are in .dev they get experiential testing, and he can run 'missing bzr.dev; [00:20] jam: ping === kiko is now known as kiko-zzz [01:11] Does anyone know when bzrtools is expected in the Bazaar repositories for gutsy? [01:12] As a suggestion, it would be very appreciated if bzr and bzrtools were released in tandem. I know that creates more work, but it's disturbing to lose often-used commands for hours or days at release times. [01:13] jkakar: its already there isn't it ? [01:13] jkakar: http://bazaar-vcs.org/releases/debs/gutsy/ has bzrtools 1.0.0 [01:15] lifeless: I keep getting 'bzrtools: Depends: bzr (< 0.93~) but 1.0~rc1-3bazaar1 is to be installed' after fresh apt-get updates. [01:18] ah, will fix. [01:18] I hate this strict versioning; its bogus. [01:20] lifeless, abentley : pong [01:21] lifeless: Thanks! [01:21] he bazaar dudes [01:21] I have some fella saying that bzr doesn't have GUIs (on windows) [01:21] what do we have? [01:21] links would be good [01:21] s/he/hey/ [01:21] * thumper needs to check more before pressing enter [01:21] bzr-gtk [01:22] works on Windows [01:22] TortoiseBzr is at least in the works [01:22] jam: is it any good [01:22] I know it "works" [01:22] but I haven't used it myself [01:22] jam: eta on TortoiseBzr ? [01:22] AFAIK, both -gtk and qbzr work OK, but are also both pretty manual to install and not as comprehensive as one would like. [01:22] fullermd: is qbzr able to work on windows? [01:23] thumper: it should be [01:23] That's what I understand from snooping on list/IRC discussions. [01:23] You just need the QT 4 libs [01:23] how's the eclipse plugin? [01:23] but there should be GPL QT 4 libs for windows [01:23] usable? [01:23] thumper: a lot of active development recently [01:23] jam: pong [01:23] Verterok: thumper wants to know about bzr-eclipse [01:23] lifeless: hey, just getting some family time before they sleep [01:23] who's working on TortoiseBzr ? [01:23] do you want to talk by phone? [01:24] thumper: it is part of the bzr-gtk package, so jelmer is at least aware of it [01:24] I believe it was a google SoC thing [01:24] jam: I was thinking of working on a pack format using mpdiffs, but I got the impression you're going to do xdelta packs. [01:24] but I can't remember his name off-hand [01:24] jam: now is good [01:24] I don't want to duplicate the effort. [01:24] lifeless: do you want by phone or by skype? [01:24] skype [01:24] jam: Alexander Haro was working on TortoiseBzr [01:25] lifeless: logging on now [01:25] abentley: did he have an IRC nick? [01:25] I don't remember. [01:26] abentley: talking with robert, will ping when done [01:26] 'kay [01:26] tortoisebzr is not actually part of bzr-gtk, nautilusbzr is [01:27] tortoisebzr was somewhat of a fork of bzr-gtk though [01:51] abentley: back [01:51] Hey. [01:52] so I certainly have some ideas of how to get there, but there are several steps to be done before we can really have an "optimal" pack layout [01:52] like, just getting the non-redundant index data put into the real data [01:52] What's the plan for 1.n versioning? Will 1.0.n releases go on until a certain set of features are complete and then the next version will be declared 1.(n+1)? [01:52] (the fact that this is a delta versus a fulltext, eol, compression parent, etc are all *only* in the index) [01:52] Odd_Bloke: well, Martin posted 1.1 in January [01:53] Oh, I get what you mean. Making the index be redundant data. [01:53] which would hint at continuing the 1.(n+1) we have now [01:53] Ah yeah, I recall now you mention it. [01:53] abentley: right, that is one of the steps [01:53] also, in talking with Robert, a good intermediate is to allow pack repos to mix their deltas [01:53] * Odd_Bloke returns to House. [01:54] since as you commit you really only generate deltas from previous [01:54] Err, really? [01:54] but after repacking you would probably want to generate reversed ones [01:54] what do you mean by mix? Different formats? [01:54] xdelta & knit deltas co-mingled was an idea [01:54] partly because when you commit [01:54] we would like a knob to turn on annotation building at commit time [01:55] and for that, we would need to generate some form of line-delta [01:55] which would be a shame to waste [01:55] and do 2 deltas at commit time [01:55] it might be okay [01:55] but it is something to think about [01:55] Yes. [01:55] Also, it would make it a lot easier to phase in a change [01:56] spiv: ping; whats the bug regarding your web proxy? [01:56] Another thing I've talked about is having a comparison cache. [01:56] if it had a way to migrate without spending 40-hours reformatting the data [01:56] abentley: well, we would probably have that, and fill it at commit time [01:56] But with the C-optimized sequence matcher, comparisons are far less expensive. [01:56] if the knob was turned on [01:57] So we seem to do fine without it. [01:57] abentley: even for whole-file annotate [01:57] gannotate is pretty slow last I checked [01:57] but I haven't tried your new stuff [01:57] My new stuff is just for merging. [01:58] But I was talking about a comparison cache, not annotation cache. We definitely need cached annotations. [01:59] abentley: couldn't you use the comparison for annotation data? [01:59] or I guess that has too small a view? [01:59] Well, we already are using cached comparisions about 3/4 of the time. [01:59] (1 text to 1 previous text, not the full history for that file) [02:00] I think you can't annotate to the origin everytime and expect good performance. [02:00] srue [02:00] sure [02:00] 10k to the origin is a long way to go [02:01] what if the annotation cache was the 'fulltexts' and the rest was comparison cached [02:01] just as a thought [02:01] also, what is the overhead of doing an actual delta, versus the I/O of reading it in from a cache [02:01] I seem to remember there wasn't much of a win depending on the circumstances [02:02] Yeah, right now I haven't seen a huge win for cached comparisions. [02:02] I suppose it also depends if you have to extract the texts as well [02:02] I think we should start with cached annotations. [02:02] if you don't have the I/O of getting the full text [02:03] you wouldn't have the texts around to do a memory comparison [02:03] Yes, that does tend to negate the IO win of doing a comparision from scratch. [02:03] so, the very first step for any of this [02:03] is that we should merge in a truly experimental format [02:03] into bzr.dev [02:03] so that it can be played with [02:03] we could do it all in a feature branch [02:04] but those tend to rot a lot more than a bzr.dev branch [02:04] I think that's okay with me. [02:06] So what I'm interested in is implementing iter_files_bytes in a way that it can read everything in a single pass. [02:07] so... iter_files_bytes, you're thinking of that for TT, and build_tree, right? [02:07] That means writing a new revision builder, which is affected by the delta format. [02:07] which means that you will tend to want only 1 version for a given file-id [02:07] Well, also operations that use a lot of different revisions of a file. [02:08] but you will want lots of file ids [02:08] diff is the only other one that comes to mind for wanting multiple versions of a file [02:08] and that is only 2 versions per file-id [02:08] I guess annotate... [02:08] but we would like to not have to do that as much from a raw iter_files_bytes point of viwe [02:08] And simple revision fetching. [02:08] view [02:08] abentley: but would you want to fetch as full texts? [02:09] iter_files_bytes returns an iterable. [02:09] So you can certainly take advantage of common lines. [02:09] abentley: right, but wouldn't you want to fetch the deltas, etc, not the full text each time? [02:10] For annotate? [02:10] Oh, for installing revisions. [02:10] abentley: not for annotate... for "simple revision fetching" [02:10] For simple revision fetching, you assume the repos have incompatible delta formats. [02:11] Like that fetch code you wrote recently. [02:11] interesting, I'm curious how things would be buffered [02:12] it does seem like *most* use cases are across a revision [02:12] Oh, probably using that handy LRU of yours. [02:12] not across a file's history [02:13] True. But I think the abstraction of just asking for a bunch of keys, not caring whether they're from the same file, is pretty nice. [02:14] moin [02:14] abentley: oh, I agree. I believe in moving away from VF as a concept, to putting more of that on Repo [02:14] jam, thumper: hi [02:14] hi Verterok [02:14] how is bzr-eclipse going? [02:15] is it in a "useable day-to-day" or still more experimental? [02:15] it's not feature complete, but sure it's usable in a day to day basis. [02:18] jkakar: uploading now [02:19] jam, thumper: I recently write a draft of the roadmap at http://bazaar-vcs.org/BzrEclipse/Roadmap [02:19] lifeless: my proxy bug is 172701 [02:20] Verterok: thanks [02:20] np [02:21] lifeless: Ta! [02:23] thumper: I'll be around, shoot any questions that might araise :) [02:23] Verterok: so were are we now with bzr-eclipse? [02:24] in which aspect? (integration with bazaar? integration with eclipse?) [02:28] thumper: about the java-bazaar integration, almost all relevant commands have a counterpart in the BazaarClient java library [02:28] abentley: another small thing, I'm looking at the Mine page, and it seems to list some things that I've merged. [02:28] like http://bundlebuggy.aaronbentley.com/request/%3C20071130201555.3F94855FFA@juju.arbash-meinel.com%3E [02:28] Have you not updated from bzr.dev in a while? [02:28] I was trying to clear out accepted but unmerged things [02:28] I've seen that too. [02:28] but my list isn't reflecting it [02:29] I know it is doing the right thing some of the time. [02:29] thumper: I'm still waiting for jython 2.5 :P [02:29] But sometimes it seems to missing things. [02:29] Verterok: what happened with the JEPP (etc) wrapper for bzrlib? [02:29] I know it happened for a Mono/.NET port [02:29] as part of the Visual Studio integration [02:29] This is likely because I switched that operation to be internal. [02:30] But I'm not getting any failure reports or anything. [02:30] k, it just would be easier for me if i could look at the list of things I haven't merged yet [02:30] I can do it manually [02:30] but I didn't want to step on anything [02:30] in case you wanted to use it as a test case [02:31] No, please go ahead. [02:31] I'm aware of the problem. Sorry for the inconvenience. [02:31] abentley: could it be that the tip wasn't merged? [02:31] I committed another rev on top of it and merged that [02:32] jam: about jepp, I played a bit but it seems too complex to install from the user perspective, the CLI wrapper is a bit slower but works fine and only requires xmloutput plugin [02:32] It shouldn't be that, but I think my test cases are against the tip. === marianom is now known as marplatens1 [02:36] jam: also jepp requires a LOT of work to get a usable interface, and jython 2.5 is comming (they have a new compiler that understand cpython bytecode ;) ) [02:37] Verterok: good to hear [02:37] last I tried jython it was pretty limited [02:37] It is a shame we probably won't ever get the bzrlib test suite to run there [02:37] as we use 'os.chdir()' a lot to ensure each test is sandboxed [02:38] (afaik, we use it 0 times in actual bzrlib code, but the test suite uses it a lot) [02:39] sure it's a shame, maybe when time of jython 2.5 comes, I can put some work to make a custom os.chdir as a native jython module [02:40] I thought it wasn't allowed because of Java limitations [02:41] JNI could do something I would've thought... [02:42] you'r right, I was thinking in a workaround and not a real fix to jython :D [02:42] just to make the bzrlib test suite run [02:47] Verterok: I was meaning 0.1? 0.2? on your roadmap [02:48] thumper: oh, ok. I'm currently working in the quickdiff integration [02:48] k [02:49] the next thing to do is basic merge support and conflict resolution with the strutctured merge, and with this working I plan to make a new build [02:52] s/strutctured merge/strutctured diff/ [03:09] lifeless: call? [03:10] New bug: #173807 in bzr "Branching from RepositoryFormat7 standalone branch from a smartserver fails" [Undecided,New] https://launchpad.net/bugs/173807 [03:15] spiv: yup [03:17] lifeless: ok, will call in a sec [03:18] kk [03:18] Hi [03:19] I have a question about bzr versions [03:19] ... [03:19] Anyone? [03:20] sure [03:20] Ok. I've got ubuntu 7.10 want to install bzr [03:20] hello, I branched bzr's main repository, and after that, I need to take 2+ hours to update my repository (getting 200+ MB at 30 kB/s for a 80 MB repository), is this normal? [03:20] thanks [03:21] echo-area: thats not normal; our repository is only 50 mb total. [03:21] echo-area: and updates should be a few seconds or a minute at most [03:21] edencane: please, ask your question [03:21] Thanks. [03:21] hmmm, what could be possible wrong in my case? [03:22] lifeless: Actually, my bzr repo is about 75 meg. It's got a handful of my revs in it, but they can't add up to 100k. [03:22] echo-area: When did you branch it? [03:23] fullermd: oh hmm, I'm considering core data. [03:23] around Nov 20 I think [03:23] latest release is 0.92, yet when I add the repository to sources.list for use with aptitude, the available version is 1.0.0.candidate.1 [03:23] echo-area: ah, perhaps you missed the announcement that I sent out that bzr.dev is now in pack format. [03:23] Ive installed that version [03:23] echo-area: Ah. Try a 'bzr info' of your branch; I'll bet it'll say 'dirstate' for the format, and is trying to pull the new pack'd bzr.dev. [03:24] echo-area: you should: let the current pull finish. Then 'bzr reconcile' and then 'bzr upgrade', using the bzr in the branch itself. [03:24] OK thanks guys :) [03:24] edencane: yup [03:24] So whats the deal with different version numbers [03:24] ? [03:24] edencane: we're getting ready to release 1.0 [03:24] Ok, great! [03:25] congrats [03:25] If I use 1.0 on a branch thats being used with 0,92 by other developers, will that cause inconsistencies? [03:26] edencane: no, it will be fine. [03:27] edencane: the main difference is that 1.0 will be default create new branches in 'packs' format. This is faster, but not supported on < 0.92, and not as well supported on 0.92 as in 1.0. [03:27] will that impact on doing a pushes and pulls or creating new branches? [03:28] edencane: when pushing or pulling a branch to a new location, so bzr needs to make a new copy, bzr will make that in the same format as the original. [03:29] edencane: so it should work just fine. [03:29] so if I push changes with 1.0 and theother pulls those changes we'll be fine? [03:29] edencane: 0.92 users will want to upgrade to 1.0 anyway, because of the bugfixes and optimisations ;) [03:29] edencane: right [03:30] Cooool [03:30] Thanks so much guys. That was great help, Best with the new release and cheers for an overall great product (-: [03:37] how do I back up bazaar? [03:38] chiefinnovator, all the information is stored in the .bzr directory [03:38] But it looks too small to be holding everything [03:38] chiefinnovator: Unless you're using a lightweight checkout, it is holding everything. [03:38] chiefinnovator, are you sure all your files are versioned? [03:39] well, I had a directory of existing files [03:39] and I did bzr init [03:39] and bzr add [03:39] chiefinnovator, and commit? [03:39] ohhh [03:39] :D [03:40] Yeah, that's better [03:40] thanks [03:41] So anything I do some work, I just do a commit when I'm done? [03:41] I'm just using it to track my own files [03:41] anytime* [03:41] Okay, running reconcile on bzr.dev made it go from 49 to 0 unreferenced text versions, and it used to say 108 inconsistent parents and now says nothing. [03:41] fullermd: Sorry but where can I find your announcement? Is it in https://lists.ubuntu.com/archives/bazaar/2007q4/thread.html ? Thanks [03:41] Still 2 ghost revisions and 2 revisions missing parents. [03:41] chiefinnovator, yeap, just commit when you're done [03:42] remember, commiting is cheap with bzr, so you can be very granular about what you do [03:42] you will have a more useful history and easier to rollback [03:42] how do I rollback? [03:42] echo-area: I think you mean lifeless, not me. Check Nov 28th, if you mean the announcement I think... [03:43] Doing a bzr status on with 1.0 on 0.92 tree, If I do a bzr upgrade, will that affect the operation of another developer who is still using 0.92? [03:43] chiefinnovator, there are several ways, bzr uncommit (undo last commit) bzr revert (to a specific revision if you like), or bzr cat (to a specific file in a specific revision) [03:43] Oh, thanks [03:43] thanks [03:47] edencane: Well, there are some issues with packs in 0.92. He should really upgrade. [03:47] jam: is it intentional that the C version of Patience only allows strings? [03:47] Thanks peng [03:47] edencane: (No data loss or anything, but "bzr cat" fails and so does pushing over bzr+ssh, and some other things are slow (which aren't all sped up in 1.0rc1).) [03:49] Ok. [03:49] Thanks again. [04:00] Peng: cool, that sounds like reconcile is working as expected for you. [04:01] spiv: Okay. [04:02] Urrgh. I shouldn't run "bzr check" before and after to see what reconcile does. It takes 5x as long. [04:02] Or 4x. I dunno. [04:02] check takes about 2x as long, and I do it twice . . [04:04] check does more :) [04:04] okies [04:05] * lifeless waves [04:07] see ya lifeless === me_too is now known as too_short === too_short is now known as me_too [04:09] If reconcile doesn't find anything to do, the repo is left unmodified? [04:10] Peng: yeah, it should be. [04:10] Okies. [04:15] Hey, I have a .pack that is 1024.0 KB. Nice. [04:16] 1,048,531 bytes, with 1 MB being 576. :) [04:22] * igc lunch [04:44] jelmer: FWIW, running reconcile on bzr-svn fixes some inconsistent parents. [06:01] I wonder, would running reconcile over sftp be any faster than just uploading a new copy of the repo (I have a reconciled copy on my PC)? [06:22] Peng: My Magic 8-Ball considers it unlikely. [06:23] (based on no real knowledge; just guessing) [06:24] I would expect reconcile over sftp to be pretty slow. [06:24] I haven't measured, but I don't think that code is written to minimise round-trips. [07:25] i386: hi [07:25] when do you return ?> [07:25] 11th :) [07:25] still up for doing dinner? [07:28] ya' [07:28] on leave now [07:33] oh right [07:33] :) [07:33] Im leaving Seattle tomorrow morning [07:33] its a bit of a shit hole [07:37] lifeless: how long are you on leave for? [08:16] * igc dinner === cprov-out is now known as cprov === Kamping_Kaiser is now known as bettong === kiko-zzz is now known as kiko === kiko is now known as kiko-afk === cfbolz_ is now known as cfbolz === kiko-afk is now known as kiko [13:44] Peng: thanks === marplatens1 is now known as marianom [14:11] abentley: I don't think it is a requirement that the C version work only on strings [14:11] My guess is that strings were the most important [14:11] I wouldn't want to see it slow down much, but I could certainly see supporting tuples [14:11] would be nice for annotated texts [14:13] It is nice to have a simple "compare_lines" function that can use something fast like "memcmp" [14:16] we could experiment with using "PyObject_Hash()" instead of a custom hash func [14:16] and maybe PyObject_Compare === cprov is now known as cprov-lunch [14:39] hello all.. i am looking for some QBZR screenshots on windows systems... [14:48] theSoftMan, http://bazaar-vcs.org/QBzr has some, but they are from old versions [14:48] it easier to just install it :) [14:48] it's [14:50] i have try ti install but it does not work :-) [14:50] file a bug report [14:57] theSoftMan, http://users.musicbrainz.org/~luks/tmp/qbzr.png this is a screenshot of the dev version [14:57] theSoftMan, what exactly didn't work for you? === vila_ is now known as vila [15:07] luks, when i lauch bzr a message appear to said that some modules are not found [15:07] luks, i try to define some path variable but qbzr never start [15:08] luks, [15:08] bzr 0.92 and qbzr 0.7.1? [15:08] luks yes sir :-) [15:08] both installer using the windows installers? [15:08] *installed [15:09] that is, the bzr.exe one [15:09] if you use your own python, you have to install pyqt4 [15:09] if you use bzr.exe, everything should be included in the installer === kiko is now known as kiko-fud [15:11] abentley: I think I put together a patch to make it allow generic objects, (as long as they are hashable), I'll clean it up and post it to the list. [15:23] luks, sorry i was disonnected... yes i use my one python installation 2.5 [15:24] luks, i will try to install pyqt4 [15:24] luks, thanks [15:26] one more question : the 1.0 will be ok in hom many times ? in your humble opinion :-) [15:40] Hi guys. Could you suggest correct way to solve text conflicts using bzr-gtk ? === cprov-lunch is now known as cprov === kiko-fud is now known as kiko === weigon_ is now known as weigo === weigo is now known as weigon === doko_ is now known as doko === kiko is now known as kiko-phone [16:45] New bug: #173941 in bzr "hard to programmatically break a lock" [Undecided,New] https://launchpad.net/bugs/173941 [16:55] New bug: #173944 in bzr "adding files below symlink causes error" [Undecided,New] https://launchpad.net/bugs/173944 [17:14] vila: ping === jam-laptop is now known as jam [17:14] I'm fixing the nick for once and all, bbiab [17:17] vila: ping again [17:21] pong [17:24] hi vila, how is it going? [17:24] I was wondering if you were going to be extra busy this week [17:24] or if you would have time to work on your patch [17:24] pretty nicely, new project starting, may be fun :) [17:25] I will be extra busy, but I already take your remarks into account [17:25] Hmmm, Did I sent the email or did I just made the commit ? Let me check [17:26] Is this the one that you had to speculate your bug fixing effectiveness for the next 12 months? [17:26] I saw the commit email, I guess [17:26] yup [17:26] so did you go with 10 as I mentioned ? [17:26] hmmm, I think we went with 3/months ;-) [17:27] but given the subject (argh, NDA), well, bugs can be pretty hard [17:28] so it's still a bit stupid, but at least I get a mention added: "Any bug will first diagnosed before an evaluation is made for fixing" [17:28] vila: no problem, what is your feeling on your changes for 1.0? [17:28] I'd really like them, do you feel like it is logically small enough to do so? [17:28] jam: just sent the email, I agree some real life testing should be good, but since we are still in RC, I pretty confident [17:29] basically I went TDD on that one and the test suite was a real pleasure [17:30] granted I had to rewrite most of the RangeFile tests, but that was pretty obvious. [17:30] Once *that was done, I get pnlu trivial bugs and typos (of course) to fix. [17:30] s/pnlu/only/ [17:30] hehe [17:31] Somebody, help! The irony is choking me! [17:31] I just can't type about typos without doing at least one, and when I don't it's bad english [17:33] Anyway, once the test suite passed, I had a bad surprise since our http tests servers are all speaking http/1.0, not 1.1, but that was a good thing finally since I ended up handling the http pipe even more cleanly that I was hoping [17:33] jam: bbl. early dinner time [17:33] vila: enjoy your food [17:35] Are there any branch commit notification bots? [17:41] somerville32: well, Launchpad will let you subscribe to branches. [17:41] There is an atom-feed plugin [17:41] there is bzr-email to send a message after commit [17:41] but if you just want to poll a bunch of branches, and send emails when they change... [17:41] I think there was something for that [17:41] It was called 'hookless mail' or something like that. [17:42] launchpad.net/bzr-hookless-email [17:43] I host it on launchpad though [17:43] So I'll just need a bot to parse the e-mails? [17:44] Preferably, I'd like a bot that polls the branches and just sends a message to my channel (and preferably I'd like it already coded, haha) [17:44] fullermd, dato: should bzr-hookless-email be listed on http://bazaar-vcs.org/BzrPlugins? [17:44] somerville32: I know there is also a dbus plugin, which is meant to alert the local network when there are changes [17:45] And lifeless was looking into an irc-notify plugin [17:45] but was hesitant to finish that before he had a way to make it scale well [17:45] somerville32: there is bzr-cia, but all people who commit there should install it themselves for it to be useful. [17:45] (1000s of people announcing all there changes would get *really* noisy.) [17:46] jam: No clue. I just work her... well, actually, I don't... [17:46] you work him ? [17:46]