[00:02] jam, igc, spiv: call now [00:02] poolie: waiting for you to show up :) [00:16] jam: also - #ubuntu-wow [00:16] poolie: ^ [00:21] thanks [00:21] lifeless, igc: reading the thread now, this might take more than 15 mins [00:22] -> food then [00:22] poolie,lifeless: let's aim for 10 then [00:27] k [00:50] abentley: ping; are you interested in me making MPVersionedFile meet the VersionedFile (reduced) api ? [00:58] abentley: also can I request a review from you for my loom push fix. [01:01] Hello. I've used bzr in linux before, but now I'm trying to get it working in windows through putty. I can run bzr in a terminal, or I can run putty and log on to my server (where I'd like to build a repository) with putty... but I'm not sure how to run bzr in putty... I think I'm missing something. [01:01] poolie: igc: its 10 [01:02] poolie,lifeless: normal number? [01:02] igc: as far as I knew, yes. [01:02] we could use skype if that's easier? [01:02] elevator music @ home sucks [01:03] calling in now on normal number [01:06] hey, can someone help a noob with an admin question? [01:06] I'd like to setup an server for a central repository [01:06] the docs tell me to use sftp to upload a branch [01:07] but I want to make it publicly accessible [01:07] how would I do this with sftp? [01:07] you can make it read-only accessible via http, and have users write via sftp [01:08] so, setup an apache server? [01:09] well, whatever htpd you like. you could setup an anonymous sftp account if you prefer. [01:09] gnu used to do that for cvs over ssh, iirc [01:09] OK. so, I tried searching for some good docs on settings up sftp, but came up short [01:10] can someone point me to a good guide? [01:10] I can setup sftp so users can access their own home dir, but not to a shared dir [01:10] or even how to allow anonymous access for that matter? [01:12] this is hard enough even if i can hear you :) [01:12] dagreen: on unix or windows [01:12] fedora === mw is now known as mw|out [01:13] How do i uze bzr in putty? [01:13] unix [01:13] ChrisPitzer: what preciesly are you trying to do? use bzr+ssh:// urls? [01:13] dagreen: so basically you should put them in a unix group [01:14] and create a directory writeable by that group to hold the repositories [01:14] if you're trying to host an open source project you can alternatively use launchpad.net [01:14] not open source, internal company use [01:15] so, if they were to checkout a project by typing bzr branch sftp://my-server/myproject [01:16] do I have to put a link to that directory from all their home directories or something? [01:16] no [01:16] bob2: I'm trying to use putty to ssh onto a server and set up / work with bzr repositories. [01:17] users connected via sftp have the same access rights as they would if they logged in via ssh [01:17] so it can go anywhere they could normally reach it (e.g. /srv/bzr/) [01:17] ChrisPitzer: as in ssh in via putty, and run bzr from the command line on the remote machine? [01:18] i tried that - bzr isn't installed on the remote machine. [01:18] there's your problem then ;) [01:18] haha. [01:18] i know [01:19] you can access it remotely with sftp:// urls, have you tried that? [01:19] i have bzr installed on *this* machine though... can't I use this bzr instance to create remote repositories...? [01:19] just from the command line - no putty...? [01:19] "bzr init-repo sftp://blah/blah" [01:19] hu... I'll give it a shot - brb [01:20] I think you need paramiko installed for that [01:20] (i still think very "windows" some times) [01:21] poolie: after I shared directory and give the appropriate permissions to the group, how do I make it so that directory is the root when they sftp?? === lamont` is now known as lamont [01:23] don't think regular openssh has sftp chrooting [01:23] k, so the only way to make urls look like root is through http then, right [01:24] ? [01:36] dagreen: just use sftp://host//home/group/repo [01:37] k. that should work for me. didn''t know there was a /home/group [01:37] thx [01:39] so... check my crummy syntax here... [01:40] bzr init sftp://username:password@sub.domain.com/src [01:40] because, that results in a bunch of happy text with a last line of "bzr: ERROR: No such file: '/src':" [01:43] try //src [01:45] same sad ending. "no such file: '//src' " [01:45] is there a /src on sub.domain.com? [01:45] hehe... yes. [01:46] where is // ? root? [01:46] ooooh... bingo [01:46] that's it. I need to specify full path on the server, not relative. [01:51] With sftp you can specify relative with a ~. sftp://user@dom.ain/~/src [01:55] thanks! [02:28] Hey all. So, am I right in figuring out that bzr-email ONLY works from the client-side? [02:28] That's right. [02:29] lifeless: was it just me that dropped out? [02:29] That is frustrating. [02:29] poolie:^ [02:29] igc: yes, credit ran out [02:36] awmcclain: https://bugs.edge.launchpad.net/bzr/+bug/211967 [02:36] Launchpad bug 211967 in bzr "bzr smart server should support hooks" [Medium,Confirmed] [02:38] lifeless: dropped out - I think we're done though, yes? [02:38] poolie:^ [02:39] lifeless: if not, you can call me on my home line now [02:40] poolie: the knit fetch hotfix has landed in trunk [02:41] awmcclain: we're working on fixing that. I just updated the bug radix linked to with some details. [02:41] woot [02:41] yay! [02:41] Ok. Not a problem. [02:42] oh, so it might already be possible? [02:42] great [02:42] radix: yeah [02:42] radix: "might" being the important word, I don't think it's actually been tested yet. In theory it should be fine... [02:42] spiv: bzr-email needs to be altered [02:43] lifeless: right. I didn't mean to give the impression that bzr-email specifically would Just Work, yet. [02:43] Just that it should now be possible to write something that uses the new hook, and have that get triggered on the server. [02:49] thumper: your patch is merged [02:50] yay [02:50] ta [03:12] lifeless: Updating the MPVersionedFile API is fine with me. I guess reducing the number of APIs is a win, but it doesn't seem like a big win to me. [03:13] abentley: i just noted in passing was all [03:13] Oh, I thought you were offering to change it. [03:14] abentley: yes, if you thought it was a good thing [03:14] but I also don't have a strong drive to do so [03:16] This loom push thing you want me to review is actually a patch to the loom plugin? [03:20] yes [03:21] there are two folk writing loom code [03:21] and I like peer review [03:22] I've taken a short cut in fixing push; I'm hoping you'll assess whether the short cut is ok, or say 'its better to leave it broken for a bit and get a more tasteful fix' [03:24] bb:approve I think it's a worthwhile improvement. I suspect the wrong hook will fire, but I guess that's tolerable for now. [03:24] hey folks [03:24] thank you [03:25] re BB, I apologize for the downtime. It messed up this morning, and I wasn't able to get it working again. [03:25] ouch [03:25] It's like everything I try to improve things makes it worse. [03:28] is there any assistence you'd like ? [03:39] lifeless: I'd like to see if using pgsql clears up the locking issues. Do you know a good way to convert the data? [03:39] I'd probably export vis csv or similar [03:40] Really. Huh. [03:40] *via* [03:40] I did try just doing an SQL dump. [03:40] But it seems like pg doesn't recognize some of SQLite's escaping. [03:41] alternatively you could do a select & insert within python [03:41] I'm sure there are good toolchains to do this, I've never needed to though === bigdo2 is now known as bigdog [04:00] got to love the weather [04:03] lifeless: It's probably different where you are than here. Nice and sunny? :) [04:05] It's dark in Denver Colorado .. but it was a nice day. [04:05] To the BZR team, thank you for a great tool. [04:08] RAOF: loud rain [04:08] poolfool_: thanks! [04:10] lifeless: have you thought about doing a pod cast? FLOSS with leo leport(sp) had somone from the GIT team on in January. [04:10] that could be interesting [04:11] no swearing. [04:11] http://twit.tv/FLOSS [04:12] bob2: searing? [04:12] s/searing/swearing/ [05:16] * spiv -> lunch [05:49] bbiab - picking kids up from school today [05:54] http://www.justdave.net/dave/2008/04/06/bugzillamozillaorg-now-in-version-control/ [05:54] ^ cute === bigdo1 is now known as bigdog [06:48] poolie: ping [06:49] pong, the witch is dead,... [06:50] Phew. That'll save me the alimony... [07:10] fullermd: better than 'the bitch is wed' [07:10] "Fornication? But that was in another country. And besides, the wench is dead." [07:44] Hi. Does anybody know what to do if I get the error message "bzrlib.errors.TokenMismatch: The lock token [...] does not match lock token (remote tokens)" while committing? (bzr 1.3) [07:46] jelmer: you had someone break the lock on you [07:46] meh [07:46] joerg_: ^ [07:47] any idea lifeless? [07:47] try again [07:47] it may be out of date [07:47] or if its bound it may need to be pushed at this point [07:49] I'm not sure what "bound" means. Do you suppose to try bzr update and then bzr commit again? [07:52] yes [07:53] docu says: "If you have a local branch and wish to make it a checkout, use the bind command like this: bzr bind sftp://centralhost/srv/bzr/X-repo/X-trunk" [07:53] That is not the case. Its a checkout from a branch laying on the server repo [07:56] k [07:56] just do update and commit I think [07:56] ok I try it. Thank you! [08:04] spiv: steve says you were going to speak to jam about the problem of " attempt to add line-delta in non-delta knit" [08:04] do you know what's up with that? [08:07] poolie: No, I don't know what's up with that. [08:07] poolie: jam thought it might be related to the critical fix we did for 1.3.1rc1 [08:08] bye for the day [08:08] poolie: which sounds plausible but not hugely likely to me. I don't know anything more about it. [08:09] (if anything, I'd expect the fix we did to try insert fulltexts unexpectedly, rather than line-deltas) [08:11] bye lifeless [08:11] it does seem to be in a similar area [08:12] i asked andreas to open a bug about it [08:12] Is the ghost issue considered serious enough to be a 1.4 blocker? [08:12] Yeah. I suspect it's related somehow, maybe the same root cause that caused the 1.3 regression? [08:13] I don't think I've seen a traceback for it yet though, so it's hard to speculate. [08:54] night all [10:20] good night [10:55] If you have an SSH key in launchpad you should be able to use bzr_shh to download anything from an LP bzr repo, no? [10:56] Or is it sftp? [10:56] both should work [10:57] I'm having trouble, is there a particular form for the username? [10:57] whatever your lp username is [10:57] what's your lp homepage URL? [10:57] https://launchpad.net/~adrian-wilkins [10:58] and which branch are you trying to fetch? [10:58] I've tried my email address (with @ escaped and not escaped), adrian-wilkins, all sorts [10:59] awilkins: you should be able to use URLs like "bzr+ssh://adrian-wilkins@bazaar.launchpad.net/..." [11:00] Hmmph, it works with paramiko but not plink [11:00] Ah, I don't know much about the magic to make plink work. [11:00] * spiv -> food [11:00] New bug: #217650 in bzr "Use of authentication.conf causes update to fail" [Undecided,New] https://launchpad.net/bugs/217650 [11:00] That's a regression, it should work with either [11:01] It used to work with plink AFAIK [11:01] Installing paramiko on Win32 is a PITA compared to plink as well. [11:53] That horizon feature would be nice around now :-) [11:54] What's the practice for submitting merges ; do you submit them all to bzr.dev, or do you submit them to the branch you are making them from? [11:55] New bug: #217666 in bzr "exceptions.MemoryError when getting http://arch.sv.gnu.org/archives/emacs/bzr/emacs.app" [Undecided,New] https://launchpad.net/bugs/217666 [11:56] awilkins: bzr.dev, unless you are making a change to something not yet merged, or fixing something on a release branch [11:57] james_w: It's jsut a little patch to a couple of the hidden commands to make them more consistent with bzr unknowns [11:58] bzr.dev sounds right then. [11:58] Is there a mail I can bzr send to? Or do I put up a bug with a merge bundle in it? [11:58] (PQM is a bit much right now) [11:59] bzr send --mail-to bazaar@lists.canonical.com [11:59] Groovy. === mrevell is now known as mrevell-lunch [13:25] New bug: #217701 in bzr "attempt to add line-delta in non-delta knit" [Undecided,New] https://launchpad.net/bugs/217701 === mw|out is now known as mw [14:55] New bug: #217737 in bzr "bzr merge gives error over Revision {('',)} not present in """ [Undecided,New] https://launchpad.net/bugs/217737 === Pilky_ is now known as Pilky === kiko__ is now known as kiko [17:40] Morning [17:40] I'm trying to use bzr with svn and have problems pushing to svn [17:41] it fails with error "('Mindestens eine Eigenschafts"anderung ist fehlgeschlagen; Projektarchiv nicht ge"andert', 175008)" wich roughly translates to "at least one property couldn't be changed" [17:44] Well, I'm quite puzzled what it means by that and am currently trying to convince it to give me a propper english response so I can search for it. [17:46] dwt: type `LANG=en_US.UTF-8` in a shell and try to push [17:47] thanks andrea-bs - I'm trying it right now === kiko is now known as kiko-fud [17:50] How can I force a synchronisation between an SVN repo and a local Bazaar branch? Bazaar claims that both a diverged (which is technically correct), however, de-facto both branches contain exactly the same files. I could merge, but then I get tons of conflicts. [17:52] Well, now it's much more talkative. I actually get a traceback and tells me that 5 should file a bug. [17:52] well.... [17:52] The error is: SubversionException: ('At least one property change failed; repository is unchanged', 175008) [17:52] I'm gonna google for that [17:52] but if anybody of you can give me a hint how to debug this further, I'd love to hear it. :) [17:53] dwt: this sounds like a bug, could you please past the entire traceback on ? [17:54] sure [17:54] http://paste.ubuntu.com/7133/ [17:57] It could be a bit more verbose about what property exactly it couldn't change.... [17:57] dwt: it seems a repo problem rather than a bzr problem [17:58] ok..... [17:58] I'l test that with svn [17:58] and see what I get [18:01] I have to go now, bye! [18:02] thansk anyway andrea-bs [18:02] Well, subversion works perfectly [18:02] and I can also pull changes I got from subversion [18:02] and merge them and everything [18:03] though no push [18:15] jam: can you remind me how your push and update plugin works again? [18:16] never mind, I realized it runs automatically [18:16] :-) [18:16] newz2000: if you have it installed (the newest version) when you do 'bzr push' it should check if it is an ssh connection, and then run 'ssh host; bzr update' fo ryou [18:16] for you [18:16] newz2000: right, an earlier version required you to run 'bzr push-and-update' instead of 'bzr push' [18:17] the newest version just installs a post-push hook to do it automatically [18:17] nice plugin. Just what I need. :-) [19:19] can someone help me use bzr-svn? i can't figure it out :/ [19:19] i do bzr branch svn://whatever and i get bzr: ERROR: Permission denied: ".": Can't get password [19:21] Stavros: hi [19:21] Stavros: See the FAQ [19:23] i did, hmm [19:23] it needed an svn info, svn up didn't cache the password [19:23] but now it fails with permission denied [19:24] :/ [19:24] did you run "svn info" on the root url of the repository? [19:24] What OS are you on? [19:24] windows [19:24] i didn't, sec :/ [19:24] apparently i don't have permission to do that [19:24] Stavros: Ah, it's broken on Windows atm unless you have Subversion 1.5 I think [19:25] i installed the patched binding [19:25] s [19:25] i can't stand svn, it bogs down my entire system to do a simple diff [19:25] bah, i guess i'll have to live with it... [19:25] Stavros: the patched bindings don't contain the required fix for this [19:25] is it safe to push with bzr-svn? [19:25] ah [19:25] yes [19:25] i ah, good [19:26] i don't want to much the repo up if it works eventually [19:47] Hey, how would I get the reverse of "bzr diff"? [19:48] abadger1999: between two revisions? [19:48] ie: the diff of working tree -> latest commit. [19:48] ah [19:48] I released a package out of a modified working tree instead of a fresh checkout. [19:49] personally I'd do [19:49] b commit -m foo [19:49] b diff -r -1..-2 [19:49] b uncommit [19:49] abadger1999: try with "bzr merge file.diff" [19:49] dato: Thanks! That'll work for me. [19:49] andrea-bs: k. I'll try that first [19:51] abadger1999: it works with patches generated by "bzr send" and I'm not sure if this will work also with diff output [19:51] andrea-bs: bzr merge just tells me "Nothing to do." [19:53] abadger1999: patch originalfile patchfile [19:54] hey, so, is a "bzr obliterate" feature on the plan anywhere? I just had to remove some data from svn that was committed a year ago. It wasn't trivial, but it was possible, without screwing up every developer's checkout everywhere. It seems like with all the fancy DVCSes, that's simply impossible. (which is a problem) [21:06] >.> [21:06] whats the difference between bzr and svn [21:06] lol [21:11] Noia: to keep it short: bzr is better :p [21:53] hi jam [21:53] lifeless: hi [21:53] lifeless: have you done anything with instrumenting packs? [21:53] I've been thinking about doing a little bit of hit/miss stuff [21:54] and then my ISP decided it required authenticated sends, and I had to spend way too much time getting Postfix to properly talk to them. [21:55] jam: exim4 ftw :P [21:55] well, my server is currently a really old FC4 install [21:56] jam: no, as I said in my mail I don't have the time to do anything about it right now [21:56] but I wanted to share the underpinnings that seemed to be missing when folk were trying to analyse it. lsprof is good, but it can't tell right from wrong. [21:56] (the problem was that FC4 versus Breezy, and Breezy didn't recognize my SATA hard-drive card automatically) [21:57] lifeless: well you could pretty easily, if you broke up the cache hit into a separate function [21:57] I've certainly done stuff like create an inner function for loops so I can see how much time is spent in each [21:57] def run_loop_x(): [21:57] for foo in bar: [21:57] pass [21:57] run_loop_x() [21:58] jam: that doesn't tell right from wrong [21:58] lifeless: that is to profile the time spent in that loop (as an example) [21:58] yes, but I never said lsprof can't do that [21:58] You could try something similar for cases where there is a hit versus a miss [21:58] call a different func [21:59] but I'm not sure where the time is actually spent [21:59] anyway, I understand your point [21:59] it is still hard to *time* a miss versus a hit [21:59] counting isn't hard [22:00] its also hard to decide if the amount of time per unit is as expected, or the number of units is as expected [22:00] that requires a model for the operation [22:01] e.g. for working tree operations we all share the model of '1 stat per file, and 1 read per file if needed' [22:01] lifeless: by the way, I think our pack => knit fetcher causes weird problems with revision_id references [22:01] specifically, I think I see it generating revisions out of order [22:01] (newest first, rather than topologically sorted) [22:01] I can say that my knit repository (which I push to from packs) has all sorts of crazy stuff going on [22:01] still technically "correct" but just improperly orderd [22:02] interesting [22:02] The problem is that I'm generally seeing all of this as artifacts in revisions.kndx, without actually reproducing it [22:08] lifeless: can I have you take a peek at a line of code [22:08] Specifically line 662 of bzrlib/index.py [22:08] It seems to be mixing indices [22:08] index = self._parsed_byte_index(location) [22:08] # if the key is below the start of the range, its below [22:08] if key < self._parsed_key_map[index][0]: [22:09] lifeless: if I'm actually reading a bug, then it would indicate we are not properly "bisecting" [22:10] or does _parsed_key_map[index] always match up to _parsed_byte_index [22:11] in the __init__ [22:12] # a sorted list of slice-addresses for the parsed bytes of the file. [22:12] # e.g. (0,1) would mean that byte 0 is parsed. [22:12] self._parsed_byte_map = [] [22:12] # a sorted list of keys matching each slice address for parsed bytes [22:12] # e.g. (None, 'foo@bar') would mean that the first byte contained no [22:12] # key, and the end byte of the slice is the of the data for 'foo@bar' [22:12] self._parsed_key_map = [] [22:12] (they use the same values to lookup [22:12] its not a single map to a tuple because of bisect needs [22:12] oh, where is my cleanup of this code [22:13] I have a branch that introduces an abstraction here [22:13] pushing it now [22:15] New bug: #217917 in bzr ""bzr commit" MemoryError crash" [Undecided,New] https://launchpad.net/bugs/217917 [22:24] jam: whats an operation thats still problematic ? [22:50] Quick question: I couldn't find an answer in the bzr user guide. [22:51] I want a "pushed" branch to always have the current contents [22:52] eg, I run bzr push from my laptop, and want the pushed location (a web accessable directory on a server) to automatically update [22:52] lifeless: well 'bzr status' after a pending merge, but that is bad for other reasons :) [22:52] goozbach: the push-and-update plugin can do that [22:52] is this possible without creating a hook [22:52] a simple 'bzr log' on a very long history is bad [22:52] * goozbach googles [22:53] mwhudson: thanks [22:53] lifeless: 'time bzr log --short -r -10..-1 bzr.dev' is quite a bit longer than it should be [22:53] goozbach: cd ~/.bazaar/plugins; bzr branch lp:bzr-push-and-update push_and_update [22:53] (possibly with a mkdir -p ~/.bazaar/plugins first) [22:54] jam: just got it [22:54] thanks though [22:54] goozbach: it will update if it detects that the remote location has a working tree, and you are connecting over sftp or bzr+ssh [22:54] it won't do it if you are using ftp etc [22:54] yay! [22:54] jam: 2.5 seconds for me [22:55] hooray for not re-inventing the wheel [22:55] thanks guys [22:55] lifeless: yeah, but it used to be <1s [22:55] k [22:55] I knew I wasn't the only one who wanted that to happen [22:55] goozbach: it does require that you have bzr installed on the remote machine, and have regular 'ssh' access [22:55] in case that matters [22:56] (it basically just calls 'ssh host bzr update' for you) [22:56] lifeless: 'bzr log --long -r -10..-1' would also be even worse, I just never use it [22:57] --long is going to do a whole revision-graph search because of dotted revnos [22:57] jam: it's working. [22:57] I was mostly wondering if someone else had done the legwork [22:58] yay! [22:59] goozbach: yep, I'm glad it works for you, feel free to post bugs, etc. [22:59] it is pretty simple, though, so I don't expect you would have problems. [23:00] I suppose I should now trap into the 'branch_changed_revision' hook in 1.4, so that it will also work if you have a checkout of the public location, rather than only on push [23:50] Good morning. [23:54] morning spiv [23:55] morning [23:55] morning jam, spiv