[00:00] morning bzr dudes [00:05] morning all [00:52] jam-laptop: there's no guarantee though that a revision with multiple parents contains only merges [00:52] jelmer: what do you mean? [00:53] lifeless: we were talking about rebasing "merge revisions" [00:53] and how you could skip them during rebase if the rhs parent has already been merged in the branch you're rebasing [00:54] jam-laptop: ping [00:54] jelmer: surely its a topo sort of the revisions and rebase them all; merges too [00:56] lifeless: rebasing a commit with a rhs parent that has already been merged is most likely going to cause conflicts [00:57] https://bugs.edge.launchpad.net/bzr-rebase/+bug/126743 [01:05] New bug: #154119 in bzr "Repository.item_keys_introduced_by should not lock Repository" [Medium,Triaged] https://launchpad.net/bugs/154119 === kiko is now known as kiko-afk [01:41] New bug: #154129 in bzr "pack does not optimise layout" [Undecided,New] https://launchpad.net/bugs/154129 [01:59] igc: poolie: first round of fixen pushed [02:27] jam-laptop: ping [02:41] hi igc [02:41] hi lifeless [02:42] working thru pack_repo.py today FYI [02:55] cool [02:59] will bazar launch a merge tool for me? [03:00] do you mean a gui conflict-resolving tool ? [03:01] lifeless, yes, such as Meld on Linux, or TortoiseMerge on windows? [03:01] / per-file merge tool ? e.g. meld ? [03:01] Yes, there are some plugins that do this [03:01] I'll look in the plugin section on the wiki. thanks. [03:01] np [03:45] ok i've read the whole patch [03:45] i'm going to trim out the boring parts and post my comments === kiko-afk is now known as kiko-zzz [03:48] woot [03:48] mm? [03:50] your having read the entire patch [03:50] I've just replied to all the reviews so far [03:50] and actioned nearly everything I agreed with [03:50] spiv: ping [03:50] lifeless: pong [03:50] theres a gem in my patch for you [03:50] insert_data_stream [03:50] where ith da docstring [03:50] lifeless: heh, just read that a few seconds ago. [03:51] i386: also where were you last night? release party one block from atlassian? [03:51] lifeless: I'll write one and send it to the list. Thanks for the poke. [03:51] lifeless: asleep! [03:51] Is there a way to get 'bzr send' to use a readable patch format? [03:52] Ive been drinking heavily for the last two weeks and Ive been kinda sick [03:52] larsl`: it's got a human copy of the patch by default [03:52] larsl`: if you're not seeing that, what parameters are you giving it ? [03:52] i386: :( [03:52] i386: we put a few back for you :O [03:52] lifeless: No other copy here. I just do 'bzr send --mail-to some@address' [03:53] larsl`: that should fire up your mail client [03:53] larsl`: with an attached patch [03:53] lifeless: It does. [03:53] larsl`: the attached patch should be human readable with a base64 tail [03:53] But the patch looks like a block of uuencoded something. There is no readable text. [03:54] larsl`: thats strange; is this open - can you pastebin the patch for me to look at ? [03:54] Sure, it's just a test. [03:55] lifeless: This is the contents of the sole attachment in the mail: http://rafb.net/p/MFCGVY79.html [03:57] ...oh. I need to commit locally before sending. [03:57] That was just an empty patch. [03:58] :) [03:58] I was just finishing extracting the data to examine [04:31] * igc food [05:12] Trying to push a branch to a FTP server, but I keep getting the error message "FTP temporary error: 451 /bzr/bzzr/.bzr/repository/inventory.knit: Append/Restart not permitted, try again. Retrying." [05:12] "bzr: ERROR: exceptions.AttributeError: 'FtpTransport' object has no attribute 'get_credentials'" [05:12] oh hmm [05:12] It seems to do something, because there are directories added on the FTP server, but I can't checkout. [05:13] Our FTP maintainer is probably asleep right now [05:13] vila: ^ [05:13] anyhow, the knit repository format requires APPE/REST be available, and they appear to be disabled on your server. [05:13] Hm. [05:14] the get_credentials thing is a bug [05:14] but probably only occuring as a side effect [05:15] Would any of the other formats work? [05:16] packs should [05:17] they are currently being reviewed, should be merged later today [05:17] Ah. I'm using 0.91.0 from Debian Testing. [05:23] lifeless: Would weaves require APPE/REST? [05:27] abentley: yes, for the history file in the branch object [05:28] How clever of me to have removed that requirement. === thumper is now known as thumper-office === thumper_laptop is now known as thumper [05:36] lifeless: here's a docstring for Repository.insert_data_stream: http://rafb.net/p/9bcOyO41.html. Any comments or should I just merge it? [05:37] I think its too vague [05:37] you say e.g. bencoded [05:37] is it or isn't it? [05:37] is it allowed to vary by repo [05:38] is there a version marker? [05:38] or is it self delimited by a version? [05:38] why why why basically [05:38] lifeless: I was afraid you'd ask the hard questions :) [05:38] I'm not sure of the answers to a lot of them to be honest. [05:39] there's a list [05:39] I hear smart people subscribe to it [05:39] So none of the current repository formats would work on a FTP server that doesn't allow Append/Restart? [05:40] I'll start a thread there, then. [05:40] New bug: #154173 in bzr "pack reconcile does not correct for the fix_text_parents problem" [Undecided,New] https://launchpad.net/bugs/154173 [05:43] larsl`: sorry, no :( [05:44] I guess there is no write support for HTTP? [05:46] there is a webdav plgin [05:46] plugin [05:47] and there is bzr+http too [05:47] there is also SFTP [05:47] which is more secure than FTP [05:48] Yeah, but FTP and HTTP is all I have for now. [05:49] What's bzr+http? Is there any documentation for it? Google only finds code. [05:51] try googling for 'serving bazaar with fastcgi' [05:52] Seems to be read-only. [05:52] or http://doc.bazaar-vcs.org/ [05:52] latest, user guide, [05:53] if you set auth up, then you can make it read write [05:54] Can I create a patch just using 'bzr -r REVNO.. > mypatchfile' ? [05:55] sure [05:55] that will go from revno to your current tree [05:55] and then the person I send that patch to just does 'patch -p0 < mypatchfile' right? [05:55] Hm. I don't think I have mod_python either. [05:56] gotgenes: if they are not using bzr yes [05:56] gotgenes: they aren't [05:56] gotgenes: if you and they are both using bzr you are much better off committing and using 'bzr send' [05:56] ha [05:56] lifeless: ah, that's good to know! [07:04] bug 154204 [07:04] bug #154204 [07:06] Launchpad bug 154204 in bzr "revision specs do not lock branches appropriately." [Critical,Triaged] https://launchpad.net/bugs/154204 [07:11] New bug: #154204 in bzr "revision specs do not lock branches appropriately." [Critical,Triaged] https://launchpad.net/bugs/154204 [07:29] heading off a bit earlier today to catch up with some people [07:29] might be back later tonight [07:29] if not, have a good weekend all [07:30] igc: me too. Have a good weekend. [07:31] thanks spiv [08:25] jelmer: pong (looks like being in the same TZ doesn't help us to get in touch ;-) [08:26] TZ? You mean those things some weird people actually obey? ;> [08:26] fullermd: yeah, especially children you insensitive clod ! [08:27] :) [08:27] Ah, you just plow a few double espressos into 'em, they'll adjust. [08:37] fullermd: obviously you don't know my daughters, they are already too much and too often awake for our taste :) [08:38] they leave us sleep sunday mornings since a few years though... [08:38] See, if you could just get them to use some of that awake time for bzr hacking... [08:39] why do you think there are so many bugs in my submissions ? [08:40] I see. Kids these days... no QC. [08:41] Sheesh, and don't start me about jam on the keyboard... [08:41] Hah. My first thought to that was "Doesn't John have his own keyboard?" :p [09:23] morning :) [09:40] hey all [09:42] lifeless: nearly, nearly there? [09:54] Good moring bzr hackers [10:16] New bug: #154259 in bzr "traceback on temporary ftp error" [Undecided,Confirmed] https://launchpad.net/bugs/154259 [10:18] I wonder if that error has EVER been temporary... === zerok is now known as zerok|away === zerok|away is now known as zerok [10:33] sabdfl: very very close === Mez is now known as Mez|Away === Mez|Away is now known as Mez === Philosof is now known as Olberd [11:10] Hi. I'm trying to install bzrsvn in windows and can't make it work [11:11] I have installed the python-svn requirement, but apparently not so that bzrsvn can locate it [11:13] or could it be that the win32 package linked to on bzrsvn's homepage isn't new enough? [11:13] jelmer, maybe you know? [11:13] Olberd, Did you install the python-subversion bindings linked fomr the wiki page? [11:15] yes, if you mean http://bazaar-vcs.org/BzrSvn [11:15] New bug: #154283 in bzr "indexerror in Knit._get_components_positions pulling in pack repo" [Undecided,New] https://launchpad.net/bugs/154283 [11:19] Olberd: What exactly doesn't work? [11:19] jelmer, it says in bzrsvn's readme that the svn should be at least 1.5. But the link on the wiki has the version 1.4.3. [11:19] yes, but the .exe linked from the wiki has got the required patches backported [11:19] When I try to run bzr bzrsvn prints: "no python bindings for subversion installed..." [11:23] can you start python and run "import svn" ? [11:24] yes, no errors [11:26] is the same python interpreter used by bzr ? [11:26] or did you perhaps install a bzr that included its own python? [11:28] I used the standalone 0.91 windows installer [11:30] you probably need the python-based installer [11:30] I'll add a link to the wiki page [11:33] ok, I'll try using the other installer [11:43] jelmer: pong (looks like being in the same TZ doesn't help us to get in touch ;-) [11:46] vila: :-) [11:46] vila: What exactly did you with your comment to bug 141105? [11:47] you mean mean ? [11:47] I consider the svn+ prefix a hack, ideally bazaar should just handle SSL certificates properly [11:48] hrm [11:49] jelmer: feel free to reopen the bug then [11:49] what I meant was that bzr now gives a proper error message instead of KeyError: 77 [11:49] ah, ok [11:50] Handling SSL certificates is on my TODO list, python 2.6 will provides an ssl module for that [11:50] problem solved :) [11:50] :-) [11:51] kidding, there is a module that can be installed for python 2.[45], I'm looking into integrating it into bzr or making bzr depend on it [11:51] Ah, I was confusing this bug with bug 82086 [11:51] sorry [11:51] np, better two brains than none on any subject :) [11:51] that module will allow us to also have a proper https server, but there is a bit of work to get there [11:52] and then, we can just deprecate pycurl and drink some champagne :) [11:54] Yeah, that'd be nice [11:56] Is there a way to make a useable diff? I know 'bzr diff', but you can't really apply === modified file 'template.htm' (properties changed) [11:56] bundles [11:57] they're more what you want [11:57] I think [11:57] thanks :) [11:57] Specifically the 'bzr send' command I think [11:59] aah or the 'bzr bundle-revisions' command may be of more use [12:01] :) [12:04] Kinnison: any idea for http://pastebin.ca/742241? [12:04] odd [12:04] make the bundle --no-patch? [12:05] does that work? [12:08] * ryanakca tries [12:08] Kinnison: bzr: ERROR: no such option: --no-patch [12:11] Olberd, any luck? [12:14] ryanakca: odd, because it's there for m [12:14] +e [12:14] hmmm... [12:14] what version? [12:15] 0.90.0? [12:21] Kinnison: hmm... I'll be back in 8 hours or so, school. See you ;) [12:49] hi, i have a question. When two developers push in one branch, and each developer has his own local branch, the log is overwrite. There is a method for push, or something similar that log well? [12:50] i mean, i push, and in the log appear danigm has changed ..., and when other developer push, must appear only his changes, not his branch log [12:51] danigm, not sure I'm following [12:54] when i change something in my own branch, the log say that i make, and i merge with the main branch, and log it as "merged with main branch". And then push my branch, and the log of main branch dissapear, and appear my own log. I upload my own branch, the main branch is dessapear, is merged. [12:57] I think it's possible having two locals branch, my branch, and the main branch. When I want to publish my chages in main branch, I should merge that with mine, and push main [12:58] I *think* he wants append_only = True, lemme re-read [12:59] but I need to branch from main, everytime that i want to push my changes [13:02] oh, he was spanish === mrevell is now known as mrevel-lunch [13:12] jelmer, other error now [13:15] it simply says: unable to load plugin u'bzrsvn' from u'.../plugins' [13:15] I've run 'bzr selftest' [13:15] It returns error: ... no module named svn.transport [13:15] the plugin has to be named 'svn' [13:16] ok [13:16] rather than bzrsvn [13:16] does it say that anywhere? [13:16] it's only necessary for the testsuite afaik [13:17] ok [13:18] well, not only for the selftest [13:19] Renaming it solved my problems it seems === mrevel-lunch is now known as mrevell === kiko-zzz is now known as kiko === mvo_ is now known as mvo [15:01] Hey - what version was pushing using bzr+ssh introduced? According to the release notes, I think it might 0.11 but then it says smart server didn't come until bzr 0.16. [15:06] bzr+ssh isn't smart server [15:06] bzr+ssh is just using ssh isn't it? [15:06] Ah right, thanks. [15:20] quicksilver: no, it's the smart server [15:21] quicksilver: You can't do much with "just ssh" :) [15:21] bzr+ssh connects on ssh and immediately starts up a smart server on the other side to handle the connection === cypherbios is now known as cypherbios|lunch === cypherbios is now known as cypherbios|lunch [15:28] radix: You could. You use use ssh and then shell out to commands like 'cat' and 'chmod' to build/alter the repo. [15:29] radix: I have used other systems which work like that. [15:29] but fair enough if that isn't what it does :) [15:29] quicksilver: that's "ssh and cat and chmod", not "just ssh" :P [15:30] but that's enough pedantry from me :-) === cprov is now known as cprov-lunch === cypherbios|lunch is now known as cypherbios === kiko is now known as kiko-fud === Mez is now known as Mez|Away === kiko-fud is now known as kiko [17:38] When using VersionedFile.add_lines() the parents argument is the previous revision-ids in which the file was modified, rather than the parents of the current revision, is that correct? [17:38] so 3 revisions, with revids rev1, rev2, rev3, and a file a that is created in rev1 and modified in rev3. [17:39] You would add lines for rev1 with no parents, and then rev3 with rev1 as parent, with nothing for rev2, is that correct? [17:43] james_w: Correct [17:43] (It is part of setting the per file graph, and also making sure the delta is built against an existing revision) [17:43] jam-laptop: thanks. [17:44] jam-laptop: also, any suggestion for what the tree root id could be for bzr-git. I am going with hash(path) for the ids, but this means that all trees would have the same root. This doesn't seem ideal, but I'm not sure what the impact would be. [17:45] james_w: At the moment, I think all bzr trees use 'TREE_ROOT' [17:45] which is also not ideal [17:45] but it turns out that older versions of bzr didn't handle other values properly [17:45] so we had to wait for a format bump to introduce unique ids [17:45] it's unambiguous though :) [17:46] I believe Knit3 uses unique ids [17:46] yeah, it does for what I have seen [17:46] (And bzr since about 0.14 or so is able to handle it) [17:46] actually, maybe all the way back to 0.10 [17:46] and it is just 0.8 that can't [17:46] anyway [17:47] The *reason* to have unique tree roots [17:47] is so that if you merge 2 trees into 1 [17:47] then when you do further merges [17:47] it knows where to put files that show up in the root dir [17:47] I'm guessing Git doesn't have any concept of project id [17:47] etc [17:47] so I would just go with hash('') [17:47] and live with it [17:47] you *could* use TREE_ROOT [17:48] if you wanted [17:48] I'll go with the hash, thanks. [17:49] I was wanting to make it unique, as git supports submodules, and so we should map them on to nested trees at some point, and it seems non-unique would get in the way. [17:49] but they don't want to be too unique :) [17:49] well, if you made them random [17:50] then 2 people using bzr-git couldn't interoperate [17:50] we'll have to handle the nested tree case anyway for our own data [17:50] since we already have all trees with non-unique root ids [17:51] plus bzr-git is going to have issues with all the same path directories looking alike anyway [17:51] (so having 'src/' is going to collide with every other project that has a src/) [17:51] ah, of course. I'll just use that solution when you find it. [17:51] of course [17:52] if you had a way to come up with a unique tree root [17:52] you could incorporate that into all the other directories [17:52] yeah, one solution could be to have a project-id passed to bzr-git that is just introduced in to the hash. [17:52] but I can't think of a way to do it [17:52] but that would require an extra argument added to branch, checkout, init etc. [17:53] if you wanted to be minorly evil [17:53] you could double hash the first commit [17:53] (take the commit's hash, and hash it) [17:53] that would most likely be unique [17:55] if a bit odd [17:55] and might have problems after joining projects [17:55] since then you have multiple rev1 nodes [17:55] (you could sort them and just always pick the 1st one) [17:56] yeah, using the root commit as the root id did occur to me. You would get collisions occasionaly, but they would be far less. [17:56] certainly far less than using the same value for everything :) [17:59] There are going to be a massive number of fork+execs to make this work it seems. [18:09] well, that is how git is written, right? [18:11] wing-commander upstart% bzr bundle [18:11] Using saved location: bzr+ssh://keybuk@bazaar.launchpad.net/%7Ekeybuk/upstart/main/ [18:11] bzr: ERROR: exceptions.AttributeError: 'RemoteRepository' object has no attribute '_make_parents_provider' [18:11] ^ d'oh [18:13] Keybuk: IIRC that's a known bug [18:13] high on the list for 0.92 [18:25] ok === cprov-lunch is now known as cprov-out === p4tux is now known as YBAM === YBAM is now known as p4tux === p4tux is now known as help === help is now known as p4tux [20:04] spiv: I still haven't heard the status of chunked encoding: http://bundlebuggy.aaronbentley.com/request/%3C20070903172153.GC22003@steerpike.home.puzzling.org%3E [20:04] I think Martin pinged you on it the other day, but I didn't see a response [20:56] bzr merge foo.bundle : any idea for http://pastebin.ca/742241? [21:08] bzr+ssh push protocol seems to ignore ~/.ssh/config [21:08] because it doesn't try to connect on the port I set it should in ~/.ssh/config [21:09] so pushing doesn't work as server use non-standard port [21:09] can anyone confirm this? [21:09] this bug* [21:10] ryanakca, tabs/spaces mixup? [21:11] AnMaster: yes, but why should bzr crash (other than python not liking mixtures of tabs/spaces) [21:11] ryanakca, no idea [21:11] any idea about my problem? [21:30] AnMaster: https://bugs.launchpad.net/debian/+source/bzr/+bug/146715 [21:30] Launchpad bug 146715 in bzr "bzr+ssh broken for non standard ports." [High,Fix committed] [21:30] yes just found it a bit before [21:31] AnMaster: Sorry didn't take the time to read it ... I was just lurking. [21:31] no problem [21:36] ryanakca: it seems to be doing the merge using a patch [21:36] not a bundle [21:37] and it is requiring the source to be an exact match [21:37] The traceback is probably because that code path isn't used yet [21:37] I can't say I've seen it before [21:38] I could be wrong [21:38] AnMaster: known bug [21:38] It has been fixed in bzr.dev [21:38] so it will be fixed in 0.92 [21:39] ryanakca: The "crash" is probably because we would rather fail safe than continue, so we would at least give an error that the patch does not match [21:39] It probably should be a simple refusal [21:39] and not a traceback [21:42] jam-laptop: so, how to I make the requiring source an exact match? [21:42] jam-laptop: bzr revert? [21:44] moin [21:45] hi LarstiQ [21:45] lifeless: [21:45] ^^ [21:45] come to think of it, I haven't seen LarstiQ in a while [21:45] ryanakca: it sounds like your bundle was munged [21:45] and it is trying to ensure that the bundle you merge is the same as the patch you see [21:45] (so that you don't look at the preview and approve that, but the actual merge merges something else) [21:46] ryanakca: so it is *possible* that you could just edit the bundle to change the lines back to what it thinks they should be. [21:46] (if they are now spaces, try making them tabs, etc) [21:46] Aha... I see. [21:47] jam-laptop: recreating the bundle fixed it... methinks it has something to do with copy-pasting. [21:47] that would do it [21:47] if it had tabs in it [21:47] and you copy pasted it from a terminal [21:47] that would probably turn it into spaces [21:47] bzr send -o foo.patch is your friend :) [21:48] (As would be bzr send --mail-to=joe@foo.com) [21:48] :) [21:49] Or just a plain old wget (since the bzr branch is in /var/www ) :D [21:49] jam-laptop: thanks! [21:50] ryanakca: no problem [22:02] ryanakca: well, if the branch is wgettable, just 'bzr merge' :) [22:03] laters [22:04] lifeless: oh yeah, hehe :) [23:43] I can't connect to my server's svn repo using bzr-svn because it's through https with a self-signed certificate. Is there a workaround?