[00:00] <bob2> aedan: only make framework changes on the framework branch.  or at least put the changes you want to send the other way in self contained commtis.
[00:00] <bob2> I dunno how smart bzr is about cherrypicking these days
[00:01] <aedan> bob2: Ooh, so you're saying, if possible, commit only the changed framework files, then I can pull from that revision?
[00:04] <lifeless> spiv: ugh
[00:20] <lifeless> mwhudson: its rsyunc
[00:31] <marianom> lifeless: thanks for the suggestions you provided me earlier today. already migrated and all issues fixed.
[00:32] <lifeless> marianom: excellent
[00:37] <bob2> heh, bzr.dev is too old to work with bzrtools.dev
[00:52] <mwhudson> spiv, lifeless: did my no-LockableFiles.__del__ patch fail tests?
[00:54] <lifeless> mwhudson: no it was pending a prior patch, one sec
[00:54] <mwhudson> k
[00:57] <mwhudson> lifeless: i still get
[00:57] <mwhudson> error: Error -5 while decompressing data
[00:57] <mwhudson> on the bzr.dev.chk
[00:57] <mwhudson> i have a 64 bit install, could that be related?
[00:58] <jelmer> lifeless, did you see my reply about default-rich-root ?
[00:59] <lifeless> mwhudson: from what? (I have a 64-bit install too)
[00:59] <lifeless> jelmer: no
[00:59] <jelmer> lifeless, http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/53957
[00:59] <mwhudson> lifeless: bzr log --short -l 10
[00:59] <mwhudson> lifeless: brisbane-core @ 3875
[00:59] <mwhudson> bzr-groupcompress @ 47
[01:01] <lifeless> rollback to 43
[01:01] <mwhudson> lifeless: ah, now we're go
[01:01] <lifeless> jelmer: you want a new format, default-rich-root, which should be an alias for another format right?
[01:03] <jelmer> lifeless, Yes, but what format it is an alias for will change in the future
[01:03] <jelmer> just like --default does
[01:03] <lifeless> jelmer: right, which is what aliases are all about
[01:03] <jelmer> lifeless, right
[01:03] <lifeless> jelmer: so just register an alias
[01:04] <jelmer> lifeless, that's what I'm doing afaik
[01:04] <lifeless> no, you're adding a new method
[01:04] <jelmer> well, a new method to maintain the alias
[01:04] <lifeless> you just need to register a new format that is an alias
[01:06] <jelmer> lifeless, so you basically want me to move the contents of set_default_rich_root() to the top-level of bzrlib/bzrdir.py ?
[01:07] <jelmer> lifeless, imho it's cleaner having that stuff in a separate method
[01:07] <lifeless> uhh
[01:08] <mwhudson> lifeless, jam, etc: bzrlib/_chk_map_pyx.pyx seems to have an error in brisbane-core
[01:08] <mwhudson> /home/mwh/canonical/repos/bzr/brisbane-core/bzrlib/_chk_map_pyx.pyx:232:25: Expected an identifier or literal
[01:09] <lifeless> jelmer: no; I'm suggesting you do what the other alias formats do
[01:09] <lifeless> jelmer: which would be consistent :)
[01:09] <mwhudson> oh
[01:09] <mwhudson> my pyrex does'
[01:09] <jelmer> lifeless, which means duplicating the branch format / repo format in a couple of places
[01:09] <mwhudson> n't support ++
[01:09] <mwhudson> +=
[01:11] <jelmer> lifeless: anyway, if it's consistent I'll fix my patch but the way the aliases work seems suboptimal to me
[01:11] <lifeless> jelmer: one place only. You could also put in a patch to make alias formats easier to manage; I object to the patch you have put in because it widens the registry interface specially rather than generally
[01:11] <lifeless> when the thing that is needed is already in  general use.
[01:14]  * mwhudson is thinking that delta computation must be a little tiny bit faster in chk repos: http://pastebin.ubuntu.com/130001/
[01:14] <mwhudson> strangely though log --short -l 10 still takes 3 seconds
[01:15] <mwhudson> and heck
[01:15] <mwhudson> *-l 1* takes 3s
[01:17] <lifeless> spiv: (Pdb) ll = bzrlib.registry._LazyObjectGetter('bzrlib.branch', 'Branch.hooks')
[01:17] <lifeless> (Pdb) ll.get_obj()
[01:17] <lifeless> *** AttributeError: 'module' object has no attribute 'Branch.hooks'
[01:17] <mwhudson> something is killing "start up" time on chk branches
[01:17] <lifeless> spiv: I am not liking this :(
[01:27] <lifeless> spiv: I would like a hand, otherwise I will feel that the code I have that works is better
[01:39] <jam> mwhudson, lifeless: the startup time could easily be the time to unpack the one large group for all of the revision texts.
[01:39] <jam> we have a couple ideas of how to make that better
[01:40] <jam> and I'll go ahead and work out a fix for broken old pyrex versions :)
[01:40] <lifeless> jam: we might want to do something about that
[01:41] <glyph> 'bzr visualize' is a completely awesome thing
[01:41] <glyph> thank you all
[01:41] <lifeless> mwhudson: --lsprof on log --short -l 10 might be useful
[01:41] <glyph> for making it possible
[01:41] <lifeless> glyph: you're welcome
[01:42] <glyph> suggestion though: "bzr glog" might be a good alias for it
[01:42] <mwhudson> jam: http://pastebin.ubuntu.com/130009/
[01:43] <glyph> is 'dvc' the generally preferred emacs integration mechanism for bzr?
[01:43] <mwhudson> lifeless: http://pastebin.ubuntu.com/130010/
[01:43]  * mwhudson not feeling so good, biab
[01:44] <lifeless> glyph: glog would be an awesome alias
[01:45] <jam> mwhudson: what is the 'iter_inventory_xml_keys' change?
[01:45] <lifeless> glyph: vila: will know
[01:45] <jam> otherwise, I understand the += => = a + change
[01:45] <mwhudson> jam: something lifeless gave me yesterday, i didn't mean to give that to you :)
[01:45] <jam> and it is committed to brisbane-core 3876
[01:45] <mwhudson> jam: the .pyx fix is all i needed to make it compile
[01:45] <mwhudson> cool :)
[01:47] <jam> mwhudson: try setting _NO_LABELS = True
[01:47] <jam> in groupcompress.py
[01:48] <jam> and see how that changes "bzr log --short" time
[01:50] <jam> mwhudson: ah, that won't actually make a difference, as it parses the labels if they are there
[01:51] <jam> I can give you a one-line change to the parser, though, just a sec
[01:56] <jam> mwhudson: you can cherrypick revno 48, or use: http://pastebin.ubuntu.com/130013/
[01:57] <jam> (sorry it isn't 1 line, but it was cleaner this way)
[02:20] <jam> mwhudson: that patch has some typos, this one is better: http://pastebin.ubuntu.com/130019/
[02:20] <jam> it drops off about 300ms for me on 'bzr log --short -r -10..-1'
[02:32] <jfroy> vila: quick fyi: new patch is up
[02:43] <mwhudson> jam: it gets me back to "error: Error -5 while decompressing data"
[02:45] <mwhudson> jam: oh no, pebkac; it just doesn't apply cleanly to r43 of groupcompress
[03:02] <mwhudson> so my branch of loggerhead is less of a dos attack on servers, i hope
[03:02] <mwhudson> it still does a pretty good job on firefox if you ask for it...
[03:27] <lifeless> mwhudson: cool
[03:28] <mwhudson> oh and the code is horrible beyond all belief
[03:28] <lifeless> :*(
[03:28] <lifeless> why
[03:28] <mwhudson> because i've been hacking
[03:29] <mwhudson> now i know it works and feels ok, it's time to do it right
[03:29] <lifeless> wat have you done
[03:30] <mwhudson> some ajaxy loading
[03:30] <mwhudson> play, if you like: bzr+ssh://bazaar.launchpad.net/~mwhudson/loggerhead/finite-revision-pages
[03:33] <lifeless> what does it do though
[03:41] <lifeless> mwhudson: like, is it just skipping html rendering on the server?
[03:44] <mwhudson> lifeless: it's more about not including stuff in the initial page sent to the browser
[03:44] <mwhudson> lifeless: so for example, in the changelog view, not sending the list of changed files until the disclosure triangle is clicked
[03:51] <lifeless> mwhudson: cool
[04:01] <gotgenes> I'm having difficulty figuring out when one branch originated from another. I thought bzr viz would show it but I don't see anything obvious. Is there some other way?
[04:14] <SamB> glyph: I have no idea if it's preferred, but if you find any bugs please report them on launchpad ;-)
[04:14] <SamB> re: dvc
[04:16] <poolie> jml, http://imgs.xkcd.com/comics/not_enough_work.png
[04:20] <spiv> mwhudson: your patch landed
[04:27] <jml> poolie: yeah, I've seen it.
[04:27] <jml> glyph: welcome to #bzr :)
[04:38]  * SamB wonders why *bzr-status* is in dvc-diff-mode
[04:39] <poolie> lifeless: thanks for the hooks registry :)
[04:39] <SamB> is there a way to get structured information out of bzr status ?
[04:43] <poolie> SamB from another process? you can try the bzr-xmloutput plugin
[04:44] <SamB> but then I'd have to parse the XML ... no json?
[04:44] <SamB> (just because it's a heck of a lot simpler to parse than XML, not that I'm writing AJAX or anything)
[04:45] <james_w> not currently I believe
[04:45] <james_w> extending bzr-xmloutput could be extended to provide json I guess
[05:11] <abentley> LarstiQ: Hi there, I've started work on nested trees, starting with merging bzr.dev into your latest.
[05:28] <poolie> spiv, not to interrupt you too much, but did you already fix something like bug 341535?
[05:31] <spiv> poolie: I did, for the TCP client medium
[05:31] <spiv> poolie: there's a osutils.until_no_eintr helper
[05:32] <poolie> thanks
[05:32] <poolie> i don't think i care quite enough to do it right now
[05:32] <poolie> maybe when fetch progress is a bit more cooked
[05:37] <SamB> is there a way to cancel a bzr rm ?
[05:39] <jml> SamB: if you mean undo, then 'bzr revert filename' works
[05:42] <SamB> jml: well ... I have files still
[05:43] <jml> SamB: I don't follow.
[05:44] <SamB> they had gotten moved away from where they should have been, is all
[05:45] <SamB> and then I foolishly ran "bzr rm" with no arguments
[05:48] <spiv> SamB: so you have a change in your working copy you want to revert, the change being that some files were unversioned; "bzr revert filenameA filenameB ..." as jml says is the way to undo that.
[05:49] <bob2> hm, should upgrading a bzr.dev mirror to --development take like hours and spin at "checking repository format 1/1" for 2 or so?
[05:54] <lifeless> bob2: possibly :P you'reusing bzr.dev?
[05:55] <bob2> lifeless: yeah
[05:58] <poolie> rfc: there should also be a 'connecting' activity indicator to show that's what we're waiting for
[05:58] <poolie> activity as opposed to a progress thing
[05:59] <SamB> i.e. a spinner
[06:03] <spiv> poolie: it would be nice, although a little bit hard to implement accurately perhaps?  I'm thinking of when bzr+ssh delegates the connecting to an openssh subprocess...
[06:04] <poolie> spiv, i'm basically saying it should do
[06:05] <SamB> spiv: what would it mean for it to be accurate in that situation?
[06:05] <poolie> > report_activity(self, 'connecting')
[06:05] <poolie> before running openssh
[06:06] <poolie> so it won't spin but at least it'll show that rather than just '0kB'
[06:08] <SamB> oh
[06:08] <SamB> you just want a message
[06:08] <SamB> "hey this is what's I'm about to do, just hold on, I'll be right back!"
[06:09] <spiv> poolie: ah, right.  +1
[06:09] <poolie> SamB, exactly
[06:10] <spiv> SamB: Well, there's arguably a significant difference between "waiting for SSH to connect" and "waiting for remote bzr to reply to my first request"
[06:11] <spiv> I'm not sure it really matter too much in practice.  At least at the moment our first requests don't require much processing time on the server.
[06:11] <SamB> spiv: well, it would at least tell you that bzr wasn't ransacking your local storage ...
[06:12] <SamB> though I guess if you're actually sitting at your computer you'd know anyway ...
[06:19] <poolie> spiv, doing something for the hello would be good too
[06:25] <spiv> poolie: when probing for bzr+http?
[06:28] <poolie> or on the first request to the smart server
[06:28] <poolie> just an idea
[06:28] <poolie> it might take a while to get going
[07:34] <poolie> spiv, remote.py has
[07:34] <poolie> 1509         if not resume_tokens:
[07:34] <poolie> 1510             # XXX: Ugly but important for correctness, *will* be fixed during
[07:34] <poolie> 1511             # 1.13 cycle. Pushing a stream that is interrupted results in a
[07:34] <poolie> 1512             # fallback to the _real_repositories sink *with a partial stream*.
[07:34] <poolie> 1513             # Thats bad because we insert less data than bzr expected. To avoid
[07:34] <poolie> 1514             # this we do a trial push to make sure the verb is accessible, and
[07:34] <poolie> 1515             # do not fallback when actually pushing the stream. A cleanup patch
[07:34] <poolie> 1516             # is going to look at rewinding/restarting the stream/partial
[07:34] <poolie> 1517             # buffering etc.
[07:34] <poolie> is that true?
[09:30] <stefanlsd> Can i push a branch i was working on to another server? I did a push and i just get the .bzr directory on the other side (no files)
[09:31] <beuno> stefanlsd, right, remote pushes don't create working trees
[09:32] <beuno> so you have the branch, but not the actual files
[09:32] <beuno> if you want the files, you need to run:  bzr co .
[09:32] <beuno> but subsequent pushes won't update them
[09:32] <beuno> you need the push-and-update plugin for that
[09:32] <beuno> unless you *only* care about the actual files remotely, then you can use bzr-upload
[09:33] <stefanlsd> beuno: mm. im trying to setup that another guy in my office can work on some of the projects with me. So i made a place on a remote server. I wanted to take my local bzr stuff and get it there.  Would it be better to just scp it to the central server now?
[09:34] <beuno> stefanlsd, no, he can just branch from that
[09:34] <stefanlsd> beuno: its not there yet. I have it all locally. i wanted to get it there first by pushing.. should I rather go central and branch it from me?
[09:35] <beuno> stefanlsd, it *is* there
[09:35] <beuno> if you pushed it, and there's a .bzr directory
[09:35] <beuno> that's the branch
[09:35] <beuno> you don't need the working tree (actual files)
[09:36] <stefanlsd> beuno: oh. interesting. wasnt aware of that
[09:40] <stefanlsd> beuno: thanks. so my understanding now is, if i want the working tree there also i need the push and update plugin. will look into that. thx!
[09:40] <beuno> stefanlsd, you're welcome
[09:41] <cristi_an> what is the diff between bzr push and bzr up
[09:41] <cristi_an> ?
[09:42] <beuno> cristi_an, one is used for checkouts, and one is used for branches
[09:42] <beuno> (there's more to it, but let's start with that)
[09:42] <cristi_an> beuno: thx...i did not find this in the 5 min tut :)
[09:43] <cristi_an> which one i sfor checkouts
[09:43] <beuno> cristi_an, how did that question pop into your head?
[09:43] <cristi_an> well...i explain
[09:43] <cristi_an> i get a project called openerp from launchpad
[09:43] <hmeland> The help for up probably ought to mention the term "checkout" somewhere.
[09:44] <cristi_an> but after a few day since i was i cvs user before
[09:44] <cristi_an> i did bzr up
[09:44] <cristi_an> but it did not bring any of the changes done by others
[09:44] <beuno> cristi_an, did you branch it, or did you make a checkout?
[09:46] <cristi_an> beuno: i run a script that get all those projects for me...
[09:46] <cristi_an> http://paste.pocoo.org/show/107535/
[09:47] <beuno> cristi_an, ok, so you branch them
[09:47] <beuno> 'bzr update' won't come into play at all for now
[09:47] <cristi_an> in terms of using cvs
[09:47] <cristi_an> i checkout them...
[09:47] <cristi_an> :)
[09:48] <beuno> well, you can do a checkout with bzr as well
[09:48] <beuno> and then it's basically the same
[09:48] <beuno> when you commit, it will commit directly to the online branch
[09:48] <beuno> "update" brings in new changes, etc
[09:48] <beuno> a checkout is bound to it's parent
[09:48] <cristi_an> but can you tell me what that script does
[09:48] <beuno> branches, on the other hand, are independant
[09:48] <cristi_an> i seee
[09:48] <beuno> yes, it creates branches
[09:49] <cristi_an> so i have c copy locally
[09:49] <cristi_an> and i work local
[09:49] <cristi_an> then i can merge with some server branch
[09:49] <cristi_an> ?
[09:49] <cristi_an> somthing like commit will commit on my local branch
[09:49] <cristi_an> not on server ?
[09:50] <hmeland> cristi_an: Your script takes a --checkout option.  Supply that option with your launchpad username to make the script do "bzr checkout" and "bzr update" instead of "bzr branch" and "bzr pull".
[09:51] <cristi_an> i have to read about this more....
[09:51] <cristi_an> :)
[09:51] <cristi_an> but i got the picture....
[09:52] <cristi_an> thx
[13:00] <nick_> Can anyone help me with setting up a bug tracker within Bazaar? The documentation I've found tells me about it, but not how to do it
[13:25] <hmeland> nick_: What kind of bug tracker are you talking about?
[13:25] <nick_> hmeland: a custom made one - I basically want to know what things I need to put in the bazaar.conf file in order to get it working with --fixes
[13:30] <hmeland> You've seen http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#bug-tracker-settings already?
[13:37] <nick_> hmeland: yes, but it seems to be lacking explanation
[13:37] <nick_> hmeland:  for example, I don't know what parameters Bazaar passes my bug tracker when I mark a commit as --fixed
[13:37] <nick_> I'm assuming it HTTP POSTs by default?
[13:38] <beuno> nick_, no, it's metadata on the branch
[13:38] <beuno> no http communication at all
[13:40] <nick_> beuno: ahhh, so how does the tracker get this information, through a post commit hook?
[13:40] <beuno> nick_, well, it's up to the tracker
[13:40] <beuno> tip-change
[13:40] <beuno> cronjob
[13:40] <beuno> whatever
[13:40] <nick_> beuno:  I see
[13:40] <nick_> beuno:  are you familiar with the shell_hooks plugin at all?
[13:41] <beuno> nick_, not really, no
[13:41] <nick_> beuno: ah, just I can't get it to work :)
[13:41] <nick_> beuno: I'm not well versed with Python
[13:43] <nick_> does anyone know of a post commit hook that can HTTP POST to a URL?
[13:54]  * SamB wishes bzr-gtk didn't have that unintended seahorse dependancy :-(
[13:58] <kfogel> When I bring in changes from someone else's branch via 'bzr merge', I have to write a new log message when I then do 'bzr commit', even though the other person already wrote a log message.  I can even see the original log message when I do 'bzr status' ("pending merge tips: ...", or with -v, "pending merges: ...").  Is there some way to commit the merged change(s) locally such that they automatically get the same author and commit message as
[13:58] <kfogel> the originals?
[13:58] <beuno> kfogel, not atomatically, no
[13:59] <kfogel> beuno: hmrm.  Okay, thanks.  So it sounds like there isn't really a way to say (in a non-mirror branch) "Just bring in these changes, I don't want to have to specify anything more about them, I just want them incorporated into my local branch."
[13:59] <kfogel> ?
[13:59] <beuno> kfogel, right, the merge is always explicit
[14:00] <kfogel> *nod*
[14:00] <kfogel> beuno: thx
[14:00] <beuno> :)
[14:01] <kfogel> beuno: is there at least some way (immediately after 'bzr merge') to get the full information about all merged-but-not-committed changes?  Specifically, I want to list their source branch and revision number, in my commit message.
[14:01] <kfogel> beuno: or is that pointless, because bzr will already record those when I commit?
[14:02] <beuno> other than bzr status?
[14:02] <kfogel> (in which case, great, but I'd still want to *see* the pending revs before committing)
[14:02] <kfogel> beuno: bzr status -v shows committer, date, and msg, but not source branch or rev num
[14:02] <beuno> right, so there's not way that I know of to see those
[14:02] <beuno> that may be useful
[14:03] <beuno> so it sounds like you're cooking a bug there
[14:03] <kfogel> :-)
[14:03] <kfogel> Yeah, it would be nice to be able to see the exact identity of what I'm about to commit.  For an especially paranoid developer, that might be part of a sanity check.
[14:03] <SamB> high in protein!
[14:03] <kfogel> SamB: breakfast of champions!
[14:04] <SamB> but at least you know their descriptions -- darcs isn't even capable of telling me what revisions have conflicted
[14:05]  * kfogel looks at bzrlib/status.py:show_pending_merges()
[14:05] <SamB> (apparantly it's not even easy in theory!)
[14:09]  * awilkins is totally awesomed out by how awesome uploading things to a PPA is
[14:10] <awilkins> Why the hell does it build fricking Atom builds of things though.....
[14:15] <kfogel> beuno: crimminy, don't even have the information available in bzrlib/revision.py:Revision, as far as I can tell.
[14:17] <SamB> Atom ?
[14:18] <SamB> you mean it converts them to RSS feeds?
[14:19] <SamB> (Yeah, I know Atom isn't actually named RSS -- but then basically no two versions of RSS expand to the same name either)
[14:20]  * SamB wonders how glyph found out about dvc
[14:21] <rocky> jelmer: bzr svn-import is currently failing for me (after a few mins of running) on htps://dev.serverzen.com/svn/cluemapper
[14:21] <rocky> jelmer: that's with bzr 1.13rc1 and bzr-svn 0.5.3
[14:23] <kfogel> policy question: when bzr can receive a setting from either an environment variable or the bazaar.conf file, which overrides which?  Does the env var dominate the config setting if both exist, or the other way around?
[14:31] <kfogel> (this is for implementing a new thing -- if it were an existing feature, I'd just test)
[14:54] <SamB> kfogel: well, usually the env var, I hope
[14:54] <kfogel> SamB: that's what I picked
[14:55] <SamB> might depend on the setting a bit, but for instance if I have an emacs package that wants to turn off the progress bar ...
[14:56] <SamB> ... then I'm going to be annoyed by https://bugs.launchpad.net/bzr/+bug/339385
[14:57]  * SamB wishes ubottu would get it right and say "Launchpad bug"
[14:58] <kfogel> SamB: well, that's just because of the bug, right?  It doesn't change the correct ordering.
[14:58] <SamB> yeah
[14:59] <SamB> I was just being silly with that last message
[14:59] <SamB> going to a conclusion unrelated to the premise
[15:00] <SamB> (the premise that the env var should override the conf file, that is)
[15:00] <SamB> (I don't think there is a conf setting for this?)
[15:01] <SamB> I certainly don't see a progress bar setting in my bazaar.conf
[15:02]  * SamB wonders if there's some sort of script to manually convert an svn:ignore property to .bzrignore
[15:03] <SamB> jelmer: is there a way to query SVN revision properties from bzr-svn ?
[15:03] <SamB> no, wait, this would be a file property
[15:03] <SamB> well, both things would be good anyway
[15:04] <SamB> and the way should be mentioned in "bzr help svn", of course
[15:06]  * SamB wonders if there's a way to get launchpad to build and serve docs
[15:16]  * SamB re-opens https://bugs.launchpad.net/bzr-svn/+bug/174947
[15:19] <SamB> does anyone know how to get word-wrap in emacs (without altering the buffer data)?
[15:19] <SamB> i.e. yes, I know how to use M-q, that's not what I want ;-P
[15:25] <SamB> oh, emacswiki says LongLines
[15:25] <jelmer> SamB, I think we did have them at some point but they got removed, since they were just aliases for "svn propset / svn propget"
[15:25] <SamB> jelmer: how's that going to work in a bzr-native format checkout/branch/etc?
[15:26] <jelmer> SamB: there's no way that can work in a bzr native format
[15:26] <SamB> oh
[15:26] <jelmer> SamB, but with a bzr-specific command it can't work in a bzr native format either
[15:26] <jelmer> since the bzr native format can't store custom file properties
[15:26] <SamB> wait, I din't need an answer to how is "svn foo" going to work in a bzr-native directory ;-P
[15:26] <SamB> that was rhetorical
[15:27] <Leon_Nardella> leon@bespin:~/Documents$ bzr update scrip/
[15:27] <Leon_Nardella> Permission denied (publickey).
[15:27] <Leon_Nardella> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) <-- What does this usually mean? I know it's something to do with my messing around backing up the branch to Dropbox and changing keys, but I'm not sure what I can do to make it work now. This branch is hosted on Launchpad and I can check it out without problems.
[15:27] <SamB> I thought you were giving the second (bzr format can't handle that) answer already ;-)
[15:27] <jelmer> SamB, I also mean "bzr svn-propset" can't work in a bzr-native directory
[15:27]  * Leon_Nardella sorry for the multiple lines
[15:27] <jelmer> SamB, since there's no place it can store the properties
[15:27] <SamB> jelmer: oh
[15:28] <jelmer> SamB, the way you've changed the bug report right now indicates I'm working on it.. that's not the case :-)
[15:29] <SamB> jelmer: well, you can change it to something more appropriate
[15:29] <SamB> I thought maybe you'd somehow hidden it where I couldn't see it :-)
[15:29] <SamB> given it a funny name or something
[15:29] <jelmer> SamB, are you still interested in it if it's just going to be an alias for "svn propset" / "svn propget" ?
[15:30] <SamB> not if it requires a .svn dir, no. but some documentation about the uselessness of such a thing would be good.
[15:31] <jelmer> SamB, I'll comment in the bug report
[15:31] <SamB> and I would be interested in extensions to bzr to allow it to be useful, as well
[15:31] <SamB> jelmer: how about adding it to the FAQ?
[15:31] <jelmer> SamB, that's the sort of documentation you meant, right?
[15:31] <SamB> in addition, I mean
[15:33] <SamB> like: "Q: How can I look at my file properties?" "A: If you're in an svn checkout, the usual way. If in a bzr native tree, there aren't any to see."
[15:35] <jelmer> SamB, Care to send a patch ? :-)
[15:40] <sohail> how can I take the difference of two branches?
[15:40] <sohail> one has a bug, one doesn't :-)
[15:41] <sohail> ah --old
[15:42] <sohail> hmm... well that is lying
[15:42] <jelmer> SamB, just curious, what sort of properties would you want to set ?
[15:44] <Odd_Bloke> sohail: How so?
[15:45] <sohail> Odd_Bloke, bzr switch buggy-branch; bzr diff --old non-buggy-branch -> no diff which is not true
[15:46] <sohail> oh do I have to give the full path to the old branch?
[15:46] <sohail> that's annoying but ok
[15:46] <Odd_Bloke> sohail: Yeah, that'll be it.
[15:47] <Odd_Bloke> sohail: Though there should probably be an error message if there isn't a branch at non-buggy-branch...
[15:50] <sohail> Odd_Bloke, I'd agree with that
[15:56] <sohail> ok I need to binary search where this bug was introduced... how do I do that with bzr? is there an equivalent to svn up -r $FOO ?
[15:56] <sohail> sorry if my question is ignorant :-)
[16:00] <Kinnison> you can either make new checkouts at given revisions, or bzr revert might help you since you can pass that -r $FOO
[16:00] <Kinnison> but I'm not a power-user, so I could be wrong
[16:01] <sohail> I just found the bzr bisect plugin
[16:01] <sohail> lets hope it doesn't screw up my repo :-)
[16:03] <glyph> how does one unbind a bound branch
[16:04] <jelmer> glyph, bzr unbind :-)
[16:04] <glyph> jelmer: I figured that out a split second before you said it, and felt appropriately foolish :)
[16:06] <jelmer> glyph, :-)
[16:10] <sohail> haha... bzr bisect: 1115 no, 1118 yes, 1116 yes, 1116, 1116, 1116, 1116, explode
[16:10] <sohail> lol!
[16:10] <sohail> screw this, I'm going ot exercise
[16:12] <Kinnison> heh
[16:22] <ripps> Does anybody here know how to mirror a git repository into a launchpad branch?
[16:35] <SamB> ripps: jelmer might?
[16:35] <SamB> then again maybe you can't
[16:36] <SamB> I think it will involve a cron job on a system you have a shell on, though
[16:36] <jelmer> ripps, small repositories should be convertable with git-import from bzr-git, alternatively you can use git fast-export/ bzr fast-import
[16:36] <jelmer> ripps, there's nothing in launchpad to have it mirror for you automatically (yet)
[16:36] <ripps> jelmer: so, back to manually uploading it
[16:36] <SamB> or if you control the git server you could use some kind of post-hook
[16:37] <SamB> ripps: cron!
[16:37] <SamB> hmm, how come you can't just give launchpad svn:// URLs to mirror the bzr way, anyway?
[16:38] <SamB> why does it have a special vc-import thing for that?
[16:38] <jelmer> SamB, hysterical raisins
[16:38] <jelmer> SamB, vcs-imports predate bzr-svn
[16:38] <SamB> I suppose it's good for the users anyway
[16:38] <SamB> jelmer: oh. how does it work then?
[16:38] <jelmer> SamB, there has been talk about using bzr-svn on lp
[16:38] <jelmer> SamB, but the problem is it will cause disruption for users of the existing mirrors
[16:39] <SamB> I mean, it would be kind of confusing to expect users to just enter an SVN url as if it was a BZR url
[16:39] <jelmer> SamB, it use cscvs
[16:39] <jelmer> SamB, what would be confusing about that?
[16:39] <SamB> jelmer: well, for new users anyway
[16:39] <jelmer> SamB, there are mirrors of "regular" bzr branches too
[16:40] <jelmer> SamB, In general the format of a branch shouldn't matter, whether it's Subversion or native Bazaar
[16:40] <SamB> anyway ... the obvious way to go to bzr-svn would be to allow people to start entering those SVN urls in the field, then tell them about it after a while ...
[16:40] <SamB> and just keep doing vcs-import the same way as before
[16:41] <jelmer> SamB, yeah
[16:41] <jelmer> SamB, unfortunately there's no shared history between stuff imported with vcs-imports and bzr-svn
[16:41] <jelmer> SamB, so users can't really migrate from vcs-imports to bzr-svn
[16:41] <SamB> yeah
[16:42] <SamB> but giving new users the option is good
[16:42] <SamB> does bzr-rebase share git-rebase's "no revision 0" flaw?
[16:42] <jelmer> SamB: well, it means that if somebody you work together with happens to do a commit based on a bzr-svn branch and your branch is a vcs-improts branch it breaks
[16:42] <SamB> jelmer: oh
[16:42] <SamB> it breaks?
[16:43] <jelmer> SamB, "breaks" in the sense that it doesn't have any shared history
[16:43] <SamB> it doesn't just ... not show up nicely?
[16:43] <SamB> vcs-imports doesn't grok SVK attributes?
[16:43] <SamB> anyway, that doesn't sound much worse than using SVN in the first place ...
[16:43] <jelmer> SamB, and will attempt to merge from rev 0 as it doesn't see common revisions
[16:43] <SamB> jelmer: huh?
[16:43] <jelmer> SamB, I'm not sure I understand what SVK has to do with it
[16:43] <SamB> what do you mean?
[16:44] <jelmer> SamB, it will attempt to merge *all* revisions from the bzr-svn branch as none are present in the vcs-imports branch
[16:44] <SamB> oh
[16:44] <jelmer> SamB, bzr-rebase doesn't have any "no revision 0" flaws
[16:44] <SamB> you mean if you try to pull a commit across via bzr!
[16:45] <SamB> apparantly git-rebase can't really rebase between branches with different roots :-(
[16:45] <SamB> I read somewhere a proposal for a special 00000... commit
[16:46] <jelmer> SamB, bzr already has such a thing
[16:46] <SamB> I thought probably
[16:46] <SamB> sounds better than git-svn, anyway ;-)
[16:47] <jelmer> SamB, so the main reason bzr-svn isn't supported at the moment yet is because it would cause confusion for existing vcs-imports users and problems merging
[16:47] <SamB> git-svn users are encouraged not to share git commits!
[16:47] <jelmer> SamB, whoa, wasn't aware of that
[16:48] <SamB> since it doesn't roundtrip too well
[16:48] <Odd_Bloke> Yeah, bzr-svn is just a ridiculous amount better than git-svn.
[16:49] <SamB> so having two incompatible tools doesn't sound nearly as bad
[16:49] <Odd_Bloke> In terms of actual functionality.
[16:49] <SamB> yeah
[16:49] <SamB> now if only it didn't spend so much time apparantly doing nothing ...
[16:49] <jelmer> SamB, are you running 0.5.3 yet?
[16:49] <Odd_Bloke> Maybe not so much in terms of speed, but <insert tired argument about features > speed here>
[16:50] <SamB> svn 0.5.4dev
[16:50] <jelmer> SamB, and what in particular is slow?
[16:51] <SamB> hmm.
[16:51] <SamB> it's stopped doing it.
[16:51] <SamB> typical!
[16:54] <SamB> hmm, maybe that's because that branch was bound to the SVN repository ...
[16:55] <SamB> bzr-svn just seems to spend an inordinate amount of time looking at svn revisions it's already seen
[16:55] <SamB> even when there are no revisions to pull
[16:56] <SamB> but apparantly not when your working directory is a heavyweight bzr-native SVN checkout
[16:57] <SamB> is there a way to dump the progress output?
[17:02] <jelmer> SamB, Not really
[17:02] <jelmer> SamB, you can run with -Dtransport and see what sort of protocol requests it's doing
[17:02] <jelmer> SamB, what progress bar phase is it spending the most time in during pull ?
[17:02] <SamB> it skips back and forth
[17:04] <SamB> there ought to be a way to dump either a trace or at least a sampling of the progress bar phases ...
[17:04] <jelmer> SamB, skips back and forward between what?
[17:04] <jelmer> SamB, what texts in the progress bar I mean
[17:05] <SamB> I know, that's what I'm saying should be traceable
[17:05] <SamB> discovering revisions and determining changes
[17:05] <SamB> Pull phase
[17:06] <SamB> and the SVN revnums are all over the place as it does that
[17:06] <SamB> hmm, gotta go to school now
[17:07] <jelmer> SamB, might be looking at tags
[17:07] <jelmer> SamB, That should hopefully be fixed in the next version
[17:08] <SamB> why does bzr not being able to delete a non-empty directory count as a conflict?
[17:10] <jelmer> SamB, because upstream has removed a directory and locally that directory can't be removed
[17:10] <SamB> I know what it means
[17:10] <SamB> but why's that a conflict?
[17:10] <SamB> it should be something more like a sticky warning or ...
[17:10] <SamB> I mean it's just object files, probably ...
[17:11] <jelmer> SamB: Well, I was stating it like that to hopefully clarify that the operation that happened remotely can't happen locally
[17:11] <SamB> I know but conflict seems a bit harsh a status for it
[17:12] <jelmer> and that's basically what a conflict is about
[17:12] <SamB> in that case
[17:12] <SamB> the directory can just be removed from version control, can't it?
[17:12] <jelmer> SamB, if there's only ignored files in it, sure
[17:12] <jelmer> SamB, but in that case the user probably won't be aware of it
[17:12] <SamB> oh. is ignoring that important?
[17:13] <SamB> well, it still seems slightly less urgent than a warning
[17:13] <SamB> er. s/warning/conflict/
[17:14] <jelmer> SamB, so you think a directory should become "unknown" at that point?
[17:15] <jelmer> SamB, in that case you risk that a user runs "bzr add" to add their other unknown files and ends up re-versioning the directory
[17:15] <SamB> hmm.
[17:15] <SamB> maybe I'd just like it to be easier to say "okay, go ahead and unversion that"
[17:15] <jelmer> SamB, right
[17:15] <SamB> could be something to add to dvc
[17:16] <jelmer> SamB, I think it would be reasonable to automatically mark a conflict as resolved if the remote removed a file/directory but it was changed locally
[17:16] <jelmer> SamB, and the user then removed the local files
[17:16] <SamB> hmm.
[17:17] <SamB> well, I didn't remove it yet actually
[17:17] <SamB> I'm so lazy
[17:17] <jelmer> join the club :-)
[17:18] <SamB> I still don't get why bzr-status and bzr-conflicts use dvc-diff-mode ...
[19:57] <mwhudson> jelmer: hello
[19:59] <BasicOSX> We still on track for 1.13final on 03/13 or should I push a 1.1.3rc2? I've posted to bazaar general about it.
[20:07] <ovnicraft> hi, i see in lauchpad trac-bzr is part of bzr if anyone can help me here?
[20:07] <mwhudson> BasicOSX: how many changes have hit bzr.1.13 since rc1 ?
[20:08] <mwhudson> BasicOSX: i was going to nag you about sneaking some patches in, but i don't think it's worth it any more
[20:10] <BasicOSX> mwhudson:  do not know the number of changes, don't have ability to check right now, and I don't control the freeze, I just do the work of pushing the release :-)
[20:11] <mwhudson> BasicOSX: do you know what revno 1.13rc1 was?
[20:12] <BasicOSX> bzr log, look for 'Release 1.13rc1'
[20:13] <LarstiQ> bzr log -m Release\ 1.13rc1
[20:13] <mwhudson> hm, there have been two landings
[20:13] <LarstiQ> ovnicraft: do you have an actual question?
[20:13] <mwhudson> (vila) Fix non ascii symlink handling
[20:13] <mwhudson>       (spiv) Fix bogus 'Source format does not support stacking' warning
[20:13] <mwhudson>         when pushing to smart server
[20:13] <BasicOSX>     revno: 4104.1.1, should be PQM submission
[20:14] <LarstiQ> abentley: ok, how is that going?
[20:15] <mwhudson> both look reasonably minor
[20:15] <mwhudson> though i guess the non-ascii one could potentially cause problems
[20:16] <ovnicraft> LarstiQ, i have problems with trac-bzr i get the output
[20:16] <ovnicraft> can you help me about that?
[20:17] <lucypher> Hi , I can't branch a project from launchpad , here the result: http://pastebin.com/m41156b8b
[20:17] <lucypher> I'm on Ubuntu jaunty
[20:17] <LarstiQ> ovnicraft: I can try, but so far I don't know what problem you are experiencing
[20:18] <LarstiQ> lucypher: Permission denied (publickey) is the important part
[20:19] <mwhudson> hmmm
[20:19] <awilkins> Ah, he's defined launchpad-login but either hasn't uploaded a key or doesn't have it available to the local bzr process
[20:19] <mwhudson> why isn't the non-ascii symlink fix in bzr.dev
[20:20] <mwhudson> vila: hi :)
[20:20] <lucypher> LarstiQ : I did...     bzr lp-login
[20:21] <awilkins> lucypher: Did you upload a public key, and is it available in your local ssh-agent
[20:21] <awilkins> Or even in ~/.ssh/id_rsa
[20:21] <awilkins> (the private key to go with that public key)
[20:22] <LarstiQ> lucypher: have you followed a process like https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair ?
[20:22] <LarstiQ> lucypher: the ssh server on launchpad is complaining it doesn't know the key you are trying to log in with
[20:23] <lucypher> I've moved my Home partition recently and did some cleanup... ;-)
[20:23] <LarstiQ> lucypher: that might explain it ;)
[20:23] <ovnicraft> LarstiQ, any pastebin to this channel?
[20:24] <ovnicraft> LarstiQ, http://pastebin.com/m35bd5f39
[20:24] <ovnicraft> my error
[20:24] <lucypher> LarstiQ , awilkins : thanks
[20:25] <jelmer> mwhudson, hi
[20:25] <mwhudson> jelmer: so, bzr-svn vs codespeak currently breaks because of that svn bug
[20:26] <mwhudson> jelmer: i can probably remove the problem revprops
[20:26] <mwhudson> jelmer: if you explain how :)
[20:26] <mwhudson> (i can probably figure it out myself, but my brain is on go-slow today)
[20:27] <awilkins> AFAICR if you set them to an empty value they will be removed
[20:27] <awilkins> Ah, or propdel
[20:28] <awilkins> svn propdel PROPNAME --revprop -r REV
[20:28] <jelmer> mwhudson, the problem is it isn't not the revprops
[20:28] <jelmer> mwhudson, it's fileprops
[20:28] <mwhudson> jelmer: grunk
[20:29] <mwhudson> jelmer: i guess committing a change that deleted the file props wouldn't help?
[20:29] <mwhudson> i mean, i have root on the box, all things are possible :)
[20:29] <mwhudson> but i'd rather not knacker the repo
[20:29] <jelmer> mwhudson: fixing it will require a svndump + edit of the svn dump + reload
[20:30] <mwhudson> jelmer: if i manage to do an import over svn+ssh:// or even file:/// will updating it over http: work?
[20:30] <jelmer> mwhudson, I think so
[20:32] <vila> mwhudson: hi (still syncing my clock so unsure if *your* was minutes or hours ago :-)
[20:32] <mwhudson> vila: minutes :)
[20:32] <mwhudson> vila: you landed a change to bzr.1.13 wrt unicode symlinks
[20:32] <mwhudson> vila: it doesn't seem to be in bzr.dev
[20:32] <mwhudson> vila: any deep reason for that?
[20:34] <jelmer> mwhudson, alternatively, you could add a hack to bzr-svn to assume an empty set of properties if it can't retrieve them
[20:35] <mwhudson> jelmer: hm, that sounds interesting
[20:35] <jelmer> mwhudson, there should only be one place where it's called
[20:36] <vila> mwhudson: check again, it should have been merged back
[20:36] <jelmer> mwhudson, I'd rather not have it in mainline bzr-svn though, since the error that is raised is a generic "RA request failed"
[20:37] <mwhudson> vila: oh right. r4124
[20:46] <jelmer> LarstiQ, perhaps in changelog
[20:48] <awilkins> Have we gone gpl2 ?
[20:48] <LarstiQ> awilkins: bzr-svn
[20:48] <LarstiQ> jelmer: I'm mimicing debian unstable now
[20:52] <jelmer> awilkins, GPLv2 or later specifically, it was GPLv3 or later
[20:53] <awilkins> Righto
[20:58] <jelmer> LarstiQ: Yeah, in hindsight I probably should've mentioned it
[20:58] <ovnicraft> LarstiQ, did you check my error with trac-bzr?
[20:59] <LarstiQ> ovnicraft: ah yes, it wasn't familiar, I then went to look if there was a bug filed for it but trailed off
[20:59] <LarstiQ> ovnicraft: what version of trac integration are you using?
[21:01] <ovnicraft> trac <IP_ADDRESS> - plugin from branch
[21:02] <LarstiQ> ovnicraft: which version of trac bzr?
[21:02] <ovnicraft> 0.2
[21:03] <LarstiQ> ovnicraft: https://bugs.launchpad.net/trac-bzr/+bug/318839 and https://bugs.launchpad.net/trac-bzr/+bug/341916 look similar
[21:03] <LarstiQ> ovnicraft: oh, that latter one is by you :)
[21:06]  * LarstiQ wonders how to track his ppa upload status
[21:17] <LarstiQ> aha! A view build records link, sneakily hiding out of view.
[21:23] <abentley> LarstiQ: Well, I've got the physical merge done, but I haven't got it logically updated so that all the tests pass.
[21:23] <abentley> LarstiQ: It's at http://code.aaronbentley.com/bzr/bzrrepo/nested-trees
[21:28] <LarstiQ> abentley: thanks for the heads up btw
[21:29] <abentley> LarstiQ: np
[21:35] <LarstiQ> gah, even in a short time the diff ratchets up :/
[21:47] <EnCuKou> Hello. Does anybody know about a bzrlib transport that simulates network failures, for testing?
[21:47] <EnCuKou> It shouldn't be too hard to write a simple one, I'd just like to reuse if one's floating around somewhere.
[21:50] <Peng_> EnCuKou: There might be stuff in the test suite.
[21:53] <EnCuKou> Peng_: Thanks. I didn't find much there though.
[21:57] <vila> EnCuKou: Hi !
[21:57] <vila> EnCuKou: There is no such thing as transport simulating failures, you want test servers simulating failures instead
[21:57] <EnCuKou> vila: Hello!
[21:58] <EnCuKou> vila: Okay, I'll look for that.
[21:59] <vila> EnCuKou: As a starting point you can have a look at bzrlib.tests.http_utils.py I think or http_server.py
[21:59] <loffe> Is there a way to ignore files when using "bzr upload"? (For example I don't wan't to upload my test cases but I want them in my repo)
[21:59] <vila> loffe: not yet, but  we're thinking about it
[21:59] <EnCuKou> vila: Okay, thanks
[22:00] <vila> loffe: filtered views may also be a way to address that, but again nothing works out of the box right now
[22:00] <loffe> vila, "thinking" as in "has not written it yet" or "not sure if it's needed" ?
[22:00] <vila> loffe: "thinking" as in "beuno kicked my ass enough that it will be written" :)
[22:01] <loffe> hehe
[22:01] <vila> EnCuKou: the closest server for what you're after may be test_http.TestWallServer
[22:02] <loffe> Is there any "smart" way of adding my testcases now?
[22:03] <vila> loffe: adding testscases *is* smart ;)
[22:04] <loffe> yeah, that was my idea, but I don't want to upload them (and then delete from webserver)
[22:04] <vila> loffe: seriously, if you want to use bzr-upload yet have test cases, write them in a different branch
[22:04] <vila> as in separate branches
[22:04] <EnCuKou> vila: Okay. I'll need some time to grok how it works, but I think I'll manage with your hints ^^
[22:07] <loffe> ok. So how do I create a "sub"-branch within my working tree?
[22:07] <loffe> bzr: ERROR: No repository present: "file:///media/windows/Users/Eloff/Documents/src/jobb/www/timjack.se/trunk/tests/"
[22:08] <loffe> when doing "bzr init tests/"
[22:09] <vila> EnCuKou: you may also want to have a look at lp:~vila/bzr/local-test-server, search for and install pyftpdlib (code.google.com/p/pyftpdlib/ ) and start a test server with failure from there
[22:10] <vila> loffe: better create your branch *outside* of the initial one for now, later on, there will be better ways to manage that setup, but for now, that's the best I can think of
[22:11] <vila> loffe: I understand it sub optimal as you will need to commit in both though....
[22:12] <EnCuKou> vila: OK
[22:12] <loffe> vila, yea, how long till upload ignore is working? weeks, months?
[22:15] <vila> loffe: not years :-) But patches welcome !
[22:16] <loffe> vila, Maybe I'll look into it. Have just fallen in love with python :)
[22:17] <vila> loffe: The main blocking point is the lack of a good and easy to modify ftp test server, and that will be available RSN
[22:27] <cyberix> I received a patch that was created with bzr send, but for some reason that persons commit did not appear in my bzr log
[22:28] <cyberix> Only my own commit, which I did after merging the patch in, is shown on the log
[22:36] <james_w> cyberix: how did you merge the patch?
[22:36] <bob2> lifeless: still upgrading to --development after 20 hours - should I ctrl-c and file a bug w/backtrace?
[22:36] <cyberix> bzr merge ../foo.patch
[22:37] <james_w> cyberix: that should work, does "bzr --no-aliases log" show it?
[22:37] <bob2> did you commit right after merging?
[22:38] <cyberix> james_w: no
[22:38] <cyberix> bob2: yes
[22:40] <james_w> odd
[22:41] <cyberix> http://www.cs.helsinki.fi/u/froblom/Kunquat/kunquat-photos.patch
[22:41] <cyberix> This is the patch
[22:41] <cyberix> It is huge
[22:41] <cyberix> It cointains a few jpgs
[22:44] <cyberix> Is there something wrong with it?
[22:44] <cyberix> You could try merging it yourself
[22:45] <cyberix> how this actually work
[22:46] <cyberix> she did her send against the lp trunk branch
[22:46] <cyberix> should I still be able to merge it in?
[22:46] <cyberix> to my own branch
[22:46] <cyberix> or can it only be merged to lp trunk?
[22:50] <cyberix> i.e. Is it at all possible to send a patch to someone, without having access to his branch?
[22:52] <cyberix> or
[22:52] <cyberix> Should anyone be able to apply that patch after doing "bzr branch lp:kunquat"?
[22:58] <lifeless> bob2: is strace showing activity?
[23:00] <AirBender> Hello
[23:01] <bob2> lifeless: yes, and it's eating 95% of a cpu
[23:01] <AirBender> I'm looking for a simple way of tracking the current version of my source code inside my code, and also with autotools, in order to show the current version automatically
[23:02] <AirBender> may be a header file generated by bzr like config.h of autotools?
[23:06] <Peng_> AirBender: bzr help version-info
[23:08] <lifeless> bob2: hit ctrl-\ and get a backtrace :)
[23:09] <bob2> lol debuggerry
[23:09] <SamB> Peng: but doesn't that vary branch-to-branch?
[23:09] <bob2> SamB: isn't that the point?
[23:10] <bob2> (you want the revid not the revno)
[23:10] <SamB> ah
[23:14] <AirBender> thanks Peng_ that's what i'm looking for, but still don't know how to integrate it with my configure.ac file in order to keep the version at make dist time
[23:15] <AirBender> but I think this is more likely an autotools question
[23:25] <lifeless> spiv: I've audited bzr.dev for missing patches
[23:35] <igc> morning