[00:00] I'd say [00:00] I've never heard of a style to not use query args [00:00] ?action=annotate [00:00] would be a reasonable use of query args [00:00] nice [00:01] so http://127.0.0.1:8080/bzr.repo/bzr.dev/tools/biobench.py?action=annotate [00:01] without that get the raw bytes of the file [00:01] or alternatively [00:01] so http://127.0.0.1:8080/bzr.repo/bzr.dev/tools/biobench.py?action=raw [00:01] and without that get the pretty view [00:02] what pretty view? [00:02] annotated text is the pretty view :) [00:02] :) [00:02] lifeless, spiv, jam, call in 2m [00:02] I think allowing space in the URL's for revision and stuff is good [00:03] as mentioned previously the only problem is: there are special files eg: [00:03] so http://127.0.0.1:8080/bzr.repo/bzr.dev/head:/tools/biobench.py?action=raw [00:03] is better IMO [00:03] http://127.0.0.1:8080/bzr.repo/bzr.dev/files [00:03] an alternative is [00:03] http://127.0.0.1:8080/bzr.repo/bzr.dev;rev=head:/tools/biobench.py?action=raw [00:03] so we might need to change http://127.0.0.1:8080/bzr.repo/bzr.dev/files -> http://127.0.0.1:8080/bzr.repo/bzr.dev?files [00:03] when is the new bzrtools going to be packaged in the bzr ppa? [00:04] bbs [00:04] right now I'm holding off installing the 1.7rc as it wants to remove bzrtools [00:04] and I use bzrtools all the time, and don't want it removed [00:04] nor do I want to use a non-packaged bzrtools [00:04] in my use case http://127.0.0.1:8080/bzr.repo/bzr.dev;rev=head:/tools/biobench.py?action=raw is not really an option (I dont know where to split the path) [00:06] amanica: well, default would be to show the head revision presumably [00:06] yup [00:06] amanica: so far i've been restraining myself a little from suggesting you fix gforge instead/as well :) [00:06] and I'd have to add another param for rev=123 [00:06] I am busy fixing it :) [00:07] I can do a bzr revno on every folder in my path to determine if it is the branch [00:07] * beuno -> home + dinner [00:07] but that didnt work for me [00:08] I have been using `bzr branches` to get a list of branches [00:08] bzr root [00:08] will tell you where the root is [00:08] whcih I can compare to the full path to see if I can determine which one is in use [00:08] ah [00:09] But I thouth if loggerhead is cleaver enough in any case I dont need to mess with that [00:09] lifeless: no, just that shell scripting makes a bit more sense than a python plugin, for hooks. [00:09] amanica: in any case it's by now pretty easily to write wsgi stuff to do url traversal however you like [00:09] amanica: unfortunately the links that get generated will be all wrong :/ [00:10] if you care to tackle _that_ problem you will definitely be my friend [00:10] which _that_ problem? [00:11] amanica: the link-generation problem [00:11] is this wsgi stuff in loggerhead [00:11] or do you mean write a site wrapper? [00:11] loggerhead is all wsgi these days [00:13] ok, Ive not seen this link generation problem [00:14] so now that I can determine the branch root, I would be able to split up the url. [00:14] amanica: well it's the standard thing of making sure that the way you generate urls and the way you interpret them line up [00:14] hey does bzr support something similar to git's submodules? [00:14] or bitkeepers ability to reference other repos? [00:15] amanica: loggerhead is flexible enough to allow the way you interpret urls to be changed easily [00:15] amanica: but the way they are generated is very hard coded and horrible [00:15] oh ok [00:16] ??? [00:16] I didn't really intend to change the url generation, but mainly just to support alternate urls [00:18] mwhudson: I would still need a way to do this for a specific revno [00:18] manunderground: Like svn:external? Something like that has been In Progress for ages. [00:18] peng_ dunno if it's the same but I imagine it is, not familiar with svn:external [00:18] it is simply the abillity to have one repo reference another as another working item [00:18] manunderground: people here may not be familiar with git submodules :) [00:19] here's the use case, you have a suite of apps, you want each app to have its own repository [00:19] you want the suite to have a repository, too, maybe it has an installer or something [00:19] so the suite references the app's repos [00:19] (which in turn reference feature repos? AHHH) [00:19] mwhudson: BTW I'm not really a gforge guy, but my company is going to use it, and I HAVE TO USE BZR OR I'LL DIE. so I'm writng a plugin.... [00:22] mwhudson: so I still like/need something like http://127.0.0.1:8080/bzr.repo/bzr.dev/tools/biobench.py?revno=123 [00:22] so, it doesn't exist but it's planned and not exactly forthcoming? [00:23] amanica: right, it can probably be added easily enough [00:24] I'm ok with that, but I'd prefer to work on something that will have a chance to get merged in the future, than going off into my own little fork [00:25] manunderground: I was just reading something today about different directory structures you can use for repositories with Bazaar. [00:25] thats why I'm trying to get an idea of what others want. and surprisingly its not what I thought [00:25] A couple of them were essentially ways where you have a shared repository for a collection of projects and then separate projects within that repository. [00:26] But I can't find the page again, so I'm not sure how closely it resembles the organization pattern you describe. [00:26] Kilroo: hm, hard to say, but it'd be cool if you found that again [00:27] I think this is actually a very important feature [00:27] manunderground: there are kind of two answer to this, there is "nested trees" which i woudn't hold your breath for, and there is "config-manager" which collects branches into one tree on disk [00:28] mwhudson: so can you explain "collects branches into one tree" means [00:28] manunderground: And in bzr terms, you mean 'branches', not 'repos'. [00:28] oh ok [00:28] haha [00:28] thanks [00:28] but then I assume that the branch is the entire tree? [00:29] (meaning, you can trace out the entire tree from the branch) [00:29] Well, branches are what you work with. You never work with 'repos'. [00:29] alright, let me try to clarify thigns here. when I say repo I mean a tree [00:29] with the root [00:30] and a branch is not the full tree, right? [00:30] the tree is a collection of branches [00:30] and I'd like to have, say, 3 independent trees [00:30] then a fourth one which references the other three [00:30] (and ideally doesn't have to put import all their files or history) [00:31] so it's a reference that I'm looking for, I think :-) [00:31] As I understand you, you'd have 3 branches, and then a fourth branch with not much in it, but references to those other 3. [00:32] (assuming that nested trees were up and running) [00:32] alright, that sounds like what I want, so that is supported? [00:33] No. [00:33] Now, there's nothing stopping you from arranging the 3 branches however you want on your system. But the bits that allow automating treating them as a single entity from the outside aren't there. [00:34] oh ok, so you would have then if I understand you there's no way to track the history of references in your project? You could put some placeholder dirs or readmes, etc, but not actually reference the other projects repo's [00:35] haha, minus the "so you would have then" bit... [00:46] poolie: woot. [00:47] jml, ? [00:47] poolie: saw the call minutes :) [00:47] * looking at failure jml is seeing on stacked [00:48] was there any other news on it from your side? [00:54] poolie: I've filed bugs with easy steps to reproduce the symptoms, that's about it. === mw is now known as mw|out [01:28] can lightweight checkouts be pushed to LP? [01:28] LaserJock: only branches. [01:28] hmm, interesting [01:29] so the only good way of sharing changes to a lightweight checkout is to send patches? [01:29] I'm a little confused. [01:30] sorry [01:30] by 'changes to a lightweight checkout', do you mean 'local edits without commits'? [01:30] it's ok, I'm just having a slow day :) [01:30] no [01:30] I mean, I want to get a branch from LP, make some commits, and then get it back to the author [01:31] I was wondering if a lightweight checkout would work for that or not [01:31] can I make local commits on a lightweight checkout even? [01:31] I don't think so. [01:31] well, you can if it's a lightweight checkout of a branch you have write access to [01:32] oh [01:32] but they aren't local [01:32] * jml should really try today again. [01:32] I don't think I have write access either [01:33] LaserJock: I think you'll need to make a real, honest-to-goodness branch. [01:34] soon, you'll be able to branch --stacked [01:34] mwhudson: that'll give me partial history? [01:34] basically yes [01:34] although I imagine that for heavy hacking you'll still probably want a shared repo model — not sure. [01:35] LaserJock: if youwant to commits you need write access; a stacked branch will work, or a normal branch [01:36] lifeless: right, I was wondering if I could do a lightweight checkout and then push it to my bzr space [01:36] makes sense though that that wouldn't exactly work [01:39] ok, another question. when I'm branching I get a notice that the branch format is old [01:39] complain to the branch owner [01:39] ok [01:39] (they should upgrade it) [01:39] I wondered if I should upgrade it or if they should [01:40] unless you have write access, you can't [01:40] but I'm not sure if it's just because I'm using newer bzr or not [01:40] if you do, then you can [with some tricks if its on launchpad] [01:40] is there a table of formats vs bzr version? [01:41] core formats have versions in them, that indicate the introducing version [01:41] formats that don't have a version in them are either very old (0.8 or so) [01:41] so this ones says: RepositoryFormatKnit1 [01:41] or plugin formats that you need a specific plugin for [01:42] there should be a line at the top [01:42] someting like 'knits' - anyhow, thats a very old format [01:42] bzr 0.8 and above read and write it, but its slow. [01:42] yeah, this branch is taking *forever* [01:42] I'll perhaps mention it to mvo tomorrow [01:43] if you upgrade a branch how does it know what to upgrade to? does it just go to the latest default? [01:44] with the exception of bzr-svn branches, it goes to the current default, which we are conservative about changing [01:44] the current default works with bzr 0.92 and above [01:44] ah, ok good [01:45] with bzr-svn branches it will error, as you need to manually specify what to upgrade to [01:45] I was wondering if it's easy to get a situation where a person upgrading via bzr.dev ends up doing bad things for other users [01:46] LaserJock: if we were silly, it would be :P [01:46] well ... :-) [01:47] jeeze, this thing is using like 2 KB/s [01:47] "slow" :P [01:49] I guess I could start like 10 branches at the same time :-) [01:58] Well, using bzr.dev caused bug 261339, frex :p [01:58] Launchpad bug 261339 in bzr "Upgrade from knit to pack fails on revision not present" [Critical,Fix released] https://launchpad.net/bugs/261339 [01:58] (well, maybe not precisely caused, but caused to exhibit anyway) [02:03] hmm, has the idea of combining init-repo with branch come up? [02:05] LaserJock: kind of. [02:05] LaserJock: rockstar and I have talked about a plugin that does the init-repo when fetching a branch for the first time. [02:06] yeah, something like that [02:06] I always forget [02:07] LaserJock: it's slightly complicated by the fact that some people like to keep their local branches separate from their working trees. [02:08] so like you would have ~/branches/* and then ~/working ? [02:13] LaserJock: something like that. [02:15] LaserJock: to do that manually, you'd go 'bzr init-repo --no-trees ~/branches; cd ~/branches; bzr branch ; cd ~/trees; bzr co --lightweight ~/branches/' [02:15] maybe there's an easier way. [02:15] * jml shrugs [02:15] I mix trees and branches with merry abandon. [02:16] oh woah, that's interesting [02:17] thumper, abentley and others use that layout [02:17] and can help you more if you're interested [02:17] jml: why do init-repo in ~/branches ? [02:18] instead of just doing individual branches [02:18] LaserJock: it creates a repository (that is, a bucket for revisions) that can be shared between branches. [02:19] LaserJock: this saves space and also makes certain operations faster [02:19] so I guess if you had branches with similar history it'd help [02:19] in particular, making new branches and fetching branches from remote hosts [02:19] LaserJock: right. [02:19] And, by "certain operations" jml means "branching". And by "faster", he means "like a hojilion times faster". [02:20] LaserJock: so actually, you _wouldn't_ do "init-repo ~/branches" [02:20] you'd probably do "init-repo ~/repos/" [02:20] and then "init-repo ~/repos/" [02:24] I was reading about a science professor who was using bzr repos for papers [02:24] jml, LaserJock it just so happens that I'm polishing that plugin right now. [02:24] so if he had a new paper or presentation he'd bzr branch [02:24] seemed like a really cool idea === kiko is now known as kiko-zzz [02:26] I know at least one PhD student who uses Bazaar for their thesis. [02:26] maybe two. [02:26] that's what I'm doing right now ... [02:27] it's nice to know what revision I gave my advisor to read [02:28] the idea of a presentations bzr repo is interesting, since often they are a fairly linear progression [02:30] Hom do I get a branch's format in bzrlib Branch? [02:30] s/Hom/How [02:30] rockstar: from a branch object? [02:30] b._format.get_branch_format() i think [02:30] well [02:30] LaserJock: I habitually make branches for any slides I'm working on [02:31] assuming a certain modernity. [02:31] there isn't actually a consistent way across all formats, I don't think. [02:32] *gasp* An API where I have to access the a property starting with _ [02:32] LaserJock: I don't think I've ever looked at the old revisions, but just knowing that I *can* lets me relax and delete unused ideas and whatever from my slides rather than leaving them floating around until the last moment in case I decide I might want to use them after all. [02:32] spiv: yeah, exactly [02:33] jml, the use case is this: I have my plugin, and I'm getting repository/branch format conflicts [02:34] rockstar: that's not a use case :) [02:34] rockstar: what are you doing to get these conflicts? [02:34] I wish I could go back in time 6 years and input everything into bzr :-) [02:34] jml, let me finish! [02:34] * jml does so [02:34] LaserJock: putting Bazaar back in time six years would solve a lot of my problems. [02:36] So, I get conflicts when I create a repository with the default format, and then try to put a branch in the repo that doesn't have a compatible format. [02:36] So I needed to open the branch to check the format BEFORE I create the repo. [02:39] rockstar: so, you need to open the url as a BzrDir and then check the repo format [02:39] I guess. [02:39] jml, yes. However, mwhudson's response seems to be incorrect. [02:39] rockstar: i think you can look at the cloning metadir for that [02:41] mwhudson, Would this help? http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.branch.BranchFormat.html#find_format [02:49] ok, really focussing on 270738 now [02:50] poolie: the patch you posted conflicts with spiv's remote error fixes (bug #2613515) [02:50] Error: Launchpad bug 2613515 could not be found [02:50] 261315 [02:50] bug #261315 [02:50] Launchpad bug 261315 in bzr "getting a stacked branch over the smart protocol fails with "Could not install revisions"" [Critical,In progress] https://launchpad.net/bugs/261315 [02:50] bug #270738 [02:50] Launchpad bug 270738 in bzr "AttributeError when branching stacked branches" [Critical,New] https://launchpad.net/bugs/270738 [02:50] jml mentioned it, I just confirmed it [02:50] jam, i intentionally did mine off an old branch to ease integration into 1.7 [02:50] sure [02:50] i guess i should merge it into 1.7? or just into trunk? [02:51] just that the 1.7 branch *has* spiv's changes [02:51] or rather, merge them into me [02:51] poolie: right, just 1.7 [02:52] poolie: the change to "get_stacked_on_url" seems like it should be a per_branch test [02:53] jam, do you mean that you can still get it even if the repo can't accommodate it? [02:53] Okay, so it looks like the branch is a RemoteBranch object. Is there a way to get the format of the RemoteBranch? [02:53] hm, maybe [02:53] poolie: right, just that it changes the API of the function [02:53] to always return the config value [02:53] rockstar: remotebranch._real_branch.format unfortunately [02:53] if you want the on-disk format [02:53] Personally, I prefer it to return None rather than raise an exception, but that is a long-ago discussion that got missed [02:54] poolie, _real_branch is apparently None [02:54] call ._ensure_real then [02:54] jam, i know [02:54] i wonder if it would be better to just change it anyhow though [02:55] like, will there really be that many external callers of it? [02:56] poolie: why do you have the "self._remote_path()" instead of "self.bzrdir._path_for_remote_call()" ? [02:56] I think it is *better* I just don't see why it was important for this patch [02:58] i just didn't want to copy & paste it again [02:58] um [02:58] i feel a tension between doing focussed patches and cleaning things as i go [02:59] sure [02:59] I was mostly just trying to understand the patch and where I needed to focus [02:59] I'm fine with the cleanup [02:59] though generally for a rc hotfix I would avoid them [03:01] true [03:02] is there a possibility of a branching from LP just stalling? [03:03] I'm going on 1.5 hrs now and I'm not sure if there's any progress [03:03] LaserJock: strace the process [03:04] LaserJock: is it a big project? [03:05] I didn't think so [03:05] gnome-app-install [03:05] 600 or so revisions [03:05] but the actual size shouldn't be bad [03:05] its more file-count that breaks knits [03:05] ok, strace says it's still doing stuff [03:05] When using relative directories for workingtree.add() and workingtree.smart_add(), what is it supposed to be relative to? [03:06] abadger1999: add is relative to tree root [03:06] My test is showing it's relative to the cwd, but the documentation says it should be relative to the wt root. [03:06] smart_add is a little broken, its relative to pwd [03:06] Ah... maybe add is giving me a different error then. [03:07] lifeless: To make smart_add work as expected, do I need to os.chdir() to the tree root and then back after the call? [03:07] lifeless: 227 files for 2.7MB is the source tree [03:08] relpath() broken too? [03:09] abadger1999: no, just give the relpath from cwd [03:09] Ah. rigt. [03:09] lifeless: Thanks [03:09] poolie: BB:tweak sent to the list [03:09] LaserJock: so it will be ~ 227 * 2 * RTT + BW*(history size) [03:09] i'm just working on the test merge, thanks john [03:11] lifeless: well, as long as I know it's still working I'll stick with it. I just didn't see the progress bar or "pinwheel" moving so I wondered if somehow it got hung up [03:12] bbs, lunching [03:19] LaserJock: over ssh or http? [03:22] * rockstar is having a hell of a time creating a repository with a format compatible with this branch === mwhudson is now known as mwh [03:27] rockstar: source_branch.repository._format.initialize(target_bzrdir) ? [03:29] spiv, well, the way it works on branches that use a something besides knitpack is: [03:29] format = bzrdir.format_registry.make_bzrdir('default') [03:29] newdir = format.initialize_on_transport(to_transport) [03:29] repo = newdir.create_repository(shared=True) [03:30] The default repository format isn't compatible with all branches, though. [03:32] poolie: ssh [03:33] spiv, yea, experiencing this now. [03:33] rockstar: what are you trying to do? [03:33] rockstar: so what problem are you trying to solve? If it's "make a branch into a new shared repository", then you probably want to preserve the original format. [03:33] spiv, yes, that's why I'm fixing the bug. :) [03:34] rockstar: if so, I'd make a new *empty* bzrdir, then use my suggestion above (passing shared=True), then just branch.sprout into a directory under that. [03:34] lifeless, I've been sitting on this plugin for a while that creates a shared repository and puts a branch inside. [03:36] rockstar: create the repo by using the source repo's bzrdir to sprout [03:36] source_branch.repository.bzrdir.sprout() [03:37] lifeless, wow, I think you just took out most of my code with that (provided it works) [03:40] LaserJock: i'm hoping to work soon on better progress messages for ssh [03:41] spiv, jml, lifeless, Functional Programming Sydney is on tomorrow at 6:30 at google [03:41] poolie: are they different than for http? [03:41] LaserJock: without going into detail yes the codepath is a bit different [03:42] poolie: d'oh. It's a birthday dinner for my mother tomorrow night. [03:47] poolie: ooh. [03:53] what's the 0/4 step in branching? copying over revisions? [04:11] lifeless, remote_branch.repository.bzrdir.sprout() seems to be sprouting the branch, not a repository. [04:12] ah yes, I was a bit quick there :P [04:12] LaserJock: file texts [04:13] It is ridiculously slow. I can't see how it could be so slow even if it is plain knits. [04:13] spiv, i know it's probably in a message somewhere but [04:13] rockstar: so the source.repository.bzr._format object should be parameterised correctly [04:13] what is the point of the error translation change in your landing to 1.7? [04:13] just asking to know, not cause i disapprove [04:15] wgrant: what is? [04:15] jml: Checking out the branch that LaserJock is attempting to check out. [04:16] wgrant: from Launchpad? [04:16] Yes. [04:17] wgrant: oh, it finished! [04:17] Branched 616 revision(s). [04:17] real 147m15.237s [04:17] LaserJock: How big is it all up? [04:18] .bzr is 33MB [04:18] lifeless, parameterized correctly how? [04:19] LaserJock: run 'bzr upgrade' in your copy [04:19] LaserJock: it will at least make your push, when you publish to LP, nice and fast :) [04:20] What is the status of stacked branches (with LP)? [04:21] lifeless: do I run upgrade in the branch or in the root of the share repo? [04:21] wgrant: the next rollout will support them and have a default stacking policy set up for certain projects. [04:21] *shared [04:22] LaserJock: oh, if you have a shared repo already, its probably already packs [04:22] jml: The rollout in a few hours? [04:22] lifeless: oh, so was it taking so long because it was converting as it was branching? [04:22] Do we get docs on how to use them, or do we have to work to actually discover that they are supported, and work harder to work out how to use them? [04:23] oh, snap [04:23] wgrant: that rollout, yes. [04:23] LaserJock: it shouldn't have no, the conversion from knits to packs is trivial - we just strip off some metadata [04:23] hmm, this doesn't look good. bzr info in the branch gives: Repository tree (format: unnamed) [04:23] jml: Aha. [04:23] wgrant: using them is a Bazaar issue :) [04:24] jml: How does LP define a stacking policy? [04:24] Or is that a branch property? [04:24] Your statement about doing it for certain projects above has me confused. [04:24] wgrant: a branch can be stacked on another branch. Bazaar has a feature where new branches can be automatically stacked on a preconfigured branch. [04:24] LaserJock: there is a bug on that [04:25] LaserJock: just run 'bzr upgrade' in the new branch [04:25] LaserJock: that will upgrade it to a tags-supporting branch [04:25] jml: Right, that makes sense, but I wondered how LP came into the configuration equation. [04:26] wgrant: roughly speaking, Launchpad will stack branches on the development focus branch by default. [04:27] I fail to see how Launchpad can decide that, but I guess I've no choice but to trust you! [04:27] lp tells bzr what to stack on === thumper_laptop is now known as thumper [04:31] wgrant: I'm not sure I follow. [04:32] jml: Normally when I push a branch to LP, LP doesn't interfere. I just upload the branch over sftp or bzr+ssh, and LP eventually scans it. LP has no say in the upload. [04:32] lifeless: yeah, bzr upgrade was trivial and got me a recognizable format [04:33] wgrant: so, Launchpad tells the client 'you should stack your branches on URL', and the client says 'OK' [04:33] jml: Aha, that makes sense. [04:33] wgrant: except actually because bzr is request / response, Launchpad only answers questions [04:34] I presume that this doesn't work unless I use bzr+ssh. [04:34] actually, sftp works fine too. [04:34] poolie: It was for https://bugs.launchpad.net/bzr/+bug/263527 [04:34] Launchpad bug 263527 in bzr "ErrorFromSmartServer should not cause a traceback" [Medium,Fix released] [04:35] poolie: basically it doesn't scare users with a client-side traceback when it's (probably) the server that's having the problem. [04:35] wgrant: it won't work for old formats. they'll just upload normally. [04:35] jml: So it speaks bzr over sftp somehow? [04:35] I thought pushing over sftp was just copying things with sftp. [04:36] not really. [04:36] Well, at least it didn't use anything bzr-specific. [04:36] Bazaar delegates to format objects, which do file operations more intelligently than dumb copying. [04:37] here, the new format checks the remote configuration file. [04:37] wgrant: lp synthesises a file at the project/ path in the sftp tree [04:37] wgrant: bzr reads that file [04:38] * jml has a mental picture of himself standing at a keyboard wearing a devo hat. [04:38] lifeless: Ahh. [04:39] lifeless: That explains it - I wondered how bzr could get information from LP from an empty directory. [04:45] wgrant: LP is full of "magic" :-) [04:46] we try to keep it to a minimum. [04:47] (alternatively, "You think that's files you're reading?") [04:48] poolie: Thanks for setting up bzr-core. I have gotten herb to zap bazaar-overall [04:49] i saw, thanks [04:55] spiv, so I was wondering about TestBranchSetLastRevisionInfo.test_unexpected_error [04:55] but maybe i understand more now [04:55] spiv, could it be that the comment at the top of that test is wrong? [04:55] # A response of 'NoSuchRevision' is translated into an exception. [04:56] actually it's testing when we get a random unexpected error [04:56] ok, so pushing the same branch (now upgraded) took 16 min [04:56] so a total turn-around for branch-push of 163 minutes [04:57] :( [04:57] !! [04:57] well, the time to upload is ok i guess... [04:57]