bob2is bzr-hg maintained upstream?00:57
=== SamB_ is now known as SamB
vilahi all07: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
frgomeshello 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
mgzmorning all!09:02
vilaheya mgz09:10
mgzwell, the twisted-doc package is pretty useless, api docs are only online11:13
mgzmeh, need someone who actually understands twisted to look over this code, I've got no idea from their docs or code what idioms make sense11:23
mgzhttp.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 response11:24
mgzI guess just in callbacks?11:24
mgzcurrently there's a funny mix of code that runs now and raises exceptions and deferred stuff that may have later issues11:25
czajkowskiwas wondering if someone  could help with a https://answers.launchpad.net/launchpad/+question/18795812:43
jelmerhi czajkowski12:44
jelmerczajkowski: it sounds like they're reverting the working tree locally rather than actually removing history from the branch12:44
* jelmer adds an answer12:44
czajkowskijelmer: thanks13:07
vilamgz: special treat for you: http://package-import.ubuntu.com/status/phpbb3.html#2012-02-17%2012:04:16.54739813:39
vilamgz: 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 way13:42
mgzwell, it depends what's actually in the tar13:42
vilabytes ?13:42
vilalinux is not supposed to interpret any file name right ?13:43
vilaand neither is tar AIUI13:43
mgzthe octal escapes for latin-1 chars seems a little cute, but is that just in the output?13:43
vilaok, I'll let you know once I can reproduce locally (I've got  another repro recipe in flight)13:45
vilajust 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
vilabut 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
vilajelmer: in other news, I also upgraded bzr to current bzr.dev on jubany and I now see deprecated calls for tree.inventory in builddeb13:47
vilajelmer: should I file a bug or are you aware of the issue already13:48
jelmervila: a bug report would be great13:49
vilaok, will do (and may even give it a try, shouldn't be that hard with all the tracebacks I already have)13:49
jelmervila: I have something already in progress, let me see about pushing that up13:50
vilaha even better13:50
jelmerIIRC it was still giving some test error that I haven't tracked down13:50
jelmerah, no - I remember what it was13:50
jelmerI was going to add Tree.iter_child_entries13:51
vilaI haven't upgraded builddeb on jubany, still running revno 70913:51
vilaoh, in bzrlib itself you mean ?13:51
vilarevno 709 == 2.8.213:51
jelmervila: Yeah - iterating over children is the main reason we access the inventory nowadays13:52
jelmerand it will also be good to have that abstraction for nested trees later on13:53
vilaiter_entries_by_dir is not enough ?13:53
wgzoddly, that seems to be arabic, not german13:53
wgzmakes sense, whereas ÔÇÄ does not.13:53
vilawgz: you read arabic ?13:54
jelmervila: that yields specific file ids or the entire tree13:54
wgzvila: nope, but I can do some search engine wrangling :)13:55
wgzamusing word to pick.13:55
vilahmm, "truth is out there" comes to mind :) I fail to see why this word would be used in a dir name...13:58
vilawell, given the german_(formal_honorifics) in front of it that is13:58
vilamay ask my daughter when she comes back ;)13:58
vilajelmer: 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
jelmervila: I use a symlink14:01
jelmerwe 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
vilano 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
GGhhhi 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? thx14:06
vilaGGhh: 1) mv, 2) no, 'bzr mv' works *inside* a tree14:11
GGhhvila: ok, so the argument to "bzr mv" can only be a single file, right?14:12
GGhhvile: I mean, your answer is a bit terse: "inside a tree" I have plenty of (sub) trees...14:16
GGhhvila I meant14:16
GGhh(from my understanding: "tree == directory")14:17
vilasry, was afk14:39
vilaby tree I meant a bzr controlled working tree14:40
vilabzr mv --help gives the details several files can be specified, the final DESTINATION can a dir in this case14:41
vilajust like 'mv'14:41
vilathe 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 fit14:43
vilaif you use a shared repo, you can move your branches and trees as long as they stay *below* the shared repo14:43
vilafinally, 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) afterwards14:44
vilaGGhh: ^14:44
GGhhvila: reading14:45
=== bigjools is now known as bigjools-afk
GGhhvila: I think I got it. thx. trying14:53
vilaGGhh: the best way to check which .bzr dirs are involved is 'bzr info -v'14:54
vilabah, scratch -v, just 'bzr info'14:54
GGhhvila: ok thx15:01
jelmervila: posted https://code.launchpad.net/~jelmer/bzr-builddeb/no-tree-inventory/+merge/9358115:19
vilaouch, 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
vilajelmer: approved15:23
jelmervila: dankuwelmerci!15:24
vilajelmer: ping me once it's landed and I'll deploy on jubany15:24
jelmervila: it has landed15:25
vilajelmer: it is deployed :)15:25
quicksilverwhat's the simplest way to --show-id a single file.16:27
quicksilverI know I can bzr ls --show-ids the containing directory16:28
quicksilverbut that seems roundabout16:28
LarstiQquicksilver: `bzr file-id <FILENAME>`16:35
quicksilverLarstiQ: weirdly that's missing from 'bzr help commands'16:45
LarstiQquicksilver: it's hidden16:45
quicksilverI did bzr help commands | grep id before asking16:45
LarstiQquicksilver: bzr help hidden-commands16:46
LarstiQquicksilver: because it is of limited use and would clog up the help page I think16:47
quicksilverbut 'bzr help commands' is the long boring list anyway.16:47
vilaquicksilver: and also because we try hard to not expose any *-id stuff as they shouldn't be needed16:47
quicksilvervila: I don't know any other way to get my head clear about files accidentally deleted and re-added16:48
quicksilveror file conflicts incorrectly resolved by moving files around without telling bzr16:48
vilawhich 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
quicksilverhelp you avoid getting in that state in teh first place16:49
quicksilverbut not help you disentangle that state once you observer you are in it16:49
vilahey, I'm not blaming you for suffering from bzr bugs ;) Just explaining the rationales ;)16:50
quicksilversure. But I thikn a good principle is to always expose the tools to enable users to understand the data model16:51
vilafor the later case, 'bzr st -C<suspicious> --show-ids' helps16:51
vilaor 'bzr st -r<right hand>..<merge> --show-ids'16:52
vilaquicksilver: yeah, the principle is good but... may also lead to exposing internals and let the user deal with the defects16:53
vilaquicksilver: the simple rule "don't expose *-id" push us to refine the UI16:54
quicksilverbut without revids you have no unique way to refer to a commit16:54
vilaconflict resolution is.... hard, let's have a beer :)16:54
vilaoh, inside a given branch revno do wonders, even inside a set of branches for a given project with a reasonable workflow16:55
vila... so many assumptions hidden behind 'reasonable' :-/16:56
quicksilversure you can cook up a local naming scheme like "foo-branch:41.2.1"16:56
quicksilverbut somtimes just being able to say "quicksilver@theboss-12345" is convenient16:56
vilamy main objections to opaque revids is that... they don't carry any useful info, they're just a token with no ordering16:58
vilaand in most of the discussions the basic question is: right, is this revid older or younger than that one16:58
quicksilvernever had that discussion16:58
quicksilvermy discussion is more "which branches is that revid in/not in"16:59
vilabug reports, irc16:59
vilayeah, ancestry checks too16:59
vilabut if you share a common branch, the revno is also meaningful16:59
=== zyga is now known as zyg-afk
vilajelmer: 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
quicksilvervila: dotted revnos don't have the information you ask for either17:05
quicksilvervila: 543.2.16 isn't before or after 832.8.5417:06
quicksilveryou know the first one *branched* earlier17:06
quicksilverbtu you don't know anything about when they happened, or if one has merged the other.17:06
quicksilverthey contain precisely one more piece of information - when they branched from master. That doesn't seem that interesting.17:06
jelmervila: hah, I was just reviewing that mp17:08
quicksilverwhereas, funnily enough, supposedly opaque revids actually have date and author information in.17:09
quicksilverso I conclude that revids have more information in that dotted revnos :P17:09
jelmerthe ones generated by bzr itself generally are. For example, revisions imported from git are just "git-v1:SOMEUUID"17:12
jelmerbut yeah, it's very useful to be able to refer to a specific revision by just a globally unique fairly short string17:12
vilajelmer: make sure you look at the rev I just pushed !17:18
vilajelmer: and thanks :)17:18
vilaquicksilver: yeah, dotted revnos, <shudder> long and old discussions, there are alternate ways but they aren't trivial17:19
quicksilverdon't get me wrong, I like dotted revnos17:20
vilagtg, friends arrived earlier than expected, have a good week-end all !17:20
quicksilverI think they're handy and concise and in some cases more memoryable17:20
quicksilverI just think revids have a place too :)17:20
quicksilverhave a great weekend.17:20
vilaquicksilver: hehe, I know opaque tokens are useful too ;)17:20
jelmervila: 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!