[00:01] Why is an upgrade necessary for the commit to succeed? [00:02] abentley: scroll back. the commit is failing with an error about incompatible repository formats. [00:02] my response to that was to attempt an upgrade on both the branch and the repo [00:02] It's not in my scrollback. [00:03] All I see is your paste of the upgrade failure. [00:03] abentley: the line immediately following that [00:03] abentley: 10:49 < bignose> the upgrade is prompted by a 'bzr commit' giving "Repository KnitPackRepository('sftp://bzr@fs/%7E/.bzr/repository/') is not compatible with repository KnitRepository('file:///home/bignose/Projects/.bzr/repository/')" [00:04] So you're committing in a checkout? [00:04] abentley: yes [00:06] So as spiv noted, the command is "upgrade --rich-root-pack" [00:06] $ bzr upgrade --rich-root-pack . [00:06] bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. [00:07] It sounds like your remote branch is the one that needs to be upgraded. [00:07] the checkout branch? [00:07] sftp://bzr@fs/%7E/.bzr/repository/ [00:08] okay, trying that [00:08] What does bzr info . say for the format? [00:08] too late, I'm upgrading it now :-) [00:11] isn't this just going to compound the problem though? surely I want to *reduce* the number of repos and branches that are in this non-default "rich-root-pack" format? [00:11] Well, the rich-root formats can't be converted into the default format. [00:11] ugh. [00:12] so I'm proceeding down a dead end? [00:12] Because they can't represent everything that the rich-root formats can. === blueyed_ is now known as blueyed [00:12] So you can make it so you can commit, which is what you were saying was your immediate priority. [00:12] And you can continue using this format for branches that are already in it. [00:13] I'm trying to merge from a colleague's branch into my copy of trunk and I get this error: [00:13] yes. I didn't think, though, that the Bazaar developers would have implemented formats that cannot be converted to each other. [00:13] That's half the point of making new formats. [00:13] bzr merge ../other-branch [00:13] bzr: ERROR: Tags not supported by BzrBranch5('file:///home/jml/project/trunk/'); you may be able to use bzr upgrade --dirstate-tags [00:13] abentley: the problem is that this is the *entire repository* of all branches that I work on at this site. [00:14] You're the one who said "too late". [00:14] I believe the plan is that rich-root support will eventually be in the default format. [00:14] There's nothing *wrong* with this format, it's just not the default yet. [00:14] why do I have to upgrade my copy of trunk? [00:14] again, I didn't think 'bzr upgrade' commands would be leading me down a dead end. [00:14] It's not a dead-end. You're just an early adopter. [00:15] seemed like a reasonable assumption. [00:15] jml: Because we are tag fascists, and you must be assimilated. [00:15] abentley: let me rephrase [00:15] bignose: Have you looked at the documentation of upgrade? [00:15] abentley: I'm not upgrading my trunk branch format [00:15] --rich-root-pack New in 1.0: Pack-based format with data compatible [00:15] with rich-root format repositories. Incompatible with [00:15] bzr < 1.0 [00:15] I'll be clear: I never chose this "rich-root-pack" format, except in response to getting a bug fixed so long ago that I can't recall what it was. [00:16] isn't bzrbranch5 dirstate-tags era? [00:16] now, there is of course the caveat to be careful of doing things suggested by people on IRC [00:16] bob2: older. [00:16] format 5 is knit era [00:17] but it's rather astounding to me that soemone would implement a format that cannot be converted *from*. [00:17] bignose: That was the whole point of the format. [00:17] Yes, I see that it's "incompatible with bzr < 1.0", which is fine because I'm no longer using versions less than that. [00:17] All it does is allow bazaar to store data that it otherwise couldn't. [00:18] bignose: the new format was made *because* there was data we want to record that cannot be recorded in earlier formats. [00:18] my concern is that you're saying it can't be converted *from* in future. [00:18] bignose: Oh certainly it can be converted from. [00:18] bignose: aah [00:18] spiv: earlier formats? you said above "I believe the plan is that rich-root support will eventually be in the default format." [00:19] so I've now got "rich-root-pack", which can't be converted to "rich-root" [00:19] which means I won't be able to convert to the future default. [00:19] It can be converted from rich-root-packs to the formats that support subtrees. [00:19] bignose: it's just that you can't convert from this to older formats. You will be able to convert this data to future formats. [00:19] bignose: as I said before, it's not a dead end. [00:20] spiv: so, if I read that right, it's *not* true (as someone said earlier) that "rich-root-pack" can't be converted to "rich-root"? [00:20] why, then, would I not convert to "rich-root" immediately, instead of "rich-root-pack"? [00:21] bignose: I don't know any reason why you couldn't covert between those. [00:21] rich-root and rich-root-pack share the same *model*. Of the two rich-root-pack is faster. [00:21] bignose: but if you're running >= bzr 1.0, I also don't know of a good reason why you'd want to downgrade from from rich-root-pack to the slower rich-root :) [00:22] bignose: rich-root-pack is likely to be the future default, not rich-root. [00:23] abentley: that makes it clearer, and is different to what spiv said. [00:24] bignose: sorry, I didn't mean to confuse you. [00:24] thanks everyone. [00:24] bignose: What spiv said was about rich root support, not a particular format. [00:24] new problem: [00:25] in trying to upgrade the checkout branch, I seem to have messed up the .bzr directory. [00:25] I've reverted to the .bzr.backup (that is, 'rm -r .bzr && mv .bzr.backup .bzr') [00:25] but still 'bzr info' says "bzr: ERROR: No repository present: "file:///home/bignose/Projects/websites.devel/www.benfinney.id.au/site.ikiwiki/" [00:26] ls /home/bignose/Projects/websites.devel/www.benfinney.id.au/site.ikiwiki/.bzr [00:26] ]$ ls .bzr [00:26] branch branch-format branch-lock checkout README [00:27] cat .bzr/branch/format [00:27] $ cat .bzr/branch/format [00:27] Bazaar-NG branch format 5 [00:28] This looks like a standalone tree whose repository is missing. [00:28] You actually deleted the .bzr directory, eh? [00:29] well, the current '.bzr' directory is one that was backed up by the 'bzr upgrade' process, so unless that has modified it somehow, it was working fine as a checkout. [00:29] I think that has modified it somehow. [00:29] yeesh. [00:29] it's not a simple 'mv .bzr .bzr.backup' ? [00:30] its a cp -r [00:30] Specifically, I think that your repository was moved from the old .bzr into the new one as part of the upgrade. [00:30] abentley: err no. [00:30] abentley: .bzr.backup is done by t.copy_tree(.bzr, .bzr.backup) [00:30] abentley: so the old repository doesn't move at all [00:30] okay. at this point I'm ready to blow away this directory and check it out again. [00:30] lifeless: Okay, so why wouldn't there be a repository directory? [00:30] should I do so? [00:31] bignose: hang on a sec please [00:31] okay [00:31] bignose: if you have significant local changes, I can show you how to retain them. [00:31] bignose: lets get a root cause so we can fix/prevent in future [00:31] bignose: can you do ls -l .bzr [00:31] bignose: and ls -l .bzr.backup [00:32] lifeless: he has deleted the .bzr that upgrade produced and moved .bzr.backup to .bzr [00:32] lifeless: bear in mind that '.bzr' has been restored from '.bzr.backup' [00:32] so the only thing we'll see in '.bzr' is whatever was put into '.bzr.backup' by the upgrade [00:33] abentley: ah [00:33] bignose: all the same, lets see whats there :) [00:33] okay. paste flood cometh [00:33] $ ls -l .bzr [00:33] total 20 [00:33] drwxr-xr-x 3 bignose bignose 4096 2008-02-27 10:40 branch [00:33] -rw-r--r-- 1 bignose bignose 35 2008-02-27 10:40 branch-format [00:33] drwxr-xr-x 2 bignose bignose 4096 2008-02-27 10:40 branch-lock [00:33] drwxr-xr-x 3 bignose bignose 4096 2008-02-27 10:40 checkout [00:33] -rw-r--r-- 1 bignose bignose 82 2008-02-27 10:40 README [00:34] lifeless: tag, you're it. I need to buy groceries. [00:34] abentley: thanks for your help [00:34] abentley: thanks :) [00:34] bignose: ok; now cat .bzr/branch/format [00:35] Bazaar-NG branch format 5 [00:35] bignose: is there meant to be a shared repository above this one ? [00:35] yes. [00:35] above this directory I mean [00:35] ok [00:35] this all looks fine to me [00:35] is it working correctly at this point [00:35] * bignose really hopes this doesn't lead to the discovery that the shared repo is gone. [00:36] lifeless: no. 'bzr info' complains there's no repository. [00:36] ok [00:36] where is the repository meant to be? [00:36] argh. [00:36] 'bzr info ~/Projects/' gives no output :-( [00:36] (a relative path is fine if you don't want to paste an abs path) [00:37] $ ls -l ~/Projects/.bzr [00:37] total 16 [00:37] -rw-r--r-- 1 bignose bignose 35 2006-09-02 09:54 branch-format [00:37] drwxr-xr-x 2 bignose bignose 4096 2006-09-02 09:54 branch-lock [00:37] -rw-r--r-- 1 bignose bignose 82 2006-09-02 09:54 README [00:37] drwxr-xr-x 5 bignose bignose 4096 2007-11-14 15:42 repository.backup [00:37] there is a distinct lack of 'repository' there [00:38] repository.backup is from november [00:38] now, there are multiple possible reasons [00:38] one is a catastrophic bzr bug [00:38] $ ls -l ~/Projects/.bzr.backup/ [00:38] total 16 [00:38] -rw-r--r-- 1 bignose bignose 35 2008-02-27 10:45 branch-format [00:38] drwxr-xr-x 2 bignose bignose 4096 2008-02-27 10:45 branch-lock [00:38] -rw-r--r-- 1 bignose bignose 82 2008-02-27 10:45 README [00:38] drwxr-xr-x 5 bignose bignose 4096 2008-02-27 10:45 repository [00:38] ok yay [00:38] bignose: here is what I think has happened. [00:39] bignose: I'll get you to cat a format file in a second to confirm [00:39] what I think is: [00:39] you are running subtree or rich-root [00:39] if it helps, I previously in this session also ran 'bzr upgrade --rich-root-pack ~/Projects/' [00:39] and you tried to upgrade the repository to something with less data [00:39] the upgrade failed; leaving the backup intact but the repo borked. [00:39] which gave "bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format." [00:40] bignose: can you cat the repository/format file from the projects repository backup [00:41] which directory? '~/Projects/.bzr/repository.backup/format' or '~/Projects/.bzr.backup/repository/format' ? [00:41] or something else? [00:41] '~/Projects/.bzr.backup/repository/format' [00:41] $ cat .bzr.backup/repository/format [00:41] Bazaar Knit Repository Format 3 (bzr 0.15) [00:42] bignose: ok, I'm correct. [00:42] bignose: I will file a bug in a minute. [00:42] good to know :-) [00:42] bignose: now, here is the cause: [00:43] we have three discreet data models [00:43] call them 'plain', 'rich root', 'subtrees' [00:43] they are ordered: plain commits done to plain can be upgraded to rich-root (which pull will do automatically), but not downgraded. [00:43] (the reason for this is long and involved; skip it for now) [00:44] likewise rich-root commits can be upgraded to subtrees but not downgraded. [00:44] what you asked bzr to do is to convert a subtrees repository to a rich-root repository, which it doesn't know how to do (as it would have to toss away data) [00:45] so - [00:45] reinstate your repository by discarding ~/Projects/.bzr and mv ~/Projects/.bzr{.backup,} [00:45] okay [00:45] and now upgrade it to pack-0.92-subtree [00:46] all the trouble with the checkout was pure confusion due to the shared repository being awol [00:46] alright. but all this started *before* I attempted the upgrade, with a commit that failed because of format incompatibilities. [00:47] ok [00:47] so I'll have to try that again and make sure there isn't more upgrading to be done. [00:47] get this upgrade done [00:47] and I'll predict what the problem was [00:47] so, what upgrade do I need to do now that I've restored the backup shared repository? [00:47] bzr upgrade --pack-0.92-subtree ~/Projects/' [00:48] I predict you have a heavyweight(the default) checkout of a project in a 'plain' repository [00:48] doing now [00:48] Your local data has been upgraded to subtrees [00:48] and the commit is failing because your local commit can't be represented in that other repository. [00:49] okay. so 'bzr upgrade --rich-root-pack ~/Projects/' was a mistake? [00:49] yes [00:49] argh. please cluebat the appropriate people in this channel then, for suggesting that I do that [00:50] next week we're planning how to change our defaults [00:50] to remove all this pain as quickly as possible [00:50] okay, the shared repo is upgraded [00:50] I will now attempt the commit again on the checkout branch [00:50] it will fail [00:50] because the problem is not your local data, its the remote data [00:51] in that the remote data is in a plain format (or -rich-root) and yours is in subtree [00:51] Permission denied: ".bzr/repository/upload/crezvop7l0z8hop1rxvb.pack": [Errno 13] Permission denied [00:52] okay. so what needs to happen next? [00:52] uhmf [00:52] thats an interesting error [00:52] thats after the upgrade finished? [00:52] okay, probably time for a quick roundup of what format everything is at [00:54] checkout branch: Bazaar-NG branch format 5 [00:54] local shared repository: Bazaar pack repository format 1 with subtree support (needs bzr 0.92) [00:55] remote central branch: Bazaar-NG branch format 5 [00:55] remote shared repository: Bazaar pack repository format 1 with rich root (needs bzr 1.0) [00:55] bignose: yup, its clear there :) [00:56] bignose: the original problem was: [00:56] local repo: subtree [00:56] remote repo: rich-root [00:56] all done by 'cat ./bzr/{branch,repository}/format' as appropriate. [00:56] the use of knits/packs/etc is orthogonal to the model of data being stored. [00:56] so what's next? upgrade the remote repository? [00:57] with 'bzr upgrade --pack-0.92-subtree' ? [00:57] if that is an option, then yes that will stop the error occuring. Or, if that is not an option or not trivial to do, then you can create a local repository that is rich-root only and use that [00:57] well, I have write permission on the remote shared repository. is there a reason I shouldn't upgrade it to that format? [00:58] all your other devs will get errors updating when you upgrade the central repository though; because across model boundaries you cannot do bidirectional push-pull [00:58] also, didn't you just take me through the necessity of *not* having the local shared repository as rich-root? [00:58] yes, remember the relationship of the models: [00:58] plain for whatever reason your _existing_ repository was at subtree [00:59] local repository? [00:59] * jdong gives jelmer a big hug [00:59] *you* can't go down from here for your existing projects [00:59] existing local repository yes. [00:59] thanks for bzr-svn goodness :) [01:00] lifeless: okay. so if I upgrade the central (remote) shared repository, everyone else needs to upgrade their own repositories for all checkouts? [01:00] lifeless: any other downsides? i.e. will I regret doing this in six months? [01:00] yes, and if you have multiple projects in each repository, and there are other places you are collaborating with, this will propogate [01:01] We will be changing our default format to be rich root, and then subtrees, in the 'near' future. [01:01] what about just branching from these repositories? [01:01] will those also need to be at the same format? [01:02] yes - think of it as water and ink - once you have the subtree ink in the water, it goes everywhere and can't be taken out. [01:02] grah. [01:02] bignose: the easiest option for you is to use a separate repository for this tree on your local disk [01:02] can't I just downgrade to "rich-root" and *discard* the extra information that can't be represented in the rich-root format? [01:03] bignose: e.g. bzr init-repo --rich-root-pack ~/Projects/Foo && bzr checkout REMOTEURL ~/Projects/Foo/bar [01:03] bignose: that will make anything in Foo be rich-root only and commits will work fine [01:04] bignose: no, because the information loss would round trip - you could downgrade and upgrade and end up with two revisions claiming to be identical but with different values; bzr will consider that a hostile attack and barf at you. [01:04] ^ no you can't just strip the information [01:04] (I suppose this could almost be a use case for rebase...) [01:05] spiv: tag you're it. [01:05] spiv: I have a plane to catch. [01:05] Heh. [01:05] lifeless: ok. [01:05] two bugs files [01:05] *filed* [01:05] lifeless: thanks [01:05] bignose: I *hope* its clearer now. [01:05] I'll have to attack this another day, I'm way late. [01:05] lifeless: it's more complicated :-) [01:05] lifeless: but thanks for the help [01:05] bignose: mail me if you like, and I'll give you a reply my tomorrow (your friday - I'll be in London) [01:06] * spiv wonders if subtree revisions with no subtrees in them could be represented adequately in a rich-root repo... [01:06] talk with you all later [01:06] New bug: #195970 in bzr "bzr upgrade --rich-root-pack fails badly when upgrading subtree repositories" [Undecided,New] https://launchpad.net/bugs/195970 [01:06] New bug: #195971 in bzr "checkout silently upgrades repo data" [Undecided,New] https://launchpad.net/bugs/195971 [01:06] ubotu: nice timing [01:06] Sorry, I don't know anything about nice timing - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi [01:06] Pfft. [01:06] lifeless: have a good trip [01:08] spiv: yes, they can be represented in a rich-root repo correctly [01:08] ideally we should be able to support downgrading from subtree to rich-root if there are no nested tree revisions in the repo [01:09] jelmer: hmm. In that case, it seems like a "bzr upgrade" from subtree to rich-root ought to be allowed if all revisions in the repo are representable. [01:09] jelmer: snap :) [01:10] Hmm, if this is true for bignose, he ought to be able to do that manually by "bzr init-repo --rich-root-pack" somewhere, and then pulling all the revisions across. [01:16] spiv: That does work AIUI [01:20] But there's no code that actually checks the revisions to ensure they have no subtrees, so it will break noisily if they do. [01:23] abentley: the model check fails [01:23] abentley: bzr won't do it. === abentle1 is now known as abentley [01:27] lifeless: is pack-0.92-subtree an alias for development-subtree? [01:27] bob2: no [01:27] bob2: the development formats are compatible with but have their own disk signatures. [01:28] "bzr help formats" needs an updatin' [01:29] bob2: What needs to change? [01:32] lifeless: Actually, I'd prefer if development-subtree were hidden. [01:33] abentley: pack-0.9.2-subtree isn't mentioned in upgrade --help or help formats [01:37] bob2: That is emphatically deliberate. [01:37] No one should be using it, except people implementing nested tree support. [01:38] ah [01:44] did repository.get_revision(NULL_REVISION) ever work? [01:48] mwhudson: no [01:49] hm [01:49] i wonder how loggerhead ever worked with empty branches then [02:11] ho ho ho [02:11] its xmas? [02:12] this seems surprising: http://paste.ubuntu-nl.org/57545/ [02:14] mwhudson: well, its not that friendly true, but I don't think we expect people to use the attributes for flow control [02:14] rephrase [02:14] don't use the attributes for flow control, kthxbye [02:14] so what loggerhead does, which is probably totally dumb [02:14] is it goes [02:14] revs = bzrlib.get_revisions(long list of revids) [02:15] which can raise [02:15] catches NoSuchRevision, throws e.revision out of the list and tries again [02:15] thats dumb [02:15] do this [02:15] parents = repository.get_graph().get_parents(revids) [02:15] missing = rev_ids - set(parents.keys()) [02:17] so given that i don't actually care about what's in the missing set [02:18] mwhudson: well, you get the point, kthxcode [02:18] repo.get_revisions(repo.get_graph().get_parents(revids)) [02:22] * igc lunch [02:22] lifeless: http://paste.ubuntu-nl.org/57546/ [02:22] looks like a typo ... [02:22] mwhudson: get_parents_map [02:23] my bad [02:23] ok [02:23] that's a pretty aggressive deprecation though :) [03:04] mwhudson: its meant to work, I think that is indeed a typo, but anyhow [04:25] New bug: #196002 in bzr-svn "lack of bzr 1.2 support" [Undecided,New] https://launchpad.net/bugs/196002 [05:01] I'm not really sure what to type for my message when I say "bzr record" [05:04] jml: you could say what music you are listening to at the time [05:05] I hate it when people do that. [05:05] in commit messages, that is. [05:05] jml: they should really use revision properties, yes. [05:05] heh heh [05:05] maybe we need hooks to let plugins add revision properties [05:06] jamesh: they already can [05:06] really? [05:06] One file in Mozilla's CVS has been committed with each message a line from a poem or whatever... :) [05:06] jamesh: it's just that cmd_commit is ugly [05:06] or maybe I'm on crack [05:07] jml: I was referring to the actual bzrlib hooks feature [05:07] oh. [05:10] not something that requires replacing cmd_commit, and only letting one plugin do stuff [05:21] lifeless: how do I break a thread out into a separate branch? [05:22] bzr branch -r thread:foo loomed-branch foo-branch doesn't seem to do what I expect [05:23] jml: you could always use the revid [05:24] spiv: how would I calculate the appropriate revid [05:24] jml: "bzr revision-info" while in the desired thread [05:25] jml: (or peek in the .bzr/branch/last-loom file) [05:25] jml: It would be good if "bzr branch -r thread:foo ..." worked, though. [05:26] nope, that didn't work either [05:26] maybe I have been allowed to do something stupid [05:29] this is going to make it difficult to land this branch. [05:30] jml: You mean "bzr {up,down}-thread" to the desired thread, followed by "bzr branch -r revid:$(bzr revision-info | sed -e 's/^[ 0-9]\+//') . foo-branch" doesn't work for you? [05:30] spiv: yes, I mean that. [05:30] except I also want to imply that your sedding is ridiculous. [05:31] :) [05:31] tbh, I was a little surprised that having the thread selected wasn't enough [05:32] jml: that method works for me [05:33] jml: in what way is it not working for you? An error, or branching the wrong revision, or...? [05:33] spiv: the whole branch is being branched [05:34] all of the changes in the threads *above* the thread I want are being pulled in. [05:34] You mean as a loom? [05:34] ("the whole branch is being branched" sounds like a *good* thing...) [05:35] spiv: my original question was "how do I break a thread out into a separate branch?" [05:36] jml: try this: 1. "bzr init" a new branch in non-loom format, 2. pull or push the desired thread into that new branch [05:36] So "bzr revision-info" in the new branch doesn't match "bzr revision-info" in the thread you are trying to extract? [05:36] (It would be nice if there were a "explode-loom" command for this...) [05:36] spiv: they aren't equal, no. [05:37] jml: so, for me, the commands I gave give me the same revision-info (and appropriate log) on both sides. [05:37] ok. [05:37] jml: (although the new branches are also in loom format, but they don't have any threads, so technically they meet your stated requirements) [05:37] I don't really care about the format. [05:37] jml: I'd be interested to hear how jamesh's instructions work for you [05:38] spiv: so all I need is for you to come over and explode the branch for me :) [05:38] judging by the README in bzr-loom, those instructions should do it [05:38] jml: but I also don't know why my method isn't working for you. [05:40] jamesh: that works [06:13] jelmer: bzr-svn's setup.py uses python2.4. Why not 'python'? [06:16] Peng: that's a good question, but on the other hand it's common to explicitly do "python setup.py ..." rather than just "setup.py ...", so that you're explicit about the python version you're using. [06:18] spiv: True. (I partially do it because I've run into setup.py files not being executable.) [06:18] spiv: I ran into it because I ran "make" and that runs "./setup.py". [06:18] s/not being/that aren't/ [06:42] crap. [06:42] does combine-thread lose changes? [06:42] jml: I wouldn't expect it to... you mean uncommitted changes? [06:43] spiv: I mean committed changes. [06:43] oh well, it's too late now. [06:43] jml: well, you can always get those back with the heads plugin [06:43] jml: although it's probably a bug if combine-thread lets you lose changes. [06:43] s/probably// [06:44] how? [06:44] jml: (Also, if you had recorded the loom before the combine-thread, you could also recover that way) [06:44] I had [06:45] jml: the "bzr heads" command will show you all the "heads" of the revision graph your repo [06:45] jml: i.e. all revisions that aren't referenced as a parent by another revision, thus are the head of a line of development. [06:46] spiv: ah, ok. it's not showing, so maybe I hadn't committed these changes [06:46] jml: there's probably a smallish number of those in your repo (unless you've been doing something crazy in your repo), so it should be easy for you to find the revision in that list, then do "bzr branch -r revid:..." to get it as a standalone branch. [06:47] jml: Also, I *think* the "bzr revert-loom" command should take the loom back to the last "bzr record"ed state, but I haven't used that command. [06:48] let's see! [06:48] yep. [07:52] Hahaha. [07:53] Of course my ConfigObj change finally gets merged right after I notice an error in it. [08:07] Peng: d'oh === doko_ is now known as doko [08:15] New bug: #196043 in bzr "Crash in bzr-svn trying to brancy python trunk" [Undecided,New] https://launchpad.net/bugs/196043 [08:18] Well the least I can do is fix the description of that bug. [08:20] I just got that too on another project. [08:20] I converted it with hg instead. :P [08:21] Well, with bzr-svn, it barfed on one of the tags. Hg just didn't import any tags... [08:21] Totally throwaway conversion anyway. [08:57] * igc dinner [09:34] hm, does somebody know if launchpad uses shared repositories for mirrored branches? [09:35] luks: no, it doesn't. [09:35] luks: all the branches on launchpad at the moment are standalone. [09:36] luks: why do you want to know? [09:36]