| bob2 | is bzr-hg maintained upstream? | 00:57 |
|---|---|---|
| lifeless | yesish | 00:58 |
| === SamB_ is now known as SamB | ||
| vila | hi all | 07:01 |
| === vila changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | ||
| frgomes | hello guys :) I'm trying to import/checkout/branch (whatever works!) a remote SVN branch. But the remote SVN is broken revisions and I get the error message "Unable to fetch revision info". I was able to do it using git. Is there any bazaar command equivalent to "git svn clone -s -r98000:HEAD http://...." ? I mean: Is is possible to tell Bazaar to consider revisions *starting* at revision 98000 ? Thanks a lot :) | 08:03 |
| mgz | morning all! | 09:02 |
| vila | heya mgz | 09:10 |
| mgz | well, the twisted-doc package is pretty useless, api docs are only online | 11:13 |
| mgz | meh, need someone who actually understands twisted to look over this code, I've got no idea from their docs or code what idioms make sense | 11:23 |
| mgz | http.Request is particularly mysterious, the process() method doesn't deal in deferreds so I'm not sure of the best way of doing error handling in response | 11:24 |
| mgz | I guess just in callbacks? | 11:24 |
| mgz | currently there's a funny mix of code that runs now and raises exceptions and deferred stuff that may have later issues | 11:25 |
| czajkowski | aloha | 12:42 |
| czajkowski | was wondering if someone could help with a https://answers.launchpad.net/launchpad/+question/187958 | 12:43 |
| jelmer | hi czajkowski | 12:44 |
| jelmer | czajkowski: it sounds like they're reverting the working tree locally rather than actually removing history from the branch | 12:44 |
| * jelmer adds an answer | 12:44 | |
| czajkowski | jelmer: thanks | 13:07 |
| vila | mgz: special treat for you: http://package-import.ubuntu.com/status/phpbb3.html#2012-02-17%2012:04:16.547398 | 13:39 |
| mgz | heh | 13:41 |
| vila | mgz: can you confirm it's some bad file name encoding and especially which one ? That's the first time I see 'tar' being fooled this way | 13:42 |
| mgz | well, it depends what's actually in the tar | 13:42 |
| vila | bytes ? | 13:42 |
| vila | linux is not supposed to interpret any file name right ? | 13:43 |
| vila | and neither is tar AIUI | 13:43 |
| mgz | the octal escapes for latin-1 chars seems a little cute, but is that just in the output? | 13:43 |
| vila | ok, I'll let you know once I can reproduce locally (I've got another repro recipe in flight) | 13:45 |
| vila | just for the record, I upgraded pristine-tar to 1.20 on jubany (with losa help) and that fixed ~40 of the ~70 previous failures \o/ | 13:46 |
| vila | but apparently a newer xz|xz-utils is needed for a good chunk of the remaining ones, phpbb3 above is yet another failure but I thought about you ;) | 13:47 |
| vila | jelmer: in other news, I also upgraded bzr to current bzr.dev on jubany and I now see deprecated calls for tree.inventory in builddeb | 13:47 |
| vila | jelmer: should I file a bug or are you aware of the issue already | 13:48 |
| jelmer | vila: a bug report would be great | 13:49 |
| vila | ok, will do (and may even give it a try, shouldn't be that hard with all the tracebacks I already have) | 13:49 |
| jelmer | vila: I have something already in progress, let me see about pushing that up | 13:50 |
| vila | ha even better | 13:50 |
| jelmer | IIRC it was still giving some test error that I haven't tracked down | 13:50 |
| jelmer | ah, no - I remember what it was | 13:50 |
| jelmer | I was going to add Tree.iter_child_entries | 13:51 |
| vila | I haven't upgraded builddeb on jubany, still running revno 709 | 13:51 |
| vila | oh, in bzrlib itself you mean ? | 13:51 |
| vila | revno 709 == 2.8.2 | 13:51 |
| jelmer | vila: Yeah - iterating over children is the main reason we access the inventory nowadays | 13:52 |
| jelmer | and it will also be good to have that abstraction for nested trees later on | 13:53 |
| vila | iter_entries_by_dir is not enough ? | 13:53 |
| wgz | oddly, that seems to be arabic, not german | 13:53 |
| wgz | شال | 13:53 |
| wgz | makes sense, whereas ÔÇÄ does not. | 13:53 |
| vila | >_< | 13:53 |
| vila | wgz: you read arabic ? | 13:54 |
| jelmer | vila: that yields specific file ids or the entire tree | 13:54 |
| vila | k | 13:54 |
| wgz | vila: nope, but I can do some search engine wrangling :) | 13:55 |
| wgz | http://en.wiktionary.org/wiki/شال | 13:55 |
| wgz | amusing word to pick. | 13:55 |
| vila | hmm, "truth is out there" comes to mind :) I fail to see why this word would be used in a dir name... | 13:58 |
| vila | well, given the german_(formal_honorifics) in front of it that is | 13:58 |
| vila | may ask my daughter when she comes back ;) | 13:58 |
| vila | jelmer: sorted out my notify issues, 'bzr-notify' is still found in /usr/bin even with sources installed (silly me), how do you run it from sources ? symlink in your $PATH ? Some ppa ? | 14:00 |
| jelmer | vila: I use a symlink | 14:01 |
| jelmer | we do also have daily builds, but I think the last few builds have failed (and I haven't had time to look into that yet) | 14:01 |
| vila | no worries, was just curious, I've been relying on the system-wide install for a few months, but I like notify enough to switch to a symlink for now ;) | 14:02 |
| GGhh | hi bzrists. couple of questions: 1) what's the cleanest way to rename a bzr repo, I mean the folder containing the .bzr sub-folder ? --- 2) Can "bzr mv" act on whole directories, i.e. moving a whole tree in another location of the repo? thx | 14:06 |
| vila | GGhh: 1) mv, 2) no, 'bzr mv' works *inside* a tree | 14:11 |
| GGhh | vila: ok, so the argument to "bzr mv" can only be a single file, right? | 14:12 |
| GGhh | vile: I mean, your answer is a bit terse: "inside a tree" I have plenty of (sub) trees... | 14:16 |
| GGhh | vila I meant | 14:16 |
| GGhh | (from my understanding: "tree == directory") | 14:17 |
| vila | sry, was afk | 14:39 |
| vila | by tree I meant a bzr controlled working tree | 14:40 |
| vila | bzr mv --help gives the details several files can be specified, the final DESTINATION can a dir in this case | 14:41 |
| vila | just like 'mv' | 14:41 |
| vila | the folder containing .bzr can be moved as you see fit unless you it's used by another folder containing a .bzr, i.e. if you use standalone branches (where .bzr contains the metadata for the tree, the branch and the repo) you can move them as you see fit | 14:43 |
| vila | if you use a shared repo, you can move your branches and trees as long as they stay *below* the shared repo | 14:43 |
| vila | finally, if you use checkouts that refer to branches then these branches can still be moved but you'll need to fix the references from the checkouts (working trees) afterwards | 14:44 |
| vila | GGhh: ^ | 14:44 |
| GGhh | vila: reading | 14:45 |
| === bigjools is now known as bigjools-afk | ||
| GGhh | vila: I think I got it. thx. trying | 14:53 |
| vila | GGhh: the best way to check which .bzr dirs are involved is 'bzr info -v' | 14:54 |
| vila | bah, scratch -v, just 'bzr info' | 14:54 |
| GGhh | vila: ok thx | 15:01 |
| jelmer | vila: posted https://code.launchpad.net/~jelmer/bzr-builddeb/no-tree-inventory/+merge/93581 | 15:19 |
| vila | ouch, just hit AssertionError: Somehow we ended up with too much compressed data, 4108 > 4096, but that seems to be without extensions compiled (too many debug stuff in flight) | 15:22 |
| vila | jelmer: approved | 15:23 |
| jelmer | vila: dankuwelmerci! | 15:24 |
| vila | :) | 15:24 |
| vila | jelmer: ping me once it's landed and I'll deploy on jubany | 15:24 |
| jelmer | vila: it has landed | 15:25 |
| vila | jelmer: it is deployed :) | 15:25 |
| jelmer | \o/ | 15:26 |
| quicksilver | what's the simplest way to --show-id a single file. | 16:27 |
| quicksilver | I know I can bzr ls --show-ids the containing directory | 16:28 |
| quicksilver | but that seems roundabout | 16:28 |
| LarstiQ | quicksilver: `bzr file-id <FILENAME>` | 16:35 |
| quicksilver | LarstiQ: weirdly that's missing from 'bzr help commands' | 16:45 |
| LarstiQ | quicksilver: it's hidden | 16:45 |
| quicksilver | I did bzr help commands | grep id before asking | 16:45 |
| quicksilver | why? | 16:46 |
| LarstiQ | quicksilver: bzr help hidden-commands | 16:46 |
| LarstiQ | quicksilver: because it is of limited use and would clog up the help page I think | 16:47 |
| quicksilver | interesting. | 16:47 |
| quicksilver | but 'bzr help commands' is the long boring list anyway. | 16:47 |
| vila | quicksilver: and also because we try hard to not expose any *-id stuff as they shouldn't be needed | 16:47 |
| quicksilver | vila: I don't know any other way to get my head clear about files accidentally deleted and re-added | 16:48 |
| quicksilver | or file conflicts incorrectly resolved by moving files around without telling bzr | 16:48 |
| vila | which is a bug that should be fixed (deleted/re-added) | 16:48 |
| vila | 'bzr resolve --take-{other|mine} file' is expected to help you avoid that :-} | 16:49 |
| vila | (conflicts inccorrectly resolved) | 16:49 |
| vila | s/cc/c/ | 16:49 |
| quicksilver | help you avoid getting in that state in teh first place | 16:49 |
| vila | yup | 16:49 |
| quicksilver | but not help you disentangle that state once you observer you are in it | 16:49 |
| vila | right | 16:50 |
| vila | hey, I'm not blaming you for suffering from bzr bugs ;) Just explaining the rationales ;) | 16:50 |
| quicksilver | :) | 16:50 |
| quicksilver | sure. But I thikn a good principle is to always expose the tools to enable users to understand the data model | 16:51 |
| vila | for the later case, 'bzr st -C<suspicious> --show-ids' helps | 16:51 |
| vila | or 'bzr st -r<right hand>..<merge> --show-ids' | 16:52 |
| vila | quicksilver: yeah, the principle is good but... may also lead to exposing internals and let the user deal with the defects | 16:53 |
| quicksilver | true | 16:54 |
| vila | quicksilver: the simple rule "don't expose *-id" push us to refine the UI | 16:54 |
| quicksilver | but without revids you have no unique way to refer to a commit | 16:54 |
| vila | conflict resolution is.... hard, let's have a beer :) | 16:54 |
| quicksilver | :) | 16:55 |
| vila | oh, inside a given branch revno do wonders, even inside a set of branches for a given project with a reasonable workflow | 16:55 |
| vila | ... so many assumptions hidden behind 'reasonable' :-/ | 16:56 |
| quicksilver | sure you can cook up a local naming scheme like "foo-branch:41.2.1" | 16:56 |
| quicksilver | but somtimes just being able to say "quicksilver@theboss-12345" is convenient | 16:56 |
| vila | my main objections to opaque revids is that... they don't carry any useful info, they're just a token with no ordering | 16:58 |
| vila | and in most of the discussions the basic question is: right, is this revid older or younger than that one | 16:58 |
| quicksilver | really? | 16:58 |
| quicksilver | never had that discussion | 16:58 |
| quicksilver | my discussion is more "which branches is that revid in/not in" | 16:59 |
| vila | bug reports, irc | 16:59 |
| vila | yeah, ancestry checks too | 16:59 |
| vila | but if you share a common branch, the revno is also meaningful | 16:59 |
| === zyga is now known as zyg-afk | ||
| vila | jelmer: wow, just fixed an additional bug with https://code.launchpad.net/~vila/bzr/930182-display-reg-options/+merge/92807 good thing you push me there ;) | 17:04 |
| quicksilver | vila: dotted revnos don't have the information you ask for either | 17:05 |
| quicksilver | vila: 543.2.16 isn't before or after 832.8.54 | 17:06 |
| quicksilver | you know the first one *branched* earlier | 17:06 |
| quicksilver | btu you don't know anything about when they happened, or if one has merged the other. | 17:06 |
| quicksilver | they contain precisely one more piece of information - when they branched from master. That doesn't seem that interesting. | 17:06 |
| jelmer | vila: hah, I was just reviewing that mp | 17:08 |
| quicksilver | whereas, funnily enough, supposedly opaque revids actually have date and author information in. | 17:09 |
| quicksilver | so I conclude that revids have more information in that dotted revnos :P | 17:09 |
| jelmer | the ones generated by bzr itself generally are. For example, revisions imported from git are just "git-v1:SOMEUUID" | 17:12 |
| jelmer | but yeah, it's very useful to be able to refer to a specific revision by just a globally unique fairly short string | 17:12 |
| vila | jelmer: make sure you look at the rev I just pushed ! | 17:18 |
| vila | jelmer: and thanks :) | 17:18 |
| vila | quicksilver: yeah, dotted revnos, <shudder> long and old discussions, there are alternate ways but they aren't trivial | 17:19 |
| quicksilver | don't get me wrong, I like dotted revnos | 17:20 |
| vila | gtg, friends arrived earlier than expected, have a good week-end all ! | 17:20 |
| quicksilver | I think they're handy and concise and in some cases more memoryable | 17:20 |
| quicksilver | I just think revids have a place too :) | 17:20 |
| quicksilver | have a great weekend. | 17:20 |
| vila | quicksilver: hehe, I know opaque tokens are useful too ;) | 17:20 |
| jelmer | vila: you too vila! | 17:21 |
| === bigjools-afk is now known as bigjools | ||
| === zyg-afk is now known as zyga | ||
| === deryck is now known as deryck[lunch] | ||
| === deryck[lunch] is now known as deryck | ||
| === RenatoSilva is now known as Pikkachu | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!