| MapMan | hello! Im seeking help! | 00:02 |
|---|---|---|
| MapMan | frikazoyd: oh hai | 00:02 |
| frikazoyd | beat you to it | 00:02 |
| frikazoyd | :P | 00:02 |
| Verterok | MapMan: just ask | 00:04 |
| MapMan | Verterok: my mate frikazoyd already asked | 00:04 |
| Verterok | ok, then | 00:04 |
| 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:06 |
| lifeless | well, I know where my disk space has gone | 00:11 |
| lifeless | evo -> 6.4g used | 00:11 |
| lifeless | !!! | 00:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| aa_ | hi everyone | 00:16 |
| 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:17 |
| 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:20 |
| 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:22 |
| 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:23 |
| 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:24 |
| frikazoyd | Oh | 00:25 |
| frikazoyd | the .bzr.log file doesn't exist | 00:25 |
| 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:26 |
| 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:27 |
| aa_ | spiv: doesn't break the lock == still has the cannot get lock error | 00:28 |
| spiv | aa_: its https://bugs.edge.launchpad.net/bzr/+bug/255062, btw | 00:30 |
| ubottu | Ubuntu bug 255062 in bzr "bzr: ERROR: Invalid url supplied to transport: "Host empty in" [High,Confirmed] | 00:30 |
| 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:31 |
| aa_ | spiv: no just returns | 00:32 |
| aa_ | I get the shell prompt afterwards | 00:32 |
| aa_ | and return code is 0 | 00:32 |
| 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:33 |
| aa_ | its exactly the thing I pasted here http://paste.pocoo.org/show/86007/ except the time is creeping up | 00:34 |
| === Guest25912 is now known as jelmer | ||
| spiv | Is your launchpad user a member of glashammer-devs? | 00:36 |
| aa_ | yes | 00:36 |
| spiv | Hmm, it appears it is. | 00:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| aa_ | spiv: sorry for the bother | 00:40 |
| spiv | That's ok. | 00:40 |
| spiv | Glad to hear that you're sorted. | 00:40 |
| Odd_Bloke | poolie: Did you get my email with bank details? I never got an ACK. | 02:11 |
| 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:13 |
| igc | morning all | 02:15 |
| poolie | hello igc, how are you going? | 02:16 |
| igc | hi poolie - ok today | 02:16 |
| Odd_Bloke | igc: Hey, long time no see. | 02:20 |
| igc | hi Odd_Bloke! | 02:20 |
| === sdboyer|oot is now known as sdboyer | ||
| 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 | 02:54 |
| === spiv_ is now known as spiv | ||
| poolie | i'm trying to work out what's up with the oldest queued patch, "setlocale (bug 128496)" | 03:31 |
| ubottu | 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:31 |
| lifeless | is it correct that opening a RemoteBranch always opens the underlying disk branch ? | 03:37 |
| poolie | yes | 03:40 |
| lifeless | k, I'll do an isinstance in my branch hook open tests | 03:41 |
| poolie | hrm, ok | 03:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| lifeless | that sound ok? | 03:48 |
| spiv | (sorry, lag on my end isn't helping) | 03:51 |
| 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:53 |
| 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:54 |
| spiv | Sure. | 03:58 |
| lifeless | thanks | 03:58 |
| 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:03 |
| lifeless | spiv: here? | 04:06 |
| spiv | lifeless: intermittently, it seems. | 04:09 |
| spiv | "Lag: 51 (??)" | 04:09 |
| * spiv restarts irssi | 04:10 | |
| spiv | Well, the "good" news is that restarting irssi didn't magically make IRC stop lagging. | 04:21 |
| Spaz | does it still lag with other clients? | 04:23 |
| * igc lunch | 04:28 | |
| 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:57 |
| === samurai is now known as samiam | ||
| AfC | $ bzr rm --keep path/to/file/I/added/by/mistake.txt | 04:58 |
| === samiam is now known as samurai | ||
| 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. | 04:59 |
| === sdboyer is now known as sdboyer|zzz | ||
| 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:00 |
| Peng_ | Yeah, "revert" works | 05:01 |
| Peng_ | If "rm" deleted an unversioned file, that would be a bug. | 05:01 |
| AfC | Nice | 05:01 |
| 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:09 |
| 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:17 |
| Peng_ | Hmm, I should test "--new". | 05:18 |
| lifeless | poolie: don't-sha-added-files is passing micro-tests, full run underway | 05:31 |
| lifeless | -> lunch | 05:31 |
| poolie | lifeless, nice | 05:40 |
| * fullermd ponders. | 05:54 | |
| fullermd | 1.7 isn't yet, right? | 05:54 |
| fullermd | Hm. Webiste doesn't like rc2 either. Wacky. | 05:54 |
| lifeless | all tests pass. wahoo | 06:05 |
| 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:34 |
| lifeless | poolie: as an option ? | 06:48 |
| poolie | if necessary | 06:53 |
| poolie | i find i'd often like to start looking at the first failure while it's running.... | 06:53 |
| 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:54 |
| 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:55 |
| 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) | 06:58 |
| lifeless | I've mentioned before wanting to do a machine parsable output to file to automate this more | 07:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| vila | Odd_Bloke: you're welcome :) | 07:04 |
| poolie | probably | 07:04 |
| 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:05 |
| lifeless | poolie: yahh, I use text vim, and many concurrent sessions | 07:26 |
| jml | spiv: ping | 07:31 |
| spiv | jml: pong | 07:42 |
| === Ng_ is now known as Ng | ||
| a_c_m | anyone know any good (semi idiot) tutorials on setting up bzr with pqm (ie automated gatekeeper workflow) | 10:43 |
| dereine | hi | 10:49 |
| dereine | how can i get all changed files since the init | 10:50 |
| dereine | or all changed files between two revisions | 10:50 |
| 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:51 |
| james_w | dereine: "bzr status -r" may be what you want | 10:52 |
| james_w | e.g. bzr status -r2..3 | 10:52 |
| dereine | thx | 10:58 |
| dereine | how do i get the latest revision? | 10:59 |
| james_w | what do you mean? | 10:59 |
| 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:00 |
| 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:23 |
| lifeless | siretart: there is a Makefile | 11:48 |
| 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:49 |
| siretart | lifeless: okay. does this $something include the results of the testsuite? | 11:52 |
| 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:53 |
| lifeless | siretart: If Debian is packaging bzr with test failures, thats bad, and it should definitely stop doing that :P | 11:54 |
| siretart | last upload contained some known pycurl failures that I was told were harmless | 11:56 |
| 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:57 |
| 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 | 11:59 |
| siretart | lifeless: I was under the impression you wanted to include results of the testsuite to NEWS | 12:02 |
| lifeless | wow | 12:03 |
| lifeless | I guess its context | 12:03 |
| lifeless | you may not but NEWS is a continual merge headache | 12:03 |
| lifeless | because entries may merge ok but be in the wrong release etc | 12:04 |
| vila | siretart: I'd be *very* interested about those pycurl failures, do you have some selftest output ? | 12:18 |
| siretart | not anymore, I removed the output some days after my upload | 12:20 |
| siretart | lifeless: see, it might make sense to install the selftest output in the package after all ;) | 12:21 |
| 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:22 |
| vila | siretart: mail me the next time you run the test suite then :) | 12:37 |
| === bac_afk is now known as bac | ||
| lifeless | vila: there is a bug | 12:44 |
| vila | lifeless: only one ? Gosh, we're close :) | 12:45 |
| vila | lifeless: yes ? What bug ? | 12:47 |
| lifeless | vila: on the pycurl failures | 12:48 |
| vila | You can reproduce it ? | 12:49 |
| lifeless | spiv can | 12:52 |
| spiv | I can't anymore; it got fixed AFAICT. | 12:53 |
| 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:54 |
| 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 |
| ubottu | Launchpad bug 225020 in bzr "pycurl reports "select/poll returned error"" [High,Fix released] https://launchpad.net/bugs/225020 | 12:55 |
| siretart | I'm running the testsuite right now on my intrepid laptop | 12:55 |
| vila | great | 12:56 |
| siretart | vila: yes, I think I've seen "select/poll returned error" back then | 12:56 |
| vila | siretart: the bug is fixed in 1.7 but not in 1.6.1. I think intrepid uses the later | 12:57 |
| 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:58 |
| lifeless | vila: arh, don't think so. | 12:59 |
| vila | lifeless: no urgency, that should be done carefully... | 13:00 |
| siretart | vila: what is your email adress? | 13:01 |
| vila | v.ladeuil+lp at free.fr | 13:01 |
| lifeless | vila: is the bug fixed? | 13:02 |
| vila | lifeless: yes, it didn't dare reproduce anywhere AFAIK | 13:03 |
| vila | lifeless: but note that it's fixed in 1.7 and pqm uses 1.6.1 if I'm correct | 13:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| * vila will try to better understand what run under the chroot and what doesn't another day :) | 13:09 | |
| lifeless | vila: 'make check' runs in teh chroot. Nothing else does | 13:12 |
| vila | clear and simple, thanks | 13:13 |
| lllama | Hello all. Anyone got a good method for running the smart server as a service on a central ubuntu box? | 13:18 |
| pysquared | Does anyone know how to do garbage collection in a shared repository after deleting unwanted branches? | 13:22 |
| 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:23 |
| lifeless | pysquared: I don't think there is | 13:24 |
| 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:25 |
| === Snaury is now known as Snaury[away] | ||
| 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:28 |
| === bac is now known as bac_breakfast | ||
| 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:29 |
| a_c_m | branches rock ! | 13:33 |
| lifeless | pysquared: qbzr|bzr-gtk|tbzr(windows) | 13:33 |
| === tro|| is now known as tro | ||
| 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:48 |
| pysquared | I have been using bzr-gtk (olive-gtk yes?) for a while, and it's better than qbzr IMVHO so far. | 13:50 |
| pysquared | Thanks for the fast-import link, looks like a useful example of using bzrlib to disect a repo. | 13:55 |
| === bac_breakfast is now known as bac | ||
| lifeless | generally speaking, I just use bzrlib to work with repo's :) | 14:00 |
| === dereine is now known as dereine[afk] | ||
| lamont | can I safely remove things in .bzr/repository/obsolete_packs (as the name would tend to imply)?? | 14:31 |
| === bac is now known as bac_standup | ||
| 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:39 |
| ubottu | Launchpad bug 225020 in bzr "pycurl reports "select/poll returned error"" [High,Fix released] https://launchpad.net/bugs/225020 | 14:39 |
| === bac_standup is now known as bac | ||
| 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:50 |
| ubottu | Launchpad bug 269770 in bzr "bzr - New upstream versions released" [Undecided,In progress] https://launchpad.net/bugs/269770 | 14:50 |
| lamont | james_w: thansk | 14:52 |
| 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:00 |
| james_w | pysquared: it's obviously just a bit of a pain to do manually | 15:01 |
| 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:08 |
| vila | Tak: ? | 15:09 |
| Tak | hell, sorry | 15:09 |
| vila | :) | 15:10 |
| Tak | script + scrollback = eek! | 15:10 |
| === Verterok is now known as Verterok|out | ||
| 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:24 |
| vila | They mentioned 1.7, that's why I mentioned it to you, no pressure, at all, I swear :) | 15:25 |
| james_w | https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/269770 | 15:27 |
| ubottu | Ubuntu bug 269770 in bzr "bzr - New upstream versions released" [Undecided,In progress] | 15:27 |
| Leonidas | why do I need to --force for a multi-branch merge? is it considered a bad idea? | 16:04 |
| 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:06 |
| Leonidas | james_w: ok, so it is just a human issue, not some technical problem. Thanks. | 16:07 |
| fdv | huh | 16:09 |
| fdv | bzr-svn seems to have replaced an svn revision | 16:09 |
| fdv | is this normal? | 16:09 |
| 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:10 |
| fdv | that was.. unexpected | 16:11 |
| 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:12 |
| jelmer | fdv, This happened after "bzr up" created pending merges I suspect? | 16:13 |
| fdv | jelmer: indeed' | 16:13 |
| === sdboyer|zzz is now known as sdboyer | ||
| 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:17 |
| guilhembi | jam: hi! good idea. We can IRC now. | 16:19 |
| jam | Is this channel fairly quiet? | 16:20 |
| jam | I haven't been watching | 16:20 |
| guilhembi | it is | 16:21 |
| === dereine[afk] is now known as dereine | ||
| jam | guilhembi: so here is my standard example for the 'bzr log file' situation: http://paste.ubuntu.com/49712/ | 16:24 |
| 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:25 |
| Verterok|out | ~/away | 16:27 |
| Verterok|out | sorry :p | 16:27 |
| === Verterok|out is now known as Verterok | ||
| guilhembi | reading | 16:28 |
| guilhembi | jam: yes; to be sure: the only changed of 'foo' is C, right? | 16:29 |
| guilhembi | s/changed/changer | 16:29 |
| 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:30 |
| 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:32 |
| 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:33 |
| guilhembi | jam: this is fine. But, | 16:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| jam | do you agree? | 16:38 |
| guilhembi | yes and no | 16:39 |
| 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:40 |
| 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 |
| === jkakar_ is now known as jkakar | ||
| jam | guilhembi: knowing those branches, I have some guesses that you might see it anyway because of non-conflict resolutions... | 16:41 |
| === ja1 is now known as jam | ||
| jam | guilhembi: sorry, network hiccup, did you respond to "knowing those branches ..." ? | 16:44 |
| 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:45 |
| guilhembi | jam: ah, then it's fine to see B and C and E. | 16:48 |
| guilhembi | jam: let's put it this way: | 16:49 |
| === bac is now known as bac_lunch | ||
| guilhembi | I believe we should see all revisions which introduced a change in the first place, | 16:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| guilhembi | jam: mmmmmm | 16:55 |
| 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:56 |
| 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:57 |
| guilhembi | jam: while I have you here, when finally will your lca_merge_multi reach bzr.dev ? | 16:58 |
| 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:00 |
| 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:01 |
| guilhembi | jam: then that patch needs higher prio, "angry customer" thing. | 17:02 |
| guilhembi | poolie: hello! please see above. | 17:03 |
| jam | guilhembi: well, poolie is in deep-sleep right now, but he'll wake up in about 6 hours | 17:08 |
| jam | anyway, I'm off to reboot and release 1.7 final, I'll be back in a second. | 17:09 |
| 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:42 |
| 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:44 |
| 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:45 |
| 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:46 |
| fdv | jelmer: is it possible to set it in svn itself? | 17:47 |
| fdv | so that no "clients" can do this | 17:47 |
| 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:48 |
| 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:49 |
| === bac_lunch is now known as bac | ||
| 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:54 |
| 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:56 |
| jelmer | fdv, I think you should be able to set it in ~/.bazaar/bazaar.conf | 17:59 |
| fdv | ok, thanks, I'll test | 17:59 |
| 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:01 |
| jelmer | fdv: What should be considered a bug exactly? | 18:02 |
| 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:03 |
| 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:04 |
| fdv | jelmer: not least that this sort of "breaks" svn | 18:05 |
| fdv | you get an inadvertent copy, which might very well not be what you want | 18:06 |
| fdv | (or replace, that is) | 18:06 |
| 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:07 |
| 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:08 |
| fdv | jelmer: in my case, indeed, but I can only speak for myself | 18:09 |
| fdv | maybe bzr could implement a prompt in these cases, unless specifically turned off | 18:10 |
| fdv | jelmer: fyi, bazaar.conf seemed to work as well | 18:13 |
| jelmer | fdv, ah, cool | 18:18 |
| === andreas__ is now known as ahasenack | ||
| Kinnison | jelmer: Are you responsible for ctrlproxy? | 18:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| Kinnison | ctrlproxy-upgrade | 18:40 |
| Kinnison | (although that might be the packager's fault) | 18:40 |
| jelmer | yeah, that's a package bug | 18:40 |
| 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 | 18:45 |
| === BasicPRO is now known as BasicOSX | ||
| === Verterok is now known as Verterok|out | ||
| bpierre | hi | 19:04 |
| === bac is now known as bac_bbiab | ||
| LeoNerd | Guys.. I have an idea... | 19:31 |
| 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:32 |
| 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:34 |
| === bac_bbiab is now known as bac | ||
| jam | Leonidas: sorry, lunch came inbetween | 19:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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 | 19:54 |
| 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:18 |
| === mw is now known as mw|food | ||
| === Verterok|out is now known as Verterok | ||
| abentley | jam: You wanted to talk with me about LCA merge stuffs. Do you still want to do that? | 20:36 |
| a_c_m | Patch Queue Manager? is it abandoned? | 20:58 |
| a_c_m | no activity in the last month | 20:59 |
| a_c_m | no download (that i could see) | 20:59 |
| === mw|food is now known as mw | ||
| james_w | a_c_m: bzr itself uses it | 21:01 |
| james_w | and there is work being done on it | 21:01 |
| seb_kuzminsky | halp! i'm using bzr to work with an svn repo, and it's backtracing on me | 21:02 |
| 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:03 |
| jelmer | seb_kuzminsky, please file a bug | 21:04 |
| seb_kuzminsky | will do | 21:04 |
| 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:05 |
| 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:06 |
| seb_kuzminsky | jelmer: thanks: https://bugs.launchpad.net/bzr-svn/+bug/273716 | 21:08 |
| ubottu | Ubuntu bug 273716 in bzr-svn "backtrace in a bzr branch of an svn repo" [Undecided,New] | 21:08 |
| james_w | a_c_m: you can grab it from bzr | 21:08 |
| jelmer | seb_kuzminsky, thanks | 21:08 |
| seb_kuzminsky | any suggestions on how i can work around this for now? i'd really like to keep working with that sandbox! | 21:09 |
| === bac is now known as bac_afk | ||
| seb_kuzminsky | jelmer: hm i think that bug is probably my fault | 21:20 |
| strk | how do I drop a working tree from a branch once I forgot the --no-tree ? | 21:21 |
| LarstiQ | strk: `bzr remove-tree` | 21:22 |
| 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:28 |
| 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:29 |
| seb_kuzminsky | i upgraded to lp:bzr-1.6 and now it's working | 21:30 |
| seb_kuzminsky | sry! | 21:30 |
| === thumper_laptop is now known as thumper | ||
| a_c_m | james_w: do you know of any good tutorials for doing hook based things? | 22:26 |
| === bpierre_ is now known as bpierre | ||
| === beuno_ is now known as beuno | ||
| beuno | statik, hi. Are you around? | 22:51 |
| 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:52 |
| 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:53 |
| james_w | a_c_m: the documentation is a start, I don't know of any tutorials | 22:54 |
| 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:12 |
| BasicOSX | I've had this "problem" before on osx, bzr remove "File" worksi | 23:13 |
| lifeless | BasicOSX: python -c "import bzrlib.workingtree; t = bzrlib.workingtree.WorkingTree.open('path'); t.remove('exact_relpath')" | 23:14 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!