[00:00] <Peng> beuno: bzr-search_integration + bzr.dev are working. :)
[00:00] <beuno> Peng, yay!
[00:01] <beuno> now, really off to bed
[00:01] <beuno> g'night
[00:01] <Peng> beuno: (Well, trunk + bzr-search_integration + my serve-branches.py changes.)
[00:01] <Peng> beuno: G'night. :)
[00:02] <james_w> [cliff]: you can merge it with "bzr merge /path/to/bundle", is that what you did?
[00:02] <LaserJock> Peng: hmm, are there any suggestions for good ways to keep branches out of the way?
[00:02] <[cliff]> james_w, not an absolute path, no. let me try that
[00:02] <LaserJock> bzr tends to make me not want to branch much
[00:02] <james_w> [cliff]: relative will work as well.
[00:03] <[cliff]> james_w, right... same result
[00:03] <Peng> LaserJock: No, I'm just crushed under a pile of separate branches. Sorry.
[00:03]  * Peng wanders off.
[00:03] <[cliff]> the NotBranchError doesn't appear to be used a lot. I was trying to figure out if there is a way of tracing it
[00:04] <james_w> [cliff]: see "bzr help debug-flags" for one thing that can help. There's also plenty of information in ~/.bzr.log
[00:04] <james_w> LaserJock: you can simulate it with one checkout and switch
[00:04] <james_w> LaserJock: there is loom, which is like quilt
[00:04] <[cliff]> james_w, says no help could be found for debug-flags... maybe I'm missing a package
[00:05] <LaserJock> james_w: hmm, I'll have a look at those
[00:05] <james_w> LaserJock: and it's possible that a plugin for multiple branches in a dir will turn up next week
[00:05] <LaserJock> I just feel like I'm losing the power of a DVCS if I'm not doing any branching
[00:05] <james_w> [cliff]: sounds like you have an old bzr, which would explain the error. What version are you using?
[00:05] <[cliff]> but .bzr.log does the trick! nice one. checking it out
[00:06] <[cliff]> james_w, 1.3.1, ubuntu's standard I think
[00:06] <james_w> [cliff]: I'd check with --version
[00:06] <[cliff]> james_w, right, 1.3.1
[00:07] <james_w> [cliff]: ah, sorry, "bzr help global-options" has a debugging flags section.
[00:07] <[cliff]> just out of curiosity, how do you manage to output those nice traces?
[00:07] <james_w> the traceback module
[00:07] <[cliff]> nice one, cheers
[00:08] <[cliff]> it appears the error is raised on "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 1426, in find_format
[00:08] <james_w> traceback.format_exc() will print the last one, there are other functions for being more specific
[00:09] <james_w> [cliff]: can you pastebin the relevant stanza from ~/.bzr.log please, I'll see if I can spot anything
[00:09] <[cliff]> certainly
[00:10] <[cliff]> james_w, http://pastebin.com/d65b306ce
[00:10] <james_w> ah, I meant the whole section, but the traceback is a start, let me look
[00:12] <james_w> hmm, it does know that it is a bundle apparently
[00:13] <[cliff]> I've updated the pastebin
[00:16] <james_w> [cliff]: ah, got it I think, can you read the top of the bundle and see what submit_branch is?
[00:16] <[cliff]> none, I only have a target_branch
[00:17] <james_w> is that a URL?
[00:17] <[cliff]> nope, a relative path
[00:17] <[cliff]> that doesn't exist on my filesystem
[00:17] <james_w> ah yeah, target branch
[00:17] <[cliff]> don't know if it's relevant but I managed to successfully merge another bundle on a different branch
[00:17] <james_w> I was reading it wrong
[00:18] <james_w> yeah, the bundle has been created wrong
[00:18] <james_w> if you could ask the person that sent it to tell you how they created it it would be useful
[00:18] <james_w> this should probably be caught
[00:19] <[cliff]> how should we do it? I'm going to smack the other guy on the head hehe
[00:19] <[cliff]> I can ask him, but not now, he's off for the weekend
[00:19] <james_w> so, a merge directive has a submit branch, which is the branch that you intend it to be merged in to.
[00:19] <[cliff]> I'll try to reach him still
[00:20] <james_w> ah, I see something else as well
[00:21] <james_w> you can specify this as the first argument to "bzr send"
[00:21] <[cliff]> james_w, hmmmm although I understand (or at least I think so :-) ) how come the target_branch can't be ignored when merging the bundle to the current workbranch?
[00:21] <james_w> if you don't then it uses the branch's parent
[00:22] <[cliff]> so for example the submit branch should be .
[00:22] <[cliff]> ?
[00:22] <james_w> it stores the branch location in the merge directive as you saw, but if the target branch has a "public_url" set then that will stored instead.
[00:23] <james_w> running "bzr send" creates a bundle (the base64 encoded bit at the bottom) that has all of the revisions that are in your current branch, and not in the submit branch.
[00:23] <james_w> so "." is pretty much always wrong, as this will be the empty set, which isn't what you wnat
[00:24] <james_w> he should have a mirror of your branch (or just use the location of it if it is public) and point to that
[00:24] <james_w> now, I see this in the code:
[00:24] <james_w>                 except errors.RevisionNotPresent:
[00:24] <james_w>                     # At least one dependency isn't present.  Try installing
[00:24] <james_w>                     # missing revisions from the submit branch
[00:24] <james_w>                     submit_branch = _mod_branch.Branch.open(self.target_branch)
[00:25] <james_w> which is where it fails
[00:25] <[cliff]> I see. let me shed some light on this matter. the way we're working is like this: a master-branch is stored on a server and all devs have a local branch off it. when someone wants to work on something, they branch their copy of the master-branch into a new branch
[00:25] <[cliff]> so the way the dev created the bundle was by bundling the differences between his work branch and his local copy of the master-branch
[00:25] <[cliff]> so the target_branch reflects his own fs directory layout
[00:26] <james_w> yep, that should work correctly.
[00:26] <james_w> you should set "public_url" on the local copy to be the url of the master branch.
[00:26] <james_w> is your copy of the branch out of date compared to master?
[00:26] <[cliff]> hehe which one? :-) the local or the remote?
[00:26] <[cliff]> yup
[00:27] <james_w> ok, so what should happen here is that it would fetch these missing revisions from the master branch, but as the location of that was set to a local path in the merge directive it cant get to it
[00:28] <[cliff]> hhhhmmmmmm
[00:29] <james_w> I'm working up an example
[00:29] <[cliff]> got the guy out of the bed :-) I've asked his revno of the master
[00:30] <james_w> heh
[00:30] <james_w> unfortunately I can't find documentation on public_url
[00:31] <james_w> so, if you have http://server/master
[00:31] <james_w> and a local ~/dev/master
[00:31] <james_w> and your feature branch to submit ~/dev/feature
[00:31] <[cliff]> james_w, that's it. my master is at a different revno of this master
[00:31] <[cliff]> james_w, that's it. my master is at a different revno of his master
[00:32] <james_w> and you set "public_url = http://server/master" in ~/.bazaar/locations.conf for ~/dev/master
[00:33] <james_w> then "bzr send ~/dev/master" should do the right thing from ~/dev/feature
[00:33] <james_w> and if the parent of the feature branch is master then "bzr send" should work
[00:34] <james_w> [cliff]: does that match your set up?
[00:34] <[cliff]> we don't set the public_url actually
[00:34] <james_w> yeah, that's why I think this fell over.
[00:35] <james_w> I'm going to see if I can write a test for this so that we can provide a better error
[00:37] <[cliff]> hmmmm maybe insert a note in the documentation, that should be sufficient (and easier to do I think)
[00:37] <[cliff]> I reckon the bundle parts of the documentation could use some love
[00:38] <james_w> yeah, it does seem to confuse people sometimes.
[00:38] <james_w> it works really well when it works
[00:38] <james_w> We can spot this problem quite easily I think, so providing an informative error would be good, even with improved documentation
[00:39] <[cliff]> true
[00:39] <james_w> I think I see a similar problem just below as well, so we can catch that as well.
[00:41] <[cliff]> he sent me a proper bundle now (branched off the same revno I have and created the bundle based on that). I'm checking out, it's close to 1am :-) thanks a lot for your help james_w
[01:03] <chandlerc[g]> jelmer: you about? i'm hitting weird errors with bzr-svn
[01:08] <chandlerc[g]> jelmer: http://pastebin.com/d1e4f1b42
[01:08] <chandlerc[g]> happy to help any way I can w/ debugging.
[01:16] <james_w> chandlerc[g]: https://bugs.edge.launchpad.net/bzr/+bug/246635
[01:16] <ubottu> Launchpad bug 246635 in bzr "svn+ syntax may be deprecated but it is still essential" [Undecided,New]
[01:17] <chandlerc[g]> james_w: yep, that explains the first one. thanks, i'll add myself to the CC of that one
[01:19] <chandlerc[g]> still no clue about the second one...
[01:19] <chandlerc[g]> its just a segfault, w/o any traceback or anything
[01:19] <chandlerc[g]> maybe i'll try and to a gdb on it
[01:24] <chandlerc[g]> jelmer: I did some gdb poking: http://pastebin.com/d6e9e66cf  I'll rebuild ra.so with debugging symbols tonight, and let you know what I find.
=== Pieter is now known as Pieter|Paris
[06:59] <lifeless> jelmer: Bug 247787
[06:59] <ubottu> Launchpad bug 247787 in bzr-svn "assert len(tview) == tview_len" [Undecided,New] https://launchpad.net/bugs/247787
[10:32]  * ToyKeeper hopes his vis changes get approved and merged
[10:40] <beuno> ToyKeeper, approved  :)
[10:40] <beuno> now you just need jelmer to pitch in
[10:41] <ToyKeeper> I'm just sending a summary + merge directive, to make things clearer.
[10:42] <ToyKeeper> I'm not too familiar with bundle buggy.  Does it take the first merge directive in a thread, or the last?
[10:42] <beuno> ToyKeeper, always the latest one
[10:43] <beuno> each time you send a new one, it overrides the previous one
[10:43] <ToyKeeper> Okay, good.
[10:43] <beuno> ToyKeeper, http://bundlebuggy.vernstok.nl/bzr-gtk/request/%3C20080712094212.GA15283@mutt.xyzz.org%3E
[10:44] <ToyKeeper> I had the wrong public branch the first time too, thinking it was supposed to be my public branch, not trunk.
[10:44] <ToyKeeper> Jasper's message in the olive bookmarks thread cleared that up for me.
[10:45] <beuno> ToyKeeper, patch looks great, really, thanks for working on it
[10:46] <beuno> ah, we have 2 bundlebuggys now
[10:46] <beuno> jelmer, which are we using?
[10:53] <ToyKeeper> I feel dirty about building labels in an unrolled loop, but didn't see an obviously better approach.
[10:54] <ToyKeeper> Anyway, vis, gci, and mdiff (diff with meld) are the only GUI bits I really use.
[10:54] <ToyKeeper> Hmm, maybe gblame, once in a while.
[10:56]  * beuno is trying to pack before check-out time
[10:58] <apol> where can I find the bzr python api?
[10:58] <apol> i've been looking for it for a while and I can't find it
[11:00] <beuno> apol, you mean, documentation for it?
[11:00] <beuno> http://starship.python.net/crew/mwh/bzrlibapi/
[11:00] <apol> beuno: yes, yesterday i found a page that showed how to add files, remove files and so using python
[11:01] <beuno> apol, http://doc.bazaar-vcs.org/latest/developers/integration.html
[11:01] <apol> (i'm a the kdev+bzr test thingie)
[11:01] <apol> yes that's what I meant
[11:01] <apol> thanks a lot
[11:01] <beuno> apol, ah, Aleix, yes, hi!
[11:02] <apol> ;)
[11:02] <beuno> how's that going?
[11:02] <apol> I should be able to have something working today
[11:02] <beuno> oh, yay!
[11:02] <beuno> please send to the list
[11:02] <beuno> everybody loves screenshots
[11:02] <apol> still working on the multilanguage plugin integration though
[11:03] <apol> beuno: I'll consider that ;)
[11:05] <beuno> apol, and, also, bzr-gtk may be a good place to find out how to get some things from bzr
[11:06] <apol> beuno: nice, I'll get it then...
[11:08] <beuno> alright, I'm off to a 16 hour flight
[11:09] <beuno> apol, I look forward to your screenshots  ;)
[11:34] <Stavros> hello
[11:35] <Stavros> how can i have bzr run pylint on files and aborting the commit if the score is too low?
[11:36] <awilkins> Pre-commit hook?
[11:36] <Stavros> awilkins: this is interesting
[11:36] <Stavros> is there anything ready-made?
[11:40] <awilkins> I don't know. You know, the docs don't even make it clear if hooks can abort steps.
[11:40] <awilkins> But you can probably get them to stop by throwing an error...
[11:41] <james_w> yeah, pre-commit can abort the commit I believe
[11:43] <Stavros> ah, good, thanks
[11:48] <james_w> https://bugs.edge.launchpad.net/bzr/+bug/247847
[11:48] <ubottu> Launchpad bug 247847 in bzr "hooks documentation doesn't clearly state which hooks can modify or abort the operation" [Undecided,New]
[11:48] <james_w> just filed that for you
[13:17] <lifeless> james_w: read more closely please; you're describing bugs incorrectly
[13:18] <james_w> sorry, which ones?
[13:18] <lifeless> 244310 was wrong
[13:18] <lifeless> I'm checking the other recent updates now
[13:19] <lifeless> separately, I'm not sure the platform is relevant for many of the bugs
[13:19] <james_w> oh yeah, I don't know why I put that
[13:19] <lifeless> no prob
[13:20] <james_w> I'm not sure it is for all of them either
[13:20] <james_w> I just got fed up of hunting through each time to dupe them.
[13:21] <james_w> I can pull it out of the ones that probably aren't if you like
[13:21] <lifeless> well
[13:21] <lifeless> not really worth the time I guess
[13:21] <lifeless> just note it for future :)
[13:22] <james_w> sure
[13:22] <james_w> p.s. I have an archive import running at the moment, about 14 hours on main and it's up to kdebase
[13:22] <james_w> debian+ubuntu
[13:23] <lifeless> cool
[13:23] <lifeless> we'll want that to play with Monday :)
[13:24] <james_w> yep, Colin asked me to make sure we had some branches for others to play with next week. There's a bunch of failures, but I think two things account for 90% of them.
[13:24] <james_w> are you still in Istanbul?
[13:24] <lifeless> yup
[13:25] <lifeless> till sunday 4pm
[13:25] <lifeless> (as in 4pm I hit london)
[13:25] <james_w> how was GUADEC?
[13:25] <lifeless> pretty good
[13:25] <lifeless> have you seen the playground?
[13:25] <lifeless> bzr-playground.gnome.org
[13:25] <james_w> no, I haven't looked yet
[13:25] <lifeless> uhm battery; bbiab
[13:49] <lifeless> back
[13:52] <lifeless> hi markh, how went the sprint ?
[13:52] <markh> lifeless: not too bad - I'm still here - but I'm all alone in the bzr world
[13:52] <lifeless> :)
[13:52] <lifeless> james_w: do look at the playground
[13:52] <markh> a couple of people have promised to send a couple of patches - hopefully they will turn into contributors
[13:53] <lifeless> awesome
[13:53] <markh> how is the middle-east (whereever it is you are!)?
[13:53] <markh> successful?
[13:53] <lifeless> istanbul :)
[13:53] <lifeless> pretty intense
[13:53] <lifeless> lots of passionate users of both bzr and git
[13:53] <markh> with the gnome guys, right?
[13:53] <lifeless> yes
[13:54] <james_w> lifeless: it doesn't seem to work too well for me. I just get the project lists, but they don't seem to go anywhere for the people ones, and the trunk ones give a proxy error
[13:54] <markh> you winning their hearts and minds? ;)
[13:54] <lifeless> james_w: the people ones have not created branches of their own yet
[13:54] <lifeless> james_w: the proxy error - needs looking at; its LH again:(. but just refresh and it should come good
[14:02] <mark1> stooopid wireless networks...
[14:02] <lifeless> :)
=== mark1 is now known as markh
[14:22] <awilkins> Woo, lots of bzr-svn branches
[15:42] <apol> why doesnt WorkingTree.has_filename() work? it is always returning True to me... :S
[15:42] <lifeless> apol: really?
[15:43] <apol> lifeless: yes, it is the first time i use it so maybe I'm doing something wrong... :S
[15:43] <lifeless> apol: it only tells you if the _path is versioned_, not if its on disk
[15:43] <lifeless> apol: er, hang on - was looking at wrong code
[15:43] <lifeless> apol: it does a lexists
[15:44] <apol> i just want to know if a path is on a working tree
[15:44] <lifeless> apol: in what manner, do you mean 'is versioned', or 'is present on disk', or 'is versioned and present on disk'
[15:45] <apol> lifeless: is versioned
[15:45] <apol> lifeless: i'm working on the kdev4 support
[15:45] <lifeless> apol: for that, use path2id
[15:45] <apol> lifeless: i just want to know if the user still has to add it or he can work with it (eg check the log or commit)
[15:46] <lifeless> apol: tree.path2id('README.txt') != None
[15:46] <apol> cool
[15:46] <apol> let me check
[15:47] <apol> thanks a lot lifeless
[15:49] <lifeless> no problem :)
[15:51] <lovebug356> Is it possible to merge with another branch but only with one command? ( like git merge --squash)
[15:51] <lovebug356> s/command/commit
[15:51] <lifeless> lovebug356: yes
[15:52] <lifeless> lovebug356: merge FOO && bzr revert --forget-merges && bzr commit -m 'squashed!'
[15:52] <andrea-bs> how about a cherrypick?
[15:52] <lovebug356> lifeless, thanks, will try that.
[15:53] <lifeless> andrea-bs: bzr merge -r x..y FOO && bzr commit -m 'This is a cherrypick'
[15:53] <andrea-bs> oh, thanks lifeless
[15:54] <lifeless> np
[15:54] <lovebug356> And does somebody know how to work with a git branch? tried bzr-git but that crashed
[15:54] <lifeless> lovebug356: your best bet to day is git-fast-export ++ bzr fast-import
[15:55] <lifeless> https://launchpad.net/bzr-fastimport
[15:56] <lovebug356> lifeless, thanks, but can you give a real-life example of that? the recipe is not clear to me
[15:57] <lifeless> lovebug356: I can't, but I am quite sure there are details on the list :).
[15:57] <lifeless> http://bazaar-vcs.org/BzrFastImport
[15:57] <lifeless> that wiki page has a howto
[15:58] <lifeless> bzr init-repo .
[15:58] <lifeless> front-end | bzr fast-import -
[15:58] <lifeless> where front-end is the exporter from git
=== oleavr_ is now known as oleavr
[16:10] <lovebug356> lifeless, ok, thanks it works
[16:11] <lifeless> lovebug356: cool
[16:11] <lifeless> I'm going offline for a while; hope someone else can help on an further questions :)
[16:13] <lovebug356> lifeless, ;-)
[17:04] <antoranz> Hi guys! I had problem with 1.5 with filenames with non-ascii characters
[17:04] <antoranz> A fix has been issued for this... but I found another kind of problem related to non-ascii characters in 1.6b2
[17:05] <antoranz> I posted a report in the same bug in launchpad... should I file a new bug for it?
[17:05] <antoranz> take a look: https://bugs.launchpad.net/bzr/+bug/135320/comments/27
[17:05] <ubottu> Launchpad bug 135320 in bzr "dirstate updating fails if there are symlinks and non-ascii filenames" [Medium,Fix committed]
[17:05] <antoranz> yes... that's it
[17:25] <antoranz> so? File a new bug or leave it like that?
[17:43] <james_w> antoranz: yeah, yours seems to be a different issue, so different bug report please.
[17:44] <antoranz> k
[17:44] <james_w> though is it https://bugs.edge.launchpad.net/bzr/+bug/244360 ?
[17:44] <ubottu> Launchpad bug 244360 in bzr "UnicodeError running "bzr st"" [Undecided,New]
[17:45] <james_w> it looks like it to me, so you could just subscribe to that one
[17:53] <Necoro> hmm ... I need to run bzr under windows ... but using the cmdline seems not to work... or am I missing something?
[17:57] <enobrev> Necoro, have to make sure bzr is in your path
[17:57] <Necoro> how do I do this? have never really used windows
[17:57] <enobrev> Necoro, on my system, I had to add "C:\Program Files\Python25\Scripts" to my system path
[17:59] <enobrev> Right click on "My Computer", go to Properties, Advanced Tab, Environment Variables (button), Look on hte bottom where it says "System Variables", Click on "PATH", then "Edit", and add a semi-colon and the path to your Python Scripts folder to the end of that line.
[18:00] <Necoro> ok - worked... thanks :)
[18:00] <enobrev> sure :)
[18:10] <apol> could somebody tell me why this doesn't work? http://rafb.net/p/bNXtm645.html
[18:10] <apol> or how to add something to a workingtree... 8-)
[18:11] <antoranz> I just added my stuff to that bug.
[18:16] <foobydoo> What's the appropriate URL to file a bug-report for bzr-svn clobbering commits if multiple users are editing their commit messages simultaneously?
[18:18] <luks> apol: smart_add takes a list of paths
[18:18] <luks> what you did is basically wt.smart_add("/home/kde-devel/testbzr/aaa")
[18:18] <luks> er
[18:19] <luks> wt.smart_add(["/", "h", ...])
[18:19] <apol> aaah
[18:20] <apol> luks: thanks a lot
[19:20] <matthewlmcclure> does bazaar have a "copy file" command?
[19:24]  * Foskasse http://failblog.files.wordpress.com/2008/06/fail-duck-writing1.jpg LOL!
=== abadger1999 is now known as abadger_afk
[19:56] <apol_> how can I initialize a directory from python?
[20:03] <james_w> matthewlmcclure: no, it doesn't
[20:03] <james_w> apol_: checkout "bzrlib/builtins.py" for "class cmd_init"
[20:04] <james_w> apol_: that handles a few cases, so you may be able to strip it down depending on what you need
[20:04] <apol_> james_w: cool, thanks
[20:04] <james_w> it's not a simple one-liner though, as you have to deal with formats
[20:04] <apol_> really? :/
[20:04] <apol_> well, I'll check it out
[20:04] <apol_> thanks a lot
[20:05] <james_w> it's not one line, but it is about three I think, if don't need to handle all cases of existing dir, no parent dirs, etc.
[20:34] <matthewlmcclure> james_w: thanks
[21:43] <libwilliam> I have a question... With bzr send... Is the --message option only used with the email option of send?
[21:46] <libwilliam> Nevermind, I guess it works with the --output also... I thought it didn't but I wanted to ask first, but the test I did that made me think I didn't was wrong.
[21:46] <libwilliam> So ignore these message :)
[21:46] <libwilliam> messages*