[00:26] <lifeless> spiv: ping; my place is available if you're interested; or I can head north.
[00:30] <Pegasus_RPG> hello there.
[00:30] <Pegasus_RPG> If a repo's URL changes, can bzr be told of that change or do people need to do a new checkout/branch?
[00:33] <lifeless> Pegasus_RPG: 'bzr switch' can be used to change what things are checkouts of
[00:33] <lifeless> branches don't care, they just need to pass the url to the next pull/merge
[00:33] <lifeless> e.g. 'bzr pull URL --remember'
[00:34] <Pegasus_RPG> lifeless: ok, so a user needs to issue both a switch and the pull --remember?
[00:34] <lifeless> Pegasus_RPG: either/or
[00:34] <Pegasus_RPG> oh ok cool
[00:35] <Pegasus_RPG> thank you muchly
[00:35] <lifeless> if they have a checkout, switch, if they have a branch, pull/merge --remember
[00:35] <Pegasus_RPG> (The #mixxx teamis getting our feet wet)
[00:35] <Pegasus_RPG> with bzr
[00:35] <lifeless> cool
[00:35] <Pegasus_RPG> reading "Bazaar was made for merges" made me happy
[00:36] <Pegasus_RPG> (I recently had to merge one of our branches to trunk on SVN...not fun)
[00:36] <Pegasus_RPG> btw, is there any decent Linux GUI for BZR? (Like KDESVN is for svn?)
[00:36] <lifeless> http://www.mixxx.org/ ?
[00:36] <Pegasus_RPG> yep that's us
[00:37] <lifeless> for kde, you should look at qbzr
[00:37] <Pegasus_RPG> ok thanks
[00:37] <lifeless> for gnome there is gtk-bzrn
[00:37] <lifeless> *gtk-bzr*
[00:37]  * Pegasus_RPG has kde and was not impressed with Olive
[00:37] <lifeless> olive is gtk based
[00:37] <lifeless> you may like qbzr more
[00:38] <lifeless> and please file bugs about the things you'd like different
[00:38] <lifeless> they are both under active development
[00:38] <Pegasus_RPG> OK cool. Thanks again
[00:40] <shtylman> can I create bazaar users without creating system users? I guess similar to how subversion could create users?
[00:41] <spiv> lifeless: I'll head south soon, just sending a fix for the get_parent_map bug
[00:41] <lifeless> cool
[00:41] <mwhudson> shtylman: svn doesn't really know about users either, do you mean the apache integration?
[00:42] <mwhudson> shtylman: but the answer is approximately "no"
[00:42] <shtylman> mwhudson: I see...so places like launchpad...they create system wide uers?...lets say I can do that...how then do I limit the user to bzr only?
[00:42] <shtylman> is that possible...?
[00:42] <mwhudson> shtylman: launchpad has a custom ssh server
[00:42] <shtylman> ahh
[00:43] <mwhudson> shtylman: you can play tricks with .ssh/authorized_keys though
[00:44] <mwhudson> (i think this is what bitbucket does for ex)
[00:46] <shtylman> mwhudson: k...thanks..I will look into some alternatives
[01:27] <jelmer> lifeless: did my InterBranch.pull patch look ok to you other than the issues you raised?
[01:28] <lifeless> jelmer: I haven't looked all that closely; as long as there is a per_interbranch test parameterisation done sanely, its probably good
[01:37] <jelmer> lifless: yeah, I think that is the case (we already had the infrastructure for InterBranch.update_revisions())
[02:20] <beuno> hello hello
[02:21] <beuno> as of yesterday
[02:21] <beuno> bzr is amazingly slow
[02:21] <beuno> https://pastebin.canonical.com/15795/
[02:21] <beuno> I'm pulling a branch with a few small changes
[02:21] <beuno> and it's taking ages
[02:22] <beuno> is there anything in bzr.dev that would provoke this?
[02:22] <beuno> not sure what all those "Repository.get_parent_map" are
[02:22] <beuno> or RemoteSSHTransport.readv 5 offsets => 2 coalesced => 1 requests (2)
[02:22] <lifeless> its falling down to vfs
[02:22] <beuno> ah
[02:23] <beuno> why would it do that?
[02:23] <lifeless> because lp is still running 1.12
[02:23] <beuno> well, it was working fantastically well up until yesterday
[02:23] <beuno> and edge says 1.13: https://code.edge.launchpad.net/
[02:23] <lifeless> you're looking at the wrong things
[02:24] <lifeless> and edge lies vis-a-vis the server
[02:24] <lifeless> the 3 minute gap between lines 11 and 12 is the problem
[02:24] <beuno> ah
[02:24] <lifeless> the rest is 17 seconds long
[02:25] <lifeless> if you have ssh connection sharing, and suspended with a master ocnnection open, that might fit
[02:25] <beuno> ah, I do
[02:25] <lifeless> nothing to do with bzr :)
[02:25] <beuno> I see
[02:26] <beuno> but something must of changed to suddenly make this a problem, no?
[02:26] <beuno> even though it's my settings
[02:26] <lifeless> no
[02:26] <lifeless> its been latent in your ssh config, or perhaps a ssh change on your system
[02:27] <beuno> .ssh/config:  https://pastebin.canonical.com/15796/
[02:28] <lifeless> beuno: ...and?
[02:28] <lifeless> beuno: kill your master connections, try the pull again, if its not faster, we can dig deeper
[02:30] <beuno> ehm
[02:32] <beuno> lifeless, as usual, you're right
[02:32] <beuno> thanks
[02:33] <lifeless> I know :)
[02:36] <AfC> lifeless: you don't *really* expect us to let THAT stand, do you?
[02:36] <AfC> :)
[02:37] <lifeless> weeeel
[02:37] <lifeless> l
[02:49] <lifeless> lunching
[03:51] <lifeless> jelmer: the check devs have said 'will be integrated in april, or we'll give you commit and you can do it yourself' :)
[04:40] <ivan> The docs say "bzr log -r date:yesterday..date:today" should give me all of today's revisions, but it only returns revision 1
[04:41] <ivan> but "bzr log -r date:yesterday.." works as I expect
[04:41] <ivan> is "today" strange or are the docs wrong?
[04:41] <spiv> Possibly both ;)
[04:41] <lifeless> you may have found a bug
[04:43] <ivan> heh, "date:today..date:yesterday" still returns revision 1
[04:56] <fullermd> Actually, date:today.. gives you all of today's revs...
[04:57] <ivan> it does
[04:57] <lifeless> ivan: did you start your project today?
[04:57] <ivan> yep
[04:57] <lifeless> so, date:today is 12am today
[04:57] <lifeless> the start of today
[04:57] <lifeless> I think
[04:57] <fullermd> date:yesterday..date:today probably gives you all of yesterday's revs, and the first rev from today.
[04:58] <fullermd> Which would fit.
[05:07] <ivan> date:1999-01-01..date:2000-01-01 still gives me r1 :)
[05:24] <lifeless> something to read http://dabeaz.com/coroutines/
[05:41] <fullermd> ivan: date: has a lot of rather scary dark corners  :)
[05:43] <ivan> I really like bzr, even after just a few hours
[05:44] <fullermd> For instance, the latest rev [I have] of bzr.dev has timestamp: Tue 2009-03-31 02:11:33 +0100
[05:45] <fullermd> But date:2009-03-31 doesn't find anything for me, because that rev is from 2009-03-30 in my TZ.
[05:45] <spiv> ivan: we like it too ;)
[06:05] <ivan> are there any consequences if I'm inconsistent about which branch is my mainline?
[06:06] <ivan> it doesn't really seem like it, given how revision numbers work
[06:07] <lifeless> ivan: mainline is just social, so you can organise however you like
[06:09] <ivan> thanks
[06:21] <lifeless> jelmer: ping
[06:55] <ivan> can I steal the commit message from the (only) change made in a branch?
[06:55] <ivan> I merge a branch in, then don't want to type the commit message again
[07:02] <lifeless> ivan: we don't have UI glue to do that; if there is only one change, why not just pull ?
[07:07] <spiv> An auto-commit-message plugin might be a cute hack.
[07:08] <fullermd> Actually, maybe using a more full variant (like --short) instead of --line for the merged revs in the commit editor might be helpful.
[07:08] <ivan> lifeless: i did not know about pull :)
[07:09] <fullermd> Well, until you get the people who remove the delimiter line accidentally and end up commiting the whole deal as the log message, anyway...   ;)
[07:21] <vila> hi all
[07:21]  * fullermd waves at vila.
[07:29] <lifeless> jml: several new-stacked-branch performance fixes landed today, last one in-train at the moment
[08:56] <luks> ehm, I hate when qbzr is being presented as a kde application :(
[09:03]  * vila quietly remove alias kbzr qbzr
[09:55] <Peng_> BasicOSX: Since you're the current release manager (and poolie's not here right now): There's a question on LP about how the "current release" branch isn't being maintained. https://answers.launchpad.net/bzr/+question/66037
[10:34] <ivan> i'm trying to use the trunk versions of bzr-git and dulwich to import a git repo, but it dies with some kind of mmap error: http://rafb.net/p/9nnue853.html
[10:34] <ivan> anyone know what to do? :-)
[10:36] <ivan> it's ok with allocating 230952 bytes, but fails when allocating 2595068
[10:37] <ivan> looks like it works if I patch dulwich/pack.py with: supports_mmap_offset = False
[10:48] <james_w> is there a ulimit for mmap?
[10:53] <ivan> probably not
[10:58] <james_w> so it is the size argument that trips it up?
[10:59] <james_w> it's possibly a bug in python2.6 with the offset, or some calculation of the parameters, because some take page sizes rather than bytes
[11:01] <ivan> oh, that's bad
[11:07] <ivan> yeah, it's definitely buggy, reported a month ago
[11:09] <james_w> oh, what's the link?
[11:12] <ivan> https://bugs.launchpad.net/bzr-git/+bug/336393
[11:12] <ivan> and https://bugs.launchpad.net/dulwich/+bug/352998
[11:13] <ivan> I don't mind fixing every program that I run, though it does get exhausting :)
[11:13] <james_w> ivan: could you do it again, but print all the parameters this time?
[11:14] <james_w> it would be good to know what they all are, thanks
[11:16] <ivan> PARAMS ARE 6 230952 1 0finding revisions to fetch 0
[11:16] <ivan> PARAMS ARE 10 2595068 1 12ding revisions to fetch 6
[11:16] <ivan> bzr: ERROR: mmap.error: [Errno 22] Invalid argument
[11:17] <ivan> the param order for the print matches mmap.mmap(f.fileno(), size, access=access, offset=offset)
[11:17] <james_w> thanks
[11:17] <james_w> I'll drop that in the bug
[11:18] <ivan> :-)
[11:18] <james_w> so the differences are that the size is greater, and that an offset is being used
[11:19] <james_w> and that it's a different fd I guess
[12:04]  * SamB lols at Guido's new title
[12:05] <SamB> or, uh, joke title
[12:11]  * SamB wishes gmail would just gray out the Archive button where it is not appropriate
[12:20] <LarstiQ> SamB: I'm partial to barry's title too :)
[12:21] <SamB> LarstiQ: but it's not as meaningful a word, I think
[12:21] <LarstiQ> SamB: true, true.
[12:22] <SamB> though it *is* delightfully silly
[12:23] <SamB> and Python people are just silly enough that that message would actually be quite plausible if it weren't April 1st
[12:24]  * jelmer wonders what he is missing
[12:25] <LarstiQ> jelmer: http://www.python.org/dev/peps/pep-0401/
[12:28] <jelmer> lol
[12:29] <vila> lifeless: ping, selftest --parallel works again, care to review ?
[12:30] <Peng_> They really did add the barry_as_FLUFL future though.
[12:30] <Peng_> http://svn.python.org/view?view=rev&revision=70945
[12:30] <vila> james_w: builddeb tests failing it may be due to recent changes in commit you may want to check
[12:32] <Peng_> But I think it just adds the <> operator, not the print statement.
[12:33] <james_w> vila: I don't see it, have a traceback for me?
[12:35] <vila> james_w: ./bzr selftest -s bzrlib.tests.test_msgeditor.MsgEditorTest.test_generate_commit_message_template_hook with bzr.dev@4230
[12:35] <vila>   File "/home/vila/.bazaar/plugins/builddeb/__init__.py", line 64, in debian_changelog_commit_message
[12:35] <vila>     if not commit.work_tree.has_filename(cl_path):
[12:35] <vila> AttributeError: 'Commit' object has no attribute 'work_tree'
[12:35] <james_w> urgh
[12:36] <vila> james_w: The bug may be on bzr side for not being compatible though, you may have a better POV than me in this area
[12:36] <SamB> darnit, I need to get that flaky RAM and/or motherboard fixed ...
[12:36] <james_w> vila: yeah, see it now
[12:38] <vila> james_w: good, I check I had builddeb up to date in the mean time, did I send you a bundle for test failures since 2009-03-16 ?
[12:38] <vila> james_w: about pristine-tar ?
[12:39] <SamB> is there an alternative to sed for rewriting many similar URLs in a number of branch.confs simultaneously?
[12:39] <james_w> vila: got one on Mon, 16 Mar 2009 17:32:11, thanks
[12:39] <vila> ok
[12:39] <james_w> it adds the PristineTarFeature
[12:41] <Peng_> SamB: I'd write a small Python script using bzrlib.
[12:41] <vila> james_w: just checking it wasn't lost as it doesn't show up on lp:bzr-builddeb
[12:41] <james_w> I've probably just not pushed yet, sorry
[12:41] <vila> james_w: np, np, no urgency
[12:42] <vila> james_w: you may even veto it, your call :-)
[12:42] <james_w> nope, it's merged in my local branch :-)
[12:42] <SamB> er, basically I meant "plugin"
[12:58] <ploum> Hello
[12:58] <ploum> I've a problem with bazaar
[12:59] <ploum> all my pushes to my local server are frozen at :
[12:59] <ploum> \     17kB @   15kB/s
[12:59] <ploum> not all, it depends on the repository
[12:59] <ploum> some are frozen, some are working normally
[12:59] <ploum> but branch is still working normally
[13:10] <Peng_> When dealing with Launchpad, what type of URL do you think should be used as the parent/submit/etc. location? lp:~foo/bar/baz? http://bazaar.launchpad.net/~foo/bar/baz/?
[13:12] <jelmer> vila: ping
[13:12] <SamB> don't forget lp:bar
[13:12] <james_w> if you let bzr set it with "bzr push lp:foo" then it will write the second form, but that's debated
[13:13] <Peng_> james_w: Yeah, I know. To use an lp: URL you'd have to edit branch.conf, but I do that all the time anyway, so..
[13:14] <vila> jelmer: pong
[13:14] <vila> ploum: what kind of server are you using ? what bzr version (client/server) ?
[13:20] <jelmer> vila: so, what do you prefer I do in regard to get_username() ?
[13:20] <jelmer> raise NotATerminal and provide a mock implementation that doesn't and test that, similar to get_password() ?
[13:20] <ploum> vila: I'm using bzr+http (smart server)
[13:21] <ploum> vila: the client and the server are both using ubuntu intrepid with bzr from ppa
[13:21] <vila> ploum: then add 'debug_flags = hpss' in bazaar.conf on the client or -Dhpss on the command line we'll know a bit more
[13:21] <ploum> after a while (like 5 minutes) I have :
[13:22] <ploum> bzr: ERROR: Could not acquire lock "(remote lock)"
[13:22] <vila> ploum: sorry I don't know intrepid version by heart, use 'bzr version'
[13:22] <ploum> vila: so it should look like : bzr -Dhpss push bzr+http://... ?
[13:22] <SamB> hmm, apparantly when pages try to use tables for layout, you can improve the way they print out by deleting extraneous cells in firebug ...
[13:22] <ploum> 1.13
[13:24] <vila> jelmer: there is no point in not testing code, I mention the two issues are distinct: get_username should check the tty (it will be called *before* get_pasword now)
[13:25] <vila> that part of get_password becomes irrelevant if you call get_username before get_password, so don't break it
[13:25] <vila> ploum: the lock should the consequence of a previous ctrl-c no ? use 'bzr break-lock' before bzr pull -Dhpss
[13:27] <ploum> No revisions to pull.
[13:27] <ploum> HPSS calls: 9 <bzrlib.transport.http.SmartClientHTTPMedium object at 0x853b82c>
[13:27] <ploum> now trying push
[13:28] <vila> jelmer: or get rid of it on the assumption that it is in fact dead code, but then you'll have to propose a solid explanation that it was never needed
[13:28] <vila> ploum: ghaaa, of course I meant push :)
[13:28] <ploum> I was not sure if you wanted some information
[13:28] <vila> ploum: sry
[13:28] <ploum> so I broke the lock (as you said)
[13:28] <ploum> no problem, thanks for trying to help me :-)
[13:28] <jelmer> vila: my point is, if I make get_username() raise NotATerminal then I can't test it
[13:29] <jelmer> vila: and I have to add a mock implementation of it like get_non_echoed_pw()
[13:31] <jelmer> wb vila (-:
[13:31] <vila> jelmer: haaaa, sry, then you should refactor get_non_echoed_password in both implementations
[13:31] <vila> jelmer: darn ctrl-w again :)
[13:32] <jelmer> vila: refactor get_non_echoed_password?
[13:33] <vila> the purpose of get_n_e_p in TestUI is to get rid of the 'echo' constraint, it's a side-effect if it doesn't raise NotATerminal :)
[13:33] <jelmer> vila: but we won't have a terminal during the tests
[13:34] <vila> jelmer: I get that and we don't want to raise NotAterminal in most of the cases
[13:34] <vila> jelmer: let start again
[13:34] <vila> when get_username|password is called by bzr, we should raise NotATerminal if indeed there is no terminal to query the user
[13:35] <vila> when testing, we don't want to check that *of course* except to test tht NotATerminal is raised but not the rest of the behavior
[13:35] <ploum> vila:
[13:35] <ploum> bzr: ERROR: Could not acquire lock "(remote lock)"
[13:35] <ploum> HPSS calls: 10 <bzrlib.transport.http.SmartClientHTTPMedium object at 0xa12562c>
[13:35] <ploum> but I did break-lock before
[13:35] <vila> ploum: are you alone using that repository ?
[13:37] <ploum> oh wait!
[13:37] <ploum> I had to break the lock on the server
[13:37] <ploum> not on the client
[13:37] <jelmer> vila: ahh
[13:37] <vila> ploum: both, but don't do that if someelse is using that repo
[13:37] <vila> jelmer: haaa too :)
[13:38] <ploum> maybe should I report a bug so :
[13:38] <ploum> 1) There's less delay when you cannot acquire a lock
[13:38] <ploum> 2) It's more explicit about locks
[13:38] <jelmer> vila: so we should have a helper for get_username() that gets overridden in TestUIFactory and just does checking for whether there's a terminal?
[13:38] <ploum> vila: I'm alone on that repository
[13:39] <vila> ploum: ok, so a bare 'bzr break-lock' should propose you to break both locks except if you mess things up before by breaking only the remote one
[13:39] <vila> jelmer: TestUIFactory shouldn't raise NotATerminal, it's here to be used *without* a terminal anyway, there should be another test for checking NotATerminal
[13:40] <ploum> vila: I think so
[13:40] <vila> which doesn't use TestUIFactory
[13:40] <ploum> not everyone a SSH access to the repository
[13:40] <vila> jelmer: whether there is a single method in [Test]UIFactory to handle that is up to the first dev that needs it :-)
[13:41] <vila> ploum: 'not everyone' is not exactly the same as 'only ploum' :)
[13:43] <ploum> vila: indeed. I mean : I have ssh access to my repository so I can break a lock if needed but what about people that cannot do that ?
[13:44] <vila> ploum: if they can't write they can't lock
[13:44] <vila> if they can't lock they don't need to break locks
[13:44] <ploum> but if you use bzr+http, you can create a lock
[13:44] <ploum> without being able to breaking it
[13:44] <vila> if you use bzr+http you can lock and you can break locks
[13:45] <ploum> that's why I didn't understood you
[13:45] <ploum> I was not aware of that
[13:45] <vila> ploum: you do 'bzr break-lock bzr+http://whatever
[13:45] <ploum> I logged into the server with SSH to break lock at that place
[13:45] <ploum> sorry
[13:45] <ploum> thanks for the information
[13:45] <vila> ploum: np
[13:47] <ploum> thanks for the help
[13:47] <ploum> I managed to push my commits
[13:47] <vila> jelmer: so basically I think prompt() should take care of NotATerminal *and* prompt encoding and then only prompt needs to be redefined in TestUiFactory
[13:48] <vila> jelmer: it sounds rather unfortunate that this was done by get_password so far...
[13:50] <jelmer> vila: well, get_password() doesn't use prompt() afaik
[13:50] <jelmer> since getpass() prints the prompt for it
[13:50] <vila> jelmer: that's one facet of the bug :)
[13:50] <vila> it should use self.prompt and then pass an empty prompt to getpass
[13:51] <jelmer> vila: but would it be ok for now to just raise NotATerminal from get_username() ?
[13:53] <vila> jelmer: you mean 'I found a bug, but I'd like to not fix it now but instead duplicate the bogus code, is that ok' ? :-)
[13:53] <jelmer> basically, yes :-)
[13:55] <vila> jelmer: hmmm, I can fix it, but then we'll conflict, wait a minute
[13:55] <fullermd> Mmph.  I wish there were a way to pass defaults to log formatters...
[13:56] <vila> fullermd: nag igc or better expose your use case to the ML, this is under discussion
[13:57] <fullermd> Well, my use case is that I WANT to see the merge revs on --long all the time   :p
[13:57] <fullermd> "Undo what you did" is rather obstreperous naggery.
[13:58] <vila> fullermd: 'My preferred use case is not the default one anymore' is a valid user feedback in my book
[13:59] <vila> fullermd: and when it comes to UI tweaks, user feedback is *gold*
[14:00] <Peng_> fullermd++
[14:01] <vila> Peng_: mail-the-ML++
[14:02] <vila> log and log formatters are actively worked on, the more feedback we get....
[14:02] <fullermd> I think I'm over my quota of griping-ish mails to the ML for one day.
[14:02] <vila> fullermd: quota++
[14:02] <Peng_> vila: Sorry, I just hit my quota of getting off my ass and doing things for the week.
[14:03] <vila> Peng_: quota++
[14:03] <Peng_> Exception: IntegerOverflow
[14:03] <Peng_> Sorry, it's limited to a 2-bit signed int.
[14:07] <jelmer> vila: ok
[14:09] <antoranz> huys, when is support for "Doesn't matter the EOL format" coming?
[14:10] <Peng_> antoranz: ...1.14?
[14:11] <Peng_> antoranz: It should land in bzr.dev, uh, yesterday or tomorrow or something.
[14:11] <antoranz> really? cause I had read about this feature coming like... a year ago... and I just made a lousy test and it failed miserably
[14:12] <Peng_> antoranz: It's been in progress for ages.
[14:13] <antoranz> and it's really coming in 1.14? or it's just a guess?
[14:14] <Peng_> antoranz: The required infrastructure has already been merged. The EOL stuff itself has either been merged, is up for review, or is projected to be up for review within 48 hours; I don't remember which.
[14:15] <antoranz> ok.... sounds like it's coming finally
[14:18] <antoranz> by the way... did you hear that microsoft is using git for version control? http://www.fsdaily.com/HighEnd/Microsoft_uses_git_for_version_control
[14:27] <abentley> antoranz: It's possible that MS *is* using git, but that article is an april fools' joke.
[14:27] <antoranz> damn! am I so obvious? :-)
[14:29] <ricardokirkner> hi guys.. I am having some issues with merges..
[14:29] <ricardokirkner> the thing is I have two svn repos
[14:29] <ricardokirkner> I need to merge
[14:29] <ricardokirkner> i tried to use bzr for this
[14:29] <ricardokirkner> I created a bzr branch for each branch in the svn repos
[14:30] <ricardokirkner> then I tried to merge between the bzr branches
[14:30] <ricardokirkner> and I got the error bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
[14:30] <jelmer> ricardokirkner: svn repositories or svn branches?
[14:31] <jelmer> ricardokirkner: I mean, do they have shared history?
[14:31] <ricardokirkner> jelmer, I have an upstream repo with branch A and a local repo with branch B (which is a copy of branch A from upstream)
[14:31] <ricardokirkner> I have worked locally on branch B and now I want to push to upstream
[14:31] <ricardokirkner> the thing is, the whole development started out with svn, and before being able to change our workflow, I need to push these changes to upstream first
[14:32] <jelmer> ricardokirkner: upstream svn repo and local svn repo?
[14:32] <ricardokirkner> and I would like to preserve history
[14:32] <ricardokirkner> jelmer, yes
[14:32] <jelmer> ricardokirkner: but how was branch B originally created from branch A?
[14:33] <ricardokirkner> jelmer, as far as I remember, svn export ; svn import
[14:33] <ricardokirkner> I know its not ideal, and that is the reason why bzr cannot find a common ancestor
[14:34] <ricardokirkner> but, cannot it be told to be 'more intelligente' :-)
[14:34] <ricardokirkner> ?
[14:34] <jelmer> ricardokirkner: you can force bazaar to do the merge by using the "-r0..-1" argument to merge
[14:34] <jelmer> ricardokirkner: but it'll most likely result in a large number of conflicts
[14:34] <fullermd> That sounds like it would yield a staggeringly terrible result...
[14:34] <jelmer> as there is no shared history information
[14:35] <ricardokirkner> jelmer, I try and let you know
[14:54] <jelmer> moin mwhudson
[14:54] <mwhudson> hi jelmer
[15:53] <james_w> vila: it's a test isolation problem. The tests don't clear the msgeditor hooks.
[15:53] <james_w> they aren't registered in hooks.known_hooks, but that registry is a little underdocumented
[16:08] <beuno> jelmer, what's the deal with bug 336749?
[16:08] <beuno> ted is getting desperate  :)
[16:12] <jelmer> beuno: it's a bug in ghost handling in VersionedFiles
[16:13] <jelmer> beuno: if you add a text with a ghost parent it blows up when re-extracting that text
[16:13] <beuno> jelmer, so I need to chase lifeless about it?
[16:13] <jelmer> beuno: yeah
[16:14] <beuno> jelmer, thanks
[16:14] <jelmer> beuno: I tried to see if I could figure out what was causing it, but couldn't easily find the issue
[16:14] <jelmer> I'm also not too sure what's happening exactly when storing packs
[16:15] <beuno> inkscape is in a bad situation because of it, because they're last import is broken
[16:15] <jelmer> something somewhere is assuming that the delta parent is the left hand side parent
[16:15] <jelmer> yeah, so I've understood
[16:15] <beuno> so they're in a situation where they either manage to do the import, or have to switch or something
[16:15] <jelmer> LarstiQ has a similar issue with his company repo
[16:15] <jelmer> and there are more people that have hit this problem
[16:19] <jelmer> beuno: I've marked this particular bug as High already earlier this month
[16:19] <vila> jelmer: sorry, longer than anticipated and phone calls too, digging the subject anyway, I end up getting rid of NotATerminal anyway, so forget about it, but add the tests for utf8 (unless you know better about what encoding should be used for unicode usernames)
[16:20] <jelmer> vila: ok
[16:20] <beuno> jelmer, yeah, saw it, thanks. I'll start chasing people and see where that gets me  :)
[16:20] <vila> jelmer: I'll submit something about NotATerminal
[16:21] <jelmer> vila: I'll send a new merge request to the list if that's ok
[16:21] <vila> see you there :)
[16:22] <vila> james_w: which tests don't clear ? yours ? bzr ones ? someone else tests ?
[16:25] <james_w> vila: the general bzr test setup
[16:26] <james_w> it clears all the know hooks so that doing say "commit" in a test doesn't trigger hooks
[16:26] <james_w> but fails to clear this hook, so my code runs. The test that fails shouldn't actually run any of the plugin code at all, so that's the real bug.
[16:30] <vila> james_w: ok, you should file a bug (I'm surprised commit hooks are not registered, but there may be a reason), anyway in the mean time you can also protect you own code, see bzrlib/tests/test_msgeditor.py test_generate_commit_message_template_hook
[16:31] <james_w> yeah
[16:43] <vila> jelmer: before I forget ! Make a big fat item in NEWS as GUIs will have to implement get_username now
[16:46] <vila> jelmer: and also: regarding defaulting to getpass.getuser(), I think the easiest it  to make get_username prompts only if asked (i.e. not prompt by default) grepping for getpass.getuser will give you the call sites, only http doesn't care anymore
[16:50] <jam> james_w: hooks.known_hooks is a recent addition, *because* of issues like this
[16:51] <jam> (there were other hook instances *inside* bzrlib that were being missed)
[16:52] <james_w> sure, I realise that, I'm just trying to work out what to add to it to register this hook point
[16:54] <jam> james_w: not 100% sure, but basically something like "bzrlib.branch", "Branch.hooks"
[16:55] <jam> so <module>, <object>
[16:55] <jam> as names
[17:13] <mwhudson> jelmer: InterToSvnRepository.fetch needs to support fetch_spec i think
[17:15] <jelmer> mwhudson: yeah, it doesn't at the moment
[17:15] <jelmer> mwhudson: when does that break?
[17:15] <mwhudson> jelmer: bzr get <svn>
[17:16] <jelmer> mwhudson: that wouldn't use InterToSvnRepository
[17:16] <jelmer> mwhudson: InterToSvnRepository is used in the case of push
[17:16] <mwhudson> jelmer: i can only tell you what my eyes tell me
[17:17] <mwhudson> jelmer: http://pastebin.ubuntu.com/142161/
[17:18] <antoranz> by the way. when is 1.14 expected/projected to come out?
[17:18] <jelmer> mwhudson: you're cloning *into* a svn repo?
[17:18] <mwhudson> jelmer: not deliberately!
[17:19] <VSpike> My workflow is way too complex .. I get the feeling I'm doing it all wrong
[17:21] <VSpike> Got a project which consists of a website tree and a library code tree.  I have library/main/... website/main/web/... website/main/lib/... website/branchA/web/... website/branchA/lib/...
[17:21] <VSpike> I work in two windows VM's on two linux boxes, so i have a sort of master shared repo on one linux box, and replicate the above structure in the master and in both VM's
[17:22] <VSpike> Trying to push changes around gets very muddled
[17:22] <VSpike> Especially for the library code
[17:24] <jelmer> mwhudson: should be fixed now
[17:26] <mwhudson> thanks :)
[17:27] <jelmer> mwhudson: of course, it won't actually fix the issue for you, as it will still try to write to the svn repo
[17:28] <mwhudson> jelmer: jam managed to convert the repository we care about now anyway
[17:28] <jelmer> mwhudson: is it correct that it tries to write to a svn repo?
[17:29] <mwhudson> jelmer: how could i tell?
[17:29] <jelmer> mwhudson: bzr info -v
[17:29] <jelmer> will tell if you have a svn repo locally
[17:29] <mwhudson> now it does this
[17:29] <mwhudson> mwh@starship:~/code$ rm -rf sizer/ && BZR_PDB=1 BZR_PLUGIN_PATH=plugs PYTHONPATH=subvertpy/ ./brisbane-core/bzr get file:///home/crew/mwh/code/codespeak/user/nick8325/sizer
[17:29] <mwhudson> bzr: ERROR: The branch file:///home/crew/mwh/code/codespeak/user/nick8325/sizer has no revision None.
[17:29] <mwhudson> mwh@starship:~/code$ bzr info -v
[17:29] <mwhudson> bzr: ERROR: Not a branch: "/home/crew/mwh/code/".
[17:31] <jelmer> that's really weird
[17:31] <jelmer> mwhudson: the first error is bzr masking some other error
[17:31] <mwhudson> it's possible that this machine has a super-ancient version of libsvn or something
[17:32] <jelmer> shouldn't matter
[17:32] <jelmer> mwhudson: bzr decided it wanted to fetch into a svn repo for some reason in the backtrace you posted earlier
[17:36] <exarkun> pushing to launchpad is taking too long :(
[17:36] <exarkun> isn't stacking supposed to mean it's super quick
[17:40] <exarkun> mwhudson: hey where are you
[17:40] <exarkun> I want to complain
[17:41] <mwhudson> exarkun: launchpad is still running 1.12 and 1.13 pushing to 1.12 sucks ass
[17:41] <exarkun> how about 1.11 to 1.12?
[17:41] <mwhudson> exarkun: if you add the bzr crack-of-the-day ppa it will be better
[17:41] <mwhudson> exarkun: that should be ok
[17:41] <mwhudson> exarkun: glyph was complaining earlier
[17:41] <exarkun> it just took about 8 minutes to push a pyopenssl branch
[17:42] <exarkun> (and took about as long for one earlier today too)
[17:42] <mwhudson> exarkun: how does 'mtr bazaar.launchpad.net' look for you?
[17:42] <exarkun> ~102ms latency
[17:42] <mwhudson> :/
[17:43] <exarkun> oh hey
[17:43] <mwhudson> well, it will be better tomorrow
[17:43] <exarkun> also 50% packet loss
[17:43] <mwhudson> if you upgrade to 1.13
[17:43] <exarkun> level3 for the lose
[17:43] <mwhudson> ah
[17:44] <exarkun> okay launchpad is super great I love it. :)
[17:44] <mwhudson> i don't think we like our isp very much
[17:44] <exarkun> but hey maybe you guys should switch to udp I hear it is fast
[17:44] <mwhudson> exarkun: go away
[17:44] <exarkun> >:)
[17:45] <mwhudson> i think unreliable delivery is *just* what you want for a vcs
[17:45] <mwhudson> "i've pushed my changes... probably!"
[17:50] <fullermd> darcs uses UDP.  After all, order doesn't matter.
[17:59] <Glenjamin> hi guys, i'm having some issues using the sftp transport
[17:59] <Glenjamin> basically, i keep getting bzr: ERROR: Unable to connect to SSH host trucklomax.com; EOF during negotiation
[18:00] <jelmer> Glenjamin: can you sftp in using the sftp client?
[18:00] <Glenjamin> yes
[18:00] <Glenjamin> is there an evn var i can set to see the full stack trace?
[18:00] <jelmer> you can use -Derror I think
[18:04] <Glenjamin> i'm getting a socket connection error in connect_sftp
[18:05] <Glenjamin> hrm, its from the subprocess vendor, is that correct?
[18:09] <Glenjamin> ah, its trying to use plink
[18:13] <Glenjamin> aha, bzr seems to favour installed ssh clients over paramiko now
[18:14] <jelmer> vila: ping
[19:45] <gioele> hello
[19:46] <gioele> bzr push complains that branches have diverged after "bzr uncommit; bzr commit". Why?
[19:47] <beuno> gioele, because the revision ids are now different
[19:47] <gioele> beuno: can't I "force" the push?
[19:48] <gioele> is push --overwrite a forced push?
[19:48] <beuno> gioele, sure, just add --overwrite
[19:48] <exarkun> Should I commit a merge and other changes in a single revision?
[19:48] <gioele> beuno: thank you
[19:51] <james_w> exarkun: you can do
[19:52] <james_w> if it's fixing up the build with the merge or something then it can be good
[19:52] <james_w> if it's something completely separate then split it in to a new revision
[19:55] <exarkun> It was a ChangeLog entry in this case
[19:55] <exarkun> I guess that kind of makes sense
[21:54] <seb_kuzminsky> i know how to use things like  "bzr log -v -r ancestor:../other-branch" to find the changes since the most recent merge
[21:54] <seb_kuzminsky> how do i find out the revision number (or revid, or something) of that ancestor?
[21:55] <james_w> bzr revno -r ancestor:...?
[21:55] <seb_kuzminsky> ^C0 seb@slurp /home/seb/bzr/emc2/hostmot2>  bzr revno -r ancestor:../upstream
[21:55] <seb_kuzminsky> bzr: ERROR: no such option: -r
[21:56] <seb_kuzminsky> that's 1.11, maybe i should upgrade?
[21:56] <james_w> no
[21:56] <james_w> don't think that's changed
[21:57] <Peng_> It hasn't,
[21:57] <james_w> find-merge-base?
[22:00] <seb_kuzminsky> james_w: yes, thank you
[22:02] <jelmer> wtf, unicode revision ids are allowed now ?
[22:03] <Peng_> jelmer: Maybe not intentionally.
[22:03] <jelmer> Peng_: there's a test that checks they work
[22:07] <Peng_> jelmer: Oh. That sounds pretty intentional, then. Never mind. :P
[22:17] <seb_kuzminsky> one of the open-source groups i'm working with is considering switching from CVS to some DVCS, i'm pushing for bzr and the other folks have some questions/issues that i'll proxy to you ;-)
[22:17] <thewrath> hello i was told to come over here
[22:17] <thewrath> i want to set up bZR and having some issues
[22:18] <thewrath> any help woudl be hot
[22:19] <thewrath> i am nto sure if i have python 2.5
[22:19] <seb_kuzminsky> is there a good way to set up the central server so a select bunch of people can push changes without having shell accounts?
[22:19] <seb_kuzminsky> thewrath: python -V?
[22:19] <thewrath> i am in windows
[22:19] <thewrath> do that in command line?
[22:20] <seb_kuzminsky> thewrath: i dont know much about windows, but yeah, try it in a command window
[22:20] <thewrath> nope
[22:20] <thewrath> anyone using it in windows
[22:20] <thewrath> i tried to install the dependency and it said python not installed
[22:22] <MizardX> ... I can't manage to get the authentication to work with bazaar <-> launchpad on windows. Keys added to lp and pageant successfully, but when I try to use bzr branch/co/push with lp I get the error "Permission denied (publickey)."
[22:22] <thewrath> MizardX: can you help me set up bazaar on widnows
[22:23] <MizardX> thewrath: No. I need help myself.
[22:23] <thewrath> ok
[22:23] <thewrath> i just need help setting it up
[22:23] <thewrath> i have installed it but after that i dont know what to do
[22:41] <thumper> MizardX: have you loaded your ssh key into Launchpad?
[22:41] <MizardX> Yes.
[22:43] <thumper> MizardX: have you done a `bzr lp-login` ?
[22:43] <thumper> MizardX: as it is likely that your lp name isn't the same as your local one
[22:44] <MizardX> Yes. "marjar-4"
[22:45] <Peng_> beuno: ping
[22:45] <beuno> Peng_, pong
[22:45] <thumper> MizardX: if this is not your normal ssh key, have you set it to be the one to use talking to bazaar.launchpad.net ?
[22:46] <Peng_> beuno: With the Loggerhead YUI CDN thing, what about changing it to just put a big "if branch.use_yui_cdn" in the template? Then the URL could be hardcoded in the template instead of the Python code. Would that be better?
[22:47] <schmichael> if i push/pull/merge with lots of remote branches, is there some way to give each one a nickname?
[22:47] <Peng_> beuno: That would mean the list of scripts would be duplicated, but I could use the nifty combo thing.
[22:47] <Peng_> schmichael: bzr-bookmarks plugin?
[22:47] <MizardX> thumper: It's my only key. Generated it to be used with bazaar/launchpad.
[22:48] <MizardX> thumper: Otherwise I don't know what you mean.
[22:48] <schmichael> Peng_: will check it out, thanks
[22:49] <thumper> hmm..
[22:49] <MizardX> thumper: Does they "bzr whoami" play any part in authentication?
[22:49] <MizardX> the*
[22:49] <thumper> MizardX: no
[22:49] <thumper> MizardX: which version of bzr are you using?
[22:50] <MizardX> latest stable... 1.13
[22:50] <thumper> in which case I have no idea why it isn't working
[22:50] <thumper> perhaps lifeless might know more
[22:50] <thumper> he knows lots of weird shit
[22:50] <lifeless> you called
[22:51] <MizardX> puttygen/pageant version 0.60.0.0
[22:51] <lifeless> MizardX: ok, you're on windows, I was about to ask :)
[22:52] <lifeless> thewrath: You don't know what to do.. to achieve what ? [do you want to start a new project, get the code for someone elses existing project ...?]
[22:53] <beuno> Peng_, I think that's better
[22:53] <beuno> at least it feels less awkward
[22:53] <schmichael> Peng_: yikes!  not even a README file for bzr-bookmarks?  maybe i'll wait for it to mature a bit first :)
[22:53] <lifeless> MizardX: we're meant to autodetect pagent automatically; uhm, first thing I'd try is giving the full url automatically.
[22:53] <beuno> mwhudson, any thoughts  ^
[22:54] <lifeless> MizardX: e.g. whats a branch you want to make from launchpad?
[22:55] <Peng_> beuno: It is better, but I think it'll be uglier and more complicated. Also I'll have to learn some TAL. :P Anyway, I'll try it.
[22:55] <beuno> Peng_, well
[22:55] <beuno> it will be uglier
[22:55] <beuno> so let's weigh this in...
[22:55] <Peng_> It will be nice to use the YUI combiner thingy.
[22:55] <mwhudson> beuno: on what?
[22:56] <beuno> Peng_, of course, you could kick off the config file work we want to do, by using a config file through bzr. Which we could install by default our something
[22:56] <Peng_> mwhudson: Option to load YUI from Yahoo!'s CDN. https://code.launchpad.net/~mnordhoff/loggerhead/yui-cdn/+merge/5119
[22:56] <seb_kuzminsky> lifeless: what's the prefered way to grant commit access to a central repo without granting shell access to the machine hosting the central repo?
[22:56] <MizardX> lifeless: http://pastebin.ca/1379351
[22:56] <beuno> mwhudson, https://code.edge.launchpad.net/~mnordhoff/loggerhead/yui-cdn/+merge/5119
[22:57] <mwhudson> oh right
[22:58] <mwhudson> well, i've nothing really against the idea
[22:58] <mwhudson> so long as we don't accidentally turn it on for launchpad or anything
[22:59] <luks> schmichael: bzr help plugins/bookmarks
[22:59] <MizardX> "Launchpad will be going offline for maintenance in 30 seconds." :(
[22:59] <mwhudson> Peng_: go for it, if you have time before the rollout >:)
[23:00] <beuno> 20 seconds!
[23:01] <schmichael> luks: thanks
[23:01] <lifeless> MizardX: do you have a ssh client?
[23:01] <mwhudson> argh
[23:01] <lifeless> MizardX: oh, yeah, there is a major maintenance rollout happening today, new backend db server change over and other cool stuff
[23:01] <mwhudson> i was working with jam on code that's only on his laptop and launchpad
[23:01] <mwhudson> and he just left
[23:02] <mwhudson> nice timing, hudson
[23:02] <Peng_> Haha. Nice timing.
[23:02] <lifeless> MizardX: when it comes back, I suggest using a ssh client to ssh to marjar-4@bazaar.launchpad.net; you can't do anything useful but it should connect ok, if it doesn't the key isn't configured right at one end or the other; if it doees bzr isn't picking up pagent/putty correctly
[23:03] <MizardX> ok
[23:05] <MizardX> Thanks for the help so far.
[23:05] <beuno> ok, I'm off for a little while
[23:09]  * Peng_ grumbles at YUI.
[23:10] <Peng_> Oh, I'm just a dummy. Never mind.
[23:12] <lifeless> seb_kuzminsky: bzr+https would meet your needs AFAICT
[23:13] <seb_kuzminsky> does the "bzr+" mean it's using the smart protocol, just tunneled over https?
[23:13] <lifeless> yes
[23:13] <seb_kuzminsky> cool :-)
[23:13] <seb_kuzminsky> where are the bzr transports documented?
[23:13] <lifeless> as opposed to e.g. webdav
[23:15] <lifeless> bzr can also autodetect, if you say 'https://' it will probe for a smart server on the host
[23:16] <lifeless> anyhow, bzr help urlspec is client side docs
[23:16] <lifeless> and there is docs in the manual for setting up a http server
[23:16] <seb_kuzminsky> thanks lifeless :-)
[23:17] <lifeless> anytime
[23:18] <Peng_> mwhudson: Stupid TAL question: It can do "if"-like stuff, but what about "else"?
[23:24] <mwhudson> <tal:b condition="thing>...</tal:b><tal:b condition="not:thing>...</tal:b>
[23:24] <mwhudson> :(
[23:24] <seb_kuzminsky> lifeless: i guess i'm being daft here - which manual has the http server setup stuff?  i'm not seeing anything in the User Guide or the User Reference
[23:27]  * igc breakfast
[23:30] <Peng_> mwhudson: Thanks.
[23:30] <Peng_> Hmm, since I got a bb:approve from both of you, maybe I shouldn't be messing with this anymore. :P
[23:30] <mwhudson> Peng_: with what?
[23:31] <igc> so hg-fast-export took 65 hours to export OOo
[23:31] <igc> bzr-fast-export took 2h42m to import the first 50k revisions of those 260K
[23:31] <Peng_> mwhudson: The YUI thing.
[23:32] <igc> on brisbane-core's latest format
[23:32] <Peng_> D'oh, I just found the YUI 3 configurator after finishing! :(
[23:32] <igc> I think we now have fast bulk data-entry almost nailed
[23:32]  * igc food
[23:33] <mwhudson> Peng_: oh right
[23:33] <mwhudson> Peng_: well, you can't land it for a bit :)
[23:36] <seb_kuzminsky> lifeless: oh i see, it's in an appendix to the User-Guide
[23:36] <lifeless> seb_kuzminsky: http://doc.bazaar-vcs.org/bzr.1.13/en/user-guide/index.html#running-a-smart-server and http://doc.bazaar-vcs.org/bzr.1.13/en/user-guide/index.html#serving-bazaar-with-fastcgi
[23:37] <lifeless> seb_kuzminsky: it needs a better title I think
[23:39] <Peng_> mwhudson: Since LP is down and I'm impatient (:P), new revision: http://bzr.mattnordhoff.com/loggerhead/loggerhead/yui-cdn/revision/323
[23:39] <Peng_> mwhudson: Do you prefer the old one? Or something else?
[23:40] <mwhudson> Peng_: i wonder if it might be better to list the module names in python rather than macros.pt
[23:46] <Peng_> mwhudson: What about defining a tuple or whatever in macros.pt, if that's possible? A bit evil, but putting it in Python seems weird.
[23:46] <lifeless> spiv: ping; we really need to motor on the inventory fetch stuff; I propose a near-full-day focused sprint if you're up for it - pick a place
[23:47] <mwhudson> Peng_: i guess you can say tal:define="yuimods python:('...',)"
[23:48] <Peng_> mwhudson: Oh. Well, if the feature exists, than it's not evil to use it, right? :D
[23:49] <mwhudson> Peng_: um
[23:49] <mwhudson> Peng_: i would recommend against applying that rule of thumb too often :)
[23:50] <Peng_> mwhudson: What could possibly go wrong? :)