of the page reveals the real name of the directory. [23:03] <beuno> Peng_, ah, right, that isn't even the same theme. I should pay more attention :p [23:04] <Verterok> awilkins: hook into gc? __del__ method maybe? [23:05] <beuno> thumper, maybe we can just add that with some explanation on how to feed LH that info? [23:07] <Verterok> __lucio__: hi :) [23:07] <__lucio__> hi Verterok , hi all :) [23:07] <awilkins> Verterok: I was wondering if hooking that in the bit of the test case object that removes folders would be better. [23:07] <beuno> __lucio__, hi! you're working in Canonical now? [23:08] <__lucio__> beuno: yep. just started. [23:08] <beuno> __lucio__, welcome :) [23:08] <__lucio__> danke :) [23:08] <Verterok> __lucio__: wow! [23:10] <Verterok> awilkins: I don't known the tests magic enough :( [23:10] <pickscrape> One of my colleagues today noticed that loggerhead's new skin doesn't have an option to view the diff as unified like the old one did [23:11] <beuno> pickscrape, yeap, that's been filed as a bug [23:11] <pickscrape> beuno: excellent, I'll let him know :) [23:12] <lifeless> SteveA: __lucio__: python bug [23:12] <lifeless> tarfile.open(None, "w|gz", sys.stdout) -> boom, on your machine afaict [23:15] <pickscrape> Hmm, does anything recently committed to loggerhead require bzr 1.6? [23:15] <lifeless> pickscrape: I believe so [23:15] <beuno> pickscrape, yes, viewing changes to a file [23:15] <pickscrape> Ah [23:15] <beuno> that should be fixed this week [23:16] <pickscrape> Actually it's the directory view that's breaking for me right now [23:16] <pickscrape> ReservedId: Reserved revision-id {null:} [23:16] <beuno> pickscrape, oh, that's new [23:16] <beuno> pickscrape, can you pastebin the traceback? [23:17] <pickscrape> It's only when viewing the root... [23:17] <pickscrape> !paste [23:17] <ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) [23:19] <pickscrape> beuno: http://paste.ubuntu.com/34205/ [23:20] <pickscrape> As I say, it only happens in the root directory. subdirectories of it (that are also just directories) aren't affected. [23:21] <beuno> pickscrape, what version of bzr are you running? [23:23] <pickscrape> 1.5 [23:24] <pickscrape> I've been tempted to put 1.6 on the server for a while now, but it's a pretty critical system :) [23:24] <beuno> pickscrape, can you file that as a bug? [23:24] <pickscrape> Certainly. [23:25] <beuno> pickscrape, thanks :) [23:25] <lifeless> james_w: 3117 follow up posted [23:26] <james_w> did you see my followup question? [23:27] <lifeless> ah just arrived [23:27] <lifeless> no its not an api break [23:27] <lifeless> if it was a required parameter it would be an api break [23:28] <lifeless> this isn't C++ we don't have linkage determined by function signature :) [23:28] <Verterok> lifeless, __lucio__: about Bug #254791, it's fixed in Python 2.5.2 :) [23:28] <ubottu> Launchpad bug 254791 in bzr "export to tar broken on mac os x" [Undecided,New] https://launchpad.net/bugs/254791 [23:28] <pickscrape> beuno: bug 254794 [23:28] <ubottu> Launchpad bug 254794 in loggerhead "root directory view traceback" [Undecided,New] https://launchpad.net/bugs/254794 [23:28] <__lucio__> Verterok: what was it? [23:29] <pickscrape> Looking at it now that doesn't seem like such a good bug title :) [23:29] <beuno> pickscrape, rockin', thanks [23:29] <james_w> lifeless: but if I implement .commit() then you force me to update for this change. I'm not sure it's something we care about, and I may be using "API break" wrongly. [23:30] <Verterok> __lucio__: as lifeless commented, a python bug [23:30] * Peng_ waves. Comments on my trivial patch? Want me to send it to the list? [23:30] <beuno> Peng_, URL again? I'll look n' merge [23:31] <Peng_> beuno: Branch is at http://bzr.mattnordhoff.com/bzr/loggerhead/dirlisting-revno-link [23:31] <Peng_> You can see it in LH at http://bzr.mattnordhoff.com/loggerhead/loggerhead/dirlisting-revno-link/revision/192 :) [23:32] <lifeless> james_w: what do you mean then :) [23:33] <beuno> Peng_, cool, thanks, I'll merge [23:33] <Peng_> beuno: Thanks. :) [23:33] <pickscrape> beuno: upgrading to bzr 1.6 doesn't fix it [23:33] <james_w> lifeless: I mean forcing plugins to make a change at the same time as the core. [23:33] <beuno> pickscrape, ah, then we have a different problem. Is the branch you are running the problem in public? [23:34] <pickscrape> I'm afraid not [23:34] <pickscrape> It isn't a branch either: the root is just a directory [23:34] <lifeless> james_w: ok, I see. Yes, plugins that implement MutableTree.commit() need to change [23:34] <james_w> lifeless: it's the other way round to usual. I think that not having commit() called commit() would be a bit off though [23:34] <thumper> Peng_: I like the icons on the listing [23:34] <Peng_> thumper: It's the new theme in the trunk. :) [23:35] <james_w> lifeless: I have no idea if anything does, bzr-svn may I guess. [23:35] <lifeless> few plugins add implementations of commit though - I only know of git/svn/hg [23:35] <lifeless> and then, its only for 'bzr commit' while sitting in a native svn etc tree [23:35] <james_w> yeah, I don't know what the policy is here, but I wanted to flag it so that at the least I could find that policy out [23:35] <lifeless> note that adding a new method would also still force the plugin to change: the UI code would be calling the new method [23:36] <james_w> there's prior art for adding a "hasattr" I believe [23:36] <lifeless> james_w: yes, but not in this case: [23:36] <james_w> in the log code I think [23:36] <lifeless> a) it was fugly inlog [23:37] <lifeless> b) MutableTree would have commit_2(), so all subclasses of it would as well [23:37] <lifeless> so it would always be tree [23:37] <james_w> true [23:37] <lifeless> also [23:37] <lifeless> nvm [23:37] <james_w> that's fine, you just might want to give a certain ninja plugin developer a heads up. [23:37] <beuno> pickscrape, and that is LH trunk? on what revno? [23:37] <lifeless> jelmer: tree.commit has a new parameter, kthxcode [23:38] <james_w> done :-) [23:38] <lifeless> actually, I'll document this [23:38] <pickscrape> beuno: 191. Did I not put that in the bug report? [23:39] <beuno> pickscrape, you did, sorry. This is a shared repo it's running on? [23:39] <pickscrape> Not at the root level [23:39] <pickscrape> The root is a plain directory that contains a number of shared repositories [23:39] <pickscrape> In each of these are both branches and other plain direcotries [23:40] <beuno> ok, I see now, it's my fault. I'm not filtering NULL revisions [23:40] <jelmer> lifeless, thanks for letting me know :-) Already in bzr.dev ? [23:40] <jelmer> lifeless, Good thing I hadn't put 0.4.11 out yet... [23:41] <lifeless> jelmer: may not hit 1.6; about to go to bzr.dev if james is giving me +1 [23:44] <beuno> does this look familiar to anyone? http://paste.ubuntu.com/34208/ [23:44] <beuno> I just updated bzr.dev [23:45] <beuno> (to work around bug #249256) [23:45] <ubottu> Launchpad bug 249256 in bzr "'property' object has no attribute 'initialize' " [High,Fix released] https://launchpad.net/bugs/249256 [23:45] <lifeless> james_w: so - +1? [23:46] <spiv> beuno: it doesn't look familiar to me... [23:46] <james_w> lifeless: sorry, I'm busy with other stuff, I can review if you like, but I don't have a vote, so it wouldn't count for anything [23:46] <beuno> spiv, so file a bug? [23:46] <james_w> lifeless: everything looked pretty sounds first time around though [23:47] <spiv> beuno: yeah, I think so [23:47] <beuno> Peng_, is your server doing aything special I should be aware of? [23:47] <Peng_> beuno: bzr+http is on. [23:47] <lifeless> spiv: can I ask for an insta review? james_w has reviewed my 3117 branch - latest mail should have just hit the list [23:48] <Peng_> beuno: Also, it's Lighttpd, not Apache. [23:48] <lifeless> spiv: but it needs someone with voting to say he was right :P [23:48] <spiv> lifeless: Ok [23:48] <beuno> Peng_, bzr version you're running? [23:49] <Peng_> beuno: Uhh, hold on. [23:49] <Peng_> beuno: bzr.dev. [23:49] <beuno> Peng_, renvo? (sorry to be such a pain) [23:50] <mwhudson> is something like 'merge' for looms implemented yet? [23:50] <Peng_> beuno: Latest. [23:50] <lifeless> mwhudson: TODO [23:50] * jml sads [23:50] <Peng_> beuno: 3602 [23:50] <mwhudson> lifeless: as i suspected [23:51] <beuno> Peng_, cool, you are now part of bug #254797 then :) [23:51] <ubottu> Launchpad bug 254797 in bzr "traceback when branching from bzr+http" [Undecided,New] https://launchpad.net/bugs/254797 [23:51] <beuno> Peng_, meanwhile, can you send me a bundle for you're patch? [23:51] <Peng_> I should just turn off bzr+http. Launchpad hates it, and now plain bzr does too? [23:52] <beuno> Peng_, please don't, or it will never get fixed :) [23:53] <Peng_> beuno: http://bzr.mattnordhoff.com/bzr/loggerhead/dirlisting-revno-link/dirlisting-revno-link.patch [23:53] <Peng_> So, this time, I didn't manage to break Loggerhead, just bzr? :) [23:53] <beuno> Peng_, yes, we're finally starting to win! [23:54] <Peng_> Heh. [23:58] <beuno> lifeless, I'm hitting this again: http://paste.ubuntu.com/34209/ [23:59] <beuno> we already danced around this for this same branch a few months ago, but I don't remember what came out of it [23:59] <lifeless> beuno: ah yes we haven't tracked that down yet [23:59] <beuno> lifeless, want to give it another shot, or should I just push --overwrite?

[00:00] op not permitted is interesting [00:00] Necoro: perhaps an umask? [00:00] could be the foo.bar.baz file naming [00:00] if its not mounted vfat it can't do that [00:01] OTOH repository > 8 anyhow so that can't be it [00:01] lifeless: its vfat [00:01] lifeless: afaik fat doesn't like chmodding to something it can't represent, and raises EPERM. [00:01] LarstiQ: interesting [00:02] whats the backtrace show? [00:02] but I really need to sleep, ciao [00:02] (from ~/.bzr.log) [00:02] LarstiQ: ciao and thanks [00:03] lifeless: http://rafb.net/p/BCAK0b42.html [00:03] lifeless: and using the print-debugging-style I saw, that it's an os.chmod that's raising the error [00:04] ok [00:05] we shouldn't be chmodding usually anyhow [00:05] I thought you had to turn on a config option to set that [00:05] chmodding is slow [00:05] in fact - [00:05] note this line: [00:05] control_files.put_utf8(file, content) [00:06] the control files have been initialised with none-None file mods [00:06] can you try just 'bzr init' on the usb drive? [00:06] and definitely file bus [00:06] *bugs* [00:07] lifeless: bzr init doesn't work either [00:15] lifeless: bug #254514 [00:15] Launchpad bug 254514 in bzr "Can't create branch/repo on vfat" [Undecided,New] https://launchpad.net/bugs/254514 [00:23] ok - time to go to bed ... =) - ciao [00:44] jelmer: is it possible to put a commit hook into a bzr repo with svn parent to push up to svn on commit to bzr? [00:45] meteoroid, just use a bound branch [00:45] a bound branch, eh? [00:45] meteoroid: e.g. a bzr branch bound to a svn branch [00:45] meteoroid, see the docs for details [00:45] sure [00:45] but basically, just run "bzr bind " to do that [00:46] any alternatives for svn:externals ? i think i'm just going to write a script to dl that format of repo urls [00:46] not at this point [00:47] can bzr set svn props? [00:47] bzr nested trees haven't landed yet but even when they will, it won't be possible to map svn:externals to them [00:47] okay [00:48] perhaps bzr-svn can generate a boilerplate config-manager file or something [00:48] hm.. [00:48] jelmer: hi! While I think of it and see a related thread on the bzr list - you recall that failing windows test with an incorrect path sep? Any thoughts on how to proceed on that? Is it likely to be a problem in practice? [00:49] lifeless, Does that sound sensible ? What are the plans for cm? [00:50] markh, it's not likely to be an issue [00:50] cool [00:50] markh, if I understand the test output correctly it's something that should be fixed in bzrlib [00:50] yeah, but I was wondering how to present that :) [00:50] ie, if you had an idea of *what*, so I would attempt a patch [00:51] I haven't dug at all - looking for an easy answer ;) [00:51] TestCaseInTempDir has a test_dir attribute with inconsistent (different os.path.sep) contents [00:51] CM really needs fixing to not use pybaz. [00:51] 'evening poolie [00:51] hello jelmer [00:52] Else it's likely to be removed from Debian along with bazaar and friends. [00:53] poolie: I'm looking at doing bzr-svn and bzr-gtk releases in the next couple of days [00:54] poolie, Are there going to be any more API breakages before 1.6 or is it just polishing things for release at this point? [00:54] jelmer: well I'd like to delete cm [00:54] jelmer: but that means bzr being able to map into foreign systems pervasively etc [00:55] lifeless: In favor of what? [00:55] jelmer: why won't a bzr tree be able to refer to a svn url for the source of a nested tree? [00:55] jelmer: nested trees everywhere [00:55] nested trees require a specific revision in the nested tree to be referenced [00:55] yes ... [00:56] svn:externals allows current head to be referenced, whatever that is at the time the user does the checkout [00:56] nested trees permit that too; its UI not core [00:56] thats just 'bzr update' after checkout [00:57] well, it's not there atm :-) [00:58] lifeless: there's also no way to represent that in the current inventory entry class for nested trees [01:01] jelmer: in that update is desired? true [01:03] lifeless: what is cm? [01:03] config-manager [01:05] jelmer: externals allow referencing revisions as well [01:05] but typically we use a tag [01:05] meteoroid: yes, jelmer is saying that nested trees are a subset of the externals interface [01:05] oh ok, allows, sure [01:06] * meteoroid goes back to trying to get bzr webdav and smart server working in apache [01:06] i thought so [01:06] i thought that was an answer re api breakage that's all [01:06] jelmer, i think it should be just bug fixes from now on [01:06] the only one i know of so far is that upgrade does not work on a stacked branch [01:13] lifeless: i'm planning to fix that by making open_unsupported (or similar) take an option to open the branch without fallback repositories [01:15] perhaps open_unsopported should be renamed to open_for_upgrade [01:15] -> doctor [01:15] open_backdoor [01:20] mornin' everyone [01:32] poolie: thanks! I'll start working on getting those release out then [01:35] mwhudson, howdy. I've been playing with the browsing template a bit. Have you had a chance to look at it? [01:36] hey beuno [01:36] evening jelmer === edcrypt1 is now known as edcrypt [02:32] beuno: ah, not really [02:45] beuno: so i did some more stuff and merged your branch [02:45] beuno: see https://code.edge.launchpad.net/~mwhudson/loggerhead/themed-directory-listing === abentley1 is now known as abentley === abentley1 is now known as abentley === abentley1 is now known as abentley === timchen119 is now known as nasloc__ [03:29] What's the argument to bzr diff to show just the changes for one commit in the current repo? Sorry, I'm trying to figure it out from help revisionspec and not getting very far [03:30] marnanel: easiest is bzr diff -c -1 [03:30] or any revisionspec in place of the -1 [03:31] poolie: wonderful, thanks [04:35] mwhudson, looking [04:40] mwhudson, cool! you made it even nicer :) [04:40] one FIXME to go, and it should be mergeable, no? [04:46] poolie: don't forget to ring me ;) [04:51] beuno: probably [04:52] ok, so you're not as enthusiastic :p [04:52] it's still sunday for me, so I'm still in a good mood :) [04:53] I'll work on whatever is left to polish tomorrow [05:03] beuno: just busy, really [05:03] beuno: a different icon for branches vs folders would be nice [05:04] mwhudson, sure, what would that icon be? [05:05] beuno: no idea :) [05:05] mwhudson, folder + bzr icon? [05:05] beuno: yeah, something like that [05:06] would be great [05:26] * meteoroid wonder if there are any recommended ui for bzr, x11 or otherwise [05:48] meteoroid, apt-get install bzr-gtk [05:49] that's all i need? rawk! [05:49] i saw 'olive' or something on rhel5 but it was a curses newsreader on ubuntu ;d [05:50] olive is the main front end [05:50] um [05:50] i thought it was included [05:51] meteoroid, you should get an olive-gtk command when installing that package [05:51] and i thought it was in the menu [05:54] ok [08:57] lifeless, spiv, would one of you (if still online) read my patch for #252428 [08:57] it's pretty tiny [09:01] where is it ? [09:03] also, your _ is showing [09:03] poolie_: ^ === poolie_ is now known as poolie [09:03] on the list [09:03] http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ce01316480808040016h4deae0daxa9e4a981983d7206%40mail.gmail.com%3E [09:04] i'm getting probably spurious failures of other upgrade scenarios [09:05] actually i just sent an update to the list [09:08] poolie: trivial question, why didn't you add the tests to per_repository_reference [09:10] because they're not going to be 1:1 with repository formats [09:10] eg i want to try upgrades from knits [09:10] right [09:11] see bzrlib/tests/repository_implementations/test_repository.py [09:11] test_upgrade_from_format4 [09:11] etc [09:12] hm [09:12] you mean i could do one dimension of parameterization by scenarios and the other by having multiple methods? [09:12] parameterisation will stack [09:12] if you have a load_tests in e.g. per_repository_reference/test_upgrade.py [09:13] Hmm, bzr-buildpackage doesn't seem to be doing signing for me ATM. [09:13] then the __init__ parameteriser will get pre-parameterised tests and parmeterise them further [09:13] interfaces FTW [09:14] interesting [09:14] i did not realise load_tests would join up like that [09:14] maybe because it's not documented ;-) [09:17] well [09:17] everything that gets tests triggers load_tests [09:18] I'm writing up a review for you [09:18] lifeless, so how does test_upgrade_from_format4 relate to multiple load_tests? [09:18] Hi there! [09:18] I've got a question regarding bzr-svn and Mac OS X. What's the recommended way to get it working? [09:18] Which version of bzr, bzr-svn, subversion, etc.? [09:18] it looks like it's not using that approach? [09:19] matid, um, the latest of each would probably be a good idea :-) [09:19] poolie: no, its from before load_tests :) - I'm just noting that you can avoid code duplication if you want :> [09:20] poolie: It's not that easy though :) I failed to get it to work with many combinations of bzr 1.5, 1.63b, svn 1.4, 1.5 and 1.6 and different branches of bzr-svn :) [09:20] matid, :-/ [09:22] lifeless, i suppose the other thing i was thinking about here (aside from just not knowing/realising they would stack) [09:22] is that i didn't necessarily want to test all n**2 combinations, just to pick some interesting ones [09:24] poolie: well, your comment in the test suggested that you wanted to have it test all formats for whatever you selected [09:24] poolie: concretely, I think we should test every 'stackable repository type' for whatever scenarios are interesting [09:24] probably [09:25] poolie: so its not n**2, its still N(stackable)*[interesting] [09:27] your updated comment is more correct [09:27] and i agree moving it would be better [09:27] i have a feeling this test actually wants to be two tests though [09:27] on a mostly unrelated matter [09:27] that is, if there is no model change, you do not need to upgrade [09:28] hm, well, maybe just the if block is enough [09:28] upgrade is already tested in that respect. [09:28] that if block is purely UI glue [09:29] (and if it is a checkout, the user needs to go over to the branch and try 'upgrade' there anyhoo) [09:30] in which respect? [09:32] if there is no model change -> no upgrade [09:32] upgrades only changes stuff when there are things to do [09:32] btw what would you think of systematizing the pattern i use here of making the injected parameters be scenario_* [09:33] lifeless, well, going from knits to packs is a substantial change but not a model change [09:35] so you're saying that in the test parameterisation you don't want same-model formats for these specific tests? [09:35] could just skip the test if the model is the same - just return early [09:35] i want to test this: the stacked-on repostiory is upgraded in a way that does not change its model; the stacked branch should still work (without needing to be upgraded) [09:36] ah right [09:36] yes [09:36] thats a good test to have too [09:37] so the annoying thing about putting this into per_repository_reference [09:37] although i agree it's good to cover all formats automatically and to have same-things-together [09:38] is choosing the right corresponding formats [09:38] hm [09:39] should be the same list you had before :P [09:40] a knit and a pack of model plain [09:45] hm [09:46] are you sure stacking load_tests actually works? [09:46] it doesn't seem to for me [09:46] i'm kind of tired of this, i think i'll leave it til tomorrow [09:47] ok [09:47] I'll peek at that for you tomorrow [09:47] could be a bug [09:47] sleep well [09:47] it is 10 hours since i started [09:47] and probly more for you [09:48] :> 11 [09:48] slept in to 7:30 [09:49] poolie: I fixed quite an old bug today [09:49] i saw [09:49] a four digit bug number! [09:49] many extra points :) [09:49] :) [09:50] maybe that should factor into lp karma? [09:50] well [09:50] have a good night [09:50] gnight, you too === doko_ is now known as doko === wgrant_ is now known as wgrant [12:17] Is there a conference on or something? It's deathly quiet in here. [12:22] I don't think so [12:31] bzr is so bug free and feature complete that it no longer needs irc [12:33] * awilkins watches tumbleweed blow past [12:33] Either that or somebody broke bzr-irc. [12:40] here's a question, if i'm making small local branches just for work and then want to put them right onto trunk (which may have diverged) ... is it ok to "push" them onto trunk even if i've already pushed them somewhere else? (and obviously after i've merged trunk changes into my branch) [12:49] rocky: ok in what sense? [12:49] rocky: it works, but it may not be the workflow you want? [12:50] well ... if i'm making small changes in my local branch, i don't want to *merge* them onto the main trunk because they show up as one lump commit ... i want my commit history maintained so they show up as several small commits on the trunk [12:51] rocky: your commit history is retained anyway [12:51] when i do a merge to trunk and commit ... and look back through history, it shows up as one commit (perhaps this is specific to bzr-svn ?) [12:52] rocky: aha. bzr-svn can not push the actual merged revisions to svn, so if you pull from svn with bzr you will get ghosts for the merged revisions. [12:52] rocky: those revisions are still referenced though. [12:52] rocky: but in your case, you might want to use rebase. [12:53] rebase seems scary ;) [12:53] that's because it is ;) [12:53] sorry, i'm still learning bzr ;) [12:53] not necessarily [12:54] (I mean you might not want to use it) [12:54] rocky: you can also merge trunk and then push the result of that. [12:54] "obviously after i've merged trunk changes into my branch" [12:54] after this, a simple push to trunk is fine [12:54] but you will get some empty looking merge revisions in your trunk [12:54] hmm [12:54] that is probably fine [12:54] but if i were working with pure bzr (no svn) then the workflow would be to just use merges right? not merge/push ? [12:55] hm, wait [12:55] it will probably not do what you want, especially not with bzr-svn [12:57] if you push such a branch with merged trunk to trunk, the revision numbers in trunk will change [12:57] so doing it the other way around, merging the branches to trunk, is better === fdv is now known as fdv_ [14:04] jelmer: Hi. You there? [14:28] Hmm, "bzr switch" does not behave as I expect [14:29] I have a heavyweight checkout, and "bzr switch bar" does not try to switch to /../bar, it tries /../bar [14:30] yeah [14:30] Is this intentional? [14:31] yeah [14:31] though I don't know if it's desirable [14:31] It doesn't seem to corresepond to what the help says [14:31] lthough the help is vague [14:31] that was added to ease the lives of people who use switch to give one working tree for lots of branches [14:31] maybe you should raise your use case and see if it could be incorporated [14:32] I don't use switch, so I'm not the best to add [14:32] I think maybe it should try the sibling of the bound branch also [14:32] s/add/ask [14:32] * fullermd blinks. [14:32] That sounds like just the case he's asking for... [14:33] it depends whether all of the branches are local or remote I guess [14:33] fullermd: I have the branch bound to a repo elsewhere, I want it to switch to repo/branches/bar not workfolder/bar [14:33] if everything is in one directory then the current behaviour is what you want, if the branches are remote then it isn't [14:33] Sounds more like another one of those irritating heavy-vs-light behavioral differences :| [14:34] It is [14:34] awilkins: perhaps the change could be made without breaking the case it was added for because of that [14:34] I believe light would behave as I expected it to [14:34] I think checking the sibling of the bound branch after the direct sibling of the branch would provide the feature I want [14:35] I think checking the sibling of the checkout at all is a bug; implementation leakage. [14:35] Well, I'd think the same but I'm being cautious :-) [14:36] I mean, I wouldn't keep a working tree huddled up in a folder fuill of branches myself [14:36] I gave my cautious a vacation this week ;) [14:36] The repo is on a USB thumb or I'd go lightweight [14:37] I want the backup in case I lose it, and the ability to commit when it's not connected on occasion [14:37] Does the bazaar test suite have any coverage reporting capability? [14:38] Intuitively, I'd say that might be difficult for Python.. [14:38] But intuition is an idiot sometimes [14:38] there is a module to allow it, but it will slow things down a lot [14:38] pickscrape: I don't think so, but I may remember something about a hack or something to do it [14:39] "coverage.py"... [14:39] :-) [14:39] http://martinpitt.wordpress.com/2008/04/08/python-code-coverage/ [14:40] yeah, but I seem to remember someone hooking coverage.py in to the test runner [14:40] Hi again! Did anyone recenly got bzr-svn to work on Mac OS X? [14:40] Thanks for the pointers. :) I'm writing tests for diffstat, and wondered how I was doing [14:40] I'm on latest bzr.dev and bzr-svn/trunk and it throws "bzr: ERROR: The branch svn+ssh://***/trunk has no revision None." on bzr branch. [14:46] Any pointers on how to determine if a BzrDir is a heavy checkout? [14:47] if its got a bound branch [14:47] Would get_bound_location always return a value for a checkout? [14:47] (I mean even checkouts that are just the local checkout for a standalone branch) [14:48] no [14:48] lightweight checkouts have no local branch object [14:48] hey lifeless, did you see the links I pasted? [14:48] note that you have have a lightweight checkout of a bound branch to a master branch [14:48] yes [14:54] Ok, that seems to fix it :-) [14:57] james_w: yes I did [14:57] bleh [15:45] * awilkins posts a fix for annoying "switch" behaviour to list [15:48] a bzr branch contains a html file that is generated from rst markup [15:49] I modify the rst markup and regenerate the html file [15:49] the problem is that the original version of this html file has windows-style newlines [15:50] I'm on Linux, so bzr diff on this file produces a huge diff (due to unix-style newlines in the new html file that was just generated) [15:50] unix2dos? [15:50] this must be a typical issue, is there any documented workaround? [15:51] evanton: there is a feature that will be in an upcoming version that may help you with this [15:51] in the meantime unix2dos or similar may be your best bet [15:51] evanton: bzr doesn't currently translate newlines, but it's in progress. You can use a program like unix2dos to convert the file back to CRLF newlines. [15:51] wait [15:51] D'oh. [15:51] aha [15:51] so now my only option is to manually convert files? [15:52] I'm afraid so [15:52] though it may be possible to write yourself a hook to correct it when it happens [15:52] My preferences in order would probably be i) Don't version generated content, version sources and optionally the tools 2) fix the tool that generates the file to use the line endings of your choice 3) hasten the development of the line endings stuff by contributing 4) wait for the line endings stuff passively [15:53] how do I know which files are binary so I could skip them? [15:54] evanton: The usual heuristics are to use the filename (e.g. .png files are probably binary), or to check for the presence of NUL bytes. [15:54] in your case I assume you know the names of the files that will be affected [15:55] can you have ghosts and still resolve them (ie. if they are present on the parent branch)? [15:56] james_w: that's correct, but in general cases when I have a lot of modified files, I'd rather run unix2dos against every file of the branch (except binaries) [15:56] mathrick: what do you mean by resolve? [15:56] evanton: why not include that in your makefile rules? [15:57] james_w: get info / contents of when needed [15:57] you would have to fetch the ghosts first [15:57] it's a pity that the output of "bzr status" is the same for text and binary files [15:57] hmm, lemme write up what I have in mind [15:58] unless you knew what were ghosts and could ask the other branch for the information [15:58] does bzr do binary patching on modified binary files or just replaces them? [15:58] or just catch RevisionNotPresent and try the other branch [15:58] evanton: you mean in it's internal storage format? [15:59] let's say I have a parent repo p, with revisions p1 .. pn. Now I want to make a branch b, which has b1 .. bn present, but all of p1..pn are ghosts in it [15:59] james_w: yes [15:59] would that work if I wanted to merge it with a parent / another branch b2? [16:00] evanton: yeah, it stores deltas at least some of the time [16:00] ok, thanks [16:00] mathrick: that's a stacked branch, if pn is a parent of b1 [16:02] What's the recommended procedure for submitting "tweaks" to the list [16:02] james_w: oh, and what exactly does that mean? [16:02] Do you just say "ok then" and let the merging developer do it? [16:02] I think the current delta format is line-based, though.. [16:03] awilkins: the original submitter will do it [16:03] james_w: That be me then :-) [16:03] awilkins: if it's a trivial tweak then the approver will normally not vote tweak and just do it [16:04] hello [16:04] the difference between resubmit and tweak is partly a difference in expectation of the time it will take, and partly an indication of the approval for the approach taken. [16:04] FAir enough [16:04] i'm looking for a good bug tracker that hopefully supports bzr, does anyone know of one? [16:05] i don't want it to be open source, like launchpad, though [16:05] you don't want it to be open source? [16:06] and what do you mean by "supports" bzr? [16:06] i mean, i don't want it mandate my code being open source [16:06] DO you mean you want an instance that supports non-open projects, or that you don't want to use any OSS software even on a provate server? [16:06] and by "supports" i mean have integration with bzr [16:06] Trac has some integration [16:06] i'd like to use OSS if possible, but i would like it to support non-OSS projects [16:07] Stavros: if you're willing to do a bit of hacking then lighthouse would work [16:07] Pilky: what's it written in? [16:07] rails, it's a hosted solution [16:07] When is Launchpad being Opened anyway? [16:07] aha [16:07] thanks, i'll look into it [16:08] but you'd need to write a post commit hook to talk to their API [16:08] Redmine supports bzr, but I dunno how much VCSes are integrated with the bug tracker. [16:08] james_w: is there any RTFM around about stacked branches? [16:08] they have one written in ruby for svn which would make a good starting point, I was going to write one myself but I haven't had time to learn python yet [16:08] mathrick: there's a bit of documentation that I think made it to bzr.dev [16:08] Yes, it did. [16:09] * mathrick updates [16:09] Pilky: it shouldn't be very hard, knowing bzr [16:09] is that a new feature? [16:09] mathrick: it will be in 1.6 [16:09] k [16:10] Stavros: well, doing something knowing bzr is different to doing something knowing python. I've got a few scripts and I'm writing a GUI for bzr, don't know a huge amount of python ;) [16:10] Pilky: that's true, i meant for me :p [16:10] Pilky: http://www.poromenos.org/tutorials/python [16:11] yeah, I've not found a true python tutorial online yet [16:11] Pilky: how do you mean true? [16:11] well all the ones I've seen have been like that [16:11] Pilky: do you know any other languages? [16:11] basically listing the data types, control blocks etc [16:12] Objective-C, C, Java, PHP, Haskell, bit of VB6 (unfortunately) [16:12] I prefer learning while building something [16:12] hmm, you shouldn't need a very detailed tutorial then [16:12] but try "dive into python", it's pretty good [16:13] tried that, it's same as everything else [16:13] hmm [16:13] each chapter seems to be "here's a big chunk of code, now lets analyse it" [16:13] ah [16:13] I find I learn better if there are real tutorials, projects that you work through that show you why a language is cool [16:13] mathrick: if you have b1 ... bn but not p1 ... pn, you should still be able to merge. [16:14] Pilky: hmm, i don't know any like that, sadly [16:14] LarstiQ: cool [16:14] by the way, is redmine any good? [16:14] Stavros: a friend of mine uses it, haven't heard a complaint so far. But that is all I know. [16:14] ah, thanks [16:15] I wanted that for an idea of how to implement good rebase --interactive [16:15] Stavros: yeah, I found it surprising that there weren't any tutorials like that online for Python, especially given how popular it seems to be [16:15] Pilky: i don't know any tutorials like that for any language, i don't think [16:17] they are far and few between unfortunately [16:18] I'm kinda spoiled by the book I used to learn Cocoa [16:18] Pilky: http://www.pythonchallenge.com/ [16:18] Pilky: focus is a bit lopsides towards http and images, but it's fun anyway. [16:19] hmm, that's a bit closer to what I'm looking for, but doesn't explain about python as you do it [16:20]