[00:57] <bob2> is bzr-hg maintained upstream?
[00:58] <lifeless> yesish
=== SamB_ is now known as SamB
[07:01] <vila> hi all
=== 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
[08:03] <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 :)
[09:02] <mgz> morning all!
[09:10] <vila> heya mgz
[11:13] <mgz> well, the twisted-doc package is pretty useless, api docs are only online
[11:23] <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:24] <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:25] <mgz> currently there's a funny mix of code that runs now and raises exceptions and deferred stuff that may have later issues
[12:42] <czajkowski> aloha
[12:43] <czajkowski> was wondering if someone  could help with a https://answers.launchpad.net/launchpad/+question/187958
[12:44] <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
[13:07] <czajkowski> jelmer: thanks
[13:39] <vila> mgz: special treat for you: http://package-import.ubuntu.com/status/phpbb3.html#2012-02-17%2012:04:16.547398
[13:41] <mgz> heh
[13:42] <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:43] <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:45] <vila> ok, I'll let you know once I can reproduce locally (I've got  another repro recipe in flight)
[13:46] <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:47] <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:48] <vila> jelmer: should I file a bug or are you aware of the issue already
[13:49] <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:50] <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:51] <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:52] <jelmer> vila: Yeah - iterating over children is the main reason we access the inventory nowadays
[13:53] <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:54] <vila> wgz: you read arabic ?
[13:54] <jelmer> vila: that yields specific file ids or the entire tree
[13:54] <vila> k
[13:55] <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:58] <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 ;)
[14:00] <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:01] <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:02] <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:06] <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:11] <vila> GGhh: 1) mv, 2) no, 'bzr mv' works *inside* a tree
[14:12] <GGhh> vila: ok, so the argument to "bzr mv" can only be a single file, right?
[14:16] <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:17] <GGhh> (from my understanding: "tree == directory")
[14:39] <vila> sry, was afk
[14:40] <vila> by tree I meant a bzr controlled working tree
[14:41] <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:43] <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:44] <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:45] <GGhh> vila: reading
=== bigjools is now known as bigjools-afk
[14:53] <GGhh> vila: I think I got it. thx. trying
[14:54] <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'
[15:01] <GGhh> vila: ok thx
[15:19] <jelmer> vila: posted https://code.launchpad.net/~jelmer/bzr-builddeb/no-tree-inventory/+merge/93581
[15:22] <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:23] <vila> jelmer: approved
[15:24] <jelmer> vila: dankuwelmerci!
[15:24] <vila> :)
[15:24] <vila> jelmer: ping me once it's landed and I'll deploy on jubany
[15:25] <jelmer> vila: it has landed
[15:25] <vila> jelmer: it is deployed :)
[15:26] <jelmer> \o/
[16:27] <quicksilver> what's the simplest way to --show-id a single file.
[16:28] <quicksilver> I know I can bzr ls --show-ids the containing directory
[16:28] <quicksilver> but that seems roundabout
[16:35] <LarstiQ> quicksilver: `bzr file-id <FILENAME>`
[16:45] <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:46] <quicksilver> why?
[16:46] <LarstiQ> quicksilver: bzr help hidden-commands
[16:47] <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:48] <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:49] <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:50] <vila> right
[16:50] <vila> hey, I'm not blaming you for suffering from bzr bugs ;) Just explaining the rationales ;)
[16:50] <quicksilver> :)
[16:51] <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:52] <vila> or 'bzr st -r<right hand>..<merge> --show-ids'
[16:53] <vila> quicksilver: yeah, the principle is good but... may also lead to exposing internals and let the user deal with the defects
[16:54] <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:55] <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:56] <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:58] <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:59] <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
=== zyga is now known as zyg-afk
[17:04] <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:05] <quicksilver> vila: dotted revnos don't have the information you ask for either
[17:06] <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:08] <jelmer> vila: hah, I was just reviewing that mp
[17:09] <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:12] <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:18] <vila> jelmer: make sure you look at the rev I just pushed !
[17:18] <vila> jelmer: and thanks :)
[17:19] <vila> quicksilver: yeah, dotted revnos, <shudder> long and old discussions, there are alternate ways but they aren't trivial
[17:20] <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:21] <jelmer> vila: you too vila!
=== 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