[00:00] fullermd: there is one particular vicious bug, which abentley suggested a great fix for [00:00] but noone has executed it [00:00] I take exception to commands doing totally different things. Special cases are bad. [00:00] fullermd: I agree with you [00:01] Especially when every other VCS has an 'update' command that goes between a WT and its Branch (or whatever equivalent that VCS has) [00:02] fullermd: well, git doesn't, hg doesn't do wt <-> branch (it does something different again), svn and cvs's updates are behaviourally identical to bzr's [00:02] (modulo the 'check out new files' aspect. [00:03] Well, git re-abuses 'checkout' for that. [00:03] And hg's update DOES update the WT to something based on the branch. [00:04] Anyway. I totally don't have the time or the energy for the whole co/bb discussion. [00:04] it changes the working copy to a revision [00:04] fullermd: ok [00:04] fullermd: I want to get to the bottom of it some day [00:04] sven_oostenbrink: Are you going to be around for a while yet? [00:04] I think we should fix the polish bugs we have first [00:05] Oh, totally. I wouldn't keep grumping about it if I didn't want to get it dealt with eventually :) [00:05] :P [00:05] I certainly agree that some of the behaviors (like that two-merge-update) are flat-out bugs, and need to be fixed irregardless of other issues. === davidstrauss_ is now known as davidstrauss [00:07] sven_oostenbrink: I have some discussions of 'mainline' I can put together and post up, but it's 18:00 and I reallyseriouslydesperately wanna go have lunch. So it'll be a while. [00:07] mwhudson: so at this point you forward your confirmation mail to plans@tripit.com and magic happens [00:08] fullermd: another thing.. since this is a DVCS.. if I want to have a backup of my work, I only need to have a copy of the .bzr directory, right? [00:09] phoenixz: Yeah. Though realize that every branch (or at least, every shared repo) is a 'backup' too. We commonly back up branches via 'push' ;) [00:09] phoenixz: See above about mainline. [00:10] phoenixz: to emphasize this fact, note that pushing to a remote branch does not create or modify the remote branch's working tree. :) [00:10] gottit, get some food, don't want you to starve to death, who else will help me out here? :) [00:11] Somebody else, who won't get into an argument with lifeless in the middle of it? 8-} [00:11] dash: yeah, I was basically talking about branches with WT that would not contain changes.. [00:11] heheh [00:17] phoenixz: BTW, you say that AboutUsingRepositories link as well, yse? [00:17] fullermd: yeah, saw it, will give it a read in a moment [01:36] jam: I might not have recompiled all of the extensions before the "merge" error. I'll see if I can reproduce it. [01:38] jam: Ehh, I'll follow up in an email. [01:44] jam: Short answer: I can't reproduce the errors. Looks like I did forget to recompile. [01:47] james_w: around? [01:48] jelmer: is there a way to push to a local (e.g. file) svn repository with bzr-svn? [01:48] is seems there's no way to separate the branch name / path from the repository URL / path [01:51] jfroy|work: WFM with file:// URLs. [01:51] WFM? [01:51] Works for me. [01:51] mmm [01:51] And it also seems to work with just a normal absolue path. [01:52] well yeah, if you want to push to another bazaar branch [01:52] I'm trying to push from bzr to a local svn repositoru [01:52] *repository [01:53] How does it complain when you try? It works fine for me. [01:54] not a branch or directory already exists [01:54] Ahh [01:54] That's from 'bzr push /path/to/repo/path/to/subpath'? [01:54] dpush fails, push works [01:54] (I was trying to use dpush) [01:55] Ahh. [01:55] Ok, that's a new one [01:55] bzr: ERROR: [Errno 24] Transaction cleanup failed [01:56] New to me also. [02:03] lifeless: i wonder if tripit is going to understand the air nz itinerary in pdf i just mailed it... [02:05] possibly :P [02:05] hm, it seems like it did, but now i can't find it online [02:06] ah, just took a while [02:06] 'magic' [02:06] so I just don't see how to use dpush [02:07] (I really don't want the metadata) [02:07] jfroy|work: file a bug :) [02:07] it won't create the branch if it doesn't exists, and when it does, its error message stating I should pass --overwrite ends in failure because it doesn't have an overwrite option! [02:08] mwhudson: indeed, it did better than for me; it thinks I stay in chch :P [02:08] I guess I should tell them somehow [02:08] which is odd vause their detailed view is right [02:10] it even coped with the hotel confirmation [02:10] lifeless: i think they might be using memcache or something a bit much [02:10] taking the "eventually consistent" to extremes [02:13] mwhudson: we have longer lag than you saw, I think [02:15] well, having more luck pushing to a svnserve-ed repository [02:23] maxb: re storing git refs in bzr nicks, I'd like to explore the idea. Storing the value exactly probably isn't the best choice but having a deterministic mapping is a great idea [02:27] igc: do you mean the object sha, or the human reflog name? [02:27] lifeless: human name [03:04] Either something odd has happened, or lp:~jameinel/bzr/2.1-static-tuple-chk-map has really helped Loggerhead's memory usage. [03:07] * igc food [03:07] * fullermd wouldn't rule out 'both', just on GP :p [03:08] so I don't understand fast-export :| [03:08] no matter what bzr branch I export, it always seems to re-import it as trunk [03:15] ahhh, 0b [03:15] *-b [03:15] magic [03:19] do I need to re-export marks (whatever those are) if I have more than 2 branches to export and import? [03:20] or do I need --export-marks only for the first export-import, and only need to use --import-marks for all subsequent export-imports? [03:39] spiv, lifeless: so i think the smart server doesn't handle unicode paths very well [03:40] mwhudson: backtraces, details, please. [03:41] lifeless: run bzr serve --allow-write somewhere [03:41] bzr push bzr://localhost/b%C3%A9 [03:42] --> http://pastebin.ubuntu.com/299462/ [03:46] on the server side, Transport.__init__ is seeing a 'base' of filtered-41598608:///b\xc3\xa9/ [03:46] yup thats wrong [03:47] sigh [03:47] i think sftp has different bugs like this :( [03:49] is there some way i can see what's going over the wire easily? [03:51] huh nosmart+bzr:// works finer [03:51] -r [03:58] tcpdump [04:00] phoenixz: http://bazaar-vcs.org/MatthewFuller/AboutMainline [04:07] the path is sent across the wire unescaped [04:10] http://pastebin.ubuntu.com/299476/ fixes things, maybe [04:10] This "pretend the screen is 65,536 columns wide" thing is causing problems. :\ [04:11] Including test failures. :D [04:12] mwhudson: hmm [04:12] (And yes I'll file bugs, once I verify that that's what's responsible.) [04:13] mwhudson: seems plausible I guess [04:13] mwhudson: in fact u1 have rolled back to paste, spawning was too much fail :) [04:13] mwhudson: I wonder about paths sent in responses, but one problem at a time... [04:13] "u1"? [04:13] Peng_: ubuntuone [04:16] lifeless: ugh [04:16] lifeless: oh well, my business with other things saved me some pain there i guess [04:18] spiv: uh yes i guess so [04:18] How should environment variables be handled in tests? If you change one, will it be automagically fixed when the test ends? [04:18] spiv: which smart verbs respond with paths? [04:19] Peng_: there is certainly some support in testcase for that [04:19] Peng_: many common ones are automatically saved and restored [04:19] "common ones"? [04:20] plugins path, email, HOME, editor etc [04:20] see bzrlib.tests [04:21] Ah. [04:23] They're fixed after every test? So it's okay to mess with them? [04:24] the set that are isolated, yes [04:24] those that aren't, you should call the isolation helper on first [04:25] ahoy my beloved bzr magicians [04:25] ahrr [04:25] i come to you in search of enlightenment. [04:25] lifeless: stay put you, i'm a happy user! [04:25] I was doing pirate [04:25] I need something akin to a hardlink in a branch [04:25] * fullermd is a couple doves short of a sixpack. [04:25] in the ahoy theme [04:25] oh righty [04:26] lifeless: ideas? [04:27] so I need a file in 2 or 3 directories, and keep 'em in sync. no risk of divergence. a straight link would do it, if bzr can grok that. [04:27] arjenAU: bzr can version symlinks [04:28] ok so I'd have a main and secondary... that would do. just not hardlinks? and I presume the symlinks break on windows or did you use the magic API to use it on NTFS? [04:28] i don't need win, just curious ;-) NTFS supports symlinks but win doesn't use 'em [04:29] we degrade on windows [04:29] there is a plugin [04:29] to do something more than we do [04:29] lifeless: no worries. ok so symlinks. ok out of the box or do I need to set anything to make this jive? [04:29] ln -s foo bar [04:29] bzr add [04:29] sounds sane as usual. ok [04:30] then, can I get conflicts on a bzr pull if I didn't have any local changes that weren't pushed? [04:30] sorry, rephrase that wont [04:30] s/wont/one/ [04:30] euh? [04:30] I don't understand the question :) [04:30] I do a bzr pull and I get conflicts, even though I have no local divergence afaik [04:31] you may have local changes [04:31] such as files that are ignored in a subdirectory [04:31] not on those files. [04:31] or uncommitted edits to a file [04:31] i've seen this a few times ove rlast week or so. using 2.0 [04:31] well jaunty ppa [04:32] it's honestly files I have not touched. [04:32] could you, for a while, do 'bzr st; bzr pull' [04:32] and when it happens file a bug with the output of those two commands - the order matters ;) [04:32] mwhudson: lots of them [04:32] lifeless: rigthy. can I nicely back out of the current state totry that again. revert? [04:32] lifeless: I don't remember it happening for files, but if you delete a directory, then you can get a conflict if there are temp files lying around [04:33] Peng_: I would like to think 'static-tuple-chk-map' helps mem, but I wouldn't have expected it to effect loggerhead [04:33] jam: yes, thats why I mentoned ignored iles in subdirs [04:33] jam: Hi. :) [04:33] arjenAU: no, because we don't have the exact state any more [04:34] lifeless: I'm currently trying to get meliae to perform 'compute_referrers' on a 500MB dump file w/ 5.6M objects. [04:34] mwhudson: list_dir obviously, but also I think various opening verbs can e.g. BzrDir.find_repositoryV3 and Branch.get_config_file and probably several others. [04:34] The problem is that a dict holding 5.6M entries is 200MB by itself... [04:34] jam: Well, Loggerhead does read data that comes through bzrlib.chk_map. [04:35] Peng_: for iter_changes? [04:35] lifeless: ehm. so to get rid of the mess, I did bzr revert then bzr clean-treeto be sure I didn't have build leftovers. then bzr pull says no rvisions to pull.... so it's just the local checkout that's the issue now, right? what command? or did I go foul somewhere [04:35] jam: No clue. I know it hits iter_ancestry, but I forget how. [04:36] arjenAU: well, thats the thing, we don't have the state that caused the conflicts [04:36] arjenAU: so we need to wait for it to happen again [04:36] arjenAU: thus my asking you to do 'bzr st; bzr pull' from here on in, to capture more detail when it happens again. [04:36] spiv: list_dir agrees on the encoding with that via a local transport fwiw [04:37] arjenAU: so if you get conflicts, 'bzr revert' should restore you to the pristine state, however, as lifeless says, determining what got you there in the first place would be useful [04:37] yes I get that, but I don't understand the situation I now have in my tree. [04:37] >>> get_transport('bzr://localhost').list_dir('.') == get_transport('/home/mwh/tmp').list_dir('.') [04:37] True [04:38] That's good. [04:38] jam: Loggerhead caches a copy of the revision graph. . . [04:38] mwhudson: yeah, I would use list_dir() as a guideline for how paths should be encoded [04:38] Peng_: revision graph comes from the indices [04:39] I thought it also cached the per-revision deltas [04:39] yeah, it does [04:39] and that could certainly come from chk_map [04:39] though not in ram very much i think [04:39] jam: if you need graph magic, look at http://openquery.com/blog latest entry, you may find useful. [04:39] mwhudson: oh, and of course the various error responses that contain paths [04:40] mwhudson: e.g FileExists [04:41] jam: FYI, I just ran "bzr selftest" on bzr.dev + 2.1-static-tuple-chk-map + statictuple-pickling, and there were no failures (related to ST, anyway) [04:42] argh [04:43] now get_transport('bzr://localhost').mkdir('b%C3%A9bbb') creates a directory with the escaped path :( [04:43] mwhudson: :( [04:46] mwhudson: so clients today are sometimes sending utf-8 bytes and sometimes sending urlutils.escape'd? [04:47] spiv: it seems that way [04:47] spiv: at a guess bzrlib.remote and bzrlib.transport.remote are different [04:47] mwhudson: is it varying by verb only? [04:48] spiv: not sure [04:48] spiv: actually [04:48] If it's just a difference between VFS verbs and not, that's not too bad [04:48] spiv: what do you mean by that question? :) [04:49] I mean, for every verb X, do clients consistently send paths a particular way? [04:49] spiv: i don't think there are cases where the same verb is called with varying levels of escaped-ness [04:49] lifeless, jam: any hints on where I should look to solve bug 441125? [04:49] Right [04:49] Launchpad bug 441125 in bzr "bzr: ERROR: exceptions.KeyError: ('makefile.am-20080508221105-rbs9wugi1qq76gcs-2', 'scott@netsplit.com-20090702173125-4nayj8jp8h4f8jnq')" [High,In progress] https://launchpad.net/bugs/441125 [04:49] spiv: right, yes, afaik [04:49] That's what I'd expect (and hope) [04:49] igc: isn't it a dupe? [04:49] If so, that's not insurmountable. [04:50] lifeless: not sure. It's well beyond my knowledge area [04:50] Especially if the split is exactly VfsRequest/everything-else [04:51] mwhudson: so bzrlib.remote calls something that seems to intentionally unquote the url before transmission [04:52] spiv: if you say so, i've become a bit lost among the various objects & methods [04:52] lifeless: so if I understand the exception, it is triggering because an inventory is referring to a file key (file_id, revision) which is *not* present in the repository [04:52] sorry igc^^ [04:53] which is certainly bad-mojo [04:53] is this a stacked branch? [04:53] jam: yes [04:53] spiv was fixing a bug like this yesterday [04:53] or so [04:53] and does reconcile fail on the base? [04:53] jam: reconcile on the trunk works ok [04:53] mwhudson: specifically RemoteBzrDir._path_for_remote_call invokes _SmartClient.remote_path_from_transport invokes the medium's remote_path_from_transport [04:53] jam: it's only on the stacked branch it fails [04:54] mwhudson: both implementions of that make a urlutil.relative_url and urlutils.unquote it. [04:54] jam: branching from there gives a branch on which reconcile works [04:54] igc: so one possibility is to probe through all of the inventories to find one that references this text key [04:54] jam: can comparing the log -v -p on the orginal branch and the created branch gives the same results [04:54] it is certainly possible that this inventory is 'unreferenced' [04:55] mwhudson: where bzrlib.transport.remote uses RemoteTransport._remote_path which appears to rely on whatever Transport._combine_paths does [04:55] (or, not in the ancestry) [04:55] spiv: ah right [04:55] _text_refs is built up by walking *all* chk pages, IIRC [04:55] not just chaining from revisions => inventories => chk_pages [04:56] spiv: so a cheap hack would be to have VfsRequest override translate_client_path to unescape again? [04:56] hold on... maybe not. Maybe only ones that are referenced via an inventory [04:56] lifeless, jam, igc: The bug lifeless is thinking of that I fixed is bug 437626, I think [04:56] Launchpad bug 437626 in bzr "exceptions.AssertionError: second push failed to complete a fetch set" [High,Fix committed] https://launchpad.net/bugs/437626 [04:56] it looks like unreferenced ones are just streamed out directly, without being parsed. [04:57] spiv: https://code.edge.launchpad.net/~mwhudson/bzr/escape-smart-server-requested-paths fwiw [04:57] lifeless, jam, igc: which didn't affect 2a repos, if that helps [04:57] spiv: thanks [04:57] however, that doesn't mean we have the *revision* for that inventory [04:57] (it does) [04:57] jam: unrefed ones shouldn't be copied though [04:57] jam: except for the adjacent ones, and those we don't want the texts for [04:58] mwhudson: I think so [04:58] jam, lifeless: so does that imply reconcile is looking at extra data it doesn't need to? [04:59] mwhudson: or not apply your escaping [04:59] mwhudson: whatever works is fine by me, though :) [04:59] igc: possibly yes [04:59] spiv: is it sane to have vfs requests have different rules than the others? [04:59] mwhudson: we'll need tests, obviously, and I should add some text about this to network-protocol.txt [05:00] igc: it is possible to have inventories in the repository that aren't referenced by the branch. it is further possible for those to be borked. [05:00] mwhudson: well, they already do AIUI? [05:00] hence why I suggested you walk all inventories and find out which one thinks it knows something about the given file_key [05:00] spiv: i guess [05:00] fixing it would require defining a whole new tranche of verbs [05:01] mwhudson: the long term plan is to remove the vfs requests anyway, so if there's cruft that's restricted to just them I'm fairly comfortable with that [05:01] for inv in b.repository.iter_inventories([k[0] for k in b.repository.inventories.keys()]): [05:01] mwhudson: and as far as cruft goes this is pretty minor, happily. [05:01] if file_key in inv: [05:01] spiv: true enough [05:01] print inv.revision_id [05:03] spiv: where are the vfs verbs tested? [05:05] just in the generic transport tests applied to RemoteTransport? [05:05] mwhudson: mainly those, yeah [05:05] mwhudson: there's also a little bit SmartServerRequestHandlerTests in test_smart_transport [05:06] mwhudson: most of the newer verbs are more rigorously tested in test_smart [05:10] spiv: i guess an appropriate test for this is to have a RemoteTransport onto a directory, mkdir('%C3%A9'), and then check list_dir via a LocalTransport matches? [05:11] spiv: can i get you to write that? :-) [05:13] jam: thanks for the code snippet. That saved me ages I'm sure ... [05:14] jam: I get 202 matches on that file-id and the rev-id is one of them [05:14] i.e. rev-id failing in the KeyError exception [05:14] jam: make that 280 matches sorry [05:14] mwhudson: I suppose so, although it's not my ideal way to spend a Friday afternoon ;) [05:15] argh [05:15] * mwhudson is all confused again :( [05:15] mwhudson: but yes, that sounds like a good test to have [05:15] mwhudson: oh, except I'd back it onto a MemoryTransport :) [05:47] spiv: https://bugs.edge.launchpad.net/bzr/+bug/458762 [05:47] Launchpad bug 458762 in bzr "smart client inconsistent about escaping of paths to the surprise of the smart server" [Undecided,New] [05:47] spiv: can i assign that to you? [05:48] mwhudson: no [05:48] mwhudson: because I just did :) [05:48] spiv: ok :) [05:48] mwhudson: thankks [05:49] spiv: np [05:49] spiv: i'm glad the problem turned out to be fairly simple in the end === AfC1 is now known as AfC [07:01] lifeless: I've written a command to upgrade Bazaar branches on Launchpad. I'm not sure it's working. Do the formats here make sense: http://pastebin.ubuntu.com/299569/ [07:05] jkakar: lp has a bug where it doesn't update the reported format [07:05] jkakar: bzr info nosmart+ [07:05] lifeless: Ah ha, I was wondering about that. [07:07] lifeless: Woot: http://pastebin.ubuntu.com/299574/ [07:07] its been upgraded :) [07:08] It's probably a good time to make the first release of AutoLP. [07:08] autolp ? [07:08] I want a place to collect Launchpad commands. I already have several scattered about. [07:08] lptools [07:08] https://code.edge.launchpad.net/lptools [07:08] and there is another one as well that the lp folk made [07:09] (that meaning rockstar/jml/abentley I think, though I'm hazy) [07:09] I didn't know about lptools, will check it out, thanks. [07:09] it has a review-notifier which is nifty [07:09] on my TODO to package it [07:09] Might want to add lptools to the lpx project group. [07:09] lpx? [07:09] surely launchpad ? [07:10] A new officially-sanctioned project group for launchpadlib-using applications. [07:10] Launchpad Extensions, similar to the tx project group for Twisted. [07:10] mmm [07:10] seems totally weird to me to not use the launchpad group [07:10] They are not part of LP. [07:11] so? [07:11] To they should not be part of LP. [07:11] s/To/So/ [07:11] you're repeatin yourself but not making a case [07:11] They are not part of LP in the real world, so why should they be part of LP on LP? [07:11] the launchpad project group isn't just launchpad.net [07:12] I like having a way to separate "Launchpad the moving parts of the service" from "The set of tools that work with Launchpad". [07:12] it needs to be shrunk if thats what its meant to be an exact match for [07:12] jkakar: I can see that [07:12] project tags FTW [07:12] Yeah. :) [07:12] Right. lpx is brand new, and things haven't been sorted out yet. [07:13] * lifeless sighs over data models [07:13] so limiting [07:13] lifeless: the reconcile problem seems to come down to parent_map(text_refs) not finding all parents [07:14] lifeless: so maybe we aren't collecting things correctly for a stacked branch? [07:14] igc: reconcile runs in unstacked mode [07:14] igc: because it has to enforce 'this repo is internally consistent' [07:14] groupcompress_repo.py, line 1289 [07:15] text_refs has 5024 items [07:15] igc: do you perhaps mean 'reconcile is not fully up to date with the setup of stacked repositories' [07:15] parent_map returns a dict with 4875 keys [07:16] I may mean that, still fumbling my way through [07:16] lifeless:^^^ [07:16] :) [07:16] I'm done for the day btw [07:16] should have been, oh, 3 hours back. But I'm bad at 8 hour days [07:16] lifeless: sorry. not great timing I know [07:17] lifeless: I'll update the bug report and look more on Monday [07:17] kk [07:18] win 32 [07:21] hi all [07:21] lifeless: win 32... 2000 ? XP ? Vista ? :-P [07:25] hi vila [07:30] wgrant: its a shame that bzr, and various things with lp support won't ever be able to be in lpx :P [07:35] privet [07:35] lifeless: This is why we need project tags. [07:35] oh! my favorite subject: project tags [07:36] * bialix looks at irclogs [07:36] wgrant: I know :) [07:36] hi vila [07:53] lifeless: I'm seeing *much* better memory usage having dropped the cache size down to 1 by default, along with the latest bzr trunk with jam's improvements [07:54] lifeless: you may want to retry a netbeans import when you get a chance [07:54] igc: I'll teach you the cache mantra eventually ;) [07:54] it helped at the time :-) [07:55] but I'm really pleased it's mostly not needed now [07:55] hows the performance? [07:55] better! [07:55] good [07:55] gc costs a lot :) [07:55] well, better or medium to large projects [07:56] on [07:56] it's slower on smaller projects but not by a big amount [07:56] igc: nice [07:57] spiv: well, turning off a cache is simple - jam and you guys did the hard yards making the core fast enough that it wasn't helpful! [07:57] spiv: but thanks :-) [08:18] * igc dinner [08:21] vila: forward your trip booking mail to plans@tripit.com, should create an itinery :) [08:21] lifeless: yup, I'm trying to sort out the email used first, but thanks for the t[r]ip :) [08:22] lifeless: next time, treat me as spiv but with a '+' instead of '-' ! [08:25] what do I need to do in order to revert some file to the state from the previous revision [08:26] vila: I wasn't sure if they were magic oryou had to configure it [08:27] loxs_wrk: bzr revert -r -2 FILE [08:27] lifeless: '+' is the "standard" magic char, spiv cheats :-P [08:28] bah, I can't find the merge accounts anymore, will just delete the othr [08:54] bug 353370 upsets babune a lot, do you I need to submit a proposal to revert revnos 4766 and 4764 or can I just go ahead ? [08:54] Launchpad bug 353370 in bzr "Lines cut off at 80 chars regardless of actual terminal size" [High,In progress] https://launchpad.net/bugs/353370 [11:13] james_w: you has bugs [11:13] lifeless: you has responses to bugs [11:13] james_w: also a merge request on -builder; would love to have a todo-to-merge for it for Monday [11:13] james_w: thanks [11:15] james_w: did you only just comment? I don't see bugmail.. [11:15] about an hour ago [11:16] for "needs -sa" I said "eh?" [11:16] bzr-builder currently builds native packages to sidestep tarball issues [11:16] so you shouldn't have an issue [11:17] for "invalid email address" I said that I couldn't see how it happened given the code [11:17] though I didn't look that closely [11:18] knowing what $DEBEMAIL $DEBFULLNAME $MAIL $NAME $EMAIL were in your environment [11:19] dch -a gets something more 'sane' (though still not great) [11:19] this uses a port of dch's algorithm, so it should give the same behaviour [11:19] I can believe that we made a mistake in porting though [11:19] I saw, it doesn't. [11:19] $ echo a $DEBEMAIL b $DEBFULLNAME c $MAIL d $NAME e $EMAIL [11:19] a b c /var/mail/bobthebuilder d e [11:19] $MAIL looks wrong to me [11:20] or not [11:21] I wonder where Javier got MAIL from, dch doesn't seem to use it [11:21] looks fine to me [11:21] its the maildir for the user [11:21] I can't imagine it ever being useful for email address detection [11:22] bzr has a pretty complete heuristic itself, built in [11:22] ok [11:22] yeah, I wanted the same as dch though [11:22] I thought that would be less surprising [11:22] so the mail thing was a distraction [11:22] using bzr stuff as a fallback before the "guess based on socket.fqdn" though [11:23] took me a bit of time to realise that it wasn't lp api's giving me grief :) [11:23] the merge proposal is more interesting to me than the bug now [as I has workaround] [11:25] its lightly tested as there doesn't seem to be any test support for lp apis [11:25] [and cody gave me a chunk of the code in one hit] [11:25] yeah, I'm reviewing that now [11:27] lifeless: if you could respond to the other bug I would appreciate it [11:27] * james_w doesn't like incomplete bugs [11:28] james_w: I thought I replied to both [11:29] ok [11:29] hanks [11:30] yeah, I did [11:30] just bugmail slowness [11:30] really, smtp==www, should be instant :) [11:48] lifeless: review done [11:49] thanks for working on this [12:02] bzr guru I have a question about bzrdir.sprout [12:03] Bug 458914 [12:03] Launchpad bug 458914 in bzr-scmproj "pget clone all revisions from shared repository instead of revisions belong to .scmproj branch" [High,Confirmed] https://launchpad.net/bugs/458914 [12:03] I have following code in scmproj to clone control branch [12:04] http://pastebin.com/d5939252d [12:04] this code using sprout [12:04] as result it does not filter out unrelated revisions when cloning branch [12:05] but get entire shared repo [12:05] what I'm doing wrong? [12:10] bialix: why don't you use branch.fetch() instead ? And why does your comment talks about creating a working tree for force_new_repo ? [12:10] I dunno, that code was written by amanica [12:10] I don't understand how sprout works [12:10] :-/ [12:11] that code invoked this way: http://pastebin.com/d41766d3d [12:12] wait [12:12] are you asking about comment after force_new_repo=True ? [12:12] vila: ^ [12:12] yes [12:13] the idea was is to create standalone branch always, regardless of presence of shared repo [12:13] bialix: especially when sprout has a _create_tree_if_local parameter... [12:13] ha [12:13] _create_tree has leading underscore, therefore it's private API [12:14] last time you was very hard that gary using private api in qbzr [12:14] meh, no underscore, sorry typo [12:14] that code was written last winter, perhaps bzrlib evolved since then [12:15] rhaa, I wasn't hard at all ! You misunderstood my intent, but nm [12:16] bialix: you may want to use the revision_id parameter too [12:16] if revision_id is not None, then the clone operation may tune [12:16] itself to download less data. [12:18] bialix: your caller certainly can get that from br_from.last_revision_info [12:22] vila: hmmm [12:22] strange [12:25] vila: so I need to change my clone fuinction? [12:26] I'd say so... [12:27] :-/ [12:28] so I need to make function as def _clone_to_local_url(br_from, revisions_id, to_url, accelerator_tree=None): [12:28] vila: ^, right? [12:29] and pass revision_id to sprout? [12:29] revision_id, no 's' , but yes, I'd try that === mrevell is now known as mrevell-lunch [12:29] bialix: do you have any evidence that this bug is recent or was it always there but unnoticed ? [12:31] my coworker just today discovered this [12:31] I think it was there always [12:32] but he has non-standard scmproj project clone [12:32] .scmproj should be standalone tree, we forcing this [12:32] but he made by hands this branch using shared repo [12:32] so it's not very critical but I'd like to fix it [12:34] * bialix trying what vila suggested [12:34] Peng: ping ! [12:34] Ping: peng [12:35] Peng: just noticed bug #458743 and bug #458741 [12:35] Launchpad bug 458743 in bzr "terminal_width fix causes progress bar hideousness when piped to "less"" [Undecided,New] https://launchpad.net/bugs/458743 [12:35] Launchpad bug 458741 in bzr "terminal_width fix causes test failures with subunit" [Undecided,New] https://launchpad.net/bugs/458741 [12:36] Peng: I've been bitten by the problem in another way and I just proposed lp:~vila/bzr/353370-notty-no-term-width [12:36] Peng: your feedback will be highly welcome [12:36] Peng: oh, and more info at bug #353370 [12:36] Launchpad bug 353370 in bzr "Lines cut off at 80 chars regardless of actual terminal size" [High,Fix committed] https://launchpad.net/bugs/353370 [12:38] vila: branch.py suggests that I can obtain rev_id tip by br_from.last_revision() call. ok? [12:38] bialix: yup [12:39] cool === weigon__ is now known as weigon [12:42] vila: many many thanks [12:42] merci [12:42] it working [12:43] bialix: \o/ [12:43] all hail vila! [12:43] :-D [12:46] * bialix mutters: that's new ajax lp made me crazy [12:48] vila: AIUI (skimming things) your patch drops the no-TTY width from 65,536 to 256. My terminal is ~130 columns wide, so it should still get spammed, just a lot less. [12:48] vila: Is that correct? [12:48] Peng: not only, it changes the way is obtained in more cases [12:48] Peng: not only, it changes the way the width is obtained in more cases [12:49] Peng: can you try it ? [12:49] err, which Peng are you ? Peng or Peng_ ? :) [12:50] Oh look, I have $COLUMNS. 183? Didn't remember it was that high. [12:50] vila: Both. [12:50] vila: ...And neither! [12:50] lol [12:51] Right, so if you set COLUMNS, it's obeyed. Period. [12:51] OK, both of my computers have $COLUMNS. If it works, I don't really care about the details. :P [12:52] vila: I'll grab a copy of your branch. [12:52] ok, I'll grab some food then :-) [12:52] * SamB_XP still wishes bzr paid attention to SIGWINCH [12:54] SamB_XP: patches welcome ! [12:54] heck, I'm not even sure I made sure there was a bug about it! [12:55] SamB_XP: see.... :-D [12:56] vila: thanks again, you my hero [12:57] That brings it to 4 branches I have merged to my bzr.dev. :D [13:00] vila: My terminal doesn't get flooded, but each time the progress bar updates, it prints a new line instead of overwriting the old one. [13:02] vila: when piped to less, anyway [13:02] vila: This is an improvement, obviously, but it's still worse than the old code. [13:04] Peng: with or without COLUMN being set ? [13:04] COLUMNS [13:06] vila: with [13:06] Peng: and is the value coherent with your terminal ? [13:06] i.e. <= [13:09] vila: Yes. [13:10] Peng: you said earlier that COLUMNS was set to 183 and your terminal ~130, right ? [13:11] anyway, try to either *not* set COLUMNS or set it to a value that is *less* than your terminal width [13:12] Peng: regarding #458741, can you tell me how to reproduce that ? [13:13] vila: I just sent an email. All I did was "bzr selftest --parallel subprocess". [13:14] vila: Well, to be exact I did "bzr selftest --parallel subprocess pending". [13:14] * Peng_ runs off to watch TV. I'll check in at ad breaks, though. [13:15] ok, I can reproduce now, that's fixed with my patch [13:15] Ohh, why is there always an ad break right when I get up? [13:15] Peng: at your next break, can you precisely tell me what width your terminal is, what COLUMNS value you use and if you still experience a problem [13:15] vila: 183, 183, and which problem? The selftest one? I'll check. [13:16] the selftest one is fixed, just checkd it [13:16] vila: Yeah, I can confirm it. [13:17] vila: Which problem do you want me to check? [13:17] You said: My terminal doesn't get flooded, but each time the progress bar updates, it prints a new line instead of overwriting the old one. [13:18] I can't reproduce that [13:18] vila: Oh. ...Show's back. [13:18] vila: Anyway, that's with latest-everything, including your branch. And 3 others, but they shouldn't break this. [13:19] ghaaa, I want a recipe to reproduce !!! :D [13:19] ha, got it, if COLUMNS >> terminal_width I can see that, but if I use COLUMNS==terminal_width it's not the case, please double check [13:21] and if COLUMNS >> terminal_width, well, it's kind of expected, if the terminal issue a linefeed, there is no way bzr can uses carriage returns to erase the current line (since it has become the previous line...) === mrevell-lunch is now known as mrevell [13:23] hmm, so, to be pedantically precise, the bug occurs if you set COLUMNS=terminal_width+2, so there probably is a off-by-one error somewhere [13:23] Peng: but it also very probably means COLUMNS is not set the way you think it is :) [13:29] Hmm. [13:30] vila: $COLUMNS is right. [13:30] vila: Also, like I said, it only happens when I pipe to less. [13:30] vila: ....Now I can't reproduce it. [13:31] Peng: haaaaa, I prefer that :-) THanks ! [13:31] vila: Sorry, I was wrong. I can reproduce it. [13:32] vila: It works fine if I do "COLUMNS=183 bzr pull -v | less -F", but fails if I just do "bzr pull -v | less -F". Even though $COLUMNS is 183 anyway. [13:32] >-/ [13:32] Sorry. :P [13:34] env | grep COLUMNS [13:34] vila:~/src/bzr/releases/2.0 :( $ echo $COLUMNS [13:34] 80 [13:34] meh.... [13:35] Peng: Can you try COLUMNS=182 [13:35] vila: "export COLUMNS=182; bzr pull -v | less -F" works. [13:35] Peng: amazing isn't it ? [13:36] so it's *another* off-by-one error somewhere else [13:36] vila: Bu I told you, 183 works. Sometimes. [13:36] But* [13:37] vila: "export COLUMNS=183; bzr pull -v | less -F" works too. Augh! [13:39] vila: Ah-ha! "echo $COLUMNS" works, but "env" doesn't list COLUMNS. [13:39] seems related to 'shopt -s checkwinsize' in my .bashrc [13:39] vila: $TERMCAP does include the columns, though. [13:40] Although I only have $TERMCAP inside of screen, but that's mostly where I run bzr anyway, so it's not a big deal. [13:43] Peng: I'm pretty sure we are chasing a different bug here... [13:45] vila: I dunno. What are we talking about? [13:46] off-by-one errors bewtween terminal width and COLUMNS [13:46] before my patch COLUMNS wasn't obeyed, so you didn't see these bugs [13:50] So, um, hmm. Since it turns out I don't actually have $COLUMNS ("echo" lies), where does that put me? [13:50] It's using the default of 156? [13:50] 256* [13:51] echo doesn't lie, try 'shopt' and search for checkwinsize [13:51] if you do echo $COLUMNS and get something, so does bzr [14:00] vila: echo really does lie. $COLUMNS is not listed in "env", or Python's os.environ. [14:00] ...I hate computers. :P [14:02] * vila kills some more chickens [14:19] lifeless: thanks! === weigon_ is now known as weigon [15:13] fullermd: Good morning! [15:13] fullermd: Just finished reading the other document you wrote [15:22] fullermd: I have to say, still not sure on how the init-repo thing works, though it seems cool.. [15:57] Trying to use Bzr against an svn repo at http://opensource.adobe.com/svn/opensource/flex/sdk: flex/sdk is the path in it, and it's from there laid out in "trunk" layout. Read-only access requires no password, and this works with svn; but bzr insists on asking for one. [15:58] I gather that this is because bzr tries to determine layout by examining the root, but I must not have read access that far up. Is there a solution to this? [15:58] dlee: specify the layout manually [15:58] I've tried messing with ~/.bazaar/subversion.conf but it didn't help. I may not have done that correctly. [15:59] and disa ble the cache [15:59] Can I use bzr co/branch or do I need bzr svn-import? [15:59] The latter has a layout parameter; the former two don't I think [16:00] you can set the layout in subversion.conf [16:01] e.g. layout = trunk0 [16:01] The 0 is new to me :) tried without. [16:02] it shouldn't be necessray [16:03] My subversion.conf is just the [uid] line, layout=trunk (with or without 0), and locations = http://opensource.adobe.com/svn/opensource [16:05] dlee: you'll also need to disable the cache [16:05] dlee: 'use-cache = False' [16:06] in subversion.conf? [16:06] yeah, in the uuid section [16:07] Hmm...still wants a user name. [16:07] tried co and svn-import, trying to check out both trunk and just flex/sdk [16:07] can you send it ia sigquit and see what code path is tryuoing to access the repo root [16:07] (apologies for my spelling today) [16:09] In the debugger, but I haven't been here before... what do you want from here? [16:10] I need to install bzr on a Mac that I don't have admin rights too. Is there some way I can do that? [16:10] cellofellow: Worst case, run from source. [16:11] dlee: 'bt' will print a backtrace [16:12] cellofellow: You've tried the installer, and it failed without admin rights? http://bazaar-vcs.org/MacOSXDownloads [16:15] Peng_: it asked for them but I didn't just click cancel and see what happened. [16:15] if I click cancel it doesn't continue to the install [16:17] source it is I guess [16:17] Trying to sift out what matters... should I be suspicious at seeing "self._cached_revnum = self.transport.get_latest_revnum()"? [16:17] or just don't use it, I can commit from my laptop. [16:20] Looks like it happens when bzr tries to get the latest revnum. Iirc, pasting large text chunks isn't appreciated in here, or I could paste some of the backtrace. [16:24] dlee: Use a pastebin. [16:27] is there a way to do a backwards merge? [16:27] use case: [16:28] shared trunk with disconnected workflow [16:28] if there is a collision in pushing to the trunk then I get told the branches have diverged [16:28] if I merge trunk then it changes the left hand history of trunk [16:29] rebase? [16:29] the "correct" way to do it is to get another copy of trunk, update it, and then merge in [16:29] but that's a faf [16:29] if I could do "bzr merge", but just put the revision parents the other way around then I could do it in one directory couldn't I? [16:30] Tak: there's no need to rebase, and in fact I don't want to [16:31] Peng_ / Jelmer: I made a pastebin - never done that before either. [16:32] dlee: What's the URL? [16:33] http://pastebin.com/m4e19701d [16:35] dlee: looks like we try to open the repository root at the moment when we try to figure out the last revision number [16:35] dlee: that's not really necessary, please file a bug [16:36] sorry, gtg - breakfast [16:36] np and thanks [16:41] I have varios SVN repositories containing various implementations of one and the same inhouse developed framework. Simplified, I have repo A with the framework itself, as trunk, branches and tags, from there copied (using SVK), in repo B project B1, B2 and B3, and I have repo C with projects C1 and C2... When making updates to the framework while working in repo C, project 1, I merge those changes back to the framework in Repo A. When I have updates to the [16:41] framework in repo A, I merge those changes to all projects in repos B and C.. I want to change from SVN / SVK to BZR. How can I import all these works from SVN / SVK to BRZ, keeping all the histories but also keeping the abilities to merge in between the various projects? [16:45] I know, SVN cannot copy cross-repository, but SVK can. Which is one of the reasons why I used SVK in the first place. Now, SVK is pretty much a dead project, and I want to jump ship, BZR seems like the perfect choice for me, but I would not want to loose the ability to merge in between projects.. [16:47] phoenixz: hi [16:47] jelmer: hi [16:48] phoenixz: yes, if I understand your situation correctl bzr-svn should be able to handle that [16:48] phoenixz: please note that you shouldn't be using the 'bzr dpush' command when attempting something like this [16:49] jelmer: I don't even know what dpush is or does, yet.. :) [16:49] phoenixz: in that case, don't worry about it :-) [16:49] phoenixz: dpush is the bzr-svn equivalent of "push but don't set svk:merge" [16:49] jelmer: haven't found dpush in bzr help commands.. [16:50] jelmer: a question here.. [16:50] so in subversion, I have varios projects [16:51] each project has a trunk, development branches and tags [16:51] pretty common way to work in SVN [16:51] I use this framework within different companies [16:51] for each company I have multiple projects that use that framework [16:52] for each company I have one SVN repository that contains the projects [16:52] like, /svn/companya/projecta/ (where companya is an SVN repo) [16:52] How do I set this up in BZR? [16:53] Because AFAIK, BZR has each branch being its own thing [16:53] there is a shared repo directory [16:53] where I can keep those branches together [16:53] so I figure, for each company, I would make a shared repository [16:54] and in there I would place directories for each project [16:54] and in those project directories, I would place the branches for each project [16:54] jelmer: does this make sense in BZR? or did I get it totally wrong? [16:55] Jelmer: Re: getting svn latest revno querying at repo root unnecessarily: Bug #459187 filed. [16:55] Launchpad bug 459187 in bzr "Unnecessary request for userID/password on bzr co/branch/svn-import from svn repo" [Undecided,New] https://launchpad.net/bugs/459187 [16:56] Can bzr import from CVS? [16:58] nm, found bzr-cvsps-import [17:01] dlee: Thanks [17:01] Meths: you may also want to check out cvs2svn's fastexport option [17:01] phoenixz: yeah, that should work [17:02] phoenixz: I would recommend sticking to the standard layout for svn inside of those branch container directories [17:02] phoenixz: because bzr-svn will automatically regonize what is a branch in that case [17:03] jelmer: another question.. Does BZR know if different branches are related? I suppose it does, but if I make a branch of a branch of a branch, etc etc.. will the last branch still know its related to the first one [17:03] ? [17:03] I know, noob questions.. :) [17:03] Meths: or use 'cvs2bzr' from the 'cvs2svn' suite. Which will create a 'fast-import' stream, that you can import using 'bzr fast-import'. [17:04] phoenixz: yes, it will know if different branches are related [17:04] jelmer: is it also possible to branch a sub directories? like, I have a project A with sub directory lib.. I want a branch of only lib, is that possible too? [17:06] phoenixz: partial checkouts are possible but the related history with the partent branch will not be recognized [17:10] jelmer: jam: thanks. How does bzr fast-import work? bzr help fast-import isn't implemented [17:10] Meths: you need the bzr-fastimport plugin [17:11] ah [17:11] phoenixz: I'm out for the day. If you have more questions, please mail the list and cc me [17:11] morning jam ! [17:11] jelmer: thanks lots for the help so far! [17:12] jam: I could spend a better week-end if I could land https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/13832 [17:12] hey vila [17:12] I'm technically on vacation again today [17:12] though I found a way to shrink mem by another ~50MB or so, so I can't stay away :) [17:12] jam: ach, sorry again, but hey you're here again :) [17:13] I'm not sure about trusting COLUMNS when isatty() is false [17:13] jelmer: btw, I figured out what the issue was with bzr-svn/subvertpy/md-bzr [17:13] jam: well, the more I dig, the more I see COLUMN being set even when you don't touch it :-) [17:13] certainly under 'less' you probably don't want to truncate [17:13] even though Peng does [17:13] Just try it in a terminal... [17:13] vila: I'm pretty sure the terminal likes to set COLUMN / COLUMNS or whatever [17:14] as a hint [17:14] bash too [17:14] vila: well bash has to get it from the terminal, rigth? [17:14] I wasn't invoking PyEval_InitThreads [17:14] or perhaps it uses SIGWINCH, or TIO or whatever [17:14] I dunno, surely they talk to each other, but that makes it even more reliable [17:15] vila: right, and my point is if I do "bzr XXX > file" [17:15] should it be paying attention to that? [17:15] also note that for our purposes [17:15] sys.stderr.isatty is probably more relevant [17:15] I don't think we ever truncate stdout [17:15] vila: can you verify that last statement? [17:15] let's not open more cans than necessary.... [17:16] log --line is one know truncate case [17:16] (stdout being valuable information that the command is generating, versus 'progress' etc information that can be truncated on a whim) [17:16] vila: so my direct preference is "revert the 'bugfix" [17:16] my second preference is "just set it to 256" [17:17] my third is 'lets have a discussion and actually get this right" [17:17] setting to 256 when using a tty is bad, I know that for sure [17:17] ok, so I'll revert the offending revnos and wait more feeedback on the patch [17:18] jam & vila: <3 [17:18] vila: but isatty() is False [17:18] Or am I missing something [17:18] jam: ECONTEXT [17:19] (11:16:57 AM) vila: setting to 256 when using a tty is bad, I know that for sure [17:19] You are setting it to 256 when "isatty()" is returning false [17:19] yes [17:20] hence "using a tty" but the system is telling us you aren't [17:20] I was replying to: [17:20] vila: I'm saying "set it to 256 when isatty() is False" [17:20] I should have typed it all out, I guess [17:20] ha ok, yes, that's what the patch does [17:20] I was trying to say "change 65536 => 256" [17:20] vila: and a bunch of other stuff [17:21] My point is there is a one line 65536 => 256 change [17:21] that seems to cover what you really need [17:21] haaaa, I started with that, but them I realized there was other problems and that wasn't enough [17:21] s/them/then/ [17:22] so, it's either, revert or fix them all [17:22] well, for some values of all... [17:23] vila: which is my point about (3) [17:23] if we are going to spend significant time on it, lets do it the right way [17:23] (and i feel stuff like checking sys.stderr is part of that, possibly handling SIGWINCH, possibly a few things) [17:24] jam: ok, I thought I did that but by all means, let's discuss it widely :) [17:24] $COLUMNS concerns me, because doing something like: [17:24] wow, wow, wow :) [17:24] bzr log --line > file [17:24] seems like it shouldn't truncate [17:24] should bzr log --line | less? [17:24] should we truncate a progress bar, but not log --line [17:24] ? [17:25] yeah, the truth is I started thinking COLUMNS wasn't set behind my back but *always* by the user, I'm less sure about that now [17:26] vila: well if you resize your window [17:26] COLUMNS is usually updated to match [17:27] it just isn't updated 'on-the-fly' while the program is running [17:27] hence SIGWINCH [17:27] I thought you had to use termios, not COLUMNS for that... It appears I was wrong (still not completely sure, try:) [17:28] try: env| grep COLUMNS [17:28] then echo $COLUMNS [17:28] then under python look at os.environ['COLUMNS'] === beuno is now known as beuno-lunch [17:32] vila: I'm currently on Windows, which has fairly fixed column width for cmd.exe [17:32] I can try it, I suppose [17:33] echo "$COLUMNS" is empty for me [17:34] Ach, windows, yeah, I have some pending questions there too... as pointed in some bugs bzr behaves differently wrt redirections on windows and linux... [17:35] vila: well, there you have to also worry about '\r\n' and setmode(binary) etc. [17:37] jam: on OSX: http://paste.ubuntu.com/299876/ [17:37] vila: pretty [17:37] I like how it ends in a frown [17:38] hehe [17:38] on jaunty: http://paste.ubuntu.com/299877/ [17:38] hmm. same result [17:38] yup [17:40] on FreeBSD: http://paste.ubuntu.com/299879/ [17:40] some result too, except when set by the user, COLUMNS is not seen by python... [17:40] I suppose *bash* knows about COLUMNS in some kind of way [17:51] Oh, good, my weird results aren't unique. [17:56] vila: go start enjoying your weekend [17:56] :) [17:57] jam: yeah, revert sent to pqm, I'll poke babune later :) [17:57] jam: thanks, enjoy yours too when you decide it :) === beuno-lunch is now known as beuno [18:43] jelmer: ping-a-pong === cellofellow is now known as undefined === undefined is now known as Guest33850 === Guest33850 is now known as cellofellow [19:18] if I set a command's outf to something other than stdout, will the file be closed automagically when the command is gced or no? [19:23] hmm, it looks like "no" === thunderstruck is now known as gnomefreak [19:55] fullermd: ping === asac_ is now known as asac [20:31] hi [20:31] kmos@kmos:~/packages/apport$ bzr push lp:apport [20:31] bzr: ERROR: Cannot lock LockDir(lp-46086288:///~apport-hackers/apport/trunk/.bzr/branchlock): Transport operation not possible: readonly transport [20:31] If I cerate an all-features branch with trunk + each feature branch, and commit fixes due to logical conflicts and tag them as CONFLICT_N, and merge each feature branch into trunk, and merge all-features into trunk, will only the new commits CONFLICT_N be merged from all-features into trunk? [20:31] break-lock doesn't work [20:32] * If I create an all-features branch with trunk + each feature branch, and commit fixes due to logical conflicts and tag them as CONFLICT_N, and merge each feature branch into trunk, and then merge all-features into trunk, then will only these new commits CONFLICT_N be merged from all-features into trunk? [20:32] RenatoSilva: don't repeat yourself [20:33] Kmos: Strictly speaking, I didn't ;) === dorins_ is now known as wave [21:10] hmm, if I have something in ~/.bazaar/plugins that I have a different version installed systemwide, will my local plugin override, or will there be a conflict? [21:20] local wins [21:27] thanks === MTeck-ricer is now known as MTecknology [22:18] hi lifeless [22:18] hi [22:18] thanks for making the changes [22:19] I haven't reviewed the incremental diff, but I don't foresee any problems [22:19] I just replied before seeing the mail that you had made them [22:20] ok [22:20] so I made the bits *I* consider a must given the things the review discussion uncovered [22:20] I haven't change print to mutter, or other such things [22:20] as I said, I'm happy to take over if you are willing to block on me [22:21] Well, I'm running from a homedir install now [22:21] not going to block regardless [22:21] but as you are asking me to maintain the code I am wary of merging it with things that I can see being problematic [22:21] so, I don't think there are things remaining that are problematic, just differnet [22:21] with the sole exception of the oauth file [22:22] and I think that all of that should be in launchpadlib *anyway* [22:22] its fugly the way the setup stuff is cargo culted around [22:22] I pointed to the API for that === wave is now known as testlongnick [22:22] did you take a look at whether it matched? [22:23] no, its saturday ;P [22:23] and I don't understand enough to know if it matches or not. [22:23] fair enough [22:23] the whole launchpadlib thing is rather opaque to me [22:23] the pydoc is epic epic epic fail [22:24] and the total inability to work and test with it offline (Without a multi-hundred mb separate download & apache locally) is a real disincentive to learn more [22:24] so there is also a bit of passive resistance to learning more:P [22:25] pydoc launchpadlib.launchpad [22:25] /login_with [22:25] if you are interested [22:25] heh [22:25] so this is actual code and documented ;) [22:27] so, login_with looks fine, but given that I know nothing about the failure modes, internals, required facilities, expected conventions... [22:27] the only issue with it is that it puts the cache in "launchpadlib_dir" [22:27] my approval doesn't mean much [22:28] and currently the cache is broken with multiple processes [22:28] Oh, I really hate the cache [22:28] it shouldn't need one. [22:28] because? [22:28] Damn silly idea, HTTP caches are extremely hard to get right. [22:29] build the API by introspecting the wsdl and compiling python from it; then ship the resulting static API, which is fully documented and faster [22:29] I say HTTP caches are hard to get right after years as squid-core :), its an informed opinion. [22:32] also, if you need an HTTP cache for a web services API to work, the API design is broken and will perform problematically [because of cache seeding overhead at a minimum] [22:33] bug 459418 filed as due dilligence [22:33] what else, oh, require write access means you can't use launchpadlib as a very restricted user, or [for instance] to grab backup data during system restore when nothing is mounted writable [22:33] Launchpad bug 459418 in launchpadlib "Cache is broken with multiple processes" [Undecided,New] https://launchpad.net/bugs/459418 [22:34] s/require/requiring/ [22:34] I can now go back to moaning about how login_with is broken with a clear conscience [22:34] :) [22:35] anyhow, I shall make some time to merge your code at some point [22:35] thanks again [22:35] that would be excellent [22:37] I'd lke to be running a packaged bzr-builder [22:38] the less string the easier to get OSA's to run the service ;) [22:51] http://trac.webkit.org/changeset/50000 [22:51] uuuuarg oops [22:51] * jfroy|work hides in shame [22:51] defeated by too many tabs, once agao [22:51] *again. I apologize. [22:59] jelmer: ok I have the weirdest problem with bzr-svn [23:00] well, it seems to me that way. I have a completely clean repository with no bzr: props or revprops and no svn:mergeinfo or svk:merge props. [23:00] jfroy|work: are you psychic? I just returned back to my computer after being away for half a day and you ask within a couple of seconds :-) [23:01] and a straight bzr branch of the trunk branch in that repo yields a bazaar branch with a number of sha1 mismatch errors [23:01] lol :p [23:01] no, I'm pretty sure I'm not :p [23:02] basically, we're migrating a project from a repo with a bunch of projects in it to a brand new repo dedicated to only one project [23:04] so I 1) branched using bzr the trunk and the current active branches from the old svn repo 2) pushed trunk (with the push merged revision option enabled) to a simulation blank svn repo 3) dumped that 4) ran a filter on the dump to strip every revprop and prop starting with bzr: (as well as svn:mergeinfo and svk:merge) 5) loaded that filtered dump into a new repo and 6) branched the trunk from that repo [23:04] did you change the UUID or throw away the cache? [23:04] that should yield a clean bzr branch, shouldn't it? [23:04] pretty sure I did [23:05] ~/.bazaar/svn-cache/ and ~/.bazaar/subversion.conf [23:05] And I get a "Initialising Subversion metadata cache" message when branching [23:06] I'm guessing the only thing left that could trip bzr-svn are copy nodes it's trying to interpret [23:06] I don't think there's anything that can be done about those [23:07] can you reproduce the problem on a small repo? [23:08] I have no idea how to reproduce this [23:09] oi, wait a second... [23:10] these are the sha1 mismatches [23:10] http://paste.ubuntu.com/300096/ [23:10] can you pastebin the backtrace? [23:10] no backtrace [23:11] this is output by bzr check [23:11] All of those files are symbolic links [23:11] I think this is the problem [23:11] ah, that might make sense [23:11] That should be a relatively trivial bzr-svn bug [23:11] those 4 files are all empty with Property svn:special set to * [23:12] and the content set to "link Versions/Current/ATF" [23:12] we're just filling in a different sha1 in the inventory as we put in the versionedfiles [23:12] s/ATF/foo [23:12] jfroy|work: can you file a bug? [23:12] jfroy|work: :-) [23:12] let me try to repro with a simple repo [23:13] jfroy|work: I have some long flights coming up, might give me something to do :-) [23:13] That would be incredibly awesome :) [23:17] yup [23:17] reproduced with a one commit repo [23:22] jelmer: https://bugs.launchpad.net/bzr-svn/+bug/459440 [23:22] Launchpad bug 459440 in bzr-svn "bzr-svn sha1 mismatches on symbolic link files" [Undecided,New] [23:23] jfroy|work: awesome, thanks [23:26] jelmer: oh, I've found another minor issue [23:27] if you create a brand new repo and push a branch to /trunk, you won't get any tags (but branches will show up if you have push merged revisions) [23:27] jfroy|work: please file a bug for that one as well [23:27] jfroy|work: and thanks :-) [23:27] if, however, you create a revision 1 with svn that creates the standard layout, then push --overwrite, then you'll get tags [23:28] I'm guessing it doesn't detect that the repo is using the standard layout [23:28] probably needs a "repo is at revision 0, I should make the standard layout first" special case [23:29] I suspect it's because we have a different code for "create this branch" vs "push revisions to this existing branch" [23:33] https://bugs.launchpad.net/bzr-svn/+bug/459444 [23:33] Launchpad bug 459444 in bzr-svn "Pushing to a blank repository does not push tags" [Undecided,New]