| abentley | Why is an upgrade necessary for the commit to succeed? | 00:01 |
|---|---|---|
| bignose | abentley: scroll back. the commit is failing with an error about incompatible repository formats. | 00:02 |
| bignose | my response to that was to attempt an upgrade on both the branch and the repo | 00:02 |
| abentley | It's not in my scrollback. | 00:02 |
| abentley | All I see is your paste of the upgrade failure. | 00:03 |
| bignose | abentley: the line immediately following that | 00:03 |
| bignose | 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:03 |
| abentley | So you're committing in a checkout? | 00:04 |
| bignose | abentley: yes | 00:04 |
| abentley | So as spiv noted, the command is "upgrade --rich-root-pack" | 00:06 |
| bignose | $ bzr upgrade --rich-root-pack . | 00:06 |
| bignose | bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. | 00:06 |
| abentley | It sounds like your remote branch is the one that needs to be upgraded. | 00:07 |
| bignose | the checkout branch? | 00:07 |
| abentley | sftp://bzr@fs/%7E/.bzr/repository/ | 00:07 |
| bignose | okay, trying that | 00:08 |
| abentley | What does bzr info . say for the format? | 00:08 |
| bignose | too late, I'm upgrading it now :-) | 00:08 |
| bignose | 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 |
| abentley | Well, the rich-root formats can't be converted into the default format. | 00:11 |
| bignose | ugh. | 00:11 |
| bignose | so I'm proceeding down a dead end? | 00:12 |
| abentley | Because they can't represent everything that the rich-root formats can. | 00:12 |
| === blueyed_ is now known as blueyed | ||
| abentley | So you can make it so you can commit, which is what you were saying was your immediate priority. | 00:12 |
| abentley | And you can continue using this format for branches that are already in it. | 00:12 |
| jml | I'm trying to merge from a colleague's branch into my copy of trunk and I get this error: | 00:13 |
| bignose | yes. I didn't think, though, that the Bazaar developers would have implemented formats that cannot be converted to each other. | 00:13 |
| abentley | That's half the point of making new formats. | 00:13 |
| jml | bzr merge ../other-branch | 00:13 |
| jml | bzr: ERROR: Tags not supported by BzrBranch5('file:///home/jml/project/trunk/'); you may be able to use bzr upgrade --dirstate-tags | 00:13 |
| bignose | abentley: the problem is that this is the *entire repository* of all branches that I work on at this site. | 00:13 |
| abentley | You're the one who said "too late". | 00:14 |
| spiv | I believe the plan is that rich-root support will eventually be in the default format. | 00:14 |
| abentley | There's nothing *wrong* with this format, it's just not the default yet. | 00:14 |
| jml | why do I have to upgrade my copy of trunk? | 00:14 |
| bignose | again, I didn't think 'bzr upgrade' commands would be leading me down a dead end. | 00:14 |
| spiv | It's not a dead-end. You're just an early adopter. | 00:14 |
| bignose | seemed like a reasonable assumption. | 00:15 |
| abentley | jml: Because we are tag fascists, and you must be assimilated. | 00:15 |
| jml | abentley: let me rephrase | 00:15 |
| abentley | bignose: Have you looked at the documentation of upgrade? | 00:15 |
| jml | abentley: I'm not upgrading my trunk branch format | 00:15 |
| abentley | --rich-root-pack New in 1.0: Pack-based format with data compatible | 00:15 |
| abentley | with rich-root format repositories. Incompatible with | 00:15 |
| abentley | bzr < 1.0 | 00:15 |
| bignose | 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:15 |
| bob2 | isn't bzrbranch5 dirstate-tags era? | 00:16 |
| bignose | now, there is of course the caveat to be careful of doing things suggested by people on IRC | 00:16 |
| abentley | bob2: older. | 00:16 |
| abentley | format 5 is knit era | 00:16 |
| bignose | but it's rather astounding to me that soemone would implement a format that cannot be converted *from*. | 00:17 |
| abentley | bignose: That was the whole point of the format. | 00:17 |
| bignose | 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 |
| abentley | All it does is allow bazaar to store data that it otherwise couldn't. | 00:17 |
| spiv | bignose: the new format was made *because* there was data we want to record that cannot be recorded in earlier formats. | 00:18 |
| bignose | my concern is that you're saying it can't be converted *from* in future. | 00:18 |
| abentley | bignose: Oh certainly it can be converted from. | 00:18 |
| spiv | bignose: aah | 00:18 |
| bignose | spiv: earlier formats? you said above "I believe the plan is that rich-root support will eventually be in the default format." | 00:18 |
| bignose | so I've now got "rich-root-pack", which can't be converted to "rich-root" | 00:19 |
| bignose | which means I won't be able to convert to the future default. | 00:19 |
| abentley | It can be converted from rich-root-packs to the formats that support subtrees. | 00:19 |
| spiv | 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 |
| spiv | bignose: as I said before, it's not a dead end. | 00:19 |
| bignose | 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 |
| bignose | why, then, would I not convert to "rich-root" immediately, instead of "rich-root-pack"? | 00:20 |
| spiv | bignose: I don't know any reason why you couldn't covert between those. | 00:21 |
| lifeless | rich-root and rich-root-pack share the same *model*. Of the two rich-root-pack is faster. | 00:21 |
| spiv | 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:21 |
| abentley | bignose: rich-root-pack is likely to be the future default, not rich-root. | 00:22 |
| bignose | abentley: that makes it clearer, and is different to what spiv said. | 00:23 |
| spiv | bignose: sorry, I didn't mean to confuse you. | 00:24 |
| bignose | thanks everyone. | 00:24 |
| abentley | bignose: What spiv said was about rich root support, not a particular format. | 00:24 |
| bignose | new problem: | 00:24 |
| bignose | in trying to upgrade the checkout branch, I seem to have messed up the .bzr directory. | 00:25 |
| bignose | I've reverted to the .bzr.backup (that is, 'rm -r .bzr && mv .bzr.backup .bzr') | 00:25 |
| bignose | but still 'bzr info' says "bzr: ERROR: No repository present: "file:///home/bignose/Projects/websites.devel/www.benfinney.id.au/site.ikiwiki/" | 00:25 |
| abentley | ls /home/bignose/Projects/websites.devel/www.benfinney.id.au/site.ikiwiki/.bzr | 00:26 |
| bignose | ]$ ls .bzr | 00:26 |
| bignose | branch branch-format branch-lock checkout README | 00:26 |
| abentley | cat .bzr/branch/format | 00:27 |
| bignose | $ cat .bzr/branch/format | 00:27 |
| bignose | Bazaar-NG branch format 5 | 00:27 |
| abentley | This looks like a standalone tree whose repository is missing. | 00:28 |
| abentley | You actually deleted the .bzr directory, eh? | 00:28 |
| bignose | 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 |
| abentley | I think that has modified it somehow. | 00:29 |
| bignose | yeesh. | 00:29 |
| bignose | it's not a simple 'mv .bzr .bzr.backup' ? | 00:29 |
| lifeless | its a cp -r | 00:30 |
| abentley | Specifically, I think that your repository was moved from the old .bzr into the new one as part of the upgrade. | 00:30 |
| lifeless | abentley: err no. | 00:30 |
| lifeless | abentley: .bzr.backup is done by t.copy_tree(.bzr, .bzr.backup) | 00:30 |
| lifeless | abentley: so the old repository doesn't move at all | 00:30 |
| bignose | okay. at this point I'm ready to blow away this directory and check it out again. | 00:30 |
| abentley | lifeless: Okay, so why wouldn't there be a repository directory? | 00:30 |
| bignose | should I do so? | 00:30 |
| lifeless | bignose: hang on a sec please | 00:31 |
| bignose | okay | 00:31 |
| abentley | bignose: if you have significant local changes, I can show you how to retain them. | 00:31 |
| lifeless | bignose: lets get a root cause so we can fix/prevent in future | 00:31 |
| lifeless | bignose: can you do ls -l .bzr | 00:31 |
| lifeless | bignose: and ls -l .bzr.backup | 00:31 |
| abentley | lifeless: he has deleted the .bzr that upgrade produced and moved .bzr.backup to .bzr | 00:32 |
| bignose | lifeless: bear in mind that '.bzr' has been restored from '.bzr.backup' | 00:32 |
| bignose | so the only thing we'll see in '.bzr' is whatever was put into '.bzr.backup' by the upgrade | 00:32 |
| lifeless | abentley: ah | 00:33 |
| lifeless | bignose: all the same, lets see whats there :) | 00:33 |
| bignose | okay. paste flood cometh | 00:33 |
| bignose | $ ls -l .bzr | 00:33 |
| bignose | total 20 | 00:33 |
| bignose | drwxr-xr-x 3 bignose bignose 4096 2008-02-27 10:40 branch | 00:33 |
| bignose | -rw-r--r-- 1 bignose bignose 35 2008-02-27 10:40 branch-format | 00:33 |
| bignose | drwxr-xr-x 2 bignose bignose 4096 2008-02-27 10:40 branch-lock | 00:33 |
| bignose | drwxr-xr-x 3 bignose bignose 4096 2008-02-27 10:40 checkout | 00:33 |
| bignose | -rw-r--r-- 1 bignose bignose 82 2008-02-27 10:40 README | 00:33 |
| abentley | lifeless: tag, you're it. I need to buy groceries. | 00:34 |
| bignose | abentley: thanks for your help | 00:34 |
| lifeless | abentley: thanks :) | 00:34 |
| lifeless | bignose: ok; now cat .bzr/branch/format | 00:34 |
| bignose | Bazaar-NG branch format 5 | 00:35 |
| lifeless | bignose: is there meant to be a shared repository above this one ? | 00:35 |
| bignose | yes. | 00:35 |
| lifeless | above this directory I mean | 00:35 |
| lifeless | ok | 00:35 |
| lifeless | this all looks fine to me | 00:35 |
| lifeless | 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:35 | |
| bignose | lifeless: no. 'bzr info' complains there's no repository. | 00:36 |
| lifeless | ok | 00:36 |
| lifeless | where is the repository meant to be? | 00:36 |
| bignose | argh. | 00:36 |
| bignose | 'bzr info ~/Projects/' gives no output :-( | 00:36 |
| lifeless | (a relative path is fine if you don't want to paste an abs path) | 00:36 |
| bignose | $ ls -l ~/Projects/.bzr | 00:37 |
| bignose | total 16 | 00:37 |
| bignose | -rw-r--r-- 1 bignose bignose 35 2006-09-02 09:54 branch-format | 00:37 |
| bignose | drwxr-xr-x 2 bignose bignose 4096 2006-09-02 09:54 branch-lock | 00:37 |
| bignose | -rw-r--r-- 1 bignose bignose 82 2006-09-02 09:54 README | 00:37 |
| bignose | drwxr-xr-x 5 bignose bignose 4096 2007-11-14 15:42 repository.backup | 00:37 |
| lifeless | there is a distinct lack of 'repository' there | 00:37 |
| lifeless | repository.backup is from november | 00:38 |
| lifeless | now, there are multiple possible reasons | 00:38 |
| lifeless | one is a catastrophic bzr bug | 00:38 |
| bignose | $ ls -l ~/Projects/.bzr.backup/ | 00:38 |
| bignose | total 16 | 00:38 |
| bignose | -rw-r--r-- 1 bignose bignose 35 2008-02-27 10:45 branch-format | 00:38 |
| bignose | drwxr-xr-x 2 bignose bignose 4096 2008-02-27 10:45 branch-lock | 00:38 |
| bignose | -rw-r--r-- 1 bignose bignose 82 2008-02-27 10:45 README | 00:38 |
| bignose | drwxr-xr-x 5 bignose bignose 4096 2008-02-27 10:45 repository | 00:38 |
| lifeless | ok yay | 00:38 |
| lifeless | bignose: here is what I think has happened. | 00:38 |
| lifeless | bignose: I'll get you to cat a format file in a second to confirm | 00:39 |
| lifeless | what I think is: | 00:39 |
| lifeless | you are running subtree or rich-root | 00:39 |
| bignose | if it helps, I previously in this session also ran 'bzr upgrade --rich-root-pack ~/Projects/' | 00:39 |
| lifeless | and you tried to upgrade the repository to something with less data | 00:39 |
| lifeless | the upgrade failed; leaving the backup intact but the repo borked. | 00:39 |
| bignose | which gave "bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format." | 00:39 |
| lifeless | bignose: can you cat the repository/format file from the projects repository backup | 00:40 |
| bignose | which directory? '~/Projects/.bzr/repository.backup/format' or '~/Projects/.bzr.backup/repository/format' ? | 00:41 |
| bignose | or something else? | 00:41 |
| lifeless | '~/Projects/.bzr.backup/repository/format' | 00:41 |
| bignose | $ cat .bzr.backup/repository/format | 00:41 |
| bignose | Bazaar Knit Repository Format 3 (bzr 0.15) | 00:41 |
| lifeless | bignose: ok, I'm correct. | 00:42 |
| lifeless | bignose: I will file a bug in a minute. | 00:42 |
| bignose | good to know :-) | 00:42 |
| lifeless | bignose: now, here is the cause: | 00:42 |
| lifeless | we have three discreet data models | 00:43 |
| lifeless | call them 'plain', 'rich root', 'subtrees' | 00:43 |
| lifeless | they are ordered: plain<rich-root<subtrees | 00:43 |
| lifeless | commits done to plain can be upgraded to rich-root (which pull will do automatically), but not downgraded. | 00:43 |
| lifeless | (the reason for this is long and involved; skip it for now) | 00:43 |
| lifeless | likewise rich-root commits can be upgraded to subtrees but not downgraded. | 00:44 |
| lifeless | 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:44 |
| lifeless | so - | 00:45 |
| lifeless | reinstate your repository by discarding ~/Projects/.bzr and mv ~/Projects/.bzr{.backup,} | 00:45 |
| bignose | okay | 00:45 |
| lifeless | and now upgrade it to pack-0.92-subtree | 00:45 |
| lifeless | all the trouble with the checkout was pure confusion due to the shared repository being awol | 00:46 |
| bignose | alright. but all this started *before* I attempted the upgrade, with a commit that failed because of format incompatibilities. | 00:46 |
| lifeless | ok | 00:47 |
| bignose | so I'll have to try that again and make sure there isn't more upgrading to be done. | 00:47 |
| lifeless | get this upgrade done | 00:47 |
| lifeless | and I'll predict what the problem was | 00:47 |
| bignose | so, what upgrade do I need to do now that I've restored the backup shared repository? | 00:47 |
| lifeless | bzr upgrade --pack-0.92-subtree ~/Projects/' | 00:47 |
| lifeless | I predict you have a heavyweight(the default) checkout of a project in a 'plain' repository | 00:48 |
| bignose | doing now | 00:48 |
| lifeless | Your local data has been upgraded to subtrees | 00:48 |
| lifeless | and the commit is failing because your local commit can't be represented in that other repository. | 00:48 |
| bignose | okay. so 'bzr upgrade --rich-root-pack ~/Projects/' was a mistake? | 00:49 |
| lifeless | yes | 00:49 |
| bignose | argh. please cluebat the appropriate people in this channel then, for suggesting that I do that | 00:49 |
| lifeless | next week we're planning how to change our defaults | 00:50 |
| lifeless | to remove all this pain as quickly as possible | 00:50 |
| bignose | okay, the shared repo is upgraded | 00:50 |
| bignose | I will now attempt the commit again on the checkout branch | 00:50 |
| lifeless | it will fail | 00:50 |
| lifeless | because the problem is not your local data, its the remote data | 00:50 |
| lifeless | in that the remote data is in a plain format (or -rich-root) and yours is in subtree | 00:51 |
| bignose | Permission denied: ".bzr/repository/upload/crezvop7l0z8hop1rxvb.pack": [Errno 13] Permission denied | 00:51 |
| bignose | okay. so what needs to happen next? | 00:52 |
| lifeless | uhmf | 00:52 |
| lifeless | thats an interesting error | 00:52 |
| lifeless | thats after the upgrade finished? | 00:52 |
| bignose | okay, probably time for a quick roundup of what format everything is at | 00:52 |
| bignose | checkout branch: Bazaar-NG branch format 5 | 00:54 |
| bignose | local shared repository: Bazaar pack repository format 1 with subtree support (needs bzr 0.92) | 00:54 |
| bignose | remote central branch: Bazaar-NG branch format 5 | 00:55 |
| bignose | remote shared repository: Bazaar pack repository format 1 with rich root (needs bzr 1.0) | 00:55 |
| lifeless | bignose: yup, its clear there :) | 00:55 |
| lifeless | bignose: the original problem was: | 00:56 |
| lifeless | local repo: subtree | 00:56 |
| lifeless | remote repo: rich-root | 00:56 |
| bignose | all done by 'cat ./bzr/{branch,repository}/format' as appropriate. | 00:56 |
| lifeless | the use of knits/packs/etc is orthogonal to the model of data being stored. | 00:56 |
| bignose | so what's next? upgrade the remote repository? | 00:56 |
| bignose | with 'bzr upgrade --pack-0.92-subtree' ? | 00:57 |
| lifeless | 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 |
| bignose | well, I have write permission on the remote shared repository. is there a reason I shouldn't upgrade it to that format? | 00:57 |
| lifeless | 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 |
| bignose | also, didn't you just take me through the necessity of *not* having the local shared repository as rich-root? | 00:58 |
| lifeless | yes, remember the relationship of the models: | 00:58 |
| lifeless | plain<richroot<subtree | 00:58 |
| lifeless | for whatever reason your _existing_ repository was at subtree | 00:58 |
| bignose | local repository? | 00:59 |
| * jdong gives jelmer a big hug | 00:59 | |
| lifeless | *you* can't go down from here for your existing projects | 00:59 |
| lifeless | existing local repository yes. | 00:59 |
| jdong | thanks for bzr-svn goodness :) | 00:59 |
| bignose | lifeless: okay. so if I upgrade the central (remote) shared repository, everyone else needs to upgrade their own repositories for all checkouts? | 01:00 |
| bignose | lifeless: any other downsides? i.e. will I regret doing this in six months? | 01:00 |
| lifeless | yes, and if you have multiple projects in each repository, and there are other places you are collaborating with, this will propogate | 01:00 |
| lifeless | We will be changing our default format to be rich root, and then subtrees, in the 'near' future. | 01:01 |
| bignose | what about just branching from these repositories? | 01:01 |
| bignose | will those also need to be at the same format? | 01:01 |
| lifeless | 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 |
| bignose | grah. | 01:02 |
| lifeless | bignose: the easiest option for you is to use a separate repository for this tree on your local disk | 01:02 |
| bignose | can't I just downgrade to "rich-root" and *discard* the extra information that can't be represented in the rich-root format? | 01:02 |
| lifeless | bignose: e.g. bzr init-repo --rich-root-pack ~/Projects/Foo && bzr checkout REMOTEURL ~/Projects/Foo/bar | 01:03 |
| lifeless | bignose: that will make anything in Foo be rich-root only and commits will work fine | 01:03 |
| lifeless | 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 |
| lifeless | ^ no you can't just strip the information | 01:04 |
| spiv | (I suppose this could almost be a use case for rebase...) | 01:04 |
| lifeless | spiv: tag you're it. | 01:05 |
| lifeless | spiv: I have a plane to catch. | 01:05 |
| spiv | Heh. | 01:05 |
| spiv | lifeless: ok. | 01:05 |
| lifeless | two bugs files | 01:05 |
| lifeless | *filed* | 01:05 |
| spiv | lifeless: thanks | 01:05 |
| lifeless | bignose: I *hope* its clearer now. | 01:05 |
| bignose | I'll have to attack this another day, I'm way late. | 01:05 |
| bignose | lifeless: it's more complicated :-) | 01:05 |
| bignose | lifeless: but thanks for the help | 01:05 |
| lifeless | bignose: mail me if you like, and I'll give you a reply my tomorrow (your friday - I'll be in London) | 01:05 |
| * spiv wonders if subtree revisions with no subtrees in them could be represented adequately in a rich-root repo... | 01:06 | |
| bignose | talk with you all later | 01:06 |
| ubotu | New bug: #195970 in bzr "bzr upgrade --rich-root-pack fails badly when upgrading subtreerepositories" [Undecided,New] https://launchpad.net/bugs/195970 | 01:06 |
| ubotu | New bug: #195971 in bzr "checkout silently upgrades repo data" [Undecided,New] https://launchpad.net/bugs/195971 | 01:06 |
| spiv | ubotu: nice timing | 01:06 |
| ubotu | Sorry, I don't know anything about nice timing - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi | 01:06 |
| spiv | Pfft. | 01:06 |
| spiv | lifeless: have a good trip | 01:06 |
| jelmer | spiv: yes, they can be represented in a rich-root repo correctly | 01:08 |
| jelmer | ideally we should be able to support downgrading from subtree to rich-root if there are no nested tree revisions in the repo | 01:08 |
| spiv | 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 |
| spiv | jelmer: snap :) | 01:09 |
| spiv | 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:10 |
| abentley | spiv: That does work AIUI | 01:16 |
| abentley | 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:20 |
| lifeless | abentley: the model check fails | 01:23 |
| lifeless | abentley: bzr won't do it. | 01:23 |
| === abentle1 is now known as abentley | ||
| bob2 | lifeless: is pack-0.92-subtree an alias for development-subtree? | 01:27 |
| lifeless | bob2: no | 01:27 |
| lifeless | bob2: the development formats are compatible with but have their own disk signatures. | 01:27 |
| bob2 | "bzr help formats" needs an updatin' | 01:28 |
| abentley | bob2: What needs to change? | 01:29 |
| abentley | lifeless: Actually, I'd prefer if development-subtree were hidden. | 01:32 |
| bob2 | abentley: pack-0.9.2-subtree isn't mentioned in upgrade --help or help formats | 01:33 |
| abentley | bob2: That is emphatically deliberate. | 01:37 |
| abentley | No one should be using it, except people implementing nested tree support. | 01:37 |
| bob2 | ah | 01:38 |
| mwhudson | did repository.get_revision(NULL_REVISION) ever work? | 01:44 |
| lifeless | mwhudson: no | 01:48 |
| mwhudson | hm | 01:49 |
| mwhudson | i wonder how loggerhead ever worked with empty branches then | 01:49 |
| mwhudson | ho ho ho | 02:11 |
| lifeless | its xmas? | 02:11 |
| mwhudson | this seems surprising: http://paste.ubuntu-nl.org/57545/ | 02:12 |
| lifeless | mwhudson: well, its not that friendly true, but I don't think we expect people to use the attributes for flow control | 02:14 |
| lifeless | rephrase | 02:14 |
| lifeless | don't use the attributes for flow control, kthxbye | 02:14 |
| mwhudson | so what loggerhead does, which is probably totally dumb | 02:14 |
| mwhudson | is it goes | 02:14 |
| mwhudson | revs = bzrlib.get_revisions(long list of revids) | 02:14 |
| lifeless | which can raise | 02:15 |
| mwhudson | catches NoSuchRevision, throws e.revision out of the list and tries again | 02:15 |
| lifeless | thats dumb | 02:15 |
| lifeless | do this | 02:15 |
| lifeless | parents = repository.get_graph().get_parents(revids) | 02:15 |
| lifeless | missing = rev_ids - set(parents.keys()) | 02:15 |
| mwhudson | so given that i don't actually care about what's in the missing set | 02:17 |
| lifeless | mwhudson: well, you get the point, kthxcode | 02:18 |
| mwhudson | repo.get_revisions(repo.get_graph().get_parents(revids)) | 02:18 |
| * igc lunch | 02:22 | |
| mwhudson | lifeless: http://paste.ubuntu-nl.org/57546/ | 02:22 |
| mwhudson | looks like a typo ... | 02:22 |
| lifeless | mwhudson: get_parents_map | 02:22 |
| lifeless | my bad | 02:23 |
| mwhudson | ok | 02:23 |
| mwhudson | that's a pretty aggressive deprecation though :) | 02:23 |
| lifeless | mwhudson: its meant to work, I think that is indeed a typo, but anyhow | 03:04 |
| ubotu | New bug: #196002 in bzr-svn "lack of bzr 1.2 support" [Undecided,New] https://launchpad.net/bugs/196002 | 04:25 |
| jml | I'm not really sure what to type for my message when I say "bzr record" | 05:01 |
| jamesh | jml: you could say what music you are listening to at the time | 05:04 |
| jml | I hate it when people do that. | 05:05 |
| jml | in commit messages, that is. | 05:05 |
| jamesh | jml: they should really use revision properties, yes. | 05:05 |
| jml | heh heh | 05:05 |
| jamesh | maybe we need hooks to let plugins add revision properties | 05:05 |
| jml | jamesh: they already can | 05:06 |
| jamesh | really? | 05:06 |
| Peng | One file in Mozilla's CVS has been committed with each message a line from a poem or whatever... :) | 05:06 |
| jml | jamesh: it's just that cmd_commit is ugly | 05:06 |
| jml | or maybe I'm on crack | 05:06 |
| jamesh | jml: I was referring to the actual bzrlib hooks feature | 05:07 |
| jml | oh. | 05:07 |
| jamesh | not something that requires replacing cmd_commit, and only letting one plugin do stuff | 05:10 |
| jml | lifeless: how do I break a thread out into a separate branch? | 05:21 |
| jml | bzr branch -r thread:foo loomed-branch foo-branch doesn't seem to do what I expect | 05:22 |
| spiv | jml: you could always use the revid | 05:23 |
| jml | spiv: how would I calculate the appropriate revid | 05:24 |
| spiv | jml: "bzr revision-info" while in the desired thread | 05:24 |
| spiv | jml: (or peek in the .bzr/branch/last-loom file) | 05:25 |
| spiv | jml: It would be good if "bzr branch -r thread:foo ..." worked, though. | 05:25 |
| jml | nope, that didn't work either | 05:26 |
| jml | maybe I have been allowed to do something stupid | 05:26 |
| jml | this is going to make it difficult to land this branch. | 05:29 |
| spiv | 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 |
| jml | spiv: yes, I mean that. | 05:30 |
| jml | except I also want to imply that your sedding is ridiculous. | 05:30 |
| spiv | :) | 05:31 |
| jml | tbh, I was a little surprised that having the thread selected wasn't enough | 05:31 |
| spiv | jml: that method works for me | 05:32 |
| spiv | jml: in what way is it not working for you? An error, or branching the wrong revision, or...? | 05:33 |
| jml | spiv: the whole branch is being branched | 05:33 |
| jml | all of the changes in the threads *above* the thread I want are being pulled in. | 05:34 |
| spiv | You mean as a loom? | 05:34 |
| spiv | ("the whole branch is being branched" sounds like a *good* thing...) | 05:34 |
| jml | spiv: my original question was "how do I break a thread out into a separate branch?" | 05:35 |
| jamesh | 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 |
| spiv | So "bzr revision-info" in the new branch doesn't match "bzr revision-info" in the thread you are trying to extract? | 05:36 |
| spiv | (It would be nice if there were a "explode-loom" command for this...) | 05:36 |
| jml | spiv: they aren't equal, no. | 05:36 |
| spiv | jml: so, for me, the commands I gave give me the same revision-info (and appropriate log) on both sides. | 05:37 |
| jml | ok. | 05:37 |
| spiv | 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 |
| jml | I don't really care about the format. | 05:37 |
| spiv | jml: I'd be interested to hear how jamesh's instructions work for you | 05:37 |
| jml | spiv: so all I need is for you to come over and explode the branch for me :) | 05:38 |
| jamesh | judging by the README in bzr-loom, those instructions should do it | 05:38 |
| spiv | jml: but I also don't know why my method isn't working for you. | 05:38 |
| jml | jamesh: that works | 05:40 |
| Peng | jelmer: bzr-svn's setup.py uses python2.4. Why not 'python'? | 06:13 |
| spiv | 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:16 |
| Peng | spiv: True. (I partially do it because I've run into setup.py files not being executable.) | 06:18 |
| Peng | spiv: I ran into it because I ran "make" and that runs "./setup.py". | 06:18 |
| Peng | s/not being/that aren't/ | 06:18 |
| jml | crap. | 06:42 |
| jml | does combine-thread lose changes? | 06:42 |
| spiv | jml: I wouldn't expect it to... you mean uncommitted changes? | 06:42 |
| jml | spiv: I mean committed changes. | 06:43 |
| jml | oh well, it's too late now. | 06:43 |
| spiv | jml: well, you can always get those back with the heads plugin | 06:43 |
| spiv | jml: although it's probably a bug if combine-thread lets you lose changes. | 06:43 |
| spiv | s/probably// | 06:43 |
| jml | how? | 06:44 |
| spiv | jml: (Also, if you had recorded the loom before the combine-thread, you could also recover that way) | 06:44 |
| jml | I had | 06:44 |
| spiv | jml: the "bzr heads" command will show you all the "heads" of the revision graph your repo | 06:45 |
| spiv | 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:45 |
| jml | spiv: ah, ok. it's not showing, so maybe I hadn't committed these changes | 06:46 |
| spiv | 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:46 |
| spiv | 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:47 |
| jml | let's see! | 06:48 |
| jml | yep. | 06:48 |
| Peng | Hahaha. | 07:52 |
| Peng | Of course my ConfigObj change finally gets merged right after I notice an error in it. | 07:53 |
| spiv | Peng: d'oh | 08:07 |
| === doko_ is now known as doko | ||
| ubotu | New bug: #196043 in bzr "Crash in bzr-svn trying to brancy python trunk" [Undecided,New] https://launchpad.net/bugs/196043 | 08:15 |
| AfC | Well the least I can do is fix the description of that bug. | 08:18 |
| Peng | I just got that too on another project. | 08:20 |
| Peng | I converted it with hg instead. :P | 08:20 |
| Peng | Well, with bzr-svn, it barfed on one of the tags. Hg just didn't import any tags... | 08:21 |
| Peng | Totally throwaway conversion anyway. | 08:21 |
| * igc dinner | 08:57 | |
| luks | hm, does somebody know if launchpad uses shared repositories for mirrored branches? | 09:34 |
| spiv | luks: no, it doesn't. | 09:35 |
| spiv | luks: all the branches on launchpad at the moment are standalone. | 09:35 |
| spiv | luks: why do you want to know? | 09:36 |
| luks | ok, thanks | 09:36 |
| luks | well, it I tell it to mirror N branches of the same product, using a shared repository would save bandwidth on both sides | 09:37 |
| luks | *if | 09:37 |
| spiv | luks: yeah, that's true. | 09:40 |
| spiv | luks: there is work underway to improve this. | 09:40 |
| awilkins | Even if the branches at LP aren't inside shared repos, if your local branches are, if they share common ancestry you should still have savings,yes? | 09:48 |
| luks | not bandwidth savings, only disk space | 09:49 |
| luks | LP will still download them one by one with full history | 09:50 |
| awilkins | Should it not just be able to download some indexes and determine which revisions you already have? | 09:53 |
| * awilkins speaks in general ignorance of internal format, forgive him | 09:53 | |
| luks | that's what shared repositories are for :) | 09:53 |
| luks | if the revision data are not shared, it doesn't know which revisions it already has | 09:54 |
| awilkins | Yes, but if you are branching an LP branch into a shared repo that contains other branches of the same ancestry, your local repo knows which revisions it has ? | 09:54 |
| luks | ah, you mean the other way around | 09:55 |
| awilkins | So it could get away with getting a revision list from the server and only downloading stuff it's missing? | 09:55 |
| luks | yes, in that case it will download only the revision it needs | 09:55 |
| awilkins | Ah, aI am reassured | 09:55 |
| unenough | how do i create a copy of an old revision of a file? | 09:56 |
| awilkins | I thought it could, with all the HTTP range downloading stuff in there | 09:56 |
| awilkins | unenough: bzr cat -r <rev> path/to/old/file > myoldfile | 09:56 |
| unenough | awilkins, thanks. | 09:56 |
| spiv | unenough: or "bzr revert -r REV path/to/file" | 10:06 |
| unenough | i didn't want to revert, just view it | 10:07 |
| unenough | cat is good | 10:07 |
| unenough | but thanks | 10:07 |
| quicksilver | bzr cat is awesome :) | 10:16 |
| === johnny is now known as vagrantc_ | ||
| === vagrantc_ is now known as johnny | ||
| ubotu | New bug: #196080 in bzr "`bzr info -v bzr://host/branch` hides actual branch/repo format" [Undecided,New] https://launchpad.net/bugs/196080 | 11:00 |
| ubotu | New bug: #196082 in bzr-loom "checkout of loom produce regular branch" [Undecided,New] https://launchpad.net/bugs/196082 | 11:05 |
| === mrevell is now known as mrevell-lunch | ||
| === _arne^ is now known as arne^ | ||
| awilkins | Is Guillermo Gonzalez here? | 14:18 |
| awilkins | Or anyone else who cares about bzr-eclipse? | 14:19 |
| === jelmer_ is now known as jelmer | ||
| === mrevell-lunch is now known as mrevell | ||
| Lo-lan-do | Hi all | 14:24 |
| Lo-lan-do | Any plans to update bzr-svn in Debian sid? It prevents upgrading to bzr 1.2... | 14:25 |
| jelmer | I hope to release 0.4.8 this weekend | 14:25 |
| Lo-lan-do | Yay :-) | 14:26 |
| Lo-lan-do | Another question: when I pull from a pure bzr branch to a branch bound to a remote SVN repo, there seem to be many many HTTPS connections, and the entire process is rather slow. Is that inherent to the way SVN works, or can that theoretically be fixed? | 14:28 |
| lamont | given a commit, how do I tell bzr to tell me what files were changed in that commit? | 14:47 |
| luks | bzr st -r X | 14:51 |
| lamont | thanks | 14:52 |
| luks | er, no | 14:52 |
| luks | bzr st -c X | 14:52 |
| luks | which is an equivalent for bzr st -r (X-1)..X | 14:53 |
| jelmer | Lo-lan-do: what version of bzr-svn are you using? | 14:56 |
| jelmer | Lo-lan-do: Theoretically a lot of it can be fixed | 14:56 |
| Lo-lan-do | 0.4.7-1 | 14:56 |
| fbond | Hi, I really want to be able to "bzr update -r xxx" in a checkout; what am I really looking for? | 15:49 |
| fbond | I want to be able to "rewind" my checkout (not just the working copy). | 15:50 |
| fbond | I know I could make a new checkout, but it seems like this should be easier... | 15:50 |
| jelmer | fbond: there's no way to do that at the moment | 16:00 |
| jelmer | afaik there are several bug reports open a bout supporting -r for bzr upgrade | 16:00 |
| jelmer | s/upgrade/update | 16:00 |
| fbond | jelmer: second time you've helped me today, thanks! | 16:09 |
| jdong | jelmer: why is "bzr missing" so significantly more costly than "bzr pull" for bzr-svn? | 16:15 |
| jelmer | it uses a different (not yet optimized) code path | 16:15 |
| jdong | ah, ok | 16:15 |
| jelmer | pull is a lot more common so I've spent more time optimizing | 16:16 |
| jdong | jelmer: are there any better ways of looking for new upstream commits rather than pulling into a branch? | 16:16 |
| jelmer | "bzr missing" :-) | 16:17 |
| jdong | :) | 16:17 |
| jdong | jelmer: do you know if any DVCS svn converters like bzr-svn work well with gigantic history svn repos? | 16:19 |
| jdong | I'd like to follow a specific branch of KDE's anonsvn and don't feel like dealing with a few million revision history | 16:19 |
| jelmer | git-svn probably although I don't have experience with it | 16:19 |
| jelmer | If you're just interested in following upstream you may want to wait until after the bzr sprint | 16:20 |
| jelmer | with a bit of luck we'll be have shallow branches support then | 16:20 |
| jdong | sweet | 16:20 |
| Lo-lan-do | Sweet indeed :-) | 16:21 |
| jdong | jelmer: does bzr-svn currently deal well with subtrees of svn repos? Like if I just want to follow ktorrent in kde's SVN, would that be an intensive operation? | 16:22 |
| jelmer | jdong: What do you mean with subtrees exactly? svn:externals? | 16:23 |
| jdong | jelmer: like a subdirectory of a svn repo | 16:23 |
| jelmer | jdong: Yes, it can do that but the size and number of files in the repository still matter at the moment. | 16:24 |
| jdong | jelmer: so would it still be prohibitively expensive, in your opinion, to bzr branch a single app's dir from anonsvn.kde.org? | 16:24 |
| jdong | the entire repo has a bazillion revs but I doubt more than 1000 pertain to ktorrent itself | 16:24 |
| Peng | Should I kill svn-import when it hasn't done anything but slightly fluctuate its RAM usage for 6 hours? | 16:25 |
| jelmer | jdong: caching those revs the first time will be pretty expensive | 16:25 |
| jelmer | jdong: After that, all KDE-repository-related operations should be pretty quick | 16:25 |
| jelmer | jdong: s/Caching the revs/caching the revs' metadata/ | 16:25 |
| jelmer | Peng: Depends on the size of the repository | 16:25 |
| jdong | jelmer: sounds painful... | 16:25 |
| jelmer | Peng: It does support resuming | 16:26 |
| jdong | jelmer: does the svn-cache take a lot of disk space? | 16:26 |
| Peng | jelmer: 60k revisions? | 16:26 |
| jelmer | Peng: Could be. I should show a progress bar though. | 16:27 |
| abentley | Peng: When you generate new merge directives, please generate them against a fresh copy of trunk. | 16:27 |
| jelmer | jdong: yes, although I'm not sure how much that would be for KDE | 16:27 |
| abentley | That way the diff shows the changes that aren't already in trunk. | 16:28 |
| jelmer | jdong: For samba (26k revs) it's 50 Mb | 16:28 |
| luks | I remember mine for the KDE SVN beeing around 2GB :/ | 16:28 |
| jelmer | luks: it should be smaller now than what it used to be | 16:28 |
| jdong | luks: ouch | 16:28 |
| luks | oh | 16:28 |
| Peng | abentley: Yeah. I only pulled and noticed that it had been merged right after sending that patch. | 16:28 |
| abentley | Okay. | 16:29 |
| Peng | If I noticed it had been merged, I would've been more apologetic. : | 16:30 |
| Peng | P | 16:30 |
| Peng | :P | 16:30 |
| abentley | Peng: Submitting your latest. | 16:41 |
| Peng | Thank you. Sorry. | 16:42 |
| mvo | lifeless: do you have a sponsor for bzr-loom yet? | 17:46 |
| === blueyed_ is now known as blueyed | ||
| Qhestion | can a plugin store metadata in branches, or do i have to use normal (versioned) files? | 19:35 |
| mwhudson | does someone want to merge http://bundlebuggy.aaronbentley.com/request/%3C47C4A6D2.7080508%40canonical.com%3E ? | 19:58 |
| mwhudson | -or- remind my how to use bzr-svn | 20:18 |
| mwhudson | oh, it helps if you get the url right | 20:19 |
| mwhudson | oh, wow, there's already a lp import of the branch i wanted | 20:28 |
| Verterok | awilkins: ping (I'm Guillermo) | 20:32 |
| abentley | mwhudson: bialix was the last reviewer, so he should have merged it. | 20:42 |
| mwhudson | oh, ok | 20:42 |
| * mwhudson is pleased with his 10 minute hack of pyflakes to understand lazy imports... | 20:42 | |
| mtaylor | GAH | 20:44 |
| mtaylor | bzr: ERROR: Repository KnitPackRepository('file:///home/mtaylor/package/python-modules/python-mysqldb/.bzr/repository/') is not compatible with repository SvnRepository('svn+ssh://mtaylor-guest@svn.debian.org/svn/python-modules') | 20:45 |
| mtaylor | I know what the problem is... I'm just complaining | 20:45 |
| mtaylor | jelmer: looking for bzr svn-import advice... | 21:05 |
| mtaylor | jelmer: http://svn.debian.org/viewsvn/python-modules/ | 21:05 |
| mtaylor | has a packages dir, underwhich are a dir for each project, each have possible a trunk and some branches... | 21:06 |
| mtaylor | jelmer: should I just svn-import the whole thing and then ignore the branches I don't care about? | 21:06 |
| mtaylor | so that the meta-data is all right? | 21:06 |
| Peng | Oh my god. | 21:21 |
| fullermd | Yes? | 21:21 |
| Peng | There's a new version of ConfigObj out! | 21:21 |
| Peng | Bwahahaha! | 21:21 |
| fullermd | Timing is everything. | 21:22 |
| mtaylor | speaking of versions and timing... | 21:28 |
| mtaylor | bzr-svn for gutsy in the ppa is not compatible with bzr for gutsy in the ppa | 21:29 |
| * mtaylor votes that bzr-svn be considered part of the release... | 21:29 | |
| Peng | The new ConfigObj has no changes to configobj.py, just docs and validate. | 21:34 |
| Peng | And the license is now executable. | 21:34 |
| === michelp_ is now known as michelp | ||
| bob2 | mtaylor: did you get that error doing a co of an originally svn branch? | 21:52 |
| mtaylor | bob2: yeah, into an init-repo'd dir that I just let init-repo to the default | 22:03 |
| mtaylor | bob2: it worked fine if I did init-repo --rich-root-pack instead | 22:03 |
| bob2 | mtaylor: ah, right, that's the workaround | 22:03 |
| * mtaylor votes that rich-root-pack become the default | 22:06 | |
| * mtaylor votes again that bzr not be released to the ppa without corresponding bzr-svn packages too | 22:07 | |
| * mtaylor votes himself a free lunch | 22:07 | |
| * bignose concurs. mtaylor is now a free lunch. | 22:12 | |
| fullermd | And me without my skewers today :( | 22:13 |
| === mtaylor is now known as a_free_lunch | ||
| === a_free_lunch is now known as mtaylor | ||
| jam | lifeless: ping, question about redefining some of the sources of knowledge for content versus indexes | 22:38 |
| jam | specifically, I'm thinking about making the ancestry accessible from the Content objects rather than the Index | 22:38 |
| jam | does that make sense? or will we always want to have the overall ancestry in the index | 22:38 |
| jam | pff, I just remembered that lifeless is traveling for the next few days | 22:39 |
| jam | :( | 22:39 |
| igc | morning all | 22:40 |
| igc | hi jam | 22:40 |
| beuno | morning igc | 22:41 |
| igc | hi beuno | 22:42 |
| beuno | igc, started packing for the sprint yet? | 22:44 |
| igc | I'm not sure I want to answer that :-) | 22:44 |
| igc | 'just in time' rules :-) | 22:45 |
| beuno | heheh, I started packing 2 hours before leaving to the airport, and so far, I don't think I've forgoten anything | 22:45 |
| abentley | Last time I went to London I forgot my laptop power brick. | 22:46 |
| beuno | aah, laptop and power brick is the only thing I triple-checked. I might of not brought any clothes with me though :p | 22:47 |
| alien | hello, you claim that bzr only needs python at runtime, but it seems it still needs a C compiler if one needs to compile its sources | 22:49 |
| abentley | alien: One doesn't need to compile its sources. | 22:49 |
| beuno | alien, not really, the c bits are only to push performance a bit more, it runs fine on python-only libraries | 22:49 |
| alien | couldn't you provide some kind of backup python code for those modules written in C | 22:49 |
| abentley | They are strictly optional optimizations. | 22:49 |
| abentley | We do in fact provide backup python code. | 22:50 |
| alien | i'm trying to port bzr to minix | 22:50 |
| alien | and it lacks a linker, since its binaries are static | 22:50 |
| alien | the bzr setup is running fine but bzr init explodes | 22:51 |
| spiv | alien: can you pastebin the error? | 22:51 |
| alien | sure | 22:51 |
| alien | http://rafb.net/p/AA29No74.html | 22:52 |
| alien | and here's the compilation error of the C sources: http://rafb.net/p/oRx27w34.html | 22:54 |
| alien | it sais it's using the py version instead | 22:55 |
| alien | but it seems i'm missing pyexpat | 22:56 |
| alien | shouldn't plain python be sufficient? | 22:56 |
| dato | alien: pyexpat.so is supposed to be built along with python itself (if expat is available, that is, of course) | 22:57 |
| spiv | alien: xml.parsers.pyexpat is part of the Python standard library | 23:01 |
| alien | miix lacks an expat port | 23:04 |
| alien | minix* | 23:04 |
| blueyed | lifeless: the /etc-messed-up system now runs again. bzr is a good regression test (in the sense of corner cases) for Ubuntu in the right hands. Just like "find /etc -type l -type -d | xargs /bin/rm" and then trying to get the system running on the next boot again.. ;) | 23:08 |
| blueyed | ...like /dev/null should get right permissions without udev properly setup. | 23:09 |
| blueyed | I think the best thing to do about "bzr revert" is to at least warn in the help text about it. Or get saner in the case of "bzr init; bzr add; bzr revert" - I can't see a reason why the previous commit state would be "empty". | 23:12 |
| mtaylor | statik: around? | 23:39 |
| === jamesh_ is now known as jamesh | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!