| awmcclain | poolie: Ahhh... that's it. I merged to trunk, found a significant bug, shelved the barnch for a while. I must not have reverted that merge in trunk. | 00:01 |
|---|---|---|
| awmcclain | Oh, what a headache. | 00:01 |
| poolie | awmcclain: so um | 00:03 |
| poolie | try doing something like this: | 00:03 |
| poolie | run log on the feature branch, to find the revisions with changes you want to keep | 00:03 |
| poolie | then do a cherrypick merge of them into trunk | 00:03 |
| poolie | this should bring the files back into existance | 00:03 |
| awmcclain | then merge back into feature branch? | 00:04 |
| awmcclain | Or, what if I create a new feature branch, and just cherrypick merge from my old branch into that? | 00:04 |
| poolie | spiv: alive? | 00:05 |
| poolie | spiv: did you already fix a dupe of bug 356699 perhaps? | 00:05 |
| ubottu | Launchpad bug 356699 in bzr "not stacking when source branch doesn't support stacking, even though it states it will do" [Undecided,New] https://launchpad.net/bugs/356699 | 00:05 |
| poolie | awmcclain: oh sorry you're trying to merge trunk in, i see | 00:06 |
| poolie | how about | 00:06 |
| poolie | merge trunk, then do | 00:06 |
| poolie | 'bzr merge -r 10..20 .' | 00:06 |
| poolie | ie replay those changes from this branch | 00:06 |
| awmcclain | oh, smart. | 00:06 |
| awmcclain | where 10 is the feature revision where trunk and feature diverge, and 20 is the feature revision just before i merge trunk back in | 00:07 |
| kenichi_ | hello, a dev here just committed a change to a branch, somehow it included a remove and add of the same file, even though his 'bzr st' and 'bzr diff' before commit didn't show this change, and he claims he didn't touch that file. | 00:10 |
| kenichi_ | now a checkout of that branch fails with "bzr: ERROR: Revision {.......} not present in "....." | 00:11 |
| poolie | kenichi_: using plain bzr or bzr-svn? | 00:11 |
| kenichi_ | i didn't set up this branch, but i believe the trunk it came from was initially set up with bzr-svn | 00:12 |
| spiv | poolie: I'm alive, I don't remember fixing that bug, although anything is possible... | 00:19 |
| * spiv quickly checks the recent changes | 00:19 | |
| poolie | it just sounded like something you changed | 00:21 |
| spiv | lifeless has touched that code recently as part of cutting out more roundtrips from push. | 00:22 |
| kenichi_ | poolie: does bzr-svn cause this? is there somewhere you could point me to read up on issues like this? | 00:22 |
| spiv | He may have accidentally fixed that at the same time, I'm not sure. | 00:23 |
| poolie | kenichi_: i've seen some bug reports similar to this, i don't know specifically what's happening sorry | 00:23 |
| poolie | jelmer might, or you can ask on the bazaar list | 00:23 |
| kenichi_ | ok, thanks | 00:23 |
| jelmer | kenichi_: what's the bug # exactly? | 00:27 |
| kenichi_ | jelmer: i haven't filed a bug report, just the abridged paste above. | 00:28 |
| jelmer | kenichi_: It's hard to say anything specifically related to the error class, can you perhaps pastebin the traceback? | 00:29 |
| kenichi_ | jelmer: i'm not actually getting a traceback, just the error, and a non-working checkout. is there a arg i can pass to get more info? (tried -v) | 00:32 |
| kenichi_ | jelmer: here's as much info as i have to give http://pastebin.com/d176d4a49 | 00:38 |
| lifeless | poolie: we have bugs remaining in autostacking | 00:48 |
| lifeless | poolie: its possible I fixed the most recently opened one, but I haven't explicitly checked | 00:49 |
| lifeless | spiv: how goes the ghost inventory tests? | 01:13 |
| igc | morning all | 01:21 |
| AmanicA | morning | 01:24 |
| lifeless | hi igc | 01:26 |
| igc | hi lifeless | 01:27 |
| vxnick | hi guys - is there any way I can remove a "pending merge", as it's not showing up in my repository viewer for some reason :S | 01:28 |
| lifeless | vxnick: bzr revert | 01:28 |
| lifeless | vxnick: a pending merge is one that has been done to your working tree but not committed to the repository | 01:28 |
| vxnick | lifeless: I see, thanks | 01:28 |
| vxnick | lifeless: any way I can "undo" that revert? I didn't realise it'd remove everything I've just done :) | 01:29 |
| lifeless | vxnick: uhm heh. It will have backed up to files with ~ in their name anything you had edited | 01:30 |
| igc | poolie: fyi, my top tasks today are admin-related: hr, expenses, etc. I'll then try to get an email out re branch specific rules status & options going forward | 01:30 |
| poolie | igc, thanks | 01:30 |
| poolie | thanks for the user documentation | 01:30 |
| lifeless | vxnick: things changed by the merge that you had not edited are recoverable by repeating the merge | 01:30 |
| poolie | mine are too, specifically expenses, report and reviews | 01:30 |
| vxnick | lifeless: sorry to bother you - how can I merge these back? | 01:31 |
| lifeless | vxnick: can you rephrase, I don't quite follow the question | 01:32 |
| vxnick | lifeless: well, I've reverted as you suggested - I see the ~ files; how do I put my changes back into the main files? Not sure how else to explain it I'm afraid | 01:32 |
| lifeless | vxnick: first, repeat the merge | 01:33 |
| vxnick | lifeless: bzr merge? | 01:33 |
| lifeless | yeah, however you did it before | 01:33 |
| vxnick | lifeless: well I didn't do it specifically last time; it just kinda happened :P | 01:34 |
| vxnick | I'll give it a go | 01:34 |
| vxnick | argh | 01:35 |
| lifeless | ok, so once you've got the merge done, you can copy the ~ files back over | 01:35 |
| vxnick | no idea | 01:35 |
| lifeless | ok | 01:35 |
| lifeless | what commands had you run leading up to this | 01:35 |
| vxnick | right - initially I made a single-file commit; I then went on to work on some other files, and committed those as a newer revision. This stated that it would merge r127 (the single commit) into r128 | 01:36 |
| vxnick | the problem then being that r127 doesn't show up in my repo viewer | 01:36 |
| vxnick | so I have since uncommited back to r126 | 01:36 |
| vxnick | then reverted as you suggested | 01:36 |
| lifeless | interesting | 01:37 |
| vxnick | in a bad way? :P | 01:37 |
| lifeless | I'm trying to imagine why you would get told a merge is happening when you haven't apparently being doing merges | 01:38 |
| lifeless | is this a checkout of a branch other people commit to as well? | 01:38 |
| vxnick | I'm using bzr as a centralised system in this case | 01:38 |
| vxnick | just myself | 01:38 |
| vxnick | it made me bzr update before I could commit r127 (the single file) | 01:38 |
| lifeless | ok! | 01:38 |
| lifeless | bzr update is a form of merge | 01:38 |
| vxnick | I see | 01:38 |
| lifeless | ok | 01:39 |
| lifeless | now, 127 is probably 126.1.1 now, because of the merge | 01:39 |
| lifeless | but because you uncommitted its all rather invisible | 01:39 |
| vxnick | right | 01:39 |
| lifeless | have you got bzrtools installed? there is a command in there 'bzr heads' that may be useful | 01:39 |
| vxnick | I believe so - I'll run it... | 01:40 |
| lifeless | bzr heads --dead | 01:40 |
| vxnick | just going to install it | 01:40 |
| vxnick | I appreciate your help btw :) | 01:40 |
| lifeless | anytime | 01:40 |
| vxnick | bah bzrtools isn't working for me | 01:43 |
| vxnick | probably because it's not compatible bzr 1.5 by the looks of it | 01:45 |
| lifeless | you'd need bzrtools 1.5 | 01:45 |
| vxnick | ah yes, just trying it | 01:45 |
| vxnick | lifeless: unknown command "head" | 01:47 |
| lifeless | heads | 01:47 |
| lifeless | its a plural ;) | 01:47 |
| vxnick | returns nothing | 01:47 |
| lifeless | bzr heads --dead ? | 01:47 |
| vxnick | yeah a load of stuff | 01:47 |
| vxnick | anything in particular I'm looking for? | 01:47 |
| lifeless | well, it will let us undo the uncommit, if you want to | 01:48 |
| lifeless | I'm not quite sure what the best way out of this is | 01:48 |
| vxnick | hmm | 01:48 |
| lifeless | anything you have committed is recoverable | 01:48 |
| vxnick | so a revert only affects my working copy, not the repo? | 01:49 |
| lifeless | and the backup files will contain any edits you'd made and not committed | 01:49 |
| lifeless | right | 01:49 |
| igc | poolie: if you get a chance, I'd like you feedback on the user doc as well, though that can wait til early next week | 01:49 |
| vxnick | so if I wanted to, I could delete my working copy and do a fresh checkout? | 01:49 |
| lifeless | a revert puts your local tree back to the state of the branch | 01:49 |
| lifeless | it gets rid of edits and of pending merges | 01:49 |
| vxnick | I see | 01:49 |
| vxnick | not quite sure where to go from here to be honest | 01:50 |
| lifeless | so, whats your current state? if I understand correctly you have | 01:51 |
| lifeless | - some stuff you uncommitted | 01:51 |
| lifeless | - some stuff we reverted | 01:51 |
| lifeless | what would you like to have? | 01:51 |
| vxnick | ultimately, I'd like to separate this merged r127 so I can commit it seperate to r128; but short-term I'd like to get back to where I was, which was without reverting :P | 01:52 |
| vxnick | before reverting, even | 01:52 |
| lifeless | so before reverting you had the content of the thing you'd uncommitted | 01:52 |
| vxnick | let me just have a quick scroll up | 01:52 |
| lifeless | I'm just gonig to reboot; I'll be back in a few minutes | 01:54 |
| AmanicA | I keep on getting the following with bzr.dev (even after trying make clean; make and I don't see old bzrlibs lying around in my pythonpath) | 01:54 |
| AmanicA | bzr: ERROR: The API for "<module 'bzrlib' from '/stuph/projects/bzr/bzr.repo/bzr.dev/bzrlib/__init__.pyc'>" is not compatible with "(1, 14, 0)". It supports versions "(1, 15, 0)" to "(1, 15, 0)". | 01:54 |
| vxnick | lifeless: thanks for letting me know | 01:54 |
| AmanicA | (andrew) Bump api_minimum_version to 0.15.0 because of the removal of | 02:01 |
| AmanicA | InstallFailed. | 02:01 |
| AmanicA | ^^^ that seems to be the culprit (pqm@pqm.ubuntu.com-20090504033314-7mfh3y311028dk2m) | 02:01 |
| lifeless | back | 02:03 |
| vxnick | hi | 02:03 |
| vxnick | right, I've checked my history | 02:03 |
| vxnick | I uncommitted 128 and 127, so I'm currently at 126 | 02:04 |
| lifeless | ok | 02:04 |
| lifeless | you should be able to just 'bzrpull -r revid:<whatever128was> .' | 02:04 |
| vxnick | and all my changed files are at r126 | 02:04 |
| vxnick | I'll give that a try | 02:04 |
| lifeless | (and bzr heads can give you the revid for what you had at 128) | 02:05 |
| vxnick | it doesn't unfrotunately | 02:05 |
| vxnick | heads --dead doesn't anyway | 02:05 |
| lifeless | thats odd | 02:05 |
| lifeless | well it will be in your ~/.bzr.log | 02:05 |
| vxnick | can I grep for 128 in that log? | 02:06 |
| vxnick | it's pretty packed | 02:06 |
| lifeless | yah | 02:06 |
| lifeless | or at least less, then /128 | 02:06 |
| lifeless | you're looking for a revid, which looks like email-date-random | 02:07 |
| vxnick | righto | 02:07 |
| vxnick | I've grep'ed for 20090508 and have one result, which I'm presuming is 128 | 02:08 |
| AmanicA | anyways, I'm surprised that nobody else is getting that problem, must be on my setup then. have to sleep now. goodnight. | 02:08 |
| lifeless | AmanicA: are you running nightlies? | 02:08 |
| AmanicA | :) | 02:08 |
| AmanicA | 3am | 02:09 |
| lifeless | AmanicA: if you're running bzr.dev or a nightly package, you will get skew like this from time to time | 02:09 |
| AmanicA | not sure what nighties are | 02:09 |
| AmanicA | ah | 02:09 |
| AmanicA | no bzr.dev | 02:09 |
| lifeless | it means a plugin (e.g. bzrtools, or bzr-svn) hasn't updated. | 02:09 |
| AmanicA | ok thx. I thought so but it seemed to be in __init__.pyc so I thought it a core issue | 02:10 |
| vxnick | lifeless: is the revid the full me@domain-datetime-random string? | 02:10 |
| vxnick | or just part of it | 02:10 |
| lifeless | the full thing | 02:10 |
| vxnick | thanks | 02:10 |
| lifeless | to give it to the ui, prefix it with revid: | 02:10 |
| vxnick | trying now | 02:11 |
| lifeless | AmanicA: __init__ has 1,15,0, whatever is asking is asking for 1,14,0 | 02:11 |
| AmanicA | but that may just be wher bzr complains | 02:11 |
| vxnick | lifeless: do I need the < > around it? | 02:11 |
| AmanicA | ok thx | 02:11 |
| lifeless | vxnick: no | 02:11 |
| lifeless | for instances, revid:pqm@pqm.ubuntu.com-20090504033314-7mfh3y311028dk2m | 02:12 |
| vxnick | bah, gotta install bzrpull too by the looks of it :) | 02:12 |
| lifeless | vxnick: 'bzr pull ...' | 02:12 |
| lifeless | vxnick: you missing a space: ) | 02:12 |
| vxnick | woops | 02:12 |
| vxnick | I was copying you literally | 02:12 |
| lifeless | *I* missed a space ;) | 02:13 |
| AmanicA | lifeless: thanks a lot for responging, I thought I was losing it for a while. Would have been nice if it said what wanted the new version, will look into it another night. anyways goodnight. | 02:14 |
| vxnick | lifeless: I think you may possibly be a genius :) | 02:14 |
| vxnick | lifeless: it says I'm on r128 now so I just need to resolve some conflicts | 02:14 |
| lifeless | vxnick: ok, cool | 02:14 |
| vxnick | are the .moved files the newer ones (r128) or the r126 ones? | 02:14 |
| lifeless | older I would expect | 02:16 |
| vxnick | many thanks for your help - I'll try to do it from here :) | 02:16 |
| vxnick | really appreciate it | 02:16 |
| lifeless | igc: responding to your doc is on my todo as well | 02:21 |
| lifeless | however today is already quite full :) | 02:21 |
| lifeless | spiv: reping, see above | 02:21 |
| vxnick | I'm afraid I need some help merging these .moved files :( | 02:23 |
| vxnick | not really sure how to do it | 02:23 |
| lifeless | well | 02:24 |
| lifeless | the easiest way is just to mv them over the non .moved files; if the non .moved files are unchanged (don't show up in bzr st or bzr diff) | 02:24 |
| lifeless | then you can do 'bzr diff' and see the difference | 02:24 |
| vxnick | I also have these ~1~ files left | 02:25 |
| lifeless | similar/same process for them | 02:25 |
| vxnick | these .moved files look identical - you're saying delete them basically? | 02:26 |
| vxnick | or delete the originals | 02:26 |
| lifeless | if they are identical delete them | 02:28 |
| vxnick | question - are they conflicting because they're identical? bzr auto-resolves conflicts usually doesn't it? | 02:28 |
| lifeless | they're conflicting because they were existing files where bzr wanted to put files | 02:29 |
| vxnick | gotcha | 02:29 |
| lifeless | bzr resolve can be used to tell bzr that you have resolved a conflict | 02:29 |
| vxnick | thanks | 02:29 |
| vxnick | ok, I've removed the duplicates however bzr resolve is still showing the conflicts | 02:33 |
| vxnick | my mistake | 02:33 |
| vxnick | I didn't do --all | 02:33 |
| vxnick | lifeless: any chance we could attempt separating the merged r127 from r128? | 02:35 |
| vxnick | or isn't that possible | 02:35 |
| lifeless | vxnick: I'm reasonably sure they are separate in bzr's internals | 02:38 |
| lifeless | vxnick: what does 'bzr log' show? | 02:38 |
| vxnick | lifeless: it'd just be nice to view the changes in my repo viewer | 02:38 |
| vxnick | lifeless: bzr log shows all revs up to 128 | 02:39 |
| vxnick | including 127 | 02:39 |
| vxnick | ah - it has 126.1.1 | 02:39 |
| lifeless | what happened is that you had two things happen at once | 02:39 |
| lifeless | and you needed to merge to combine them - the 126.1.1 shows the thing that happened outside the 'trunk' | 02:40 |
| vxnick | so is there anyway I can go back and do that? | 02:41 |
| vxnick | the reason I'm so keen to view r127 is that it was a massive commit | 02:41 |
| igc | bbiab | 02:42 |
| lifeless | vxnick: well your repository view should be able to show it | 02:43 |
| lifeless | just look at 126.1.1 | 02:43 |
| vxnick | 126.1.1 is the commit prior to the big one though | 02:43 |
| vxnick | 126.1.1 was a single file commit | 02:43 |
| jam | hey lifeless, I'm around for a bi | 02:44 |
| jam | bit | 02:44 |
| lifeless | jam: hi; just keen to get bbc->production readiness planned | 02:44 |
| lifeless | I'm worried about iter_changes and stacking | 02:44 |
| lifeless | jam: also we need to write our talks | 02:44 |
| lifeless | for next week | 02:44 |
| lifeless | s/for/during/ | 02:44 |
| jam | dang, its friday already ... | 02:45 |
| lifeless | yup | 02:45 |
| vxnick | lifeless: slight problem - I've checked-out the repo in a different place and bzr revno is showing as r126 :S | 02:47 |
| vxnick | rather than 128 | 02:47 |
| vxnick | I tried bzr co -r revno:128 (not sure of the syntax) but it said no such revision | 02:47 |
| lifeless | vxnick: that sounds like they are in your checkout only. | 02:51 |
| lifeless | vxnick: if you are happy with how it looks now, do 'bzr push repo' | 02:51 |
| lifeless | where repo is the url you checkout from | 02:52 |
| vxnick | lifeless: any chance we can sort the 126.1.1 or is it stuck like that? | 02:52 |
| vxnick | i.e. get it into its own rev no | 02:52 |
| lifeless | vxnick: its basically stuck like that | 02:52 |
| vxnick | lifeless: ok no probs - i'll push | 02:53 |
| lifeless | it can be rewritten but its getting kinda complex | 02:53 |
| vxnick | lifeless: "pushed up to revision 128" :-) | 02:54 |
| vxnick | anything else or should I be good now? | 02:54 |
| lifeless | should be good | 02:54 |
| lifeless | go to your other checkout and do 'bzr update' to see | 02:54 |
| vxnick | yeah am currently runnig | 02:54 |
| vxnick | works fine | 02:54 |
| vxnick | thanks loads | 02:54 |
| vxnick | I'm glad there's a decent community around here | 02:55 |
| lifeless | no problem | 02:56 |
| jam | lifeless: did you just get a new gpg key? | 02:58 |
| jam | I guess it is now "(My Canonical long address)" :) | 02:58 |
| lifeless | jam: I added a new signing subkey for a machine | 02:58 |
| igc | jam: so 'log DIR' is slow in dev6rr because ... | 02:58 |
| jam | so igc, 'log DIR'... I think we are fundamentally approaching it from the wrong direction, simply because that was the easiest for XML formats | 02:58 |
| lifeless | jam: my laptop has it, but that new machine has only it. | 02:59 |
| igc | Inventory.filter() is slow | 02:59 |
| jam | igc: 'log DIR' is slow because the algorithm is structured to hit every item in the directory each time | 02:59 |
| jam | rather than starting with changes | 02:59 |
| igc | and it's slow because children is slow | 02:59 |
| jam | 'log -v' on 1k revs of mysql is 3s | 02:59 |
| jam | log DIR is 1m30s | 02:59 |
| jam | O(tree) algorithms are *bad* | 02:59 |
| igc | jam: so post-processing the delta will probably work *much* quicker | 03:00 |
| jam | igc: From what I can tell, part of the issue is handling 'recursion' | 03:00 |
| igc | jam: precisely | 03:00 |
| jam | in that if someone gives "DIR" we need to figure out if "some-random-delta-file-id" is part of that DIR | 03:00 |
| jam | there are a few ways we can do it | 03:00 |
| jam | 1) Change Inventory.filter() for CHKInventory | 03:01 |
| igc | jam: I couldn't see how to that faster down at the inventory layer (i.e. iter_entries(dir=X)) | 03:01 |
| jam | the size of specific_fileids() is always going to be much smaller and define a smaller subset of the set | 03:01 |
| jam | iter_entries_by_dir(dir=X for X in specific_fileids) | 03:01 |
| lifeless | jam: s/always/usually/. Pathological users abound. | 03:01 |
| jam | but that still scales poorly | 03:01 |
| jam | lifeless: this is a case where optimizing for the common case is probably going to give the best wins, as long as we aren't terribly pathological | 03:02 |
| jam | 2) Do 'changes' first, and then filter that after the fact | 03:02 |
| jam | technically the path filter can be computed from the parent_id_basename =>file_id map | 03:02 |
| lifeless | jam: oh agreed; I'm just making sure we don't forget that silly things happen | 03:02 |
| jam | and can be 'cached' between trees that have the same root hash | 03:02 |
| jam | however, that still scales as O(entries_in_dir) | 03:02 |
| jam | when O(num_changes) is often ~5-10 | 03:03 |
| jam | (on average) | 03:03 |
| lifeless | also! | 03:03 |
| lifeless | remember we're about to change iter_changes | 03:03 |
| jam | So I was thinking that if we do a smart inversion of | 03:03 |
| lifeless | this will impact chk delta stuff | 03:03 |
| lifeless | and it may do so helpfully | 03:03 |
| jam | for ..., file_id, ... in iter_changes(): | 03:03 |
| jam | parents = get_id_path(file_id) | 03:03 |
| jam | if file_id or parents in specifice_fileids: | 03:04 |
| jam | add | 03:04 |
| jam | lifeless: right, because we are looking to include parents of changes, right? | 03:04 |
| jam | igc: so I would inline the get_id_path part | 03:04 |
| jam | because | 03:04 |
| jam | a) You can keep a set of "known_uninteresting" directories | 03:04 |
| lifeless | jam: yes, in an as-yet-un-pinned-down-way | 03:04 |
| jam | as well as a set of "known_interesting" ones | 03:05 |
| jam | so that you only have to recurse to the root sometimes | 03:05 |
| jam | and as changes are likely to be grouped by dirs | 03:05 |
| jam | you'll likely get fast culling | 03:05 |
| igc | jam: sounds promising | 03:06 |
| jam | igc: I *think* you could push some of that down into iter_changes, except you lose any chance to cache info between trees | 03:08 |
| jam | as the *tree_shape* information could be cached between trees | 03:08 |
| jam | as long as parent_id_basename_root_id (sha1) didn't change | 03:08 |
| lifeless | jam: we could pass a cache in | 03:08 |
| lifeless | lunchtime | 03:08 |
| jam | however, by my numbers that only gives... 5:1 hits | 03:08 |
| jam | so *something* but unless we added 'delta' support to the cache maintenance, I'm not convinced it saves a whole lot | 03:09 |
| jam | (you could have the delta look at the parent_id_basename map changes, and determine what could be kept/discarded, but that takes more thinking.) | 03:09 |
| jam | igc: do you feel like that is enough info for you to work on it? | 03:10 |
| igc | jam: yes thank-you | 03:10 |
| lifeless | I have a couple of thoughts too | 03:10 |
| jam | lifeless: If I'm still here when you get back, I'd be interested in chatting a bit about stacking requirements and GC+CHK | 03:10 |
| jam | GC makes stacking 'easy' because it doesn't have deltas | 03:10 |
| lifeless | have you guys considered using the per-file graph to jump back in log DIR? | 03:10 |
| jam | but CHK is doubly difficult | 03:10 |
| lifeless | jam: stacking is currently serialiser-locked, I don't see how CHK impacts it | 03:11 |
| jam | lifeless: as in finding the recursive set of possible file ids, and then grabbing all of their graphs | 03:11 |
| jam | etc | 03:11 |
| lifeless | jam: [recursive set] - no | 03:11 |
| jam | lifeless: CHK 'externals' are not easily deduced from just the index | 03:11 |
| jam | and they are potentially "deep" | 03:11 |
| jam | in that the direct referenced one will reference more | 03:11 |
| lifeless | I mean, in rev Y, under DIR, 5-10 files are changed | 03:11 |
| lifeless | consider only their per-file graphs, and you get 5-10 possible revs to jump to | 03:12 |
| jam | lifeless: I don't think you know that in Y-1 another 3 files disjoint were modified | 03:12 |
| lifeless | jam: oh bother | 03:12 |
| lifeless | jam: I really wish we'd had time to do the recursive-change field in inventories; it would solve this trivially | 03:12 |
| jam | lifeless: right | 03:13 |
| jam | though at the expense of a bit more data churn | 03:13 |
| igc | lifeless: and another minor issue: the per-file graphs don't contain delete info yet & log needs to report that | 03:13 |
| jam | lifeless: so if your smart fetch requires the complete inventory for a given revision in order to determine the file-ids to fetch | 03:14 |
| jam | we only know the chk pages by *walking* them | 03:14 |
| lifeless | igc: indeed | 03:14 |
| jam | we can get some of that by the first pass as we transmit data | 03:14 |
| jam | but that only gives us a single depth of referenced pages | 03:14 |
| lifeless | igc: we can fix that by including a node at deletes | 03:14 |
| jam | so we may need to walk *those* as well, in case of > depth-2 trees | 03:14 |
| lifeless | jam: smart fetch requires a delta, not a inventory | 03:15 |
| lifeless | jam: [once we have the delta patch finished]. CUrrently your 'make xml' hack is in place | 03:15 |
| jam | lifeless: ouchie | 03:15 |
| jam | lifeless: so GCVF already supports fallback versioned files | 03:16 |
| jam | and passes the VF test suite for that | 03:16 |
| jam | So the *only* whole I can think of for stacking support | 03:16 |
| jam | is how we handle CHK pages | 03:16 |
| lifeless | jam: I'd approach this by a) turning it on and reenabling it, see how it goes | 03:16 |
| lifeless | b) look closely at whether we're going to have showstopper design issues, or things we can tweak to improve | 03:17 |
| lifeless | hole? | 03:17 |
| lifeless | today, I'd say we want the entire CHK tree for edge-revisions in the stacking branch, as this philosophically matches our current 'can get full inventory' rule for them. | 03:18 |
| jam | lifeless: well, 99% of all current trees we work in are only going to be depth 2 | 03:18 |
| jam | (one root, then leaves, or at most 1 root + 1 internal + 1 leaf) | 03:19 |
| jam | but the design is that they can be much deeper | 03:19 |
| jam | I'm somewhat concerned that we won't have problems because depth 2 won't trigger bugs | 03:19 |
| lifeless | ideally we can drop that back to 'all CHK page needed to generate a delta of any revision present against its parents' | 03:19 |
| lifeless | jam: I'm really not quite understanding the concern; are you saying fetch won't copy the right data? | 03:20 |
| jam | ATM, fetch has 2 passes, right? | 03:20 |
| lifeless | or can't be made to copy it? or will be slow if it does? | 03:20 |
| jam | The first pass could inspect the data it wants to transmit | 03:20 |
| jam | to determine the data it needs to transmit | 03:20 |
| lifeless | jam: StreamSource can do as many passes as it wants | 03:20 |
| jam | except for CHK pages, that might need yet-another pass to get to the actual end | 03:21 |
| lifeless | it generates 1 stream | 03:21 |
| lifeless | StreamSink can, after insertion, say 'I need more data' | 03:21 |
| lifeless | and that will result in a second stream | 03:21 |
| jam | It only gets to say that 1 time, right? | 03:21 |
| jam | but I guess you're right about stream sending a multi-pass stream | 03:21 |
| jam | since we already do that now | 03:21 |
| lifeless | the CHK pages introduced in the revs being pushed should all be included in the first stream, always. | 03:22 |
| lifeless | if the revs are at the edge of the stacking repository, it will ask for the inventories of the adjacent-absent revisions | 03:22 |
| lifeless | StreamSource in that case should provide all the CHK pages of those inventories | 03:22 |
| jam | lifeless: so the 'pages introduced' should always be included, I'm wondering if the 'pages referenced' should always be included | 03:23 |
| jam | as well as the inventories for adjacent | 03:23 |
| jam | though I suppose that should overlap | 03:23 |
| jam | I'm not sure it is 100% overlap | 03:23 |
| jam | (might be) | 03:23 |
| lifeless | pages referenced-and-not-introduced should be included in adjacent-inventories-full-page-set | 03:23 |
| lifeless | a future improvement would be to have the second stream be 'pages-required-to-delta-against-this-but-not-the-full-closure' - and thats where it gets tricky and is why you are concerned. | 03:24 |
| lifeless | that should be done after basic support is up | 03:25 |
| jam | lifeless: right, especially because it depends on the delta algorithm | 03:25 |
| lifeless | I think for fetch we should be only deltaing adjacently | 03:25 |
| lifeless | or within the set being sent | 03:25 |
| lifeless | really lunching now | 03:29 |
| jam | lifeless: btw, I think dev6rr fetch just picks 'an' adjacent revision, not *all* adjacent revisions. Though it could certainly do so. | 03:35 |
| lifeless | jam: if we can consolidate the two similar code paths it would do all | 03:35 |
| lifeless | :) | 03:35 |
| lifeless | hmm, regression in ignore:( | 03:39 |
| lifeless | bzr ignore foo, where foo is a versioned directory, and contents of foo showing as unknown | 03:39 |
| === poolie1 is now known as poolie | ||
| jml | a revision object has no reference to its repository | 04:00 |
| jml | is this deliberate? | 04:00 |
| lifeless | is it something we care deeply about? I don't think so | 04:01 |
| lifeless | deliberate is harder to answer | 04:01 |
| mwhudson | i can't say i've ever found that surprising | 04:01 |
| mwhudson | revisions have always seemed pretty atomic in some sense to me, not that much more structured than strings in some sense | 04:02 |
| mwhudson | huh, nice repetition hudson | 04:03 |
| lifeless | in some sense | 04:03 |
| jml | what's the difference between supports_delta and supports_diff in a log formatter? | 04:09 |
| mwhudson | jml: delta is like bzr st, diff is like bzr diff | 04:11 |
| mwhudson | (i think) | 04:11 |
| jml | ok. that makes sense. | 04:11 |
| jml | mwhudson: so, what you were saying earlier about revisions not being more than structured strings | 04:11 |
| jml | mwhudson: I get that, but it can go either way wrt having a reference to a repository | 04:12 |
| mwhudson | jml: yes | 04:13 |
| mwhudson | well, | 04:13 |
| mwhudson | no | 04:13 |
| mwhudson | jml: i guess what i mean is that you don't go directly from a string to something else | 04:13 |
| jml | sure | 04:13 |
| jml | the string is often a key into a real object | 04:13 |
| mwhudson | you might look up something under a string to find something else | 04:13 |
| mwhudson | but you don't go string.object_with_key | 04:13 |
| mwhudson | revisions are like that | 04:14 |
| jml | *nod* | 04:14 |
| jml | but maybe they could also be such that revision.get_parents() worked. | 04:14 |
| mwhudson | yeah | 04:14 |
| jml | I'm just noticing that I can't use a log formatter to show the author of the second-to-left parent revision of mainline as the author of the mainline revision. | 04:15 |
| mwhudson | ah | 04:20 |
| mwhudson | the log formatter doesn't get the branch or repo or anything? | 04:20 |
| mwhudson | well, i guess there may not be a branch | 04:20 |
| jml | mwhudson: no. | 04:21 |
| mwhudson | ugh | 04:21 |
| jml | mwhudson: I mean, you subclass the log formatter, so you can pass it one yourself | 04:21 |
| mwhudson | yeah, but that's pretty icky | 04:22 |
| mwhudson | will work for what i guess you're doing :) | 04:22 |
| jml | and in the canonical use case, there is a branch | 04:22 |
| spiv | lifeless: late pong | 04:25 |
| lifeless | spiv: its all there in history ;P | 04:26 |
| lifeless | how is it going basically | 04:26 |
| spiv | lifeless: I've been taken a little by surprise by fileids_altered_by_revision_ids, when a (stacked, no fallbacks set) repo has say rev-2 but not rev-1, and rev-2 doesn't change any files from rev-1, fileids_altered_by_revision_ids(['rev-2']) still reports rev-1. | 04:27 |
| lifeless | right | 04:28 |
| lifeless | thats the root of the bug in fact | 04:28 |
| lifeless | heres why it occurs: | 04:28 |
| lifeless | without rev-1's inventory, we can't calculate the delta | 04:28 |
| lifeless | so we get everything that is referenced | 04:28 |
| lifeless | not new references | 04:28 |
| lifeless | its why we want rev-1's inventory in the stacking repo | 04:29 |
| spiv | Yeah, it makes sense (the fulltext inventory clearly says "this file is at version rev-1"), but for some reason I was expecting fileids_al... to incorrectly deduce rev-2 there. | 04:30 |
| lifeless | ah | 04:30 |
| lifeless | :) | 04:30 |
| lifeless | it used to return nothing | 04:30 |
| lifeless | this lead to bugs in fetch where incorrect inventories caused stuff to be dropped | 04:30 |
| lifeless | so we fixed that | 04:30 |
| spiv | It doesn't really matter which version it reports, so long as it reports something and I can check that it's present. | 04:30 |
| spiv | i.e. this doesn't break my fix, but it's caused me grief when designing tests. | 04:31 |
| lifeless | if rev1's inventory is there it will report nothing | 04:31 |
| lifeless | if its not there it will report rev1's version, because rev2 doesn't have a version | 04:31 |
| lifeless | ok | 04:32 |
| spiv | (Also, there are no explicit unit tests for this corner of fileids_al...'s behaviour) | 04:32 |
| lifeless | what do you want to test | 04:32 |
| lifeless | spiv: uhm, there are actually, its just that those tests are pretty much inpenetrable | 04:32 |
| spiv | That the fix works ;) | 04:32 |
| lifeless | ok | 04:32 |
| spiv | More specifically, | 04:32 |
| lifeless | less broads | 04:32 |
| spiv | [re: fileids_al...'s tests, grep didn't find any other than test_fileid_involved.py, and it has no tests that show a revision in the result that wasn't passed as an arg to fileids_al...) | 04:34 |
| lifeless | hmmm, you may be right | 04:34 |
| lifeless | I know I wrote tests when I changed it | 04:35 |
| lifeless | it may be layered | 04:35 |
| lifeless | so - what behaviours do you want to ensure | 04:37 |
| lifeless | 'it works' | 04:38 |
| lifeless | that can be expanded | 04:38 |
| lifeless | are there things that shouldn't happen | 04:38 |
| spiv | Anyway, I'm testing: simple linear history where [parent inv missing + all texts present -> ok], [parent invs present + new texts present -> ok], [parent inv missing + text missing -> not ok] | 04:38 |
| lifeless | and things that should | 04:38 |
| lifeless | ok | 04:38 |
| spiv | Also, ghost rev that does not cause missing texts -> ok | 04:38 |
| lifeless | that shouldn't interact badly with fileids_altered | 04:39 |
| lifeless | branchbuilder supports ghosts now | 04:39 |
| spiv | Ah, handy, I didn't know that. | 04:39 |
| lifeless | I added it for a test | 04:39 |
| lifeless | look at record_snapshot's docstring | 04:40 |
| spiv | Also, I found I needed to use add_inventory directly on the target repo rather than get/insert_record_stream, because ensuring that I get a single fulltext inventory record was too fiddly with the stream API. | 04:41 |
| lifeless | thats surprising | 04:43 |
| lifeless | I would have expected roughly insert_record_stream(FullTextRecord(get_record_stream(foo, 'topological', True).next())) to Just Work | 04:44 |
| spiv | Right, I could probably manually assemble a FullTextContentFactory, but that's considerably more complicated than just calling add_inventory. | 04:45 |
| lifeless | true | 04:45 |
| lifeless | add_inventory is fine too | 04:45 |
| spiv | Yeah. I was a bit reluctant too at first, because it takes the test slightly further away from the way streaming fetch works, but I made peace with the idea fairly quickly :) | 04:46 |
| spiv | s/too/to/ | 04:46 |
| spiv | Anyway, I feel that I do understand all the dark corners now, so it's going rapidly now. But right now it's lunch time! | 04:47 |
| * spiv -> food | 04:48 | |
| lifeless | excellent | 04:48 |
| lifeless | I'm doing pdr stuff | 04:48 |
| lifeless | so just ping if you are able to save me from it at any point | 04:48 |
| lifeless | oh yeah | 05:01 |
| lifeless | jml: https://code.edge.launchpad.net/~lifeless/subunit/autoconf/+merge/6328 is textually large, but code wise tiny | 05:01 |
| lifeless | jml: I'd love a review :) | 05:01 |
| jml | lifeless: I might not get around to it for a week or so | 05:02 |
| jml | lifeless: but I'll put it on my todo list -- who knows what will happen! | 05:02 |
| lifeless | jml: I'lll nag other people then | 05:03 |
| lifeless | jml: as it will block me | 05:03 |
| jml | lifeless: ok. | 05:03 |
| lifeless | jml: or you can opt and and I'll land it as is | 05:03 |
| jml | lifeless: I'm basically talks talks talks until next weekend :) | 05:03 |
| lifeless | beamer where art thou? | 05:04 |
| lifeless | jml: basically it moves subunit to use autoconf; this gives the library a good soname and makes it packagable | 05:04 |
| jml | ok. | 05:05 |
| lifeless | jml: no python code changes at all; minor changes to the shell tests to support VPATH builds | 05:05 |
| lifeless | spiv: I've checked, build_snapshot in bzr.dev has support for ghosts | 05:10 |
| krisfremen | hello there, i'm gettign "Cannot build extension "bzrlib._btree_serializer_c"." | 05:10 |
| krisfremen | anyone knows a little bit of insight as to what is wrong? | 05:11 |
| lifeless | there should be more output than that | 05:11 |
| krisfremen | it's quite long | 05:11 |
| lifeless | if you can pastebin it somewhere I will look at it | 05:11 |
| krisfremen | http://pastebin.com/d2a36e92d | 05:17 |
| lifeless | # | 05:18 |
| lifeless | bzrlib/_btree_serializer_c.c:4:20: error: Python.h: No such file or directory | 05:18 |
| lifeless | # | 05:18 |
| lifeless | that suggests you don't have the python library header files on your system | 05:18 |
| lifeless | you might prefer to use a prebuilt bzr, but if you do want to build bzr yourself you need 'python-dev' or whatever the package is called on your operating system | 05:19 |
| lifeless | or you can run bzr without building the extensions (it can run as pure python) | 05:19 |
| krisfremen | i do have that package | 05:19 |
| lifeless | can you do | 05:20 |
| lifeless | ls /usr/include/python2.5/Python.h | 05:20 |
| krisfremen | hmm | 05:21 |
| krisfremen | not there | 05:21 |
| lifeless | are you running jaunty ? | 05:21 |
| krisfremen | debian lenny | 05:22 |
| lifeless | hmm, I think that has 2.5 as defalt | 05:23 |
| lifeless | *default* | 05:23 |
| lifeless | anyhow, you need /usr/include/python2.5/Python.h | 05:23 |
| lifeless | I think its normally in python2.5-dev, which is pulled in by python-dev usually | 05:23 |
| krisfremen | sudoed it and it worked | 05:26 |
| krisfremen | weird, maybe some permissions are messed up | 05:26 |
| krisfremen | thanks! | 05:27 |
| lifeless | no probs | 05:29 |
| jam | spiv, lifeless: btw, if you add a FulltextContentFactory, I believe it goes down to '.add_lines()' which can create a delta | 05:31 |
| jam | you have to insert a KnitFulltext record if you want to force it to be a full text | 05:31 |
| jam | though I believe add_inventory() can also generate a delta | 05:31 |
| lifeless | jam: it won't create a delta if the target repo is missing the parent | 05:32 |
| lifeless | jam: which is the scenario | 05:32 |
| lifeless | jam: the point is to avoid dragging the parent content around by mistake | 05:32 |
| lifeless | -> pdr stuff done | 05:44 |
| lifeless | deep hacking time on check; if anyone wants me SMS or ring | 05:45 |
| lifeless | abentley: if you're around; we used to have code for determining left-hand-distance-to-null; do you happen to recall what we did with it? | 06:12 |
| lifeless | (I'm refactoring Branch.check to take a precalulated graph rather than every branch doing the same thing) | 06:13 |
| jml | does bzrlib have a standard way of taking an optional location and turning it into a branch? | 06:20 |
| jml | should it? | 06:20 |
| lifeless | EPARSE | 06:20 |
| lifeless | [what talk are you writing btw, and if you're all talk at the moment, consider mailing jam and I] | 06:20 |
| jml | lifeless: I think the cost of explaining what I mean is greater than or equal to the cost of figuring it out myself :) | 06:21 |
| lifeless | jml: if you mean 'open_or_init' or something like that, uhm no, And I don't think so | 06:21 |
| lifeless | if you mean something else, maybe, who knows. | 06:22 |
| jml | lifeless: I mean more like a command-level thing for saying "just default to the branch that's in the current directory." | 06:22 |
| jml | lifeless: but I think that's just if location is None: location = '.' | 06:23 |
| jml | talks I'm doing are: Introduction to Twisted; Tour of Launchpad Code; Teach Me Packaging; "Your Code Sucks and I Hate You" | 06:25 |
| jml | lifeless: and whatever help I can spare for your & jam's talk | 06:26 |
| lifeless | jml: we're doing two :P | 06:31 |
| lifeless | so please pluralise :) | 06:31 |
| lifeless | jml: anyhoo, thats Branch.open_containing | 06:31 |
| jml | lifeless: the one I submitted the proposal for :) | 06:31 |
| lifeless | and yes, if location is None: location='.' | 06:31 |
| lifeless | jml: la-la-la-la | 06:32 |
| * igc celebrates completing his just-in-time hr paperwork by starting his many-weeks-late expenses paperwork | 08:03 | |
| spiv | igc: :) | 08:09 |
| spiv | igc: I know the feeling! | 08:09 |
| igc | spiv: does that mean you've remembered my "review me" invitiation? :-) | 08:10 |
| spiv | igc: yes :) | 08:13 |
| spiv | igc: (doing those now, in fact) | 08:13 |
| bialix | luks: ping | 08:22 |
| luks | pong | 08:22 |
| bialix | luks: I'd like to make Gary admin of qbzr google group. He's most active these weeks | 08:23 |
| luks | sure, no objections to that | 08:23 |
| bialix | ok | 08:23 |
| * igc packs it in for the day | 09:28 | |
| igc | have a good weekend all | 09:28 |
| === dereine[OFF] is now known as dereine | ||
| === dereine is now known as dereine[OFF] | ||
| === dereine[OFF] is now known as dereine | ||
| abentley | lifeless: It's on Graph. | 12:46 |
| abentley | lifeless: Graph.find_distance_to_null | 12:47 |
| lifeless | abentley: thanks | 12:49 |
| === dahoste|away is now known as dahoste | ||
| === abentley1 is now known as abentley | ||
| === nevans1 is now known as nevans | ||
| === pindonga is now known as ricardokirkner | ||
| === BjornT_ is now known as BjornT | ||
| Mez | how do I create a working tree for something that doesnt have one ? | 14:53 |
| beuno | Mez, bzr co . | 14:53 |
| ricardokirkner | hi. is there any way to have a bzr repo be pushed to svn, and keep each commit author? (I mean, every team member commits to a central bzr repo, and from there one person pushes to a svn repo... each individual commit.. retains authorship, or are all commits re-owned by the person who effectively pushes to svn?) | 15:03 |
| lifeless | jelmer: I've packaged subunit | 15:07 |
| lifeless | jelmer: if you want to change the maintainer field and do the upload to close your bug in debian, that would be fine | 15:07 |
| lifeless | ricardokirkner: bzr will add metadata saying the original author, but I'm not sure whether svn looks ast that or not; I suspect it doesn't. | 15:08 |
| ricardokirkner | lifeless, it uses svn properties for that right? | 15:09 |
| ricardokirkner | I had some issues with that... its not very nice from the svn point of view to have a lot of properties set/reset on each commit | 15:10 |
| jelmer | ricardokirkner: it uses revision properties if you have a new enough version of svn (svn >= 1.5) | 15:26 |
| jelmer | lifeless: ah, nice | 15:26 |
| jelmer | lifeless: care to be co-maintainer ? | 15:27 |
| lifeless | jelmer: sure | 15:27 |
| ricardokirkner | jelmer, and if you have a lesser version? what does it use? | 15:27 |
| jelmer | ricardokirkner: file properties | 15:28 |
| ricardokirkner | jelmer, sorry I am missing something here.. | 15:28 |
| ricardokirkner | svn:ignore is a svn property... this is a revision property? | 15:29 |
| ricardokirkner | if so, what is a file property? | 15:29 |
| === dereine is now known as dereine[OFF] | ||
| jelmer | ricardokirkner: svn:ignore is a file property | 15:32 |
| jelmer | ricardokirkner: revision properties are generally not visible for the user | 15:32 |
| lifeless | jelmer: https://code.edge.launchpad.net/~subunit/ubuntu/jaunty/subunit/releases revno 70 | 15:32 |
| savvas | does bzr require repackaging like git if it gets big? | 15:33 |
| lifeless | savvas: bzr automatically packs as needed | 15:34 |
| lifeless | you can manually trigger a pack if you have reason to, but its not something we recommend | 15:34 |
| jelmer | lifeless: whu | 15:34 |
| jelmer | lifeless: what sort of fancy branch is that? | 15:34 |
| lifeless | jelmer: package branch | 15:34 |
| savvas | it's ok, I like "automagic" :) | 15:35 |
| lifeless | halt() | 15:35 |
| lifeless | gnight | 15:35 |
| Odd_Bloke | How can I list the files changes in a commit? | 15:36 |
| Odd_Bloke | *changed | 15:37 |
| beuno | Odd_Bloke, -v | 15:37 |
| lifeless | Odd_Bloke: bzr st -c revno | 15:38 |
| lifeless | Odd_Bloke: log -v -c revno | 15:38 |
| lifeless | bzr diff -c revno | diffstat | 15:38 |
| lifeless | (really gone now) | 15:38 |
| jelmer | lifeless: ah, interesting | 15:38 |
| jelmer | lifeless: 'night | 15:38 |
| lifeless | jelmer: oh | 15:39 |
| lifeless | one more thing | 15:39 |
| lifeless | there is a tarball | 15:39 |
| jelmer | lifeless: and appropriately set debian/watch ? :-) | 15:39 |
| lifeless | no | 15:39 |
| lifeless | watch can't do bzr well | 15:39 |
| lifeless | https://edge.launchpad.net/~subunit/+archive/ppa | 15:39 |
| jelmer | lifeless: it can deal with tarballs though :-) | 15:39 |
| lifeless | grab the -65 tarball from there | 15:40 |
| jelmer | lifeless: btw, how do I register new package branches? | 15:40 |
| lifeless | jelmer: yes, but I'm not making official release tarballs at this point | 15:40 |
| lifeless | jelmer: usual way, push to em | 15:40 |
| jelmer | lifeless: ah, k | 15:40 |
| jelmer | lifeless: but mirrorred branches? There's no register link | 15:40 |
| lifeless | the tarball of -65 is a snapshot, you could make your own but nicer to reuse | 15:40 |
| lifeless | jelmer: I don't know that you can, or that it has even been considered | 15:41 |
| james_w | jelmer: not currently possible to have a mirrored package branch | 15:41 |
| lifeless | jelmer: anyhow, lp is fast now | 15:41 |
| jelmer | lifeless: Yeah, but I'd like to register the branches on bzr.debian.org | 15:42 |
| lifeless | good use case | 15:42 |
| lifeless | jelmer: ^ | 15:42 |
| jelmer | as packaging branches seem to be supported for debian in lp too | 15:42 |
| lifeless | james_w: ^ | 15:42 |
| lifeless | ciao | 15:42 |
| james_w | they are | 15:43 |
| james_w | I think the immediate problem is that the form for registering just has a space for "Project:" | 15:43 |
| james_w | so it can't be used | 15:43 |
| james_w | I don't know if there are more fundamental issues | 15:43 |
| Kamping_Kaiser | Is any special work required for a bzr 'head' branch? | 15:46 |
| Kamping_Kaiser | (in a configuration sense) | 15:46 |
| jelmer | james_w: should I file a bug? | 15:47 |
| james_w | Kamping_Kaiser: you might like to set "append_revisions_only", but other than that there isn't much | 15:47 |
| james_w | that's not required, it just enforces something that most people expect for a "head" branch | 15:48 |
| james_w | jelmer: bug 347755 I think | 15:48 |
| ubottu | Launchpad bug 347755 in launchpad-code "No UI for registering package branches" [Medium,Triaged] https://launchpad.net/bugs/347755 | 15:48 |
| Kamping_Kaiser | james_w, thanks. | 15:48 |
| LarstiQ | whatever is a head branch? | 15:49 |
| jelmer | james_w: thanks | 15:49 |
| Kamping_Kaiser | LarstiQ, something I link to on a public site as a 'known working' rcs snapshot | 15:49 |
| LarstiQ | Kamping_Kaiser: ah ok, so not trunk if that isn't guaranteed to be known working | 16:11 |
| Kamping_Kaiser | LarstiQ, true, the wording on my part was bad. | 16:12 |
| gcerquant | I have a noob question: I just did a merge and have some conflicts. I understand the .OTHER files are the one from the branch I am merging into the branch I am working on. Could someone clarify what is the .BASE and .THIS? | 16:40 |
| awilkins | Can anyone tell me how to get the Nautilus integration going in bzr-gtk? | 16:42 |
| * awilkins installs the GNOME-python binding | 16:42 | |
| * awilkins discovers they are already there | 16:43 | |
| james_w | gcerquant: THIS is from the tree you merged in to | 16:44 |
| james_w | gcerquant: BASE is the common ancestor | 16:44 |
| === dereine[OFF] is now known as dereine | ||
| gcerquant | But I branched a copy, worked on it, and then merged it back | 16:45 |
| gcerquant | shouldn't THIS and BASE be the same ? | 16:45 |
| awilkins | They won't be because if THIS and BASE were the same, there would be no conflict | 16:46 |
| awilkins | Which OS are you using? | 16:46 |
| gcerquant | Mac | 16:47 |
| gcerquant | ok, I get it | 16:47 |
| * awilkins doesn't know much about 3-way merge editors for Mac | 16:47 | |
| vxnick | gcerquant: changesapp.com is good | 16:47 |
| gcerquant | I forgot I did a revert on the main branch | 16:47 |
| awilkins | I was going to suggest it might be easier if you open it in meld / TortoiseMerge / stuff | 16:47 |
| gcerquant | Changes.app is awesome, yes | 16:47 |
| gcerquant | thanks for your help | 16:48 |
| vxnick | gcerquant: you can also integrate it with bzr if you haven't already :) | 16:48 |
| gcerquant | I did :) | 16:48 |
| gcerquant | with this alias: diff = diff --using=chdiff | 16:49 |
| gcerquant | anything more efficient? | 16:49 |
| vxnick | gcerquant: add it your .bashrc file | 16:50 |
| vxnick | sorry | 16:50 |
| vxnick | ignore that | 16:50 |
| gcerquant | np | 16:51 |
| vxnick | gcerquant: ALIASES] | 16:51 |
| vxnick | chdiff = diff --using chdiff --diff-options --wait | 16:51 |
| vxnick | gcerquant: in ~/.bazaar/bazaar.conf | 16:51 |
| vxnick | [ALIASES] on the line above it | 16:51 |
| gcerquant | yep, that's what I have | 16:51 |
| gcerquant | except for the --wait options | 16:52 |
| gcerquant | what does it change? | 16:52 |
| james_w | --diff-options isn't passed to chdiff in that case is it? | 16:52 |
| vxnick | gcerquant: http://pastie.org/472261 | 16:52 |
| vxnick | gcerquant: it means you can use "bzr chdiff" | 16:52 |
| vxnick | gcerquant: --wait means bzr halts until changes.app is quit | 16:53 |
| gcerquant | but unless I miss something, I prefer it without the wait | 16:53 |
| vxnick | fair enough :) | 16:53 |
| gcerquant | so I can open a diff, look at it in Changes, maybe do an other commands in my term (bzr conflicts, or just ls...) | 16:54 |
| vxnick | yeah | 16:54 |
| vxnick | I see your point | 16:54 |
| vxnick | I think I just copied/pasted the whole thing from the changes website | 16:54 |
| vxnick | it wasn't a conscious decision | 16:54 |
| gcerquant | :) | 16:54 |
| gcerquant | I had done a script for Changes in svn to edit the files in place, with the right name. So I could edit and save within Changes, and be done | 16:55 |
| gcerquant | might adapt it for bzr | 16:55 |
| gcerquant | vxnick, what do you develop for Mac? | 16:56 |
| vxnick | gcerquant: I just do web stuff - LAMP type stuff | 16:56 |
| awilkins | Here's a thought - could we use an "ignored" status change kind ; e.g. - you've got a file that you want to stop tracking, the only way being to `bzr rm --keep foo` and then `bzr ignore foo` ; unfortunately when others pull your revision this will delete their local copy of the file instead of just ignoring it. | 16:57 |
| awilkins | In other words, would tracking the use of `rm` vs `rm --keep` as separate types of change be useful (for me, yes). | 16:59 |
| vxnick | awilkins: I think that sounds sensible | 16:59 |
| vxnick | prevention is better than the cure ;) | 17:00 |
| awilkins | Specific example, using Maven with the eclipse plugin ; it generates .project files ; someone has added these to version control in error. | 17:00 |
| awilkins | I want to remove and ignore them without spoiling his day. | 17:00 |
| awilkins | Ok, he can just regenerate them :-) | 17:00 |
| gcerquant | http://paste.lisp.org/display/79905 | 17:04 |
| gcerquant | It looks like my merge produce a conflict because I removed a new line. | 17:04 |
| gcerquant | Is this possible? | 17:04 |
| gcerquant | Is there an option for that? | 17:04 |
| gcerquant | I. Just. Love. Bazaar. | 17:48 |
| LeoNerd | .oO( "Get a roooom!" ) ;) | 17:49 |
| gcerquant | :-p | 17:49 |
| vxnick | I love it too - can't bring myself to use anything else :P | 17:50 |
| === dahoste is now known as dahoste|away | ||
| gcerquant | I have check other system, but bzr has the right approach for so many things it's a no-brainer decision | 17:50 |
| vxnick | yeah | 17:51 |
| vxnick | I *love* bzr uncommit ;) | 17:51 |
| gcerquant | can you unrevert as well? | 17:51 |
| gcerquant | I was once burned by this with svn (used an newly alias the wrong way. alias was deleted just after I finished crying) | 17:52 |
| LeoNerd | revert saves a backup copy of the modified files in the local checkout. I don't know if it has an automatic "unrevert" command, but you can just mv foo.c.~1~ foo.c | 17:53 |
| LeoNerd | Though usually I use vimdiff between them | 17:53 |
| james_w | there is no unrevert | 17:54 |
| james_w | one day... | 17:54 |
| bialix | jelmer: are you around? | 17:57 |
| james_w | hi bialix | 17:57 |
| bialix | hi james_w | 17:57 |
| bialix | there is question about conversion from svn: http://stackoverflow.com/questions/839683/how-to-migrate-from-a-complicated-subversion-repository-to-a-distributed-version | 18:00 |
| bialix | jelmer: ^^ | 18:02 |
| jelmer | bialix: answered | 18:06 |
| bialix | thx | 18:08 |
| === dereine is now known as dereine[OFF] | ||
| === dereine[OFF] is now known as dereine | ||
| Peng_ | Haha, subunit switched from scons to autoconf *one day* after i installed scons specifically for it. :P | 19:47 |
| LarstiQ | make it switch back! | 19:47 |
| Peng_ | Since I'm just using it for Python, I don't even need to compile it though. | 19:50 |
| LarstiQ | ronny: try again. I note http://paste.pocoo.org/show/116024/ doesn't include releases like 1.14.1 | 20:29 |
| ronny | LarstiQ: yes, its a bit incomplete, its just a pretty generic guess | 20:30 |
| * LarstiQ nods | 20:30 | |
| LarstiQ | ronny: you could try parsing http://pypi.python.org/simple/bzr or something like that | 20:30 |
| === kiko is now known as kiko-afk | ||
| ronny | LarstiQ: i will probably put dealing with that in an actual py.test extension using the xmlrpc api or some code i worte for the pida plugin updates | 20:31 |
| * LarstiQ might want some code like that too | 20:32 | |
| LarstiQ | ronny: anyway, for the releases in that script, they should now work :) | 20:32 |
| ronny | LarstiQ: i just wrote a scanner for the simple http pypi | 20:33 |
| ronny | its pretty nasty and just has some regex | 20:33 |
| ronny | it works semilar to things like easy_install and pip | 20:33 |
| ronny | #its just less smart | 20:33 |
| LarstiQ | right | 20:34 |
| * LarstiQ has read the easy_install code | 20:34 | |
| LarstiQ | that's actually how I got to know about /simple/ | 20:34 |
| ronny | i hope you didnt cry in tears of blood | 20:35 |
| LarstiQ | only a little bit | 20:35 |
| ronny | reading code by pje is a #1 health danger | 20:35 |
| ronny | well, luckyly hes now a self-refactoring guru and wont fuck up python any more | 20:35 |
| LarstiQ | he has had some good ideas tough | 20:37 |
| LarstiQ | mainly thinking of wsgi here | 20:38 |
| === beuno_ is now known as beuno | ||
| yam | quick ? - I want to look at a file from December in my bzr repo, and then go back to today's version | 20:45 |
| yam | possible? | 20:45 |
| jam | yam: bzr cat -r XXX file | 20:47 |
| jam | or bzr revert -r XXX file; bzr revert file | 20:47 |
| * LarstiQ thought yam was talking to himself | 20:51 | |
| LarstiQ | jam: how are you doing? | 20:51 |
| jam | LarstiQ: I'm doing pretty good. how about you? | 20:51 |
| yam | Sorry, not talking to myself, trying it out - works! | 20:51 |
| LarstiQ | yam: I meant you and jam's nicks being very similar | 20:52 |
| yam | thank you kindly - I knew that IRC would be the answer I needed | 20:52 |
| LarstiQ | jam: feeling a bit ground by work and studying, but otherwise not unhappy | 20:52 |
| yam | LarstiQ: yam jam sounds pretty good, actually | 20:53 |
| andriijas | how do i remove a pending merge tips? | 21:03 |
| jelmer | andriijas: bzr revert --forget-merges | 21:03 |
| andriijas | thx | 21:04 |
| rellis_ | HI everyone. I am seeing this bug https://bugs.launchpad.net/bzr-svn/+bug/373726. Has anyone else seen this, is there a nifty workaround? | 21:26 |
| ubottu | Ubuntu bug 373726 in bzr-svn "Error importing svn repository" [Undecided,New] | 21:26 |
| LarstiQ | rellis_: I haven't seen that before, but it violates an invariant of bzr, I wonder how you got to that point. | 21:34 |
| LarstiQ | hmm, I can think of one way to do that. | 21:35 |
| psykidellic | Hi, I guess I am missing something very stupid in the docs. But how do you init a branch with an existing branch info? | 21:36 |
| jelmer | rellis_: hi | 21:36 |
| psykidellic | *init a new | 21:36 |
| jelmer | rellis_: I think this might be a bug that's fixed in 0.5.4, is there any chance you can try with that? | 21:37 |
| jelmer | rellis_: Is this repo publicly accessible? | 21:37 |
| LarstiQ | psykidellic: do you want a copy of the other branch? `bzr branch old new` | 21:41 |
| LarstiQ | psykidellic: if not, it is unclear to me what effect you're after | 21:41 |
| psykidellic | LarstiQ: We have a branch at: /bzr/project/branch..... . I created a new repo using: init-repo. I want to import project/brnach with all its history to the new repo. | 21:55 |
| psykidellic | *branch | 21:55 |
| LarstiQ | psykidellic: if it's one branch, just `bzr branch` it. | 21:56 |
| psykidellic | LarstiQ: Alright. And it will be added to repository when I push it first time. | 21:56 |
| LarstiQ | psykidellic: if I understand you correctly as having added a repository after deciding a standalone branch wasn't the way to go, `bzr reconfigure` might be handy. | 21:56 |
| psykidellic | LarstiQ: Exactly :) | 21:57 |
| LarstiQ | psykidellic: that's fine too | 21:57 |
| psykidellic | LarstiQ: You read my mind! | 21:57 |
| LarstiQ | psykidellic: specifically, `bzr reconfigure --use-shared` would have been of help to you | 21:57 |
| psykidellic | I have not yet branched to new one. I will look into reconfigure now. | 21:58 |
| psykidellic | Thanks. | 21:58 |
| * psykidellic goes back to docs. | 21:58 | |
| === dereine is now known as dereine[OFF] | ||
| lifeless | jelmer: bah, packaging fail. I'm fixing | 22:30 |
| === beuno_ is now known as beuno | ||
| lifeless | jelmer: all fixed now | 23:00 |
| lifeless | missing pkg-config build-dep | 23:00 |
| lifeless | Peng_: its packaged now | 23:00 |
| lifeless | launchpad.net/~subunit/+archive/ppa | 23:00 |
| xlax | Can anyone explain why I can't push any repo? I constantly get "Target directory xx already exists [...]" or "Generic path error" | 23:18 |
| xlax | Or permission denied errors are common too. | 23:19 |
| lifeless | xlax: are you pushing to launchpad? | 23:22 |
| xlax | lifeless: no, I'm trying my own (s)ftp solution. | 23:23 |
| xlax | Because I need the project to be private, and I didn't see any option for that in launchpad. | 23:24 |
| FurnaceBoy | hi all. is there a pure CLI way to achieve per-file commit messages? I'm using bzr on a headless box | 23:24 |
| lifeless | launchpad cann host private projects, but its for a fee. | 23:24 |
| lifeless | anyhow - Target directory xx already exists - means you've made a directory rather than having bzr push to a new directory. | 23:25 |
| === dereine[OFF] is now known as dereine | ||
| lifeless | either pass --use-existing-dir to push, or don't make the branch directories by hand | 23:25 |
| lifeless | the GPE I'd need to see a backtrace of - there will be one in ~/.bzr.log | 23:25 |
| xlax | lifeless: using --use-existing-dir will get me the GPE ^^ | 23:25 |
| lifeless | FurnaceBoy: I don't think so | 23:25 |
| FurnaceBoy | lifeless, hm ok, thanks. just on a project whose policy encourages them. | 23:26 |
| Peng_ | lifeless: Oh, nice. I've already set up running it from source, so I'm not sure I'll bother with the PPA though. Plus I don't run Jaunty. | 23:26 |
| lifeless | FurnaceBoy: you could use the python interface, or write aplugin to support it. | 23:26 |
| lifeless | FurnaceBoy: mainly a UI problem, its a lot easier to write that sort of thing in a gui | 23:26 |
| FurnaceBoy | lifeless, interesting! | 23:26 |
| FurnaceBoy | lifeless, I'll think about that. thankyou | 23:26 |
| lifeless | FurnaceBoy: feel free to file a bug saying you'd like it in the CLI | 23:26 |
| lifeless | Peng_: lenny? | 23:27 |
| FurnaceBoy | lifeless, is the main Bzr on lp? | 23:27 |
| Peng_ | lifeless: Hardy. Plus Gutsy. :X | 23:27 |
| Peng_ | (I'll upgrade soon i swear!) | 23:27 |
| lifeless | FurnaceBoy: http://launchpad.net/bzr | 23:27 |
| lifeless | Peng_: :) | 23:27 |
| FurnaceBoy | lifeless, ok, so if i wanted to write such a plugin, would i branch to do it? (sorry i'm new to bzr/lp) | 23:28 |
| lifeless | Peng_: hopefully jkakar will do the autoppa magic and I can upload gutsy and hardy too | 23:28 |
| lifeless | FurnaceBoy: well a plugin is a new separate project; so you'd start a new project, which would be a bzr plugin | 23:28 |
| Peng_ | lifeless: Is creating gutsy packages even allowed anymore? It's not supported... | 23:28 |
| lifeless | FurnaceBoy: or you could just patch bzr itself; it might be easier in this particular case:- for that you would branch bzr, yes. | 23:28 |
| lifeless | Peng_: not sure. | 23:29 |
| lifeless | hardy is | 23:29 |
| xlax | Hmm. It seems my host has an odd way of calling its directories... | 23:29 |
| jkakar | lifeless: AutoPPA magic for Bazaar? | 23:29 |
| lifeless | jkakar: subunit | 23:29 |
| lifeless | jkakar: (hi) | 23:29 |
| jkakar | lifeless: Ah, okay, yeah, I should finish that since it's already half done. Hi! :) | 23:29 |
| lifeless | jkakar: I've done C/python/tools/C-dev packages | 23:30 |
| jkakar | lifeless: I noticed that. I'll see if I can review/integrate your changes sometime this weekend. | 23:30 |
| lifeless | jkakar: they're built https://edge.launchpad.net/~subunit/+archive/ppa and code is https://code.edge.launchpad.net/~subunit/ubuntu/jaunty/subunit/releases | 23:30 |
| jelmer | lifeless: btw, the last entry in changelog is by robertc@lifelessdesktop | 23:31 |
| lifeless | debian/changelog? | 23:31 |
| lifeless | meh, I haven't set DEBFULLNAME and DEBEMAIL yet on that machine | 23:31 |
| jelmer | lifeless: ah | 23:32 |
| lifeless | my desktop went bang | 23:32 |
| lifeless | I have a new i7 920 :) | 23:32 |
| jelmer | lifeless: also, any chance you can use 0.0.1~bzr65 for the upstream version? That way bzr-builddeb can Do The Right thing at some point | 23:32 |
| === zirpu is now known as zirpu-away | ||
| jelmer | lifeless: what's an i7 ? | 23:33 |
| lifeless | 4-core, 8 hyperthreadedvcpu's goodness | 23:33 |
| jelmer | lifeless: nice | 23:33 |
| lifeless | intels current gamer/workstation cpu | 23:33 |
| lifeless | jelmer: I used - deliberately | 23:34 |
| === zirpu-away is now known as zirpu | ||
| jelmer | lifeless: why the - ? | 23:34 |
| lifeless | jelmer: its an upstream release | 23:34 |
| lifeless | not on the path to 0.0.1, after 0.0.1 | 23:34 |
| lifeless | we could use 0.0.2~bzr65 if we wanted | 23:35 |
| jelmer | lifeless: so it's actually 0.0.1 ? or just a snapshot after 0.0.1 ? | 23:35 |
| lifeless | the latter | 23:35 |
| jelmer | lifeless: what about 0.0.1+bzr65 ? | 23:35 |
| jelmer | I guess we could also get bzr-builddeb to support something like 0.0.1-bzr65 though | 23:35 |
| lifeless | bzr-builddeb should support it | 23:35 |
| lifeless | in terms of parsing etc, its legit | 23:36 |
| jelmer | lifeless: it might be confusing for native packages though | 23:36 |
| lifeless | no, if foo-x-y, -y is debian revision, -x is part of upstream version | 23:36 |
| lifeless | jkakar: overview is 'used autoconf to get a soname, and after that its stock debhelper magic mostly' | 23:37 |
| lifeless | jkakar: the thing that you could do that would be nice is get it working with autoppa for future release builds | 23:37 |
| jelmer | lifeless: what I mean is that it makes parsing the version string harder for bzr-builddeb | 23:37 |
| lifeless | jelmer: it should be getting parsed by python-dpkg anyhow ;) | 23:38 |
| lifeless | jelmer: which DTRT | 23:38 |
| lifeless | if it does make it harder, well I'm not married to this | 23:38 |
| james_w | python-apt, but yeah | 23:38 |
| lifeless | hi :) | 23:39 |
| lifeless | james_w: I went with -f on autoreconf | 23:39 |
| james_w | it should work with two -, but is currently broken, fixed in the 2.1 branch | 23:39 |
| lifeless | datestamps and patches, eww. | 23:39 |
| james_w | lifeless: cool | 23:39 |
| james_w | plus, it doesn't care if you create a native package with - in it | 23:39 |
| jkakar | lifeless: Cool, that shouldn't be hard. | 23:39 |
| james_w | hi jkakar | 23:40 |
| jkakar | Heya james_w! :) | 23:40 |
| james_w | jkakar: did you know that launchpad will soon support uploads with a target of "hardy intrepid jaunty"? | 23:40 |
| lifeless | jkakar: I'd like to keep two packaging branches. One 'official' this-is-packaged-for-$distro [debian with flow-down to ubuntu for now], and one 'upstream' this-is-ppa-magic. | 23:40 |
| lifeless | jkakar: the ppa one should descend from the official one | 23:41 |
| jkakar | lifeless: Cool, that makes sense. | 23:41 |
| lifeless | james_w: awesome | 23:41 |
| jkakar | james_w: I didn't, no. That sounds pretty awesome. | 23:41 |
| james_w | yeah, it removes the simple case that autoppa solves | 23:41 |
| james_w | then you should just write your package so the same source works on multiple distributions :-) | 23:42 |
| jelmer | james_w: that's awesome | 23:42 |
| jkakar | james_w: Well, sort of. That's only half of the case AutoPPA solves--the other half is providing some simple templating so that slightly different control files and such can be used for each build. | 23:42 |
| james_w | also, you two may be interested in https://launchpad.net/bzr-builder that I wrote | 23:42 |
| james_w | jkakar: yeah, but that's rarely required, though can often be nice to have | 23:43 |
| jkakar | james_w: Really? I probably just don't know enough about packaging, but that seems to be required for every single project I've packaged (which is like 4 things). | 23:43 |
| lifeless | james_w: you've reinvented config-manager ;) | 23:44 |
| jkakar | james_w: For example, on dapper my Python libraries need to Build-Depends on python-support, whereas on newer releases they need to Build-Depends on python-central. | 23:44 |
| jkakar | james_w: The same kind of problem crops up when you need to depend on version 1.1 of libfoo on dapper and 1.2 on hardy. | 23:44 |
| james_w | lifeless: yeah | 23:44 |
| jkakar | james_w: Anyway, I really hope it is rarely needed... it'd be great for AutoPPA to be killable. | 23:45 |
| james_w | jkakar: yeah, Build-Depends is the main case. Depends you can do from within the package | 23:45 |
| james_w | python-central isn't something you can do with an "|" though, unless you are really sneaky | 23:45 |
| Peng_ | Would it make sense for the SMP test stuff to use the multiprocessing module? Nose does, Or So I Heard. | 23:46 |
| james_w | Build-Depends: package-that-only-exists-in-dapper | python-central | 23:46 |
| lifeless | Peng_: no | 23:46 |
| lifeless | Peng_: we want full isolation ;) | 23:47 |
| james_w | so http://bazaar.launchpad.net/~dailydebs-team/bzr-builder/cookbook/annotate/head%3A/bzr/jaunty.recipe is what controls what is uploaded to the jaunty nightly PPA now | 23:47 |
| james_w | lifeless: the plan is apparently to integrate this with launchpad | 23:47 |
| lifeless | back in a bit | 23:48 |
| jelmer | james_w: what's advantage of bzr-builder and nested trees (when they land..) | 23:48 |
| jelmer | james_w: ? | 23:48 |
| Peng_ | lifeless: I don't know what that means, but okay. :D | 23:48 |
| * Peng_ doesn't know a thing about multiprocessing. | 23:48 | |
| james_w | jelmer: I don't know how it will work with nested trees, it will probably do a join there I guess | 23:49 |
| james_w | jelmer: I just throw away the created tree at the moment, so I don't really care | 23:49 |
| james_w | it does mean that it can't use bzr-builddeb currently, which nested trees would allow us to do | 23:49 |
| === dereine is now known as dereine[OFF] | ||
| james_w | lifeless: oh, I also tested a larger package earlier. A chunk of nautilus was 2 minutes to branch, 30 seconds to apt-get | 23:50 |
| lifeless | james_w: not a great ratio | 23:59 |
| lifeless | james_w: but better than the past | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!