[00:02] <MapMan> hello! Im seeking help!
[00:02] <MapMan> frikazoyd: oh hai
[00:02] <frikazoyd> beat you to it
[00:02] <frikazoyd> :P
[00:04] <Verterok> MapMan: just ask
[00:04] <MapMan> Verterok: my mate frikazoyd already asked
[00:04] <Verterok> ok, then
[00:06] <MapMan> maybe you can help us though
[00:06] <MapMan> we have a problem with bzr
[00:06] <MapMan> every commit > push causes a lock
[00:06] <MapMan> and everytime someone wants to push, he needs to break lock
[00:11] <lifeless> well, I know where my disk space has gone
[00:11] <lifeless> evo -> 6.4g used
[00:11] <lifeless> !!!
[00:12] <lifeless> frikazoyd: the branch you are pushing to; is it on nfs/ftp/sftp/bzr+ssh ?
[00:12] <lifeless> frikazoyd: and are the permissions set to allow both of you to create and delete common files?
[00:13] <MapMan> its ftp mate
[00:13] <MapMan> i dunno about the permissions, i havnt seen the cfg
[00:13] <lifeless> check in ~/.bzr.log for errors related to deleting
[00:13] <lifeless> (unless break-lock does work, in which case you clearly can delete)
[00:14] <lifeless> might be a ftp server bug that you can't delete a file you created in the same session or something weird
[00:14] <lifeless> anyhow, its not usual, we do work on ftp; please file a bug and the devs can ask for details there to figure out whats wrong (if you can't figure out a config issue shortly)
[00:16] <aa_> hi everyone
[00:17] <aa_> I get this error trying to push: http://paste.pocoo.org/show/86007/
[00:17] <aa_> now I try what it suggested but unknown protocol
[00:17] <aa_> is it a launhcpad thing or a bzr thing?
[00:20] <spiv> aa_: it's a bit of both
[00:20] <spiv> aa_: use bzr break-lock with your usual URL.
[00:20] <spiv> aa_: e.g. bzr break-lock lp:~name/proj/foo
[00:22] <frikazoyd> Lifeless:  The problem isn't that we can't delete, the problem is that a lock is automatically created if someone pushes
[00:22] <frikazoyd> and it doesn't release
[00:22] <frikazoyd> so if I commit a file in a local branch and then push, it puts a lock on the central repo I'm pushing to
[00:23] <frikazoyd> so nobody else can push that file either (even if it is up to date before editing) unless they break my lock
[00:23] <frikazoyd> We don't want to have to break locks to commit and merge every time someone changes an existing file
[00:24] <lifeless> frikazoyd: I'm talking about the technical details required to manage the transient locks bzr uses to ensure data consistency as it pushes
[00:24] <lifeless> frikazoyd: please assume I understand exactly what you want and how it works and am trying to help you get it to work as it *should* for you.
[00:25] <frikazoyd> Oh
[00:25] <frikazoyd> the .bzr.log file doesn't exist
[00:26] <frikazoyd> also breaking works fine
[00:26] <lifeless> bzr --version
[00:26] <lifeless> will have a line like
[00:26] <lifeless>   Bazaar log file: /home/robertc/.bzr.log
[00:26] <lifeless> with the full path to the local log file
[00:26] <MapMan> we use windows binaries
[00:26] <frikazoyd> Okay
[00:26] <frikazoyd> Map:  You can do it from command line :P
[00:26] <MapMan> its in default user folder in windows
[00:27] <MapMan> I hate that, it should be placed in apps folder
[00:27] <aa_> spiv: I did that and it returns without error, but it doesn't break the lock
[00:28] <aa_> spiv: doesn't break the lock == still has the cannot get lock error
[00:30] <spiv> aa_: its https://bugs.edge.launchpad.net/bzr/+bug/255062, btw
[00:31] <spiv> aa_: That should break the lock.  You could try "bzr break-lock sftp://aafshar@bazaar.launchpad.net/~glashammer-devs/glashammer/glashammer-main" instead, but that shouldn't be any different.
[00:31] <spiv> aa_: Hmm, by "returns without error", you mean it doesn't output anything, not even a prompt?
[00:32] <aa_> spiv: no just returns
[00:32] <aa_> I get the shell prompt afterwards
[00:32] <aa_> and return code is 0
[00:33] <spiv> Ok, then there is no lock to break.
[00:33] <aa_> "locked 24 minutes, 59 seconds ago"
[00:33] <spiv> What's cannot get lock error look like?
[00:33] <aa_> spiv: that thing I apsted
[00:33] <spiv> (and on what operation?)
[00:33] <aa_> on bzr push
[00:34] <aa_> its exactly the thing I pasted here http://paste.pocoo.org/show/86007/ except the time is creeping up
[00:36] <spiv> Is your launchpad user a member of glashammer-devs?
[00:36] <aa_> yes
[00:36] <spiv> Hmm, it appears it is.
[00:37] <spiv> What URL exactly is your local branch pushing to?
[00:37] <aa_> spiv: if I forget about it for a while is it likely to go away, or will it stay forever?
[00:38] <spiv> It isn't going to go away by itself unless the connection that created it is still connected.
[00:38] <aa_> bzr push bzr+ssh://aafshar@bazaar.launchpad.net/%7Eglashammer-devs/glashammer/glashammer-main/
[00:39] <aa_> locked 30 minutes, 44 seconds ago? [y/n]:
[00:39] <aa_> that's new
[00:39] <aa_> yay
[00:39] <aa_> spiv: guess I was running break-lock on the wrong url
[00:40] <aa_> spiv: sorry for the bother
[00:40] <spiv> That's ok.
[00:40] <spiv> Glad to hear that you're sorted.
[02:11] <Odd_Bloke> poolie: Did you get my email with bank details?  I never got an ACK.
[02:13] <poolie> Odd_Bloke: hi, yes, i passed it on to our finance guy
[02:13] <Odd_Bloke> poolie: Cool, thanks. :)
[02:13] <poolie> i wonder if gpg defeated him because i didn't hear anything myself :)
[02:13] <Odd_Bloke> Heh.
[02:13] <poolie> but i did send an extra comment explaining it
[02:15] <igc> morning all
[02:16] <poolie> hello igc, how are you going?
[02:16] <igc> hi poolie - ok today
[02:20] <Odd_Bloke> igc: Hey, long time no see.
[02:20] <igc> hi Odd_Bloke!
[02:54] <poolie> jam, the description of the change to log seems to make sense to me too
[02:54] <poolie> if you want me to look at it harder, just say so
[03:31] <poolie> i'm trying to work out what's up with the oldest queued patch, "setlocale (bug 128496)"
[03:37] <lifeless> is it correct that opening a RemoteBranch always opens the underlying disk branch ?
[03:40] <poolie> yes
[03:41] <lifeless> k, I'll do an isinstance in my branch hook open tests
[03:41] <poolie> hrm, ok
[03:42] <poolie> lifeless: it's a bit hard to avoid it given the repository stacking must be configured when the branch is opened
[03:42] <lifeless> poolie: yeah
[03:42] <lifeless> poolie: its just to make the interface tests that say what the hook should do, pass
[03:43] <poolie> obviously you could just make a promise to do it later, but iirc people have argued errors with the repo must be detected then
[03:43] <lifeless> If spiv knows that opening a remote branch generates remote + normal object
[03:43] <spiv> I'm aware that the stacking stuff has caused that, yeah :(
[03:43] <lifeless> elf.assertEqual([b], self.hook_calls)
[03:43] <lifeless> AssertionError: not equal:
[03:43] <lifeless> a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)]
[03:43] <lifeless> b = [RemoteBranch(bzr://127.0.0.1:49396/extra/),
[03:43] <lifeless>  BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)
[03:43] <lifeless> AssertionError: not equal:
[03:43] <lifeless> a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)]
[03:43] <lifeless> b = [RemoteBranch(bzr://127.0.0.1:49396/extra/),
[03:43] <lifeless>  BzrBranch6('chroot-46912499497232:///')]
[03:43] <lifeless>  BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)
[03:43] <lifeless> AssertionError: not equal:
[03:43] <lifeless> a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)]
[03:43] <lifeless> b = [RemoteBranch(bzr://127.0.0.1:49396/extra/),
[03:43] <lifeless>  BzrBranch6('chroot-46912499497232:///')]
[03:43] <lifeless>  BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)
[03:43] <lifeless> AssertionError: not equal:
[03:44] <lifeless> a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)]
[03:44] <lifeless> b = [RemoteBranch(bzr://127.0.0.1:49396/extra/),
[03:44] <lifeless>  BzrBranch6('chroot-46912499497232:///')]
[03:44] <lifeless>  BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)
[03:44] <lifeless> AssertionError: not equal:
[03:44] <lifeless> a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)]
[03:44] <lifeless> b = [RemoteBranch(bzr://127.0.0.1:49396/extra/),
[03:44] <lifeless>  BzrBranch6('chroot-46912499497232:///')]
[03:44] <lifeless>  BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)
[03:44] <lifeless> AssertionError: not equal:
[03:44] <lifeless> a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)]
[03:44] <lifeless> b = [RemoteBranch(bzr://127.0.0.1:49396/extra/),
[03:44] <lifeless>  BzrBranch6('chroot-46912499497232:///')]
[03:44] <lifeless>  BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)
[03:44] <lifeless> AssertionError: not equal:
[03:44] <lifeless> a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)]
[03:44] <lifeless> b = [RemoteBranch(bzr://127.0.0.1:49396/extra/),
[03:44] <lifeless>  BzrBranch6('chroot-46912499497232:///')]
[03:44] <lifeless>  BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)
[03:44] <mwhudson> lifeless: oops
[03:44] <lifeless> AssertionError: not equal:
[03:44] <lifeless> a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)]
[03:44] <lifeless> b = [RemoteBranch(bzr://127.0.0.1:49396/extra/),
[03:44] <lifeless>  BzrBranch6('chroot-46912499497232:///')]
[03:44] <lifeless>  BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)
[03:44] <lifeless> AssertionError: not equal:
[03:44] <lifeless> a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)]
[03:44] <lifeless> b = [RemoteBranch(bzr://127.0.0.1:49396/extra/),
[03:44] <lifeless> oooooh
[03:44] <lifeless> sorry
[03:45] <lifeless> no idea what caused that; wifi glitch I guess
[03:45] <lifeless> (it wasn't pasting, so I tried again..)
[03:45] <spiv> lifeless: stop playing hopscotch on your middle mouse button ;)
[03:45] <lifeless> spiv: anyhow
[03:45] <lifeless> self.assertEqual([b], self.hook_calls)
[03:45] <lifeless> AssertionError: not equal:
[03:45] <lifeless> a = [RemoteBranch(bzr://127.0.0.1:49396/extra/)]
[03:45] <lifeless> b = [RemoteBranch(bzr://127.0.0.1:49396/extra/),
[03:45] <lifeless>  BzrBranch6('chroot-46912499497232:///')]
[03:45] <lifeless> thats the clear unmixed up assertion
[03:45] <lifeless> so I propose to isinstance it and changed the expect value appropriately.
[03:48] <lifeless> that sound ok?
[03:51] <spiv> (sorry, lag on my end isn't helping)
[03:53] <spiv> adjusting the test for the RemoteBranch scenario to assert that the hook observes the same remote branch get opened, plus a non-RemoteBranch, sounds good to me.
[03:53] <spiv> Given that's what (currently) happens.
[03:53] <lifeless> well specifically, I'll use the real branch from the opened branch
[03:53] <spiv> Ah, ok.
[03:54] <lifeless> we know what it is after all, no need for a hand-wave
[03:54] <spiv> Yeah, that makes sense. "if isinstance(b, RemoteBranch): expected.append(b._real_branch)", basically?
[03:54] <lifeless> yes
[03:54] <spiv> Sounds reasonable.
[03:54] <lifeless> is that bb:approve to this change ?
[03:58] <spiv> Sure.
[03:58] <lifeless> thanks
[04:03] <lifeless> oh, I see, it is a remote VFS call already
[04:03] <lifeless> tweaking more
[04:03] <lifeless> can I ask though, why the current find_branch wasn't just extended to return the stacking url as well, to avoid additional round trips ?
[04:06] <lifeless> spiv: here?
[04:09] <spiv> lifeless: intermittently, it seems.
[04:09] <spiv> "Lag: 51 (??)"
[04:10]  * spiv restarts irssi
[04:21] <spiv> Well, the "good" news is that restarting irssi didn't magically make IRC stop lagging.
[04:23] <Spaz> does it still lag with other clients?
[04:28]  * igc lunch
[04:57] <nealmcb> I just did a "bzr add" of some files I didn't really want to add.   I've been stung in the past because iirc immediately doing "bzr remove" actually removed the file.  how do I un-do the "add".  I haven't committed yet
[04:57] <AfC> nealmcb: use Bazaar's remove command, but add the --keep option
[04:58] <AfC> $ bzr rm --keep path/to/file/I/added/by/mistake.txt
[04:59] <nealmcb> AfC: thanks.  Last time I think I decided that --new  would do that (Remove newly-added files) but --keep looks much better  :)
[04:59] <AfC> Although as I read the help for remove in 1.7rc1 I see it say "--safe       Only delete files if they can be safely recovered (default)."
[04:59] <Peng_> What about "bzr revert"ing them? Would that work?
[04:59] <AfC> which would make me think that you would have been ok after all.
[05:00] <AfC> Peng_: I imagine Bazaar would respond by complaining that the paths aren't versioned. (ie, "How can I revert a file to a state that I don't know about?"). But it might have special case logic. One way t find out.
[05:01] <Peng_> Yeah, "revert" works
[05:01] <Peng_> If "rm" deleted an unversioned file, that would be a bug.
[05:01] <AfC> Nice
[05:09] <lifeless> also, I think bzr rm <added-file> should act like revert, IMO. I don't know if it *does*, but it seems like a sensible default to me.
[05:17] <Peng_> "bzr rm added-file" errors out with "bzr: ERROR: Can't safely remove modified or unknown files".
[05:17] <Peng_> "bzr rm --keep added-file" works fine, just like revert.
[05:18] <Peng_> Hmm, I should test "--new".
[05:31] <lifeless> poolie: don't-sha-added-files is passing micro-tests, full run underway
[05:31] <lifeless> -> lunch
[05:40] <poolie> lifeless, nice
[05:54]  * fullermd ponders.
[05:54] <fullermd> 1.7 isn't yet, right?
[05:54] <fullermd> Hm.  Webiste doesn't like rc2 either.  Wacky.
[06:05] <lifeless> all tests pass. wahoo
[06:34] <poolie> lifeless, i was thinking of changing the test runner so that if a test fails it shows the stacktrace rightaway
[06:34] <poolie> rather than waiting til the suite has finished
[06:48] <lifeless> poolie: as an option ?
[06:53] <poolie> if necessary
[06:53] <poolie> i find i'd often like to start looking at the first failure while it's running....
[06:54] <lifeless> I'm pretty sure I had a project once that output nothing at all, except error traces, and those as they happened
[06:54] <lifeless> weirded people out
[06:54] <lifeless> uhm
[06:55] <lifeless> I'm personally pretty happy with the current behaviour, but then if I'm running either to get all the errors to filter, or with -1, as a general pattern
[06:55] <poolie> i can't parse that "either"
[06:58] <vila> hi all !
[06:58] <spiv> vila: good afternoon
[06:58] <lifeless> I tend to run bzr selftest in one of a few modes
[06:58] <lifeless> with -1, to find and debug a failure
[06:58] <lifeless> without -1 to find all the failures (and I want a compact manner of inspecting them
[06:58] <lifeless> without -1 on a small set of tests (found by the previous run)
[07:00] <lifeless> I've mentioned before wanting to do a machine parsable output to file to automate this more
[07:01] <poolie> ok, same
[07:01] <vila> I do the same. And when I get a small enough set of failing tests, I start putting some pdb.set_trace()
[07:01] <lifeless> I don't know if this is optimal, or an accomodation of sorts
[07:01] <poolie> the main thing i want is to not have to wait until all of them run to find the rest
[07:01] <lifeless> other data point is I run from within vim
[07:01] <lifeless> so I'm always going to be waiting
[07:01] <poolie> possibly it would be better to write them either to a separate file (maybe in a subdirectory)
[07:02] <poolie> or to use tribunal or something
[07:02] <vila> But sometimes, I wish I had the traceback for one of them. In that case I C-c and re-run only that tests with --starting-with
[07:02] <poolie> oh btw i have a vim tip
[07:02] <poolie> for when switching to another branch
[07:02] <poolie> do :1,9999bdel to remove everything already in memory
[07:03] <poolie> and avoid accidentally editing files from your old directory
[07:03] <lifeless> poolie: heh, I don't need that
[07:03] <lifeless> I suspect I use vim rather...differently to you
[07:03] <Odd_Bloke> vila: I used --starting-with when writing the `branch --standalone` stuff, and it's much faster.  Good job on that. :)
[07:04] <vila> Odd_Bloke: you're welcome :)
[07:04] <poolie> probably
[07:05] <poolie> to start with i use gvim
[07:05] <Odd_Bloke> Heresy!
[07:05] <poolie> quitting and restarting is adequate but it's nice to know an alternative
[07:26] <lifeless> poolie: yahh, I use text vim, and many concurrent sessions
[07:31] <jml> spiv: ping
[07:42] <spiv> jml: pong
[10:43] <a_c_m> anyone know any good (semi idiot) tutorials on setting up bzr with pqm (ie automated gatekeeper workflow)
[10:49] <dereine> hi
[10:50] <dereine> how can i get all changed files since the init
[10:50] <dereine> or all changed files between two revisions
[10:51] <james_w> a_c_m: I don't know of one, sorry
[10:51] <a_c_m> james_w: yeah thats a shame... i'm googling for one now
[10:52] <james_w> dereine: "bzr status -r" may be what you want
[10:52] <james_w> e.g. bzr status -r2..3
[10:58] <dereine> thx
[10:59] <dereine> how do i get the latest revision?
[10:59] <james_w> what do you mean?
[11:00] <lifeless> the pqm docs include setup info; file bugs please if its not enough
[11:00] <lifeless> dereine: '-1' refers to the tip revision
[11:23] <siretart> lifeless: maybe I didn't get what you mean with 'part of the target that pqm runs to run tests could update NEWS'
[11:48] <lifeless> siretart: there is a Makefile
[11:49] <lifeless> siretart: it has targets; one of those targets is dedicated to PQM, its the 'run this when doing a merge' target
[11:49] <lifeless> siretart: I'm suggesting it can be extended to also update the NEWS file from the merge source (because its run in a tree with a pending merge, it can do $something to do this)
[11:52] <siretart> lifeless: okay. does this $something include the results of the testsuite?
[11:53] <lifeless> siretart: no
[11:53] <lifeless> siretart: I'm talking about the NEWS file
[11:53] <lifeless> siretart: which is a problem for merges
[11:53] <siretart> okay. then I misunderstood you completely. ignore me then
[11:53] <lifeless> siretart: I don't understand why you are talking about test suite output - its always all-pass because thats the policy for PQM
[11:53] <lifeless> siretart: if it fails, we don't commit it
[11:54] <lifeless> siretart: If Debian is packaging bzr with test failures, thats bad, and it should definitely stop doing that :P
[11:56] <siretart> last upload contained some known pycurl failures that I was told were harmless
[11:57] <lifeless> they happen consistently on recent pycurls, I'm not convinced they are harmless
[11:57] <lifeless> visik7: ^
[11:57] <lifeless> erm
[11:57] <lifeless> vila: ^
[11:57] <lifeless> sorry visik7
[11:59] <lifeless> siretart: I am curious why you thought a thread about NEWS was related to Debian packaging ?
[11:59] <lifeless> oops, community council meeting time, back later
[12:02] <siretart> lifeless: I was under the impression you wanted to include results of the testsuite to NEWS
[12:03] <lifeless> wow
[12:03] <lifeless> I guess its context
[12:03] <lifeless> you may not but NEWS is a continual merge headache
[12:04] <lifeless> because entries may merge ok but be in the wrong release etc
[12:18] <vila> siretart: I'd be *very* interested about those pycurl failures, do you have some selftest output ?
[12:20] <siretart> not anymore, I removed the output some days after my upload
[12:21] <siretart> lifeless: see, it might make sense to install the selftest output in the package after all ;)
[12:22] <lifeless> siretart: sure, I wasn't saying it was a bad idea, just totally confusing for me in that tread
[12:22] <siretart> yes, I was confused as well. sorry
[12:22] <lifeless> siretart: it was a non sequiter :)
[12:37] <vila> siretart: mail me the next time you run the test suite then :)
[12:44] <lifeless> vila: there is a bug
[12:45] <vila> lifeless: only one ? Gosh, we're close :)
[12:47] <vila> lifeless: yes ? What bug ?
[12:48] <lifeless> vila: on the pycurl failures
[12:49] <vila> You can reproduce it ?
[12:52] <lifeless> spiv can
[12:53] <spiv> I can't anymore; it got fixed AFAICT.
[12:54] <vila> the poll/select one ?
[12:54] <spiv> Yep, that's the one I used to see.
[12:54] <vila> a nightmare :)
[12:54] <lifeless> siretart: how long ago was the upload?
[12:54] <vila> Once I upgraded to hardy it popped up everywhere :)
[12:55] <siretart> lifeless: that was the last upload to debian experimental
[12:55] <lifeless> siretart: not what, when
[12:55] <siretart> sep 5, 2008
[12:55] <vila> siretart: does it looks like bug #225020 ?
[12:55] <siretart> I'm running the testsuite right now on my intrepid laptop
[12:56] <vila> great
[12:56] <siretart> vila: yes, I think I've seen "select/poll returned error" back then
[12:57] <vila> siretart: the bug is fixed in 1.7 but not in 1.6.1. I think intrepid uses the later
[12:58] <vila> lifeless: by the way, did pycurl get re-installed on pqm (you said you asked for it to be removed in the bug comments) >
[12:58] <vila> s/>/?/
[12:59] <lifeless> vila: arh, don't think so.
[13:00] <vila> lifeless: no urgency,  that should be done carefully...
[13:01] <siretart> vila: what is your email adress?
[13:01] <vila> v.ladeuil+lp at free.fr
[13:02] <lifeless> vila: is the bug fixed?
[13:03] <vila> lifeless: yes, it didn't dare reproduce anywhere AFAIK
[13:05] <vila> lifeless: but note that it's fixed in 1.7 and pqm uses 1.6.1 if I'm correct
[13:06] <lifeless> vila: errr
[13:06] <lifeless> vila: it was removed from the pqm chroot, not from the bzr pqm uses
[13:06] <lifeless> vila: two totally separate thing
[13:07] <vila> I understand that
[13:07] <vila> My point was that running the tests should not fail anymore, but merging before running the tests may
[13:08] <lifeless> vila: my point is that the bzr doing the merging *still has pycurl* AFAIK
[13:08] <lifeless> vila: and never had trouble merging
[13:08] <vila> lifeless: then all is fine and I will cure my paranoia happily :)
[13:09]  * vila will try to better understand what run under the chroot and what doesn't another day :)
[13:12] <lifeless> vila: 'make check' runs in teh chroot. Nothing else does
[13:13] <vila> clear and simple, thanks
[13:18] <lllama> Hello all. Anyone got a good method for running the smart server as a service on a central ubuntu box?
[13:22] <pysquared> Does anyone know how to do garbage collection in a shared repository after deleting unwanted branches?
[13:23] <lifeless> pysquared: currently there isn't a simple answer; unless your branches are large I would say don't worry
[13:23] <pysquared> This post https://lists.ubuntu.com/archives/bazaar/2007q3/031099.html mentions a "garbage collection" plugin, but provides no link, and I cannot find one.
[13:24] <lifeless> pysquared: I don't think there is
[13:25] <pysquared> I thought it would be nice to have a bzr2xyz (and back again) in a similar vein to http://msi2xml.sourceforge.net, to allow open-heart-surgery on a repo - anyone else thought this?
[13:28] <lifeless> pysquared: thats roughly what fast-import|fast-export is, though note that *any* modification makes your content appear like new branches to others (its a distributed DB)
[13:28] <lifeless> pysquared: rebase and similar tools are much more user friendly ways to make it hard for people to merge :P
[13:29] <pysquared> For a technically minded newbie to bzr, I would also appreciate a program which would give me a nice view of a shared repo, all branches using it, orphaned heads etc., and it could be extended to show possible actions like commit, branch etc.
[13:29] <pysquared> lifeless: thanks. checking out fast-[import|export]
[13:33] <a_c_m> branches rock !
[13:33] <lifeless> pysquared: qbzr|bzr-gtk|tbzr(windows)
[13:48] <pysquared> I'm on Ubuntu 8.04, so tbzr (TortoiseBZR?) is out.  Just tried qbzr, feels a bit clunky though, you have to wrestle with it to get information out.
[13:50] <pysquared> I have been using bzr-gtk (olive-gtk yes?) for a while, and it's better than qbzr IMVHO so far.
[13:55] <pysquared> Thanks for the fast-import link, looks like a useful example of using bzrlib to disect a repo.
[14:00] <lifeless> generally speaking, I just use bzrlib to work with repo's :)
[14:31] <lamont> can I safely remove things in .bzr/repository/obsolete_packs (as the name would tend to imply)??
[14:39] <james_w> lamont: removing the directory is not a good idea, but the contents of the directory will be safe to delete if your system didn't die before things were synced to disk
[14:39] <vila> siretart: got your mail, I can confirm that bug #225020 is *not* fixed in bzr-1.6 nor bzr-1.6.1 :-/
[14:50] <vila> jam: when you'll come online, are you aware of bug #269770 ? 1.7 may still find its way into intrepid... (me? trying to push a time-based release trough a Freeze exception ? me ?)
[14:52] <lamont> james_w: thansk
[15:00] <pysquared> Would a good method of cleaning out orphan revisions, i.e. garbage collecting (after deleting branch directories) be this: create a new shared repo, and branch every branch from old to new?
[15:00] <james_w> pysquared: yeah, that works
[15:01] <james_w> pysquared: it's obviously just a bit of a pain to do manually
[15:08] <Tak> vila meant: lifeless: by the way, did pycurl get re-installed on pqm (you said you asked for it to be removed in the bug comments) ?
[15:09] <vila> Tak:  ?
[15:09] <Tak> hell, sorry
[15:10] <vila> :)
[15:10] <Tak> script + scrollback = eek!
[15:24] <jam> vila: I'll be packaging 1.7 "now-ish" I don't know whether that means it will get merged or not. Certainly I would hope they do 1.6.1
[15:25] <vila> They mentioned 1.7, that's why I mentioned it to you, no pressure, at all, I swear :)
[15:27] <james_w> https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/269770
[16:04] <Leonidas> why do I need to --force for a multi-branch merge? is it considered a bad idea?
[16:06] <james_w> Leonidas: well, the first merge will mean that there are files modified in the working tree, and merging in that state can be a headache, I don't know if there is more to it than that
[16:07] <Leonidas> james_w: ok, so it is just a human issue, not some technical problem. Thanks.
[16:09] <fdv> huh
[16:09] <fdv> bzr-svn seems to have replaced an svn revision
[16:09] <fdv> is this normal?
[16:10] <fdv> never done it before, but I haven't done this with the latest and greatest bzr-svn before
[16:10] <jelmer> fdv, see the FAQ
[16:10] <fdv> oh
[16:11] <fdv> that was.. unexpected
[16:12] <fdv> jelmer: I had a bound branch, and the operation was a commit
[16:12] <fdv> unsure how to interpret the faq on that point
[16:13] <jelmer> fdv, This happened after "bzr up" created pending merges I suspect?
[16:13] <fdv> jelmer: indeed'
[16:17] <jam> guilhembi: ping, I'd like to chat with you sometime about the 'bzr log file' changes
[16:17] <jam> just to get a feel of someone outside the bzr project itself
[16:19] <guilhembi> jam: hi! good idea. We can IRC now.
[16:20] <jam> Is this channel fairly quiet?
[16:20] <jam> I haven't been watching
[16:21] <guilhembi> it is
[16:24] <jam> guilhembi: so here is my standard example for the 'bzr log file' situation: http://paste.ubuntu.com/49712/
[16:25] <jam> You have 3 branches, the one on the left (ABEG) is the mainline
[16:25] <jam> guilhembi: do you understand the graph, in general?
[16:27] <Verterok|out> ~/away
[16:27] <Verterok|out> sorry :p
[16:28] <guilhembi> reading
[16:29] <guilhembi> jam: yes; to be sure: the only changed of 'foo' is C, right?
[16:29] <guilhembi> s/changed/changer
[16:30] <jam> guilhembi: right, that is the only *direct* change to the file.
[16:30] <guilhembi> ok
[16:30] <jam> well, and "A" for introducing it
[16:30] <jam> however, if you were to do "bzr diff" or E, or F, you would also see it "changing" C
[16:30] <jam> because of the merge
[16:32] <guilhembi> jam: right, makes sense; E changed 'foo' compared to ancestor B.
[16:32] <guilhembi> due to merge.
[16:32] <jam> and same for F
[16:33] <jam> so, there are 3 possible results from "bzr log foo"
[16:33] <jam> A C
[16:33] <jam> A C E F
[16:33] <jam> A C E
[16:33] <jam> My 'file-log' plugin does the first
[16:33] <jam> only reporting *direct* changes to the file
[16:34] <guilhembi> jam: this is fine. But,
[16:35] <jam> sorry, I'm having side conversations so this is taking a while.
[16:35] <guilhembi> what if when the merge was done in E (pulling C into B), a conflict happened in 'foo',
[16:35] <guilhembi> then I'd like "bzr log" to how A C E.
[16:35] <jam> guilhembi: if a conflict happens then there is a new node
[16:35] <jam> because B had to change the file
[16:35] <jam> And E is then resolving the changes between B and C
[16:35] <guilhembi> jam: so would I see A B C E?
[16:35] <jam> *in fact*
[16:36] <jam> If there are *no conflicts* you'll still see "ABCE" because E is merging the texts together to create a new text that has not been seen before.
[16:36] <guilhembi> jam: this is fine too
[16:36] <jam> guilhembi: the existing "bzr log file" code shows "ACEF"
[16:37] <jam> my change would start to show "ACE"
[16:37] <jam> (though I have a change which solves the bulk of the problem, and still gives ACEF)
[16:37] <jam> So back to the original example...
[16:37] <jam> the reason to show "E" is because it is nice to know when that change was "landed"
[16:37] <jam> rather than just when it was created.
[16:38] <jam> do you agree?
[16:39] <guilhembi> yes and no
[16:40] <guilhembi> it's nice, but it multiplies the output, creating some sort of noise;
[16:40] <guilhembi> in MySQL, we merge all the time, so we'd rather see what revision introduced a change for the first time,
[16:40] <guilhembi> and not the multiple merge revisions which propagated it all around,
[16:41] <jam> guilhembi: so, the idea with the *new* code, is to only see the changes as it propagates to *your branch mainline*
[16:41] <jam> so the changes as it propagates to *this* branch, rather than showing "F" which is propagating to some other branch.
[16:41] <guilhembi> from MySQL 5.0-team to 5.0-main to 5.1-team to 5.1-main to 6.0-team to 6.0-main, that's a lot of noise merge revisions; I call them noise only if there were no conflicts.
[16:41] <jam> guilhembi: knowing those branches, I have some guesses that you might see it anyway because of non-conflict resolutions...
[16:44] <jam> guilhembi: sorry, network hiccup, did you respond to "knowing those branches ..." ?
[16:45] <guilhembi> not yet
[16:45] <guilhembi> jam: what is a "non-conflict resolution" ?
[16:45] <jam> guilhembi: B & C both modified 'foo', just in a way that doesn't conflict
[16:45] <jam> (B changes the first line, C changes the last)
[16:48] <guilhembi> jam: ah, then it's fine to see B and C and E.
[16:49] <guilhembi> jam: let's put it this way:
[16:49] <guilhembi> I believe we should see all revisions which introduced a change in the first place,
[16:50] <guilhembi> plus, if you wish, merges where the two ancestors changed 'foo'.
[16:50] <guilhembi> It's "if you wish", because I don't see a need to see such merges if there were no conflicts.
[16:50] <guilhembi> as then I consider they didn't really change something.
[16:51] <jam> well, they did get a new text. Also, I don't think there is a way to figure out whether it was a conflicting or non-conflicting without explicitly recording that at commit time.
[16:52] <jam> As it can even depend on the merge algorithm used
[16:52] <jam> (as you've seen for bzr merge --weave/lca/merge3)
[16:53] <jam> so, in the short-short term, I'll point you towards my "bzr file-log" plugin, which gives you the minimal revisions you requested, and I'll probably land the change to "bzr log file" which is a step along the way.
[16:55] <guilhembi> jam: mmmmmm
[16:56] <guilhembi> I'd rather not tell people to switch to your plugin, it is a bit hell to make 100+ devs use a plugin,
[16:56] <jam> With newest code in both, "bzr file-log sql/..yacc.yy" was 4-5s, and "bzr log file" was about 10s
[16:56] <guilhembi> then abandon it when the changes are in bzr.dev
[16:56] <guilhembi> how about "land the change to "bzr log file" which is a step along the way"
[16:56] <guilhembi> - which is easier to sell to my colleagues -
[16:57] <guilhembi> do you see a problem with getting your change into bzr.dev?
[16:57] <jam> just waiting on final approval, things seem positive
[16:57] <guilhembi> jam: I believe that the person who reported that problem can accept waiting for a couple of weeks (but not a couple of months) and then just upgrade its bzr.
[16:58] <guilhembi> jam: while I have you here, when finally will your lca_merge_multi reach bzr.dev ?
[17:00] <jam> I don't know what is happening here....
[17:00] <jam> bad network
[17:00] <jam> 10:58:02) guilhembi: jam: while I have you here, when finally will your lca_merge_multi reach bzr.dev ?
[17:00] <jam> (10:59:05) jam: a bit unclear
[17:00] <jam> (10:59:10) jam: it took a month to get anyone to review it
[17:00] <jam> (10:59:18) jam: and then they asked for some large changes
[17:01] <guilhembi> jam: :((
[17:01] <jam> so I need to find some time to both discuss with him what has to happen
[17:01] <jam> and have time to make the changes.
[17:01] <jam> (we're also in the process of discussing our review process, as it seems to not be functioning as smoothly as it should)
[17:02] <guilhembi> jam: then that patch needs higher prio, "angry customer" thing.
[17:03] <guilhembi> poolie: hello! please see above.
[17:08] <jam> guilhembi: well, poolie is in deep-sleep right now, but he'll wake up in about 6 hours
[17:09] <jam> anyway, I'm off to reboot and release 1.7 final, I'll be back in a second.
[17:42] <Leonidas> what is the dirrefence between lock_read and lock_write?
[17:42] <Leonidas> *difference
[17:42] <jam> Leonidas: "lock_read" indicates that you are going to not be modifying the object you are locking, "lock_write" says the opposite
[17:44] <Leonidas> jam: so other processes could access a lock_read locked tree also via lock_read, but that wouldn't be possible with a lock_write?
[17:44] <jam> Leonidas: ATM, I'm pretty sure you just can't take two lock_write at the same time. lock_write doesn't block a lock_read
[17:44] <jam> as our data model stays consistent for old data when adding new data.
[17:45] <fdv> jelmer: I now tried setting append-revisions-only on the repository I bind to an svn repo (where I update from and commit to), but this doesn't seem to make any difference
[17:45] <fdv> jelmer: is that expected?
[17:45] <jelmer> fdv, append-revisions-only has to be set on the master branch (the svn repository), e.g. in ~/.bazaar/subversion.conf
[17:46] <fdv> ah
[17:46] <Leonidas> jam: ok. I'm asking because I need read access to a repo and locking&unlocking on every operation is quite slow
[17:47] <fdv> jelmer: is it possible to set it in svn itself?
[17:47] <fdv> so that no "clients" can do this
[17:48] <jelmer> fdv, not atm, no
[17:48] <fdv> we just had a very hectic couple of hours here, it'd be nice to be able to aviod that :p
[17:48] <Leonidas> jam: anyway, this is cool; thanks.
[17:48] <fdv> ok
[17:48] <jelmer> fdv: feel free to file a wishlist item about it
[17:48] <fdv> is this new behaviour or has it been like this for some time?
[17:48] <jelmer> fdv, it's always done this
[17:49] <fdv> ok, guess I've just been lucky in the past
[17:49] <fdv> jelmer: will add it to the wishlist. thanks for your help
[17:49] <Leonidas> jam: but, uhm, of what use is the lock_read?
[17:54] <fdv> jelmer: btw, you said 'e.g. ~/.bazaar/subversion.conf', does this mean that there are other options? Can I set it 'globally' for a user (across repos), for instance?
[17:56] <jelmer> fdv, the setting is append_revisions_only btw, not append-revisions-only - I'll update the FAQ
[17:56] <fdv> jelmer: I tested and found out :)
[17:59] <jelmer> fdv, I think you should be able to set it in ~/.bazaar/bazaar.conf
[17:59] <fdv> ok, thanks, I'll test
[18:01] <fdv> jelmer: you don't think this could be considered a bug? I mean, in centralised thinking I think it's a bit counter-intuitive that the checkout should act as "master"..
[18:02] <jelmer> fdv: What should be considered a bug exactly?
[18:03] <fdv> jelmer: that append-revisions-only isn't default (against svn)
[18:03] <jelmer> the fact that the mainline can be altered rather than only be appended to ?
[18:04] <fdv> yes
[18:04] <jelmer> fdv: In that case, it would have to be the default against bzr itself too (for consistency)
[18:04] <fdv> well, maybe
[18:04] <Pieter> 2
[18:04] <fdv> on the other hand, when you're working against svn you might be in a slightly different mindset
[18:05] <fdv> jelmer: not least that this sort of "breaks" svn
[18:06] <fdv> you get an inadvertent copy, which might very well not be what you want
[18:06] <fdv> (or replace, that is)
[18:07] <jelmer> fdv: true, but you may not want a changing mainline for native bzr master branches either
[18:07] <fdv> quite possibly, I'm not sure how bazaar handles this
[18:07] <jelmer> fdv: I'm not opposed to making append_revisions_only the default, but only across bzr, not just for a particular master branch format.
[18:08] <fdv> I see, I don't think I'm sufficiently proficient to be strongly opinionated on the matter
[18:08] <jelmer> fdv: I could add a info message that points at the FAQ, would that help?
[18:09] <fdv> jelmer: in my case, indeed, but I can only speak for myself
[18:10] <fdv> maybe bzr could implement a prompt in these cases, unless specifically turned off
[18:13] <fdv> jelmer: fyi, bazaar.conf seemed to work as well
[18:18] <jelmer> fdv, ah, cool
[18:35] <Kinnison> jelmer: Are you responsible for ctrlproxy?
[18:36] <jelmer> Kinnison, yes
[18:36] <Kinnison> jelmer: why is 3.0.x such a regression? is it still WiP ?
[18:36]  * Kinnison accidentally upgraded, spent an hour trying to make it work, gave up and force downgraded again
[18:36] <jelmer> Kinnison, it works fine here - what do you consider a regression exactly?
[18:37] <Kinnison> jelmer: I couldn't get it to start an SSL listener which would actually transact any data
[18:37] <Kinnison> jelmer: Also, startlistener and then saveconfig => no listeners saved
[18:38] <Kinnison> at that point, I gave up trying to make it work
[18:38] <jelmer> the second one is a known issue
[18:38] <Kinnison> jelmer: it's also a showstopper with no config documentation :-)
[18:38] <jelmer> the first one I'm not sure - what version exactly?
[18:38] <Kinnison> whatever is in hardy
[18:38] <Kinnison> I think
[18:38] <jelmer> ah, ok - that's a known issue as well then but that's resolved now
[18:39] <Kinnison> mmm 3.0.5-1
[18:39] <jelmer> I do plan to fix the documentation for the next release
[18:39] <Kinnison> there was nothing in the NEWS which hinted at SSl fixing for incoming connections
[18:39] <jelmer> I'll give you a ping when that's out.
[18:39] <Kinnison> so I didn't try trunk
[18:39]  * Kinnison shrugs, I've downgraded the package and put it on hold
[18:39] <Kinnison> also, it asks you to run a script which doesn't exist
[18:40] <Kinnison> ctrlproxy-upgrade
[18:40] <Kinnison> (although that might be the packager's fault)
[18:40] <jelmer> yeah, that's a package bug
[18:45] <Verterok> hi
[18:45] <Verterok> would make sense to implement __str__ in bzrlib.inventory.Inventory?, mainly to avoid this http://rafb.net/p/yY76bI24.html
[19:04] <bpierre> hi
[19:31] <LeoNerd> Guys.. I have an idea...
[19:32] <LeoNerd> I would loveyoulongtime if you provided me a way to hook into bzr's local file reading, and mangle a string that contains a file's content before bzr looked at it
[19:32] <LeoNerd> I'd then use it to squash  $cvs: .*$  into   $cvs$   meaning that bzr ignores changes to CVS's keyword expansions
[19:32] <LeoNerd> Currently, I have a dual CVS/bzr working directory (don't ask :P) and every single time I "cvs ci" I have to "bzr ci" as well because CVS has rewritten them
[19:34] <LeoNerd> I know it'd slow things down a bit, but hey.. bzr is about 5 times quicker on my workdir than CVS ever is anyway, so it has plenty of leeway ;)
[19:50] <jam> Leonidas: sorry, lunch came inbetween
[19:51] <jam> anyway, 1 caveat, "WT.lock_read()" does take out an OS shared lock on a file
[19:51] <jam> and *will* block a lock_write on a working tree
[19:51] <jam> (we are considering ways to avoid this)
[19:51] <jam> and 2
[19:51] <jam> it gives a lifetime for cache objects
[19:51] <LeoNerd> How confusing... someone else with the same initial 4 letters as me :P
[19:51] <jam> LeoNerd: there *is* a pre-commit hook
[19:52] <jam> but that would require modifying the file-on-disk
[19:52] <LeoNerd> Yah...
[19:52] <jam> you could also monkey patch WT.get_file*
[19:52] <LeoNerd> What I want is a filter between the filesystem read() calls, and what bzr internally uses
[19:52] <jam> LeoNerd: well, igc was working on just that sort of thing recently
[19:52] <jam> it got a little side tracked when he got sick
[19:53] <jam> LeoNerd: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C4880CF60.2080805%40canonical.com%3E
[19:53] <jam> Is part of his work on that
[19:53] <jam> along with a plugin on his end
[19:53] <jam> Leonidas: back to the "cache lifetime". The idea is that we'll have a snapshot of how a branch/repository looks and cache certain things in memory. By using lock_read()/unlock() we define the boundary of when that cache is valid.
[19:54] <jam> Leonidas: so that if you have a long running process, it doesn't think a branch is always at the same point, nor does it have to re-query all information repeatedly.
[19:54] <jam> for bzr, the cache lifetime is generally just the process lifetime
[20:18] <a_c_m> is anyone actually using PQM ?
[20:18] <a_c_m> finding it really hard to find any useful doc's or tutorials on how to set it up
[20:36] <abentley> jam: You wanted to talk with me about LCA merge stuffs.  Do you still want to do that?
[20:58] <a_c_m> Patch Queue Manager? is it abandoned?
[20:59] <a_c_m> no activity in the last month
[20:59] <a_c_m> no download (that i could see)
[21:01] <james_w> a_c_m: bzr itself uses it
[21:01] <james_w> and there is work being done on it
[21:02] <seb_kuzminsky> halp!  i'm using bzr to work with an svn repo, and it's backtracing on me
[21:03] <seb_kuzminsky> i'm on intrepid, fully apt-get updated, with bzr-svn from the 0.4 branch, also recently updated
[21:03] <jelmer> seb_kuzminsky, please pastebin the traceback somewhere
[21:03] <seb_kuzminsky> here's the backtrace: http://pastebin.ca/1209653
[21:03] <seb_kuzminsky> ;-)
[21:04] <jelmer> seb_kuzminsky, please file a bug
[21:04] <seb_kuzminsky> will do
[21:05] <a_c_m> james_w: right... but i would love to see if i can set it up for my purposes, seems like a really cool plugin/addon/thing even for trival stuff like checking committed code matches our coding standards... or would there be a better way to do that? perhaps with pre-commit hooks?
[21:05] <james_w> a_c_m: either would work I think, it's about where you want to check it really.
[21:06] <a_c_m> james_w: as i cant find any released code for the PQM, i guess pre-commit hooks is where its at ;)
[21:08] <seb_kuzminsky> jelmer: thanks: https://bugs.launchpad.net/bzr-svn/+bug/273716
[21:08] <james_w> a_c_m: you can grab it from bzr
[21:08] <jelmer> seb_kuzminsky, thanks
[21:09] <seb_kuzminsky> any suggestions on how i can work around this for now?  i'd really like to keep working with that sandbox!
[21:20] <seb_kuzminsky> jelmer: hm i think that bug is probably my fault
[21:21] <strk> how do I drop a working tree from a branch once I forgot the --no-tree ?
[21:22] <LarstiQ> strk: `bzr remove-tree`
[21:28] <strk> thx
[21:28] <seb_kuzminsky> jelmer: it's my fault, sorry for wasting your time
[21:28] <jelmer> seb_kuzminsky, what's the problem exactly?
[21:29] <seb_kuzminsky> i'd been playing with a newer version of bzr (from lp:bzr)
[21:29] <seb_kuzminsky> i made a shared repo of format RepositoryFormatKnitPack5RichRoot (bzr 1.6.1)
[21:29] <seb_kuzminsky> but intrepid only has 1.6, i think that's what made it confused
[21:30] <seb_kuzminsky> i upgraded to lp:bzr-1.6 and now it's working
[21:30] <seb_kuzminsky> sry!
[22:26] <a_c_m> james_w: do you know of any good tutorials for doing hook based things?
[22:51] <beuno> statik, hi. Are you around?
[22:52] <beuno> a few of us have been using the bzr nightly PPA
[22:52] <beuno> and have a very very very very special request  :)
[22:52] <beuno> (add bzrtools to it as well)
[22:53] <BasicOSX> how do I remove just the file ID? I have a fileName and filename and on osx native fs those are the same file
[22:54] <james_w> a_c_m: the documentation is a start, I don't know of any tutorials
[23:12] <lifeless> a_c_m: looking at an existing plugin - e.g. email - that uses hooks is a good way to see what they do
[23:12] <lifeless> BasicOSX: uhm
[23:13] <BasicOSX> I've had this "problem" before on osx, bzr remove "File" worksi
[23:14] <lifeless> BasicOSX: python -c "import bzrlib.workingtree; t = bzrlib.workingtree.WorkingTree.open('path'); t.remove('exact_relpath')"