abentleyWhy is an upgrade necessary for the commit to succeed?00:01
bignoseabentley: scroll back. the commit is failing with an error about incompatible repository formats.00:02
bignosemy response to that was to attempt an upgrade on both the branch and the repo00:02
abentleyIt's not in my scrollback.00:02
abentleyAll I see is your paste of the upgrade failure.00:03
bignoseabentley: the line immediately following that00:03
bignoseabentley: 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
abentleySo you're committing in a checkout?00:04
bignoseabentley: yes00:04
abentleySo as spiv noted, the command is "upgrade --rich-root-pack"00:06
bignose$ bzr upgrade --rich-root-pack .00:06
bignosebzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.00:06
abentleyIt sounds like your remote branch is the one that needs to be upgraded.00:07
bignosethe checkout branch?00:07
bignoseokay, trying that00:08
abentleyWhat does bzr info . say for the format?00:08
bignosetoo late, I'm upgrading it now :-)00:08
bignoseisn'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
abentleyWell, the rich-root formats can't be converted into the default format.00:11
bignoseso I'm proceeding down a dead end?00:12
abentleyBecause they can't represent everything that the rich-root formats can.00:12
=== blueyed_ is now known as blueyed
abentleySo you can make it so you can commit, which is what you were saying was your immediate priority.00:12
abentleyAnd you can continue using this format for branches that are already in it.00:12
jmlI'm trying to merge from a colleague's branch into my copy of trunk and I get this error:00:13
bignoseyes. I didn't think, though, that the Bazaar developers would have implemented formats that cannot be converted to each other.00:13
abentleyThat's half the point of making new formats.00:13
jmlbzr merge ../other-branch00:13
jmlbzr: ERROR: Tags not supported by BzrBranch5('file:///home/jml/project/trunk/'); you may be able to use bzr upgrade --dirstate-tags00:13
bignoseabentley: the problem is that this is the *entire repository* of all branches that I work on at this site.00:13
abentleyYou're the one who said "too late".00:14
spivI believe the plan is that rich-root support will eventually be in the default format.00:14
abentleyThere's nothing *wrong* with this format, it's just not the default yet.00:14
jmlwhy do I have to upgrade my copy of trunk?00:14
bignoseagain, I didn't think 'bzr upgrade' commands would be leading me down a dead end.00:14
spivIt's not a dead-end.  You're just an early adopter.00:14
bignoseseemed like a reasonable assumption.00:15
abentleyjml: Because we are tag fascists, and you must be assimilated.00:15
jmlabentley: let me rephrase00:15
abentleybignose: Have you looked at the documentation of upgrade?00:15
jmlabentley: I'm not upgrading my trunk branch format00:15
abentley    --rich-root-pack    New in 1.0: Pack-based format with data compatible00:15
abentley                        with rich-root format repositories. Incompatible with00:15
abentley                        bzr < 1.000:15
bignoseI'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
bob2isn't bzrbranch5 dirstate-tags era?00:16
bignosenow, there is of course the caveat to be careful of doing things suggested by people on IRC00:16
abentleybob2: older.00:16
abentleyformat 5 is knit era00:16
bignosebut it's rather astounding to me that soemone would implement a format that cannot be converted *from*.00:17
abentleybignose: That was the whole point of the format.00:17
bignoseYes, 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
abentleyAll it does is allow bazaar to store data that it otherwise couldn't.00:17
spivbignose: the new format was made *because* there was data we want to record that cannot be recorded in earlier formats.00:18
bignosemy concern is that you're saying it can't be converted *from* in future.00:18
abentleybignose: Oh certainly it can be converted from.00:18
spivbignose: aah00:18
bignosespiv: earlier formats? you said above "I believe the plan is that rich-root support will eventually be in the default format."00:18
bignoseso I've now got "rich-root-pack", which can't be converted to "rich-root"00:19
bignosewhich means I won't be able to convert to the future default.00:19
abentleyIt can be converted from rich-root-packs to the formats that support subtrees.00:19
spivbignose: 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
spivbignose: as I said before, it's not a dead end.00:19
bignosespiv: 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
bignosewhy, then, would I not convert to "rich-root" immediately, instead of "rich-root-pack"?00:20
spivbignose: I don't know any reason why you couldn't covert between those.00:21
lifelessrich-root and rich-root-pack share the same *model*. Of the two rich-root-pack is faster.00:21
spivbignose: 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
abentleybignose: rich-root-pack is likely to be the future default, not rich-root.00:22
bignoseabentley: that makes it clearer, and is different to what spiv said.00:23
spivbignose: sorry, I didn't mean to confuse you.00:24
bignosethanks everyone.00:24
abentleybignose: What spiv said was about rich root support, not a particular format.00:24
bignosenew problem:00:24
bignosein trying to upgrade the checkout branch, I seem to have messed up the .bzr directory.00:25
bignoseI've reverted to the .bzr.backup (that is, 'rm -r .bzr && mv .bzr.backup .bzr')00:25
bignosebut still 'bzr info' says "bzr: ERROR: No repository present: "file:///home/bignose/Projects/websites.devel/www.benfinney.id.au/site.ikiwiki/"00:25
abentleyls /home/bignose/Projects/websites.devel/www.benfinney.id.au/site.ikiwiki/.bzr00:26
bignose]$ ls .bzr00:26
bignosebranch  branch-format  branch-lock  checkout  README00:26
abentleycat .bzr/branch/format00:27
bignose$ cat .bzr/branch/format00:27
bignoseBazaar-NG branch format 500:27
abentleyThis looks like a standalone tree whose repository is missing.00:28
abentleyYou actually deleted the .bzr directory, eh?00:28
bignosewell, 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
abentleyI think that has modified it somehow.00:29
bignoseit's not a simple 'mv .bzr .bzr.backup' ?00:29
lifelessits a cp -r00:30
abentleySpecifically, I think that your repository was moved from the old .bzr into the new one as part of the upgrade.00:30
lifelessabentley: err no.00:30
lifelessabentley: .bzr.backup is done by t.copy_tree(.bzr, .bzr.backup)00:30
lifelessabentley: so the old repository doesn't move at all00:30
bignoseokay. at this point I'm ready to blow away this directory and check it out again.00:30
abentleylifeless: Okay, so why wouldn't there be a repository directory?00:30
bignoseshould I do so?00:30
lifelessbignose: hang on a sec please00:31
abentleybignose: if you have significant local changes, I can show you how to retain them.00:31
lifelessbignose: lets get a root cause so we can fix/prevent in future00:31
lifelessbignose: can you do ls -l .bzr00:31
lifelessbignose: and ls -l .bzr.backup00:31
abentleylifeless: he has deleted the .bzr that upgrade produced and moved .bzr.backup to .bzr00:32
bignoselifeless: bear in mind that '.bzr' has been restored from '.bzr.backup'00:32
bignoseso the only thing we'll see in '.bzr' is whatever was put into '.bzr.backup' by the upgrade00:32
lifelessabentley: ah00:33
lifelessbignose: all the same, lets see whats there :)00:33
bignoseokay. paste flood cometh00:33
bignose$ ls -l .bzr00:33
bignosetotal 2000:33
bignosedrwxr-xr-x 3 bignose bignose 4096 2008-02-27 10:40 branch00:33
bignose-rw-r--r-- 1 bignose bignose   35 2008-02-27 10:40 branch-format00:33
bignosedrwxr-xr-x 2 bignose bignose 4096 2008-02-27 10:40 branch-lock00:33
bignosedrwxr-xr-x 3 bignose bignose 4096 2008-02-27 10:40 checkout00:33
bignose-rw-r--r-- 1 bignose bignose   82 2008-02-27 10:40 README00:33
abentleylifeless: tag, you're it.  I need to buy groceries.00:34
bignoseabentley: thanks for your help00:34
lifelessabentley: thanks :)00:34
lifelessbignose: ok; now cat .bzr/branch/format00:34
bignoseBazaar-NG branch format 500:35
lifelessbignose: is there meant to be a shared repository above this one ?00:35
lifelessabove this directory I mean00:35
lifelessthis all looks fine to me00:35
lifelessis it working correctly at this point00:35
* bignose really hopes this doesn't lead to the discovery that the shared repo is gone.00:35
bignoselifeless: no. 'bzr info' complains there's no repository.00:36
lifelesswhere is the repository meant to be?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/.bzr00:37
bignosetotal 1600:37
bignose-rw-r--r-- 1 bignose bignose   35 2006-09-02 09:54 branch-format00:37
bignosedrwxr-xr-x 2 bignose bignose 4096 2006-09-02 09:54 branch-lock00:37
bignose-rw-r--r-- 1 bignose bignose   82 2006-09-02 09:54 README00:37
bignosedrwxr-xr-x 5 bignose bignose 4096 2007-11-14 15:42 repository.backup00:37
lifelessthere is a distinct lack of 'repository' there00:37
lifelessrepository.backup is from november00:38
lifelessnow, there are multiple possible reasons00:38
lifelessone is a catastrophic bzr bug00:38
bignose$ ls -l ~/Projects/.bzr.backup/00:38
bignosetotal 1600:38
bignose-rw-r--r-- 1 bignose bignose   35 2008-02-27 10:45 branch-format00:38
bignosedrwxr-xr-x 2 bignose bignose 4096 2008-02-27 10:45 branch-lock00:38
bignose-rw-r--r-- 1 bignose bignose   82 2008-02-27 10:45 README00:38
bignosedrwxr-xr-x 5 bignose bignose 4096 2008-02-27 10:45 repository00:38
lifelessok yay00:38
lifelessbignose: here is what I think has happened.00:38
lifelessbignose: I'll get you to cat a format file in a second to confirm00:39
lifelesswhat I think is:00:39
lifelessyou are running subtree or rich-root00:39
bignoseif it helps, I previously in this session also ran 'bzr upgrade --rich-root-pack ~/Projects/'00:39
lifelessand you tried to upgrade the repository to something with less data00:39
lifelessthe upgrade failed; leaving the backup intact but the repo borked.00:39
bignosewhich gave "bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format."00:39
lifelessbignose: can you cat the repository/format file from the projects repository backup00:40
bignosewhich directory? '~/Projects/.bzr/repository.backup/format' or '~/Projects/.bzr.backup/repository/format' ?00:41
bignoseor something else?00:41
bignose$ cat .bzr.backup/repository/format00:41
bignoseBazaar Knit Repository Format 3 (bzr 0.15)00:41
lifelessbignose: ok, I'm correct.00:42
lifelessbignose: I will file a bug in a minute.00:42
bignosegood to know :-)00:42
lifelessbignose: now, here is the cause:00:42
lifelesswe have three discreet data models00:43
lifelesscall them 'plain', 'rich root', 'subtrees'00:43
lifelessthey are ordered: plain<rich-root<subtrees00:43
lifelesscommits 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
lifelesslikewise rich-root commits can be upgraded to subtrees but not downgraded.00:44
lifelesswhat 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
lifelessso -00:45
lifelessreinstate your repository by discarding ~/Projects/.bzr and mv ~/Projects/.bzr{.backup,}00:45
lifelessand now upgrade it to pack-0.92-subtree00:45
lifelessall the trouble with the checkout was pure confusion due to the shared repository being awol00:46
bignosealright. but all this started *before* I attempted the upgrade, with a commit that failed because of format incompatibilities.00:46
bignoseso I'll have to try that again and make sure there isn't more upgrading to be done.00:47
lifelessget this upgrade done00:47
lifelessand I'll predict what the problem was00:47
bignoseso, what upgrade do I need to do now that I've restored the backup shared repository?00:47
lifelessbzr upgrade --pack-0.92-subtree ~/Projects/'00:47
lifelessI predict you have a heavyweight(the default) checkout of a project in a 'plain' repository00:48
bignosedoing now00:48
lifelessYour local data has been upgraded to subtrees00:48
lifelessand the commit is failing because your local commit can't be represented in that other repository.00:48
bignoseokay. so 'bzr upgrade --rich-root-pack ~/Projects/' was a mistake?00:49
bignoseargh. please cluebat the appropriate people in this channel then, for suggesting that I do that00:49
lifelessnext week we're planning how to change our defaults00:50
lifelessto remove all this pain as quickly as possible00:50
bignoseokay, the shared repo is upgraded00:50
bignoseI will now attempt the commit again on the checkout branch00:50
lifelessit will fail00:50
lifelessbecause the problem is not your local data, its the remote data00:50
lifelessin that the remote data is in a plain format (or -rich-root) and yours is in subtree00:51
bignosePermission denied: ".bzr/repository/upload/crezvop7l0z8hop1rxvb.pack": [Errno 13] Permission denied00:51
bignoseokay. so what needs to happen next?00:52
lifelessthats an interesting error00:52
lifelessthats after the upgrade finished?00:52
bignoseokay, probably time for a quick roundup of what format everything is at00:52
bignosecheckout branch: Bazaar-NG branch format 500:54
bignoselocal shared repository: Bazaar pack repository format 1 with subtree support (needs bzr 0.92)00:54
bignoseremote central branch: Bazaar-NG branch format 500:55
bignoseremote shared repository: Bazaar pack repository format 1 with rich root (needs bzr 1.0)00:55
lifelessbignose: yup, its clear there :)00:55
lifelessbignose: the original problem was:00:56
lifelesslocal repo: subtree00:56
lifelessremote repo: rich-root00:56
bignoseall done by 'cat ./bzr/{branch,repository}/format' as appropriate.00:56
lifelessthe use of knits/packs/etc is orthogonal to the model of data being stored.00:56
bignoseso what's next? upgrade the remote repository?00:56
bignosewith 'bzr upgrade --pack-0.92-subtree' ?00:57
lifelessif 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 that00:57
bignosewell, I have write permission on the remote shared repository. is there a reason I shouldn't upgrade it to that format?00:57
lifelessall your other devs will get errors updating when you upgrade the central repository though; because across model boundaries you cannot do bidirectional push-pull00:58
bignosealso, didn't you just take me through the necessity of *not* having the local shared repository as rich-root?00:58
lifelessyes, remember the relationship of the models:00:58
lifelessfor whatever reason your _existing_ repository was at subtree00:58
bignoselocal repository?00:59
* jdong gives jelmer a big hug00:59
lifeless*you* can't go down from here for your existing projects00:59
lifelessexisting local repository yes.00:59
jdongthanks for bzr-svn goodness :)00:59
bignoselifeless: okay. so if I upgrade the central (remote) shared repository, everyone else needs to upgrade their own repositories for all checkouts?01:00
bignoselifeless: any other downsides? i.e. will I regret doing this in six months?01:00
lifelessyes, and if you have multiple projects in each repository, and there are other places you are collaborating with, this will propogate01:00
lifelessWe will be changing our default format to be rich root, and then subtrees, in the 'near' future.01:01
bignosewhat about just branching from these repositories?01:01
bignosewill those also need to be at the same format?01:01
lifelessyes - 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
lifelessbignose: the easiest option for you is to use a separate repository for this tree on your local disk01:02
bignosecan't I just downgrade to "rich-root" and *discard* the extra information that can't be represented in the rich-root format?01:02
lifelessbignose: e.g. bzr init-repo --rich-root-pack ~/Projects/Foo && bzr checkout REMOTEURL ~/Projects/Foo/bar01:03
lifelessbignose: that will make anything in Foo be rich-root only and commits will work fine01:03
lifelessbignose: 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 information01:04
spiv(I suppose this could almost be a use case for rebase...)01:04
lifelessspiv: tag you're it.01:05
lifelessspiv: I have a plane to catch.01:05
spivlifeless: ok.01:05
lifelesstwo bugs files01:05
spivlifeless: thanks01:05
lifelessbignose: I *hope* its clearer now.01:05
bignoseI'll have to attack this another day, I'm way late.01:05
bignoselifeless: it's more complicated :-)01:05
bignoselifeless: but thanks for the help01:05
lifelessbignose: 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
bignosetalk with you all later01:06
ubotuNew bug: #195970 in bzr "bzr upgrade --rich-root-pack fails badly when upgrading subtreerepositories" [Undecided,New] https://launchpad.net/bugs/19597001:06
ubotuNew bug: #195971 in bzr "checkout silently upgrades repo data" [Undecided,New] https://launchpad.net/bugs/19597101:06
spivubotu: nice timing01:06
ubotuSorry, I don't know anything about nice timing - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi01:06
spivlifeless: have a good trip01:06
jelmerspiv: yes, they can be represented in a rich-root repo correctly01:08
jelmerideally we should be able to support downgrading from subtree to rich-root if there are no nested tree revisions in the repo01:08
spivjelmer: 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
spivjelmer: snap :)01:09
spivHmm, 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
abentleyspiv: That does work AIUI01:16
abentleyBut 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
lifelessabentley: the model check fails01:23
lifelessabentley: bzr won't do it.01:23
=== abentle1 is now known as abentley
bob2lifeless: is pack-0.92-subtree an alias for development-subtree?01:27
lifelessbob2: no01:27
lifelessbob2: the development formats are compatible with but have their own disk signatures.01:27
bob2"bzr help formats" needs an updatin'01:28
abentleybob2: What needs to change?01:29
abentleylifeless: Actually, I'd prefer if development-subtree were hidden.01:32
bob2abentley: pack-0.9.2-subtree isn't mentioned in upgrade --help or help formats01:33
abentleybob2: That is emphatically deliberate.01:37
abentleyNo one should be using it, except people implementing nested tree support.01:37
mwhudsondid repository.get_revision(NULL_REVISION) ever work?01:44
lifelessmwhudson: no01:48
mwhudsoni wonder how loggerhead ever worked with empty branches then01:49
mwhudsonho ho ho02:11
lifelessits xmas?02:11
mwhudsonthis seems surprising: http://paste.ubuntu-nl.org/57545/02:12
lifelessmwhudson: well, its not that friendly true, but I don't think we expect people to use the attributes for flow control02:14
lifelessdon't use the attributes for flow control, kthxbye02:14
mwhudsonso what loggerhead does, which is probably totally dumb02:14
mwhudsonis it goes02:14
mwhudsonrevs = bzrlib.get_revisions(long list of revids)02:14
lifelesswhich can raise02:15
mwhudsoncatches NoSuchRevision, throws e.revision out of the list and tries again02:15
lifelessthats dumb02:15
lifelessdo this02:15
lifelessparents = repository.get_graph().get_parents(revids)02:15
lifelessmissing = rev_ids - set(parents.keys())02:15
mwhudsonso given that i don't actually care about what's in the missing set02:17
lifelessmwhudson: well, you get the point, kthxcode02:18
* igc lunch02:22
mwhudsonlifeless: http://paste.ubuntu-nl.org/57546/02:22
mwhudsonlooks like a typo ...02:22
lifelessmwhudson: get_parents_map02:22
lifelessmy bad02:23
mwhudsonthat's a pretty aggressive deprecation though :)02:23
lifelessmwhudson: its meant to work, I think that is indeed a typo, but anyhow03:04
ubotuNew bug: #196002 in bzr-svn "lack of bzr 1.2 support" [Undecided,New] https://launchpad.net/bugs/19600204:25
jmlI'm not really sure what to type for my message when I say "bzr record"05:01
jameshjml: you could say what music you are listening to at the time05:04
jmlI hate it when people do that.05:05
jmlin commit messages, that is.05:05
jameshjml: they should really use revision properties, yes.05:05
jmlheh heh05:05
jameshmaybe we need hooks to let plugins add revision properties05:05
jmljamesh: they already can05:06
PengOne file in Mozilla's CVS has been committed with each message a line from a poem or whatever... :)05:06
jmljamesh: it's just that cmd_commit is ugly05:06
jmlor maybe I'm on crack05:06
jameshjml: I was referring to the actual bzrlib hooks feature05:07
jameshnot something that requires replacing cmd_commit, and only letting one plugin do stuff05:10
jmllifeless: how do I break a thread out into a separate branch?05:21
jmlbzr branch -r thread:foo loomed-branch foo-branch doesn't seem to do what I expect05:22
spivjml: you could always use the revid05:23
jmlspiv: how would I calculate the appropriate revid05:24
spivjml: "bzr revision-info" while in the desired thread05:24
spivjml: (or peek in the .bzr/branch/last-loom file)05:25
spivjml: It would be good if "bzr branch -r thread:foo ..." worked, though.05:25
jmlnope, that didn't work either05:26
jmlmaybe I have been allowed to do something stupid05:26
jmlthis is going to make it difficult to land this branch.05:29
spivjml: 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
jmlspiv: yes, I mean that.05:30
jmlexcept I also want to imply that your sedding is ridiculous.05:30
jmltbh, I was a little surprised that having the thread selected wasn't enough05:31
spivjml: that method works for me05:32
spivjml: in what way is it not working for you?  An error, or branching the wrong revision, or...?05:33
jmlspiv: the whole branch is being branched05:33
jmlall of the changes in the threads *above* the thread I want are being pulled in.05:34
spivYou mean as a loom?05:34
spiv("the whole branch is being branched" sounds like a *good* thing...)05:34
jmlspiv: my original question was "how do I break a thread out into a separate branch?"05:35
jameshjml: try this: 1. "bzr init" a new branch in non-loom format, 2. pull or push the desired thread into that new branch05:36
spivSo "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
jmlspiv: they aren't equal, no.05:36
spivjml: so, for me, the commands I gave give me the same revision-info (and appropriate log) on both sides.05:37
spivjml: (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
jmlI don't really care about the format.05:37
spivjml: I'd be interested to hear how jamesh's instructions work for you05:37
jmlspiv: so all I need is for you to come over and explode the branch for me :)05:38
jameshjudging by the README in bzr-loom, those instructions should do it05:38
spivjml: but I also don't know why my method isn't working for you.05:38
jmljamesh: that works05:40
Pengjelmer: bzr-svn's setup.py uses python2.4. Why not 'python'?06:13
spivPeng: 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
Pengspiv: True. (I partially do it because I've run into setup.py files not being executable.)06:18
Pengspiv: I ran into it because I ran "make" and that runs "./setup.py".06:18
Pengs/not being/that aren't/06:18
jmldoes combine-thread lose changes?06:42
spivjml: I wouldn't expect it to... you mean uncommitted changes?06:42
jmlspiv: I mean committed changes.06:43
jmloh well, it's too late now.06:43
spivjml: well, you can always get those back with the heads plugin06:43
spivjml: although it's probably a bug if combine-thread lets you lose changes.06:43
spivjml: (Also, if you had recorded the loom before the combine-thread, you could also recover that way)06:44
jmlI had06:44
spivjml: the "bzr heads" command will show you all the "heads" of the revision graph your repo06:45
spivjml: 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
jmlspiv: ah, ok. it's not showing, so maybe I hadn't committed these changes06:46
spivjml: 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
spivjml: 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
jmllet's see!06:48
PengOf course my ConfigObj change finally gets merged right after I notice an error in it.07:53
spivPeng: d'oh08:07
=== doko_ is now known as doko
ubotuNew bug: #196043 in bzr "Crash in bzr-svn trying to brancy python trunk" [Undecided,New] https://launchpad.net/bugs/19604308:15
AfCWell the least I can do is fix the description of that bug.08:18
PengI just got that too on another project.08:20
PengI converted it with hg instead. :P08:20
PengWell, with bzr-svn, it barfed on one of the tags. Hg just didn't import any tags...08:21
PengTotally throwaway conversion anyway.08:21
* igc dinner08:57
lukshm, does somebody know if launchpad uses shared repositories for mirrored branches?09:34
spivluks: no, it doesn't.09:35
spivluks: all the branches on launchpad at the moment are standalone.09:35
spivluks: why do you want to know?09:36
luksok, thanks09:36
lukswell, it I tell it to mirror N branches of the same product, using a shared repository would save bandwidth on both sides09:37
spivluks: yeah, that's true.09:40
spivluks: there is work underway to improve this.09:40
awilkinsEven 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
luksnot bandwidth savings, only disk space09:49
luksLP will still download them one by one with full history09:50
awilkinsShould 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 him09:53
luksthat's what shared repositories are for :)09:53
luksif the revision data are not shared, it doesn't know which revisions it already has09:54
awilkinsYes, 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
luksah, you mean the other way around09:55
awilkinsSo it could get away with getting a revision list from the server and only downloading stuff it's missing?09:55
luksyes, in that case it will download only the revision it needs09:55
awilkinsAh, aI am reassured09:55
unenoughhow do i create a copy of an old revision of a file?09:56
awilkinsI thought it could, with all the HTTP range downloading stuff in there09:56
awilkinsunenough: bzr cat -r <rev> path/to/old/file > myoldfile09:56
unenoughawilkins, thanks.09:56
spivunenough: or "bzr revert -r REV path/to/file"10:06
unenoughi didn't want to revert, just view it10:07
unenoughcat is good10:07
unenoughbut thanks10:07
quicksilverbzr cat is awesome :)10:16
=== johnny is now known as vagrantc_
=== vagrantc_ is now known as johnny
ubotuNew bug: #196080 in bzr "`bzr info -v bzr://host/branch` hides actual branch/repo format" [Undecided,New] https://launchpad.net/bugs/19608011:00
ubotuNew bug: #196082 in bzr-loom "checkout of loom produce regular branch" [Undecided,New] https://launchpad.net/bugs/19608211:05
=== mrevell is now known as mrevell-lunch
=== _arne^ is now known as arne^
awilkinsIs Guillermo Gonzalez here?14:18
awilkinsOr anyone else who cares about bzr-eclipse?14:19
=== jelmer_ is now known as jelmer
=== mrevell-lunch is now known as mrevell
Lo-lan-doHi all14:24
Lo-lan-doAny plans to update bzr-svn in Debian sid?  It prevents upgrading to bzr 1.2...14:25
jelmerI hope to release 0.4.8 this weekend14:25
Lo-lan-doYay :-)14:26
Lo-lan-doAnother 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
lamontgiven a commit, how do I tell bzr to tell me what files were changed in that commit?14:47
luksbzr st -r X14:51
lukser, no14:52
luksbzr st -c X14:52
lukswhich is an equivalent for bzr st -r (X-1)..X14:53
jelmerLo-lan-do: what version of bzr-svn are you using?14:56
jelmerLo-lan-do: Theoretically a lot of it can be fixed14:56
fbondHi, I really want to be able to "bzr update -r xxx" in a checkout; what am I really looking for?15:49
fbondI want to be able to "rewind" my checkout (not just the working copy).15:50
fbondI know I could make a new checkout, but it seems like this should be easier...15:50
jelmerfbond: there's no way to do that at the moment16:00
jelmerafaik there are several bug reports open a bout supporting -r for bzr upgrade16:00
fbondjelmer: second time you've helped me today, thanks!16:09
jdongjelmer: why is "bzr missing" so significantly more costly than "bzr pull" for bzr-svn?16:15
jelmerit uses a different (not yet optimized) code path16:15
jdongah, ok16:15
jelmerpull is a lot more common so I've spent more time optimizing16:16
jdongjelmer: are there any better ways of looking for new upstream commits rather than pulling into a branch?16:16
jelmer"bzr missing" :-)16:17
jdongjelmer: do you know if any DVCS svn converters like bzr-svn work well with gigantic history svn repos?16:19
jdongI'd like to follow a specific branch of KDE's anonsvn and don't feel like dealing with a few million revision history16:19
jelmergit-svn probably although I don't have experience with it16:19
jelmerIf you're just interested in following upstream you may want to wait until after the bzr sprint16:20
jelmerwith a bit of luck we'll be have shallow branches support then16:20
Lo-lan-doSweet indeed :-)16:21
jdongjelmer: 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
jelmerjdong: What do you mean with subtrees exactly? svn:externals?16:23
jdongjelmer: like a subdirectory of a svn repo16:23
jelmerjdong: Yes, it can do that but the size and number of files in the repository still matter at the moment.16:24
jdongjelmer: so would it still be prohibitively expensive, in your opinion, to bzr branch a single app's dir from anonsvn.kde.org?16:24
jdongthe entire repo has a bazillion revs but I doubt more than 1000 pertain to ktorrent itself16:24
PengShould I kill svn-import when it hasn't done anything but slightly fluctuate its RAM usage for 6 hours?16:25
jelmerjdong: caching those revs the first time will be pretty expensive16:25
jelmerjdong: After that, all KDE-repository-related operations should be pretty quick16:25
jelmerjdong: s/Caching the revs/caching the revs' metadata/16:25
jelmerPeng: Depends on the size of the repository16:25
jdongjelmer: sounds painful...16:25
jelmerPeng: It does support resuming16:26
jdongjelmer: does the svn-cache take a lot of disk space?16:26
Pengjelmer: 60k revisions?16:26
jelmerPeng: Could be. I should show a progress bar though.16:27
abentleyPeng: When you generate new merge directives, please generate them against a fresh copy of trunk.16:27
jelmerjdong: yes, although I'm not sure how much that would be for KDE16:27
abentleyThat way the diff shows the changes that aren't already in trunk.16:28
jelmerjdong: For samba (26k revs) it's 50 Mb16:28
luksI remember mine for the KDE SVN beeing around 2GB :/16:28
jelmerluks: it should be smaller now than what it used to be16:28
jdongluks: ouch16:28
Pengabentley: Yeah. I only pulled and noticed that it had been merged right after sending that patch.16:28
PengIf I noticed it had been merged, I would've been more apologetic. :16:30
abentleyPeng: Submitting your latest.16:41
PengThank you. Sorry.16:42
mvolifeless: do you have a sponsor for bzr-loom yet?17:46
=== blueyed_ is now known as blueyed
Qhestioncan a plugin store metadata in branches, or do i have to use normal (versioned) files?19:35
mwhudsondoes someone want to merge http://bundlebuggy.aaronbentley.com/request/%3C47C4A6D2.7080508%40canonical.com%3E ?19:58
mwhudson-or- remind my how to use bzr-svn20:18
mwhudsonoh, it helps if you get the url right20:19
mwhudsonoh, wow, there's already a lp import of the branch i wanted20:28
Verterokawilkins: ping (I'm Guillermo)20:32
abentleymwhudson: bialix was the last reviewer, so he should have merged it.20:42
mwhudsonoh, ok20:42
* mwhudson is pleased with his 10 minute hack of pyflakes to understand lazy imports...20:42
mtaylorbzr: 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
mtaylorI know what the problem is... I'm just complaining20:45
mtaylorjelmer: looking for bzr svn-import advice...21:05
mtaylorjelmer: http://svn.debian.org/viewsvn/python-modules/21:05
mtaylorhas a packages dir, underwhich are a dir for each project, each have possible a trunk and some branches...21:06
mtaylorjelmer: should I just svn-import the whole thing and then ignore the branches I don't care about?21:06
mtaylorso that the meta-data is all right?21:06
PengOh my god.21:21
PengThere's a new version of ConfigObj out!21:21
fullermdTiming is everything.21:22
mtaylorspeaking of versions and timing...21:28
mtaylorbzr-svn for gutsy in the ppa is not compatible with bzr for gutsy in the ppa21:29
* mtaylor votes that bzr-svn be considered part of the release... 21:29
PengThe new ConfigObj has no changes to configobj.py, just docs and validate.21:34
PengAnd the license is now executable.21:34
=== michelp_ is now known as michelp
bob2mtaylor: did you get that error doing a co of an originally svn branch?21:52
mtaylorbob2: yeah, into an init-repo'd dir that I just let init-repo to the default22:03
mtaylorbob2: it worked fine if I did init-repo --rich-root-pack instead22:03
bob2mtaylor: ah, right, that's the workaround22:03
* mtaylor votes that rich-root-pack become the default22:06
* mtaylor votes again that bzr not be released to the ppa without corresponding bzr-svn packages too22:07
* mtaylor votes himself a free lunch22:07
* bignose concurs. mtaylor is now a free lunch.22:12
fullermdAnd me without my skewers today   :(22:13
=== mtaylor is now known as a_free_lunch
=== a_free_lunch is now known as mtaylor
jamlifeless: ping, question about redefining some of the sources of knowledge for content versus indexes22:38
jamspecifically, I'm thinking about making the ancestry accessible from the Content objects rather than the Index22:38
jamdoes that make sense? or will we always want to have the overall ancestry in the index22:38
jampff, I just remembered that lifeless is traveling for the next few days22:39
igcmorning all22:40
igchi jam22:40
beunomorning igc22:41
igchi beuno22:42
beunoigc, started packing for the sprint yet?22:44
igcI'm not sure I want to answer that :-)22:44
igc'just in time' rules :-)22:45
beunoheheh, I started packing 2 hours before leaving to the airport, and so far, I don't think I've forgoten anything22:45
abentleyLast time I went to London I forgot my laptop power brick.22:46
beunoaah, laptop and power brick is the only thing I triple-checked. I might of not brought any clothes with me though  :p22:47
alienhello, you claim that bzr only needs python at runtime, but it seems it still needs a C compiler if one needs to compile its sources22:49
abentleyalien: One doesn't need to compile its sources.22:49
beunoalien, not really, the c bits are only to push performance a bit more, it runs fine on python-only libraries22:49
aliencouldn't you provide some kind of backup python code for those modules written in C22:49
abentleyThey are strictly optional optimizations.22:49
abentleyWe do in fact provide backup python code.22:50
alieni'm trying to port bzr to minix22:50
alienand it lacks a linker, since its binaries are static22:50
alienthe bzr setup is running fine but bzr init explodes22:51
spivalien: can you pastebin the error?22:51
alienand here's the compilation error of the C sources: http://rafb.net/p/oRx27w34.html22:54
alienit sais it's using the py version instead22:55
alienbut it seems i'm missing pyexpat22:56
alienshouldn't plain python be sufficient?22:56
datoalien: pyexpat.so is supposed to be built along with python itself (if expat is available, that is, of course)22:57
spivalien: xml.parsers.pyexpat is part of the Python standard library23:01
alienmiix lacks an expat port23:04
blueyedlifeless: 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
blueyedI 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
mtaylorstatik: around?23:39
=== jamesh_ is now known as jamesh

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!