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