[00:18] "Rendering RevisionUI: 51.553565979003906 secs, 35388458 bytes, 15192308 (42.9%) bytes saved" <-- Oops. [00:21] I accidentally loaded it again, and this time it took 73 seconds. :) [02:04] Does bzr have a way to auto-generate a patch? [02:05] I want to generate a patch from local branch "development" against local branch "trunk" to be emailed. [02:07] ah, send. [02:20] I use bazaar to track version changes with my python application... you know that __version__ attribute seen in most python programs? I was wondering if those are typically automatically given a value after doing a version commit (and how to do that), or if the developer puts in a number manually? [03:00] * rockstar looks around for james_w === stewart_ is now known as stewart === stewart_ is now known as stewart [05:26] rockstar: james_w is on utc time [05:28] lifeless, yea, I knew that, but thought I'd try anyway. [05:29] 1am - hoopeful :) [06:44] lifeless: morning. [06:47] hi abentley [06:48] lifeless: When are you flying? [06:48] leaving hotel at 1100 [06:49] I was thinking 11:45 [06:49] that would be too late for my flight, have to be at airport by 1200 [06:50] so I'm catching a lift with davyd [06:51] Okay. I'm packing right now, but ping me if you want to pair on something, or just hang out. [06:52] k [06:52] I'm eating now [06:53] the 333MB index has under 1MB left to parse [06:53] Teh Rock! [06:59] jelmer: around? [07:01] lifeless: With your mailing list message about adding bzr-svn to the PPA, do you mean 0.4.10? Because it's gotten significantly better since then.. [07:01] Peng: 0.4.aything >> None [07:02] 0.4.11exp0? :D [07:02] well [07:02] I updated my bzr-svn branch (0.4) and now it fails to load [07:02] concretely I'd like something that matches the bzr in each ppa [07:02] LaserJock: run make [07:03] lifeless: The 0.4 branch matches bzr.dev. :P [07:03] Peng: if you use the ppa today you end up not having bzr-svn [07:03] Peng: this is a bug [07:04] hmmpf, it needs apr-config [07:04] Are you implying that the PPA works? [07:05] Wow, it's been almost 2 months since 1.5 was released. [07:05] 1 month since 1.6b2. [07:15] ok, phew, got it working again :-) [07:25] time to finish packing [07:26] You people with your lives and traveling and contributions to society... Pssh. [07:32] :) [07:33] oh darn, I'm in a bit of a pickle :/ [07:34] are there any bzr-tools packages compatible with the bzr 1.6 betas? [07:34] yes [07:34] 1.6 bzrtools should be in the beta ppa [07:34] ... it's not [07:35] oh [07:35] https://edge.launchpad.net/~bzr-beta-ppa/+archive only has bzr [07:35] well its at lp:bzrtools I think [07:35] *sigh* OK [07:37] this well this spagetti of packages is getting messy [07:39] yes [07:39] I can't remove bzr-tools because of bzr-builddeb [07:39] I'd love some more csript support for the folk doing ppa maintenance [07:40] although I suppose I can keep it but use the bzr branch of bzr-tools [07:40] but I only need bzr 1.6 because I updated bzr-svn [07:46] * Peng doesn't use the packages at all. [08:07] Peng: well, I'm a simple user and I'd rather spend time using the VCS than tracking down all the versions [08:10] LaserJock: the thing is that it's easier to do `bzr branch lp:bzrtools ~/.bazaar/plugins` than to find the right package [08:25] luks: yeah, but then you update and things are screwed [08:26] LaserJock: why do you think so? [08:26] because that's what I just did [08:26] LaserJock: in me experience, things are screwed more if some debian packages refuse to update [08:27] *my [08:27] I wondered if new stuff was in bzr-svn, and now I'm running after dependencies [08:30] New stuff is most definitely in bzr-svn. [08:34] well, I figured being on the 0.4 branch wouldn't be too bad [08:35] It's not bad. [08:35] But it has new C bits, so you have to run make. [08:35] except it require a beta bzr [08:35] Oh. [08:35] I run bzr.dev anyway, so I hadn't noticed. [08:35] which gives me problems with bzr-tools [08:47] hmm, I can't find what reversion the bzr-dep was bumped :/ [09:04] ok, so I can't branch bzrtools because my current bzr won't work [09:06] hmm, so I think I need to start from scratch [09:11] LaserJock: Why won't it work? [09:13] Peng: gives me some traceback [09:14] LaserJock: Details? [09:14] Peng: so I went back and removed everything bzr [09:14] LaserJock: If it's from a plugin, you can run bzr without plugins temporarily. [09:14] reinstalled 1.5 [09:14] now I'm trying to see if I can get a bzr-svn that works [09:15] bah! it want's python2.4 [09:16] Bazaar has required Python 2.4 or greater for ages. [09:16] no, I mean I have 2.5 [09:16] You mean bzr-svn specifically wants python2.4 rather than 'python -- yeah./ [09:17] Um, I use bzr-svn's 0.4 branch, and I don't have python2.4. [09:17] yeah, I can't use that branch right now [09:17] Why not? [09:17] because it requires a newer bzr! [09:17] this is the cycle I've been going through [09:18] Oh. [09:18] somewhere the bzr dependency got bumped [09:18] There's no cycle for me, but I use the dev branches of everything. [09:18] And don't build packages or anything. [09:18] right, which is not great for me [09:19] I'm not trying to be necessarily at the tip of development, I just want a set that works [09:20] The tip of development works. :P [09:20] if I can find where in the 0.4 branch the bzr dep was bumped I can go back to that revision, but I can't find it [09:20] Hi - I'm having a problem with ext-merge on windows. The file name has / separators and it should have \ . [09:21] Peng: I guess, but I'd end up updating a lot of branches to keep up [09:21] if I have to do bzr, bzrtools, bzr-svn, and the other plugins [09:21] Is there a api method to get a windows path from a unix path or should is just replace / with \ if on windows? [09:21] and if they don't work with the current bzr.dev branch then they break [09:22] anyway, I've got to go to bed, I'll trying to think of something tomorrow [09:23] LaserJock: Yeah. I do keep up with them, and it's not too much effort. I update bzr.dev and bzr-svn whenever I'm bored (which is every 2 hours), and update the others whenever I think of it (every week or two?), and things usually work. [09:23] LaserJock: Anyway, good night. :) [09:23] GaryvdM: os.path? [09:24] * Peng stares at Freenode. [09:24] This is where it gets the filenames: [09:24] http://bazaar.launchpad.net/~zindar/bzr-extmerge/trunk/annotate/10?file_id=__init__.py-20060218133530-ac9ae4e505cbcfa9#L70 [09:25] I'm browsing bzrlib/osutils.py atm [09:26] I think might be able to find something there. === Leonidas is now known as Guest31276 === Guest31276 is now known as Leonidas === Leonidas is now known as Guest91348 === Guest91348 is now known as Leonidas === Leonidas is now known as Guest51572 === Guest51572 is now known as Leonidas === Leonidas is now known as Guest46979 === Guest46979 is now known as Leonidas === Leonidas is now known as Guest14604 [10:07] Is there a way to specify --fixes= after you have commited? === Guest14604 is now known as Leonidas === Leonidas is now known as Guest71672 === Guest71672 is now known as Leonidas === Leonidas is now known as Guest13600 === Guest13600 is now known as Leonidas === Leonidas is now known as Guest54580 === Guest54580 is now known as Leonidas === Leonidas is now known as Guest35646 === Guest35646 is now known as Leonidas === Leonidas is now known as Guest94398 === Guest94398 is now known as Leonidas === Leonidas is now known as Guest26547 === Guest26547 is now known as Leonidas === Leonidas is now known as Guest68291 === Guest68291 is now known as Leonidas === Leonidas is now known as Guest27615 === Guest27615 is now known as Leonidas === Leonidas is now known as Guest97330 === Guest97330 is now known as Leonidas === Leonidas is now known as Guest12932 [10:54] Guest12932: you are thashing your name; please stop, its filling the page up with noice === Guest12932 is now known as Leonidas === Leonidas is now known as Guest2534 [10:58] lifeless: Do you have the ability to ban him? [11:00] yes, though I think Lnidas is somewhat regular and that seems harsh [11:02] I agree, but temporarily banning people with misconfigured clients isn't an uncommon practice. === Guest2534 is now known as Leonidas [11:03] Heck, it's not like anything is going on here anyway. [11:03] Leonidas: ping === Leonidas is now known as Guest86753 [11:03] Peng: OTOH I'm about to hop on a plane; I won't be around to unban [11:03] lifeless: Oh. [11:05] which is more of a problem I feel === Guest86753 is now known as Leonidas === Leonidas is now known as Guest55290 [11:07] lifeless: Before you go, what's the status of bzr-search? Is it, like, done? Do you think it should be merged into the core? [11:08] Peng: well, there are some bugs open indicating future work [11:08] Peng: I consider it alpha status [11:08] That would've been great if he had auto-rejoin off. [11:09] * Peng blinks. [11:09] ok, so its entertaining but useless [11:10] bah [11:10] I don't want to kick the username, because I won't be around [11:10] sorry, but perhaps /ignore Guest* ? [11:10] or *@chronon.pointtec.de [11:10] he's not changing his name to guest, nickserv is [11:11] because he's not entering the password for the nick [11:11] oleavr: yeah, I want him/her to be able to join the channel; I will be offline very soon [11:11] Toksyuryel: oh, interesting [11:12] given the number of attempts I'd wager that's not the real owner of that nick [11:12] I'm pretty sure it is [11:12] lifeless: ah I see [11:12] oleavr: so if they could msg me and say 'fixed unban me' I would ban them, but as I have to go - bad idea === Guest55290 is now known as Leonidas === Leonidas is now known as Guest40836 [11:14] lifeless: yep, understandable :) [11:14] Toksyuryel: I reckon they are not in front of the pc/not notcing nickserv complaining [11:14] lifeless: then why does the nick keep changing back? [11:14] Toksyuryel: client [11:15] Toksyuryel: or they don't understand why its happening [11:15] lifeless: what client auto-changes one's nick back? [11:15] if they don't understand why it's happening it means they don't own the nick [11:16] 20:15 [freenode] -!- away : Auto Away at Thu Jul 3 16:41:12 2008 [11:16] a better script might be an auto-identify script :P === Guest40836 is now known as Leonidas [11:17] -Guest2534- VERSION ZNC by prozac - http://znc.sourceforge.net <-- Apparently that client. === Leonidas is now known as Guest560 [11:18] Oh, it's a bouncer. [11:19] *!*leonidas@chronon.* [11:20] clearly, after 10 days idle this is unlikely to go away in the next 5 hours :) [11:20] heh heh [11:21] Peng: so search [11:21] Peng: I think its alpha - it works but there are some important things to do to make it as slick and smooth as the rest of bzr [11:22] Peng: getting indices shared between branches; stemming; date ranges; for starters [11:24] and there is the boarding call; I must go [11:24] back in 6 or so [11:24] lifeless: D'oh, I was jsut about to say something. Anyway, have a nice flight. :) [11:24] Peng: oh, I think search is reliable now, just not complete; if that helps with clarity [11:24] bye [11:25] lifeless: Thanks, it does. [11:28] ping luks [11:33] GaryvdM: FWIW, my IRC client says his last message was 186 minutes ago. [11:33] ok - thanks [11:36] GaryvdM: pong [11:37] I wanted to chat about qdiff [11:37] I was thinking for background loading [11:38] The different views each have a append_diff method [11:39] The background loading calls thoughs methods when it has finished a diff. [11:40] have you seen my changes to the code from yesterday? [11:40] That will split populate_diff_documents. [11:40] Yes [11:40] Thats why I wanted to chat [11:41] So far - I actually have not written any code. Just reading and planing. [11:41] personally, the only thing I'd do is moving sequence matching from the initialization code to populate_diff_documents [11:41] and make populate_diff_documents only work on one file at a time [11:42] which would be repeatedly called by an idle timer, until all files are diffed [11:43] ok [11:46] GaryvdM: I mean, I don't mind any other solution if you think it's better, but this seemed the easiest to me [11:46] you are going to write the code, after all, you decide :) [11:47] DiffSourceView.setChanges and DiffViewHandle.setChanges need the be changed to extendChanges [11:47] yep [11:47] Yes - but you know then code better than I so you might be able to give me advice... [11:48] Ok - time to dive in.... [12:14] $ bzr update [12:14] You tried to execute: bzr serve --inet --directory=/ --allow-writes [12:14] Sorry, you are not allowed to execute that command. [12:14] bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) [12:14] gnash project, repository on savannah [12:14] lp? [12:14] does 'unset BZR_REMOTE_PATH ; bzr up' work? [12:15] no such env [12:15] misconfigured server on savannah? [12:15] same error with the unset anyway [13:06] strk: sounds like a misconfigured server [13:12] they must have changed something within the last 12 hours then [13:52] hi there [13:52] I'm using bzr bzr1.5 installed from fink in mac os x [13:52] I'm always getting a locale error [13:53] bzr: warning: unknown encoding . Continuing with ascii encoding. [14:10] hiya [14:10] I hit a bug in bzr cat [14:10] http://pastebin.com/f78cd4840 [14:10] I don't know what to make of it [14:25] mathrick: That's https://bugs.launchpad.net/bzr/+bug/175570, I think. [14:25] Launchpad bug 175570 in bzr "bzr cat over bzr protocol fails" [Undecided,New] [14:26] spiv: ah, bummer === bigdo2 is now known as bigdog [15:55] I just posted a patch on the bzr-gtk mailinglist with some dialog cleanup.. any comments? [15:56] Yeah, but I'm replying on-list. [16:21] lifeless: you can unban me already, I've got it working again [16:21] my bouncer started to play ping-pong with the services [16:22] (sorry for these problems, I'll take a look at the configuration of the bouncer) [16:24] Did the bouncer finally give up or what? [16:46] Hi; I plan to turn my web site into a branch repository to hold different simultaneous developments. But is there an easy way to check out a whole repository with all branches? [16:56] clemente, I don't know of such a way; I've occasionally wanted a "bzr branches http://foo/repository" kind of command, which would let one script things [16:56] (there might be one, I have not really looked for one throughly) [16:59] About the olive.glade file: The window_merge is used in MergeDialog in olive. But, unlike the other window_* dialogs, MergeDialog is not in the olive subfolder but in the main folder in merge.py. Is it thus used outside of olive? [17:01] liw: that would be good; otherwise you need to know the exact name of each branch; is it like that? [17:01] clemente, as far as I know, you need to know the exact name of each branch to check them all out [17:17] I'm enhancing Bugs Everywhere to support operations on arbitrary branch URLs, not just working trees in the current directory, and I'm not sure how best to go about re-structuring the bzr backend of it [17:18] namely, the current implementation happily invokes bzr as a subprocess (ie. plain old popen()), and assumes there is a working tree available. So it can do things like add several files, then commit them all in a batch [17:18] bzrtools adds a "bzr branches" command that recursively finds all branches in the current directory. [17:18] what is the best way to implement that from python using bzrlib? [17:18] that is, I want to be able to accept several ops, construct a revision from them, and then push it to a branch [17:19] having temp files is A-OK, but requiring working trees is not [17:22] Peng: but not on a remote server, I think [17:23] (trying) [17:25] Mmmm :-( [17:25] bzr: ERROR: Could not understand response from smart server: ('UnicodeDecodeError', 'ascii', 's:w7p0aWxlcw==') === kiorky_ is now known as kiorky [17:59] * mathrick still looks for someone to help him with navigating bzr's innards [18:00] to rephrase my question, is it possible to build up a commit without having a (physical) working tree? [18:25] mathrick: I have no idea... Maybe you can construct a pack directly? Or maybe using bzr fast-import... fast-import accepts just a stream of data and does not require files [18:25] oh, that's certainly a hint, thanks [18:26] It is the same data format that „git fast-export“ creates [18:28] mathrick: yes [18:28] mathrick: there are tests that do this using InMemoryWorkingTree [18:28] or MemoryTree or whatever I called it [18:28] oh! [18:29] cool, so reading those tests should tell me everything I need to know? [18:29] its only as sophisticated as I needed it to be at the time; but further improvements would be welcomed:) [18:29] mathrick: yah [18:30] I don't expect my needs to be terribly sophisticated, I follow a rigid protocol and mostly communicate with myself [18:30] well, somewhat rigid [18:33] mathrick: well, give it a shot; let me know how it goes [18:34] yup, doing that now [18:34] Leonidas: unbanned, thanks [18:38] lifeless: thank you. I changed the settings and will change the bouncer to prevent this from happending in the future [18:38] Leonidas: no probs [18:50] * Odd_Bloke returns. [18:55] http://www.yosefk.com/blog/dvcs-and-its-most-vexing-merge.html -- that has probably been discussed to death, yes? [18:56] does put_file_bytes_non_atomic replace the previous contents? [18:56] liw: the answer is "depends on your merge algorithm" [18:57] in particular, diff3 fails this test miserably [19:23] funfact: bzr-gtk trunk is 1000 days old today [19:23] at least.. according to my olive information dialog :) [19:28] mathrick: yes it replaces [19:29] colbrac: cool [19:33] In a repository, I did (knowingly...) „rm -rf branch/“. But since the contents were stored in repo/.bzr and not in the branch, repo/.bzr has still a lot of things I don't want. How can I really remove the remainings of the branch? [19:34] clemente: you mean a gc? [19:34] yes [19:34] I should really write that :). Anyhow, the manual way is to make a new repo; branch the branches you want to keep into it and then replace the old repo's .bzr/repository with the new one's. [19:34] but there's no „gc“ command [19:35] thats what bzr gc will do when I get around to writing it [19:35] (well, it will optimise away some of the copying, but it will be conceptually the same) [19:37] Thanks, I'll try it. By the way, I had to remove the branch by force because I had interrupted a „branch“ with C-c and then no command I tried could delete it [19:37] That reminds me... is there a way to see which abandoned branches are in the repo, and maybe get them back? [19:37] clemente: did you try zr break-lock ? [19:37] ToyKeeper: bzr hads [19:37] *heads* [19:38] bzr heads only shows 2 for me [19:38] and I have a few more [19:38] Hmm, must be in some plugin I don't have right now. I think I've seen it somewhere, though. [19:39] bzr help heads to the rescue [19:39] bzr heads --all [19:39] or even better [19:39] bzr heads --dead-only [19:39] lifeless: No... In fact I don't know how to remove the branch. Is it remove-tree? [19:40] lifeless: By the way, I thought that command „reconcile“ would be similar to what you said about „gc“. Maybe they share features [19:51] clemente: to remove a branch its normally just rm -rrf branch [19:51] erm, -rf I mean :) [19:51] ToyKeeper: its in bzrtools [19:51] clemente: remove-tree removes the working tree, so you just have the branch on its own. [19:54] But it's still needed a command to remove a branch which exists in a repository [19:54] Althought rm -rf + bzr gc would work, too... [19:54] Ah, I just hadn't set up a version compatible with bzr.dev yet. [19:59] clemente: well, yes. generally though a branch is a tiny fraction of a repo [19:59] clemente: so there has been little user pressure to make this part of the system streamlined (though it will happen) :). In particular, rming the directory leaves the head behind which is beneficial [19:59] (if you want to recover later :)) [20:03] Hmm, I occasionally mess up with bzr-svn and pollute a repo. A gc command would be nice there. [20:05] Peng: well a first implementation for packs would be refs = last-revision + tags for b in repo.find_branches(); create-pack_from_packs(revs = refs); remove packs matching refs; [20:06] Would it wind up packing everything into one pack? [20:12] nah, only the ones it has to read to grab shit from [20:13] theres a little more glue etc in there, that was clearly just a sketch :) [20:39] how can I update to a revision from a workingtree? [20:42] apol: udpate will take you to tip, revert can take you back [20:42] mmm [20:42] fine [20:42] but... update only updates [20:42] yes, need to add -r to it [20:42] lifeless: i need to update it to a certain revision (say as svn up -r213) [20:43] apol: revert -r 213 [20:43] apol: if you have local edits, shelve them first [20:44] lifeless: and with the python interface? is it the old_tree parameter? [20:45] apol: not sure offhand, builtins.cmd_revert and follow your nose probably [20:45] lifeless: cool [20:47] thx [20:47] np [21:45] Huh, Loggerhead's RAM usage has dropped slightly twice today. === abadger_afk is now known as abadger1999 === RAOF_ is now known as RAOF === davi_ is now known as davi [22:52] * Foskasse http://graphjam.files.wordpress.com/2008/06/gj32.gif LOL! [22:57] ok, so I can hit https://bugs.launchpad.net/bzr/+bug/175570 with memorytree as well against bzr:// [22:57] Launchpad bug 175570 in bzr "bzr cat over bzr protocol fails" [Medium,Confirmed] [22:57] it seems that branch.lock_read() does NOT lock the repo [22:57] even though branch.is_locked() returns true [22:58] could anyone assist me with debugging that? [22:59] mathrick: do you have a testcase ? [22:59] mwhudson: I will in a second, but I wanted to poke around more in PDB [23:03] hm, the traceback in the bug report is out of date [23:04] mathrick: it seems to work for me now [23:05] it doesn't for me [23:05] I'm running 1.5 btw [23:05] mathrick: i'm running 1.6b2 i think [23:05] mostly because 1.6 breaks loggerhead and it hasn't been updated last I checked [23:05] mathrick: this seems like this sort of thing that might have been fixed by accident in the versionedfiles refactoring [23:05] mathrick: i'm pretty sure loggerhead works with 1.6... [23:06] it didn't when I tried [23:06] try again :) [23:06] if it does, then I see no reason to stick with 1.6 :) [23:06] http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/revision/181 looks relevant [23:12] yep, thanks [23:14] isn't there a PPA for bzrtools? [23:29] mwhudson: still happens for me on 1.6b2 [23:29] mathrick: hmm [23:29] oh, maybe it's because the server is still running 1.5 [23:29] ah [23:30] nope [23:30] reran it as 1.6b2, still happens [23:34] mwhudson: https://bugs.launchpad.net/bzr/+bug/175570 [23:34] Launchpad bug 175570 in bzr "bzr cat over bzr protocol fails" [Medium,Confirmed] [23:35] mathrick: can you pastebin the traceback? [23:35] mwhudson: I did [23:35] if i run bzr serve in one window [23:35] as a python comment [23:35] oh ok [23:35] i can run "bzr cat bzr://localhost:4155/README" in another [23:36] mwhudson: hmm, can you try subdir/README? [23:36] nah, that happens here for files in the main dir as well [23:37] mwhudson: what is the format of the repo? [23:37] very odd [23:37] mine is pack-0.92 [23:38] same [23:38] hm, if i run your python code it fails in a different way [23:38] http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/revision/181 [23:38] no [23:38] NotImplementedError: > [23:39] oh [23:40] mwhudson: definitely something is not in sync at your place [23:40] it's implemented and supposed to work [23:41] oh [23:41] that's because i have symlinks in the tree i'm testing with, it seems [23:43] ok, now it fails the same way as for you [23:45] mathrick: http://pastebin.ubuntu.com/27148/ seems to summarize the problem [23:46] * mwhudson pulls in latest bzr.dev [23:54] I'm working on a bzr branch and it uses the bzrlib from my Ubuntu installation instead the one from that branch ( without my permission ;-) [23:54] How do I force it to use the one that comes with it [23:54] s/bzr branch/bzr bzr branch/ [23:55] cyberix: /path/to/branch/bzr selftest ;) [23:55] cyberix: s/selftest// [23:58] That is what I'm doing [23:59] hm, cyberix: try with: PYTHONPATH=/path/to/branch:$PYTHONPATH /path/to/branch/bzr