| lifeless | thats a new one then | 00:00 |
|---|---|---|
| lifeless | uhum | 00:00 |
| lifeless | python version? | 00:00 |
| lifeless | also file a bug to track this; its not usual :) | 00:00 |
| denys | 2.6.2 | 00:00 |
| Noldorin | lifeless: erm, according to the ftp log, it's quite justified to throw that error | 00:03 |
| lifeless | Noldorin: it is? | 00:03 |
| Noldorin | a previous rename has occured which renames a certain dir to that name | 00:03 |
| Noldorin | yeah, let me paste it for you | 00:03 |
| Noldorin | lifeless: http://pastebin.ca/1537024 | 00:06 |
| Noldorin | search for '/lock/held/' | 00:07 |
| Noldorin | and you should see two RNTO commands without any RNFR or RMD commands inbetween | 00:07 |
| Noldorin | lines 759 and 825 | 00:08 |
| lifeless | Noldorin: there is a RNFR for it | 00:09 |
| poolie | jam, still around at all? | 00:10 |
| Noldorin | lifeless: hm? | 00:10 |
| Noldorin | are you assuming that rename commands automatically overwrite existing dirs? | 00:12 |
| lifeless | mmm | 00:13 |
| lifeless | no, I was looking earlier | 00:13 |
| lifeless | is this your patched bzr ? | 00:13 |
| Noldorin | yeah, look between those line numbers | 00:13 |
| Noldorin | nope | 00:13 |
| Noldorin | standard 1.1.7 release | 00:13 |
| lifeless | and is it a trace of a single failing command ? | 00:13 |
| Noldorin | the command was bzr push -Dtransport ftp://... | 00:14 |
| lifeless | did the command complete or error ? | 00:14 |
| Noldorin | i got the old lock error | 00:14 |
| Noldorin | Unable to obtain lock ftp://alexreg-repos@213.175.198.12/texdotnet/.bzr/reposito | 00:14 |
| Noldorin | ry/lock | 00:14 |
| Noldorin | held by alexreg@gmail.com on host Alex-Laptop-PC [process #11988] | 00:14 |
| Noldorin | locked 7 seconds ago | 00:14 |
| lifeless | and it was a new directory ? | 00:14 |
| Noldorin | yep | 00:15 |
| Noldorin | well i was pushing to a clean dir | 00:15 |
| Noldorin | so *do you* assume that rename commands automatically overwrite existing dirs? | 00:16 |
| Noldorin | (i'm not terribly familiar with how ftp servers handle requests, in particular linux ones.) | 00:16 |
| lifeless | 339 locks 455 unlocks. Thats the 'init' phase. 759 locks. 771 reads-back to check it locked. 785 reads again. 825 tries again. | 00:16 |
| lifeless | no, we assume that file systems are horribly broken. | 00:17 |
| Noldorin | heh | 00:17 |
| lifeless | Noldorin: heres what I get from that trace: | 00:17 |
| Noldorin | not horribly broken enough :) | 00:17 |
| lifeless | something went wrong and bzr attempts to spin on the lock. | 00:17 |
| Noldorin | right | 00:17 |
| lifeless | the repeated attempt to acquire the lock is consistent with a failed lock attempt | 00:18 |
| Noldorin | i see... | 00:18 |
| Noldorin | but the curious thing is... | 00:18 |
| Noldorin | it seems to have actually succeeding in creating the lock, no? | 00:18 |
| lifeless | the rename succeeded. | 00:18 |
| Noldorin | mm | 00:19 |
| Noldorin | so what did fail here? | 00:19 |
| Noldorin | sorry if i'm being slow | 00:19 |
| lifeless | you're not. its tricky. | 00:19 |
| Noldorin | quite | 00:19 |
| lifeless | do you have the .bzr.log from that run ? | 00:21 |
| lifeless | ah | 00:21 |
| lifeless | do this | 00:21 |
| lifeless | bzr -Dtransport -Dlock push ... | 00:22 |
| lifeless | this will log more to the .bzr.log | 00:22 |
| Noldorin | right ho | 00:22 |
| lifeless | get a network trace at the same time | 00:22 |
| Noldorin | lifeless: http://pastebin.ca/1537042 | 00:24 |
| Noldorin | http://pastebin.ca/1537043 | 00:25 |
| Noldorin | and yes, that actually is the log from the new run. | 00:27 |
| Noldorin | seems to be identical | 00:27 |
| Noldorin | erm, network trace | 00:27 |
| lifeless | cool | 00:28 |
| lifeless | so | 00:28 |
| lifeless | look at the .bzr.log | 00:28 |
| Noldorin | yep | 00:28 |
| lifeless | line 65 locks | 00:28 |
| lifeless | line 73 unlockks | 00:28 |
| lifeless | or starts the unlock sequence | 00:28 |
| Noldorin | that's for the bzr init process, no? | 00:29 |
| lifeless | yes | 00:30 |
| lifeless | so thats the release | 00:30 |
| Noldorin | right. well we know that succeeds at least | 00:30 |
| lifeless | then we wite some temp data | 00:30 |
| Noldorin | from other things to | 00:30 |
| Noldorin | yep | 00:30 |
| lifeless | and 105 starts a new lock sequence | 00:31 |
| lifeless | which renames into plce at 108 | 00:31 |
| lifeless | but, at 110 when we read it back we see it is held by the earlier lock object | 00:31 |
| lifeless | so I'll make a patch to make that blow up | 00:32 |
| lifeless | and then the network log will be cleaner | 00:32 |
| Noldorin | alright | 00:32 |
| Noldorin | something for me to test now, yeah? | 00:32 |
| lifeless | yes | 00:33 |
| Noldorin | :) | 00:33 |
| lifeless | you can see that the nonce is unchanged | 00:33 |
| lifeless | search for 0cgz | 00:33 |
| lifeless | the init-lock uses that nonce | 00:33 |
| lifeless | and the later lock encounters that lock | 00:33 |
| Noldorin | yep | 00:35 |
| lifeless | http://pastebin.ca/1537052 | 00:36 |
| Noldorin | cheers | 00:40 |
| lifeless | that works for me, with a local filesystem ;) | 00:40 |
| lifeless | it should work for you too | 00:40 |
| Noldorin | erm, should i be editing the source i already hacked | 00:41 |
| Noldorin | or do a clean pull? | 00:41 |
| lifeless | either | 00:41 |
| Noldorin | ok | 00:41 |
| lifeless | IIRC the other changes were to lock ? | 00:42 |
| Noldorin | yeah | 00:43 |
| Noldorin | i think they were mainly delays and such | 00:43 |
| Noldorin | maybe an extra command in one or two places | 00:43 |
| Noldorin | bzr.log/network trace/both? | 00:44 |
| Noldorin | interesting | 00:46 |
| Noldorin | i get the 'ftp breakage' message (from our previous test i believe) | 00:47 |
| Noldorin | but not your new 'we know its broken now' one | 00:47 |
| Noldorin | lifeless: http://pastebin.ca/1537063 | 00:47 |
| lifeless | the .bzr.log please | 00:49 |
| Noldorin | http://pastebin.ca/1537064 | 00:49 |
| Noldorin | lifeless: anything interesting? | 00:53 |
| lifeless | analysing | 00:55 |
| lifeless | it tries to unlock twice | 00:55 |
| lifeless | uhm | 00:56 |
| lifeless | please try on a clean copy | 00:56 |
| lifeless | you can 'bzr shelve1' your existing changes | 00:56 |
| lifeless | or just bzr diff > old.patch | 00:56 |
| lifeless | bzr revert | 00:56 |
| lifeless | then apply my new patch | 00:56 |
| Noldorin | ok | 00:57 |
| Noldorin | sounds sensible | 00:57 |
| lamont | lifeless: when I did bzr shelve; bzr commit; bzr unshelve, bzr changed group ownership on (the one) modified file.. .is that expected? | 00:58 |
| lifeless | lamont: it writes a new file | 00:58 |
| lamont | ah, that would do it | 00:58 |
| lifeless | so, 'yes'. | 00:58 |
| denys | hmm... (tried something with the test suite) how long does selftest need for a full run? minutes, hours, days? | 00:59 |
| lamont | always sad when a corner-case use-case smacks against designs that make sense for everything else... no worries | 00:59 |
| lifeless | if you file a bug that we should preserve that (where we can), we can look at what it will take to do it. | 00:59 |
| lamont | lifeless: I'll file the bug | 00:59 |
| lifeless | denys: depends on your machine | 00:59 |
| lifeless | denys: on mine, 40minutes, on vilas with --parallel=fork, 4 minutes | 00:59 |
| lamont | lifeless: you need a new machine. :-p | 01:00 |
| lifeless | lamont: no, I need to fix the test suite | 01:00 |
| lifeless | we run some code paths millions of times. Thats inefficient. | 01:00 |
| Noldorin | lifeless: -Dtransport and -Dlock this time? | 01:02 |
| denys | I was wondering about --parallel. the option's help is completely unhelpful. I had no idea ARG could be fork (or anything). I don't know what it does. | 01:03 |
| Noldorin | lifeless: erm, i get 'bzr: ERROR: exceptions.NameError: global name 'error' is not defined' in stdout | 01:04 |
| lamont | lifeless 416718 | 01:04 |
| Noldorin | erm, note that 'in stdout' isn't part of the error message :P | 01:05 |
| lifeless | Noldorin: a typo | 01:09 |
| lifeless | errors. | 01:09 |
| lifeless | not error. | 01:09 |
| Noldorin | lifeless: where? | 01:10 |
| lifeless | in my patch | 01:10 |
| lifeless | I wrote error.BzrError twice. I should have written errors.BzrError | 01:11 |
| poolie | lifeless: did you make a 2.0 branch? | 01:12 |
| lifeless | yes | 01:12 |
| lifeless | or rather spm did | 01:12 |
| poolie | spiv: ah that explains why you were talking over me :) | 01:12 |
| poolie | great | 01:12 |
| lifeless | as I can't anymore :P | 01:12 |
| spiv | poolie: :) | 01:12 |
| === Noldorin_ is now known as Noldorin | ||
| Noldorin | bzr: ERROR: epic unlock fail | 01:14 |
| Noldorin | lol | 01:14 |
| Noldorin | lifeless: you want bzr.log? | 01:14 |
| lifeless | Noldorin: please | 01:14 |
| spm | lifeless: it was a team effort: you had the daunting task of telling me to "make it so"; I merely had to do the steps. :-P | 01:14 |
| lifeless | spm: I am an alpha particle | 01:15 |
| spm | ha | 01:15 |
| Noldorin | lifeless: http://pastebin.ca/1537092 | 01:15 |
| lifeless | hey, better than claiming to be cpt kirk | 01:19 |
| Noldorin | *confused* | 01:19 |
| lifeless | Noldorin: ok, this shows the error we thought was happening | 01:20 |
| lifeless | we've done a rename | 01:20 |
| lifeless | but we can read the old file back after the rename and delete | 01:20 |
| Noldorin | erm, i meant confused about your comments :) | 01:20 |
| emmajane | poolie, I've given beuno I bit of feedback as well. | 01:20 |
| Noldorin | also confused about this ftp stuff though! | 01:20 |
| lifeless | Noldorin: two conversations at once | 01:20 |
| poolie | cool, thanks | 01:20 |
| Noldorin | yeah | 01:20 |
| lifeless | Noldorin: get a network trace of this, and the log. | 01:20 |
| Noldorin | lifeless: i know. couldn't help but wondering though | 01:20 |
| lifeless | and we should be able to make a demo script | 01:20 |
| poolie | jam, i'll put up a patch for the trivial indexerror of bug 416550 | 01:20 |
| poolie | i don't know what his actual problem is | 01:21 |
| Noldorin | lifeless: well we already have the log, no? | 01:22 |
| lifeless | the random details will not match the network trace unless they are done at the same time | 01:22 |
| lifeless | you need to capture the data sessions to, to have the files that are uploaded | 01:22 |
| Noldorin | good point | 01:22 |
| Noldorin | like the nonce values | 01:22 |
| Noldorin | yeah, never mind. | 01:22 |
| Noldorin | late night debugging for the win | 01:23 |
| Noldorin | lifeless: http://pastebin.ca/1537106 and http://pastebin.ca/1537107 | 01:23 |
| lifeless | btw, your password is in clear text in the traces... you may want to change it ;) | 01:26 |
| emmajane | poolie, maybe I ping Joey for that though... | 01:27 |
| poolie | hi lifeless | 01:27 |
| lifeless | Noldorin: can you see if you can read /texdotnet/.bzr/branch-lock/held/info ? | 01:29 |
| Noldorin | lifeless: manually? | 01:30 |
| lifeless | the trace didn't capture file contents | 01:30 |
| lifeless | yes | 01:30 |
| Noldorin | ok | 01:30 |
| Noldorin | erm, there's nothing in branch-lock/ | 01:30 |
| Noldorin | lifeless: ..? | 01:33 |
| lifeless | so | 01:33 |
| lifeless | the server has deleted it | 01:33 |
| lifeless | what are you capturing with ? | 01:33 |
| Noldorin | wireshark | 01:35 |
| lifeless | we need to make it capture the uploads | 01:35 |
| * igc ignores email for a few hours and gets back to wrapping up the upgrade patch | 01:35 | |
| Noldorin | ok | 01:35 |
| Noldorin | what port is that? | 01:36 |
| Noldorin | (i know that it uses a different connection, from my memory of the ftp protocol) | 01:36 |
| lifeless | its dynamic | 01:37 |
| lifeless | 227 Entering Passive Mode (213,175,198,12,9,122) | 01:37 |
| lifeless | hmm | 01:37 |
| lifeless | ok | 01:39 |
| lifeless | another small patch | 01:39 |
| Noldorin | ok | 01:39 |
| lifeless | === modified file 'bzrlib/transport/log.py' | 01:39 |
| lifeless | --- bzrlib/transport/log.py 2009-07-01 07:29:37 +0000 | 01:39 |
| lifeless | +++ bzrlib/transport/log.py 2009-08-21 00:39:32 +0000 | 01:39 |
| lifeless | @@ -143,6 +143,7 @@ | 01:39 |
| lifeless | return return_result | 01:39 |
| lifeless | 01:39 | |
| lifeless | def _shorten(self, x): | 01:39 |
| lifeless | + return x | 01:39 |
| lifeless | if len(x) > 70: | 01:39 |
| lifeless | x = x[:67] + '...' | 01:39 |
| lifeless | return x | 01:39 |
| lifeless | then add log+ to the start of the url you push to | 01:39 |
| Noldorin | kk | 01:42 |
| Noldorin | network trace again? | 01:43 |
| lifeless | yes, both again in fact :) | 01:43 |
| Noldorin | lifeless: interesting. after i delete the push dir on the ftp server, i have to wait a while before bzr will let me push again | 01:45 |
| Noldorin | ~20/30 seconds | 01:46 |
| Noldorin | i wonder if that has anything to do with this issue | 01:46 |
| lifeless | does bzr pause, or error, or ? | 01:46 |
| Noldorin | lifeless: http://pastebin.ca/1537136 and http://pastebin.ca/1537132 | 01:47 |
| Noldorin | bzr: ERROR: At log+ftp://alexreg-repos@213.175.198.12/texdotnet you have a valid | 01:47 |
| Noldorin | .bzr control directory, but not a branch or repository. This is an unsupported | 01:47 |
| Noldorin | configuration. Please move the target directory out of the way and try again. | 01:47 |
| Noldorin | started working soon enough though, and that just disappeared. | 01:47 |
| lifeless | yes | 01:49 |
| lifeless | thats identical behaviour | 01:49 |
| lifeless | deletes taking a long time to actually be deleted. | 01:49 |
| Noldorin | thought so | 01:49 |
| Noldorin | is that the root of all our problems here then, do you think? | 01:49 |
| Noldorin | or just another symptom? | 01:50 |
| lifeless | Its the root behaviour causing the problems; what drives it I don't know | 01:50 |
| Noldorin | yeah, fair enough | 01:51 |
| Noldorin | anything helpful in those new logs i just pasted? | 01:51 |
| lifeless | yes, we've got the data now | 01:53 |
| lifeless | Noldorin: whats the bug number for this? | 01:56 |
| Noldorin | lifeless: https://bugs.launchpad.net/bzr/+bug/412244 | 01:58 |
| lifeless | Noldorin: ok, I've attached sanitised versions to the bug | 02:02 |
| lifeless | its late for you, I think | 02:02 |
| lifeless | so you should go crash | 02:02 |
| lifeless | when you get up, we now have enough data that you can use the StringO stuff in the log trace + the network trace to make a test | 02:02 |
| Noldorin | heh, yeah. i've given enough hints as to that | 02:02 |
| Noldorin | right | 02:02 |
| lifeless | put the strings that are uploaded on disk as files with the right names so you can | 02:02 |
| lifeless | push | 02:03 |
| lifeless | sory | 02:03 |
| lifeless | put FOO | 02:03 |
| lifeless | rename | 02:03 |
| lifeless | etc | 02:03 |
| lifeless | etc | 02:03 |
| lifeless | I'll help you validate the test - or anyone here can do that if you turn up while I'm not active | 02:03 |
| Noldorin | lifeless: i'll try to catch you tomorrow evening | 02:03 |
| Noldorin | (will i be able to?) | 02:03 |
| Noldorin | ok | 02:03 |
| Noldorin | cool | 02:03 |
| Noldorin | mind summarising that in a comment on the bug? | 02:04 |
| lifeless | sure thing | 02:04 |
| lifeless | well, it will be my weekend | 02:04 |
| lifeless | I may or may not be around | 02:04 |
| Noldorin | yeah, fair point | 02:04 |
| Noldorin | well see you, perhaps | 02:04 |
| Noldorin | thanks again, lifeless | 02:04 |
| lifeless | np | 02:04 |
| Noldorin | have a good weekend | 02:04 |
| Noldorin | bye | 02:04 |
| lifeless | ciao | 02:06 |
| poolie | lifeless: i propose to look at your specific-files-commit thing now | 02:07 |
| poolie | john says in https://code.edge.launchpad.net/~lifeless/bzr/commit-specific-files/+merge/9413 there's a previous patch - is that still outstanding, and if so what is it? | 02:07 |
| lifeless | iter-changes-partial-parents | 02:07 |
| lifeless | its the machinery patch | 02:08 |
| poolie | ok and that ends up with you saying you found two bugs and you'd fix them after lunch | 02:11 |
| lifeless | and then discussion on the list | 02:11 |
| poolie | ok | 02:12 |
| lifeless | [meta: this goes back to 'why aren't reviews on the list like they were with BB' :P] | 02:12 |
| poolie | we just had that thread | 02:12 |
| lifeless | yes, I saw. We had had it before anyway, when we started using code reviews. | 02:13 |
| lifeless | and we filed code reviews bugs at the time | 02:13 |
| poolie | maybe it should be in a wave | 02:14 |
| poolie | email tends to get thread fragmentation too | 02:14 |
| lifeless | waves look like a really good fit for bugs | 02:15 |
| lifeless | perhaps code too | 02:15 |
| poolie | one of the problems is that email doesn't have practically usable urls that you can pass around | 02:18 |
| poolie | can you give me the subject of the thread about this? | 02:19 |
| poolie | there are a lot mentioning "commit" :) and none apparently mentioning that branch | 02:19 |
| poolie | ok i have it | 02:20 |
| poolie | "iter_changes, delta consistency and revert" | 02:21 |
| igc | poolie ping | 02:33 |
| igc | poolie: can we chat re upgrade when you're free? | 02:34 |
| igc | poolie: I'd like to discuss the exception catching and whether we should continue with other branches if one fails say | 02:34 |
| lifeless | poolie: bug 375013 | 02:36 |
| lifeless | poolie: I had that set deliberately :(. I thought I was clear in my comments as to why its not closed... | 02:37 |
| lifeless | I'd like to know how I can make it clearer in future to avoid us churning. | 02:37 |
| FryGuy- | are there any read-write plugins for git? | 02:37 |
| lifeless | poolie: comment #6 specifically | 02:38 |
| elmo | wildly off topic, but I suspect people here now; are svn revision numbers monotonically increasing within a single tree? | 02:46 |
| bob2 | yes | 02:46 |
| elmo | ta | 02:46 |
| igc | elmo: not like bzr though to my knowledge ... | 02:47 |
| igc | elmo: svn numbers increase across the repo I think | 02:47 |
| lifeless | elmo: no | 02:47 |
| bob2 | oh, oops | 02:47 |
| elmo | haha | 02:47 |
| lifeless | elmo: they are monotonically in a svn repo | 02:47 |
| lifeless | elmo: they are strictly increasing in a single tree | 02:47 |
| igc | elmo: so, IIUIC, the number will increase with a tree but not necessarily be contiguous | 02:48 |
| igc | s/number/numbers/ | 02:48 |
| igc | s/with/within/ | 02:48 |
| lifeless | elmo: its a single global counter stored in the svn repository - revno in svn is 'transaction sequence number' | 02:48 |
| igc | FryGuy: try the bzr-git plugin | 02:49 |
| elmo | lifeless/igc/bob2: ta | 02:49 |
| lifeless | anytime | 02:50 |
| spiv | lifeless, poolie: pyflakes-vim: http://www.vim.org/scripts/script.php?script_id=2441 | 02:51 |
| lifeless | spiv: heh, yes. saw on facebook yesterday :) | 02:51 |
| spiv | :) | 02:51 |
| spiv | I remembered it just now because it just happened to highlight some clearly broken code in get_raw_records, which is a bit alarming. | 02:52 |
| spiv | I guess the codepath that tries to use the undefined 'current_list' is never triggered... | 02:52 |
| igc | lifeless: it looks like upgrading of a shared repo + branches from 0.92 -> 2a is broken currently | 02:52 |
| lifeless | igc: how so? | 02:52 |
| igc | lifeless: at least as documented in the Upgrade Guide | 02:53 |
| igc | lifeless: the shared repo upgrades ok ... | 02:53 |
| igc | lifeless: but then trying the branch errors ... | 02:53 |
| igc | NoSuchRepository | 02:53 |
| spiv | I need to merge mwhudson's lazy_import awareness patch for pyflakes into that vim plugin though. It's a bit of a shame that it has effectively a fork of pyflakes (to make it faster and also report column numbers)... | 02:53 |
| igc | yet info, check and everything else seem ok | 02:53 |
| lifeless | igc: how is the repo being upgraded/branch being upgraded? | 02:53 |
| FryGuy- | igc: the plugins page said it was read-only, as in i could only branch from git, and not push changes back | 02:54 |
| lifeless | [point me at the uprade guide bit that talks about this] | 02:54 |
| igc | cd repo; bzr upgrade | 02:54 |
| igc | http://doc.bazaar-vcs.org/bzr.1.18rc1-html/en/upgrade-guide/index.html#migrating-branches-in-a-shared-repository | 02:54 |
| igc | cd branch-in-repo; bzr upgrade | 02:54 |
| * igc pastebins | 02:55 | |
| lifeless | igc: looks like a regression in upgrade | 02:55 |
| lifeless | its probably the fix from poolie to read off disk | 02:55 |
| igc | lifeless, poolie: http://pastebin.com/m7178eb8e | 02:56 |
| lifeless | igc: have you filed a bug ? | 02:56 |
| igc | lifeless: not yet ... | 02:56 |
| lifeless | please do :) | 02:56 |
| lifeless | I'm fixing now | 02:56 |
| igc | I'm tracking down why my upgrade patch isn't working and it seems it's in trunk without my changes | 02:57 |
| igc | lifeless: filing bug now | 02:57 |
| poolie | mm that probably is my change | 02:57 |
| poolie | so the repo is actually ..? | 02:58 |
| lifeless | you have to call the api to find it | 02:58 |
| lifeless | or handle one not being there. | 02:58 |
| poolie | sure | 03:00 |
| poolie | i thought i only changed the destination format determination though | 03:00 |
| igc | poolie: so the repo and trunk were both 0.92 | 03:00 |
| poolie | igc, assign it to me | 03:00 |
| igc | step 1: upgrade repo - that works | 03:00 |
| igc | step 2: upgrade branch - that falls over | 03:01 |
| lifeless | igc: the formats don't atter | 03:02 |
| igc | alter? matter? | 03:03 |
| lifeless | matter | 03:03 |
| igc | I suspect not | 03:03 |
| lifeless | possibly broken earlier actually | 03:06 |
| lifeless | mmm, no. 4608 broke it | 03:06 |
| lifeless | fixed | 03:08 |
| lifeless | sending for review | 03:10 |
| spiv | Hmm, I wish that pdb would let me skip over yield statements (the way 'next' skips over function calls) rather than taking me back to the caller. | 03:15 |
| lifeless | that would be nice | 03:15 |
| lifeless | of course there's no guarantee it will get back | 03:15 |
| spiv | Yeah. | 03:15 |
| lifeless | and unlike next it won't see exceptions raised in the interim | 03:16 |
| spiv | I can see why they haven't implemented it, but I don't really care ;) | 03:16 |
| igc | thanks lifeless - I'll test out the fix | 03:16 |
| spiv | The point of a debugger is to do hard things for me ;) | 03:16 |
| lifeless | does pdb do breakpoints? | 03:16 |
| lifeless | if so | 03:17 |
| lifeless | breakpoint +1 | 03:17 |
| lifeless | continue | 03:17 |
| lifeless | wouldn't be horrible | 03:17 |
| spiv | It does, although I've always found them cumbersome so virtually never use them. | 03:17 |
| spiv | Maybe it's less cumbersome than unwinding three levels of generator yields and then going back in again... | 03:17 |
| lifeless | 1) get a cumbersome recipe. 2) patch to make it easier ;) | 03:18 |
| spiv | Right :) | 03:19 |
| poolie | lifeless: i don't see the mp | 03:20 |
| poolie | trivial review wanted: https://code.edge.launchpad.net/~mbp/bzr/trivial/+merge/10501 | 03:21 |
| lifeless | https://code.launchpad.net/~lifeless/bzr/upgrade/+merge/10502 | 03:22 |
| lifeless | poolie: I'd like a test in test_errors for that, showing the sort of data we were seeing | 03:23 |
| lifeless | poolie: with that, I'm +1 | 03:23 |
| poolie | lifeless: me too, but it's the kind of thing that gives an unsatisfying test | 03:23 |
| poolie | if i directly raise a socket error | 03:24 |
| poolie | do we know that's consistent with what python does? | 03:24 |
| poolie | i guess i could actually make and then fail to bind a socket | 03:24 |
| lifeless | I was meaning static data actually | 03:24 |
| lifeless | but sure, if it needs a socket to make the old code break.. | 03:24 |
| poolie | ah yes, that's better | 03:25 |
| poolie | ^ re your patch | 03:26 |
| igc | lifeless: that test mightn't be good enough? | 03:26 |
| igc | lifeless: make_branch_and_tree calls make_branch which always creates it's own non-shared repo IIUIC | 03:27 |
| lifeless | igc: how do you mean? | 03:27 |
| lifeless | igc: thats why the delete_tree is there :P | 03:27 |
| lifeless | igc: try the test without my change to bzrdir.py, if you doubt :) | 03:28 |
| igc | lifeless: ah | 03:29 |
| lifeless | there was the opprtunity to yak shave | 03:29 |
| lifeless | but we're a little short on time at the moment | 03:30 |
| poolie | igc: ~poolie is not me | 03:30 |
| poolie | and lp has a huge bug that it lets you make that mistake :} | 03:30 |
| poolie | i'm ~mbp | 03:30 |
| igc | poolie: well LP *did* tell me assigning to poolie was unusual ... | 03:30 |
| lifeless | I thought lp queried on new assignees | 03:30 |
| lifeless | ^^ | 03:31 |
| poolie | i do actually write some code you know :) | 03:31 |
| igc | because poolie didn't have any other assignments in bzr | 03:31 |
| lifeless | igc: it probably will never query again now :) | 03:31 |
| poolie | oh i thought it would do that | 03:31 |
| poolie | but it's still a bit barn-door-horse | 03:31 |
| lifeless | poolie: how many times should it ask though? | 03:31 |
| igc | poolie: I went to fix it but the fast moving lifeless had assigned it to himself before I could blink | 03:32 |
| poolie | you should be able to just point to one of the common reviewers | 03:32 |
| lifeless | personally, I think it should just do it and tell you it was odd afterwards | 03:32 |
| poolie | s//contributors | 03:32 |
| poolie | there's no good reason you should need to remember | 03:32 |
| lifeless | with type-completion listing the folk it knows | 03:32 |
| poolie | iow vocabularies should prioritize the likely choices | 03:32 |
| poolie | lifeless: i replied to the iter_changes thread | 03:42 |
| poolie | i'm not sure that will have unblocked it though | 03:42 |
| poolie | what do you think would be a good next step? | 03:42 |
| poolie | i can think of | 03:42 |
| poolie | 1- read the patches in detail | 03:42 |
| poolie | 2- just decide the knownfailure is ok | 03:42 |
| poolie | i don't have a problem with 2 for this particular case but it is a concern if this is likely to cause bugs with code making assumptions about the change lists | 03:43 |
| * igc lunch | 03:44 | |
| lifeless | poolie: the knownfailure is the symptom of the API change; Aaron's objections are to the API change, and you also express some concern about it not being symmetrical. | 03:45 |
| poolie | right, exactly | 03:47 |
| poolie | so i'm trying to work out if those concerns are well founded or not | 03:47 |
| lifeless | our UI works on symmetric deltas; our core works on asymmetric deltas. | 03:48 |
| lifeless | (e.g. 'bzr diff A B' == reverse_patch(bzr diff B A) | 03:49 |
| lifeless | but push A B doesn't send the data A is missing from B, only the data needed to be added to B to have A | 03:49 |
| poolie | right | 03:51 |
| poolie | and that's actually a bit of a .. well, not accident, but specific choice for this ui | 03:52 |
| poolie | it'd be reasonable for someone to want a diff output format that's not symmetric for file deletions | 03:52 |
| lifeless | right | 03:52 |
| poolie | or indeed not symmetric at all, like ed diffs | 03:52 |
| lifeless | so this patch matches bzr diff A B != reverse_patch(bzr diff B A) | 03:52 |
| lifeless | *when specific paths are used and inconsistent states would be encountered* | 03:53 |
| poolie | even for diff? | 03:53 |
| lifeless | yes | 03:53 |
| poolie | so one way to make that look less weird is to specif | 03:53 |
| lifeless | currently diff will skip alterations to the parents of the names files | 03:53 |
| lifeless | and all the related logic | 03:54 |
| poolie | bzr_diff(A, B, paths_in_A) != reverse(bzr_diff(B, A, paths_in_B)) | 03:54 |
| lifeless | yes | 03:54 |
| lifeless | precisely | 03:54 |
| poolie | is that it? | 03:54 |
| poolie | k | 03:54 |
| lifeless | well, modulo the fact that we look for paths in [A B] | 03:54 |
| lifeless | but thats part of our 'expansion for correctness' logic as well | 03:54 |
| poolie | ok so it's actually | 03:54 |
| poolie | paths_in=(A, B) vs paths_in=(B, A) | 03:55 |
| poolie | or maybe not even precisely that, but the point is that there's more going on here than just the main two inputs | 03:55 |
| lifeless | roughly. Its hard to reason about even before the patch. | 03:55 |
| lifeless | The key bits are: we diff more than just the named paths; the patch means that 'more' becomes larger when directory changes are involved, and does so assymetrically. | 03:56 |
| lifeless | now, named paths diffs don't turn A into B, or vice verca - they are explicitly a subset of the changes. | 03:57 |
| * poolie looks at the revert code | 04:00 | |
| abentley | poolie: I'm around, if you have questions about it. | 04:01 |
| lifeless | hi abentley | 04:02 |
| abentley | lifeless: hi | 04:02 |
| poolie | hi, welcome back | 04:02 |
| abentley | poolie: thx | 04:02 |
| poolie | actually it's not so much answers about the code i'm looking for as a decision about iter_changes | 04:02 |
| poolie | see the scrollback and the list | 04:03 |
| poolie | igc or others - any comments on the new slimmer http://bazaar-vcs.org/Roadmap | 04:03 |
| abentley | poolie: I've thought about the issues on vacation, though I haven't read tonight's list discussion and I've been offline for ~5 hours. | 04:05 |
| poolie | well | 04:05 |
| poolie | i don't mean to pull you into it in your evening | 04:05 |
| poolie | unless you want to | 04:05 |
| === abentley1 is now known as abentley | ||
| abentley | darn flaky wifi. | 04:08 |
| abentley | poolie: I don't have clear answers, but I do have the nagging feeling that what commit wants is a similar-but-different API to what revert, shelve, merge, and possibly status want. | 04:09 |
| poolie | maybe so | 04:13 |
| poolie | at any rate it sometimes needs more data | 04:13 |
| poolie | it seems like it should use the same expansion rules | 04:13 |
| poolie | iow status should be pretty similar to commit --dry-run | 04:14 |
| abentley | poolie: When a parent directory is renamed or moved, should status report that the children have had their path change? | 04:15 |
| poolie | abentley: i'd be ok either way tbh | 04:16 |
| poolie | perhaps at the api level it should | 04:16 |
| abentley | I like the way status works right now. | 04:16 |
| lifeless | abentley: do you mean unaltered children? | 04:16 |
| poolie | and then at a ui level it might decide that it wants to show the minimum description | 04:16 |
| abentley | lifeless: Yes. | 04:16 |
| lifeless | abentley: because that isn't changing | 04:16 |
| poolie | what does it do now? | 04:17 |
| abentley | lifeless: You proposed that "bzr status foo/bar" should report a change to foo. This is how I extrapolated that. | 04:17 |
| lifeless | abentley: if foo has changed, it should yes. | 04:17 |
| abentley | lifeless: Even though bar is unaltered? | 04:18 |
| abentley | lifeless: Anyhow, I know that if I merge, revert or shelve foo/bar, I don't want to affect foo. | 04:19 |
| lifeless | no | 04:19 |
| lifeless | if bar hasn't changed, bzr st foo/bar won't report a change to foo | 04:20 |
| lifeless | robertc@lifeless-64:/tmp/test$ ~/source/baz/pending/iter-changes-partial-parents/bzr st foo/bar | 04:20 |
| lifeless | robertc@lifeless-64:/tmp/test$ bzr st | 04:20 |
| lifeless | renamed: | 04:20 |
| lifeless | a/ => foo/ | 04:20 |
| lifeless | Quite separately to why I'm working on this, there is a bug open that 'bzr st foo/bar', when bar is changed, and foo is renamed, doesn't show foo as changed. | 04:21 |
| lifeless | I think some users might like bzr st foo/bar to always show changes to foo; I haven't formulated an opinion on that. | 04:21 |
| lifeless | abentley: if you're shelving foo/bar, and foo was renamed; it seems reasonable to me to be asking if the dir should be renamed back. A file-only based VCS would ask about renaming foo/bar back to old/bar | 04:22 |
| abentley | lifeless: Oh, I could have sworn that you held that bug up as another example that your approach was the correct way to go. | 04:23 |
| abentley | lifeless: Why? If I go to the dry cleaner to get a shirt cleaned, they don't offer to shower me, too. | 04:24 |
| lifeless | They also don't offer to put the threads back into the spiders they came from | 04:25 |
| abentley | lifeless: I'm saying "shelve changes to bar". Shelving changes to foo is not what I want when I ask for that. | 04:25 |
| abentley | lifeless: If I want to shelve changes to foo, I can ask for that. | 04:25 |
| lifeless | I'm looking for that bug, I can't easily find it :( | 04:30 |
| lifeless | abentley: arguably, being at 'foo/bar' is as much of a change to the file as the content changes | 04:31 |
| poolie | so i'd like to work out what we have to do to get this unblocked | 04:32 |
| poolie | i can see how the expansion might not always be what you want but it's not clearly wrong | 04:33 |
| poolie | and there does seem some risk in having asymmetric deltas but that's not clearly wrong either | 04:33 |
| abentley | lifeless: But from that perspective, reverting foo is also affecting all the other files in foo, which doesn't align well with the user's minimal request. | 04:33 |
| abentley | poolie: I think if we want to maintain iter_changes as a single method, we should have a flag to specify when we want this asymmetric expansion. | 04:35 |
| poolie | otherwise it would do no expansion at all? | 04:35 |
| lifeless | so there are bits here | 04:36 |
| abentley | poolie: It would behave the way it does now, which recurses into subdirectories. | 04:36 |
| lifeless | symmetry and correctness | 04:36 |
| lifeless | we can make it symmetrical always, at the cost of larger deltas in some corner cases. | 04:36 |
| lifeless | and those larger deltas - I don't like them for the same reason you're arguing against foo being reported | 04:37 |
| abentley | lifeless: And at the cost of having to filter it to get the current behaviour back. | 04:37 |
| lifeless | they make 'small' requests into larger ones | 04:37 |
| lifeless | the expansion to ensure consistent deltas is something that I firmly believe has to be enabled for commit+diff+status+revert. | 04:38 |
| lifeless | Those four because: status and diff should show what commit and revert will do | 04:39 |
| poolie | i can't remember, is it actually correct that reverting a file in a renamed directory will revert everything else in there? | 04:39 |
| lifeless | I think it would be odd and require explanation to have shelve do things differently to revert. | 04:39 |
| poolie | or just the rename of the directory? | 04:39 |
| lifeless | poolie: it won't with my patch | 04:39 |
| abentley | poolie: It will rename the directory. | 04:40 |
| lifeless | it would revert that file, and rename the directory back. | 04:40 |
| lifeless | which is the same set of changes 'commit' would do given that path. | 04:40 |
| lifeless | in fact | 04:40 |
| lifeless | its the same set of changes commit /commits today/ given that path. | 04:40 |
| abentley | lifeless: So, I don't think that commit foo/bar should commit a rename of foo, either. | 04:40 |
| lifeless | abentley: Just to be clear; you are aware that thats what it does at the moment - and always has. | 04:41 |
| abentley | lifeless: No, I was not aware that it did that. I consider that a bug. | 04:41 |
| poolie | so maybe you'd want a "strictly minimal" mode | 04:41 |
| poolie | i'm not sure that should be any different between commands | 04:42 |
| poolie | or that the default would differ | 04:42 |
| lifeless | $ bzr st | 04:42 |
| lifeless | brenamed: | 04:42 |
| lifeless | a/ => foo/ | 04:42 |
| lifeless | robertc@lifeless-64:/tmp/test$ bzr commit -m '2' foo/bar | 04:42 |
| lifeless | Committing to: /tmp/test/ | 04:42 |
| lifeless | renamed a => foo | 04:42 |
| lifeless | Committed revision 2. | 04:42 |
| abentley | lifeless: Anyhow, the argument could be made that since status, diff, revert and shelve *don't* do this expansion, it's commit that should change. | 04:44 |
| lifeless | abentley: I'm open to that argument | 04:44 |
| lifeless | However, how should commit change? | 04:44 |
| igc | poolie: roadmap page looks fine to me - I tweaked my wishlist as well | 04:45 |
| lifeless | foo and bar might not exist in the basis, so its impossible to commit foo/bar at all without commiting foo | 04:45 |
| abentley | lifeless: I suggest commit should commit adds of parent directories, not renames, and possibly not deletions. | 04:45 |
| abentley | lifeless: I'm trying to think of an example where a deletion of a parent would be necessary in order for a commit to succeed. | 04:46 |
| lifeless | what about paths, should commit show the path in the committed tree or the path in the working tree of stuff committed? | 04:46 |
| lifeless | if it shows the committed tree, status should match, so status should start reporting paths that aren't on the disk in front of the user. | 04:46 |
| poolie | lifeless, abentley: so I'm feeling there is more to do here, but it's not something we should block this patch upon | 04:47 |
| lifeless | if commit shows the paths from the working tree, then what it actually committed may be very different and confusing to users. | 04:47 |
| poolie | would you be desperately unhappy with that? | 04:47 |
| abentley | lifeless: I would think working tree. | 04:47 |
| lifeless | => this means we might commit a change to 'NEWS' that actually alters a file README.txt in the repository. | 04:48 |
| lifeless | mm, to simple an example. Needs a dir - but the idea is obvious | 04:48 |
| lifeless | I think it would mean we need to start reporting both paths. | 04:48 |
| abentley | lifeless: no matter which tree you show, it will be confusing. I think the working tree is less confusing. | 04:48 |
| lifeless | to be understandable | 04:48 |
| lifeless | at the moment the two paths are always the same. | 04:49 |
| abentley | poolie: I need to look at the patch. | 04:49 |
| poolie | ok, that'd be good | 04:51 |
| poolie | but in principle yes? | 04:51 |
| poolie | i'm just trying to work out what to do to get this disposed of | 04:51 |
| abentley | poolie: No, in principle it sounds like muddling low-level technical details with UI issues. | 04:51 |
| abentley | poolie: It doesn't sound like this was necessary to solve the InconsistentDelta issues. | 04:52 |
| poolie | i'm trying to understand the first one of those | 04:54 |
| poolie | because to me it sounds like the issue that iter_changes should generate consistent deltas is a concern at the level of deltas | 04:55 |
| poolie | not a ui concern | 04:55 |
| e-jat | hi .. can i use svn n bzr in the same branch ? | 04:58 |
| abentley | poolie: It has never been part of the contract of iter_changes that the deltas it generate are consistent in this way. The desire for this kind of consistency stems from the way commit uses iter_changes, AIUI. | 04:59 |
| lifeless | e-jat: kindof; you can use bzr-svn to push and pull between svn and bzr | 05:00 |
| lifeless | e-jat: I would suggest having separate trees for the bzr and svn copies though | 05:00 |
| poolie | but can't we get similar issues applying inconsistent deltas to the wt eg from revert? | 05:00 |
| e-jat | lifeless: thanks for the info .. | 05:01 |
| abentley | poolie: No. | 05:01 |
| lifeless | poolie: yes, but tree transform has a bunch of machinery to fix these up. The no parent for 'new-5' style bugs are where this is falling down. | 05:01 |
| e-jat | so i need to svn export 1st . .then copy it to bzr branch ? | 05:01 |
| abentley | poolie: tree transforms go through resolution to handle these cases. | 05:01 |
| lifeless | e-jat: no, install bzr-svn | 05:01 |
| lifeless | e-jat: then bzr branch svn://foo/bar/baz | 05:01 |
| e-jat | lifeless: i hv installed bzr-svn | 05:01 |
| e-jat | do that inside the svn branch ? | 05:02 |
| lifeless | do it where you want the new bzr branch to be made | 05:02 |
| abentley | poolie: Now that tree transforms can be committed, it would even be possible for commit to take advantage of this machinery. | 05:02 |
| e-jat | lifeless: thanks ... let me try it 1st .. | 05:03 |
| poolie | so, can i help with this at all, or should i leave it to you two to sort it out? | 05:08 |
| poolie | or ..? | 05:08 |
| abentley | lifeless: Do you feel that it is necessary to change iter_changes in order to fix commit? | 05:12 |
| lifeless | Yes, or end up reimplemnting some key chunks o it outside to allow external expansion - and change record_iter_changes to be given both trees to do said expansion | 05:13 |
| abentley | lifeless: What about explicitly adding all parents to the iter_changes invocation? | 05:14 |
| lifeless | that ends up gathering the entire tree every time (because iter_changes spiders down) | 05:15 |
| lifeless | if iter_changes had a non-recursive flag you could do iter_changes[paths], then iter_changes(parents, non_recursive) and filter out any parents already seen | 05:16 |
| lifeless | but that still isn't enough, because you need to also include the children of deleted directories where the delete was at the same path as a parent you had to add | 05:16 |
| abentley | lifeless: I imagine you wouldn't be in favour of doing the filtering after running iter_changes? | 05:17 |
| lifeless | but you don't want to recurse to the children of those children, as the user didn't request them | 05:17 |
| lifeless | performance tests show that filtering after doing the full tree is adequately fast on large trees *with hot cache* | 05:17 |
| lifeless | but the actual filtering algorithm needed ends up being roughly all of iter_changes anyhow | 05:18 |
| lifeless | commit is robust against bad deltas now, so I don't have a strong correctness reason for doing it elsewhere - the worst that will happen is a crash in commit with it refusing to commit. | 05:19 |
| lifeless | OTOH doing it in iter_changes means that anyone using iter_changes, or a per_intertree tested version of iter_changes, will be able to pipe their iter_changes through commit with confidence. | 05:20 |
| lifeless | ideally, we wouldn't do iter_changes on paths we don't need to, to avoid stating and checking irrelevant files. | 05:20 |
| lifeless | if we improve dirstate some more, we should be able to make selective commit really really fast, and thats where doing a full iter_changes would really show up | 05:21 |
| abentley | lifeless: my feeling is that if you really need to implement this in iter_changes, you should add a flag to toggle the behaviour, so that we can have the UI discussion without the pressure of blocking a fix. | 05:23 |
| lifeless | so; I'm open to that in principle but - I really believe that commit+revert should match status+diff. I'm not sure what commands then, would pass in the flag (or conversely not pass in the flag) | 05:30 |
| abentley | lifeless: I really believe that the existing behaviour of revert, status and diff is the best one, and I don't want to have this discussion under pressure. | 05:32 |
| lifeless | then have the discussion at a slower rate :) | 05:33 |
| lifeless | sleep on it | 05:33 |
| lifeless | I'll have a think about ways to land this without changing that behaviour over the weekend | 05:33 |
| abentley | lifeless: works for me. | 05:34 |
| abentley | poolie: I would appreciate it if you would review https://code.edge.launchpad.net/~abentley/bzr/devnotes/+merge/8766 | 05:35 |
| poolie | hi, i know | 05:42 |
| Kamping_Kaiser | is someone aware of a bzr or bzr-svn cheat sheet? | 06:42 |
| lifeless | in the docs, there is a reference card | 06:43 |
| Kamping_Kaiser | bril, thanks :) | 06:44 |
| vila | hi all | 07:13 |
| Kamping_Kaiser | can bzr suck all the details out of an SVN repo (over http) without access to a dump from the svn server? | 07:27 |
| bob2 | yes | 07:27 |
| Kamping_Kaiser | win. thanks again :) *goes to investigate* | 07:27 |
| poolie | vila: hello | 07:36 |
| poolie | i might call it a day | 07:36 |
| poolie | spiv, how did you go with that bug? | 07:36 |
| vila | gag of the day: try 'bzr stats' on bzr trunk.... laugh... wonder who will fix that first :-) | 07:58 |
| fullermd | Wassat? | 08:00 |
| spiv | poolie: it's going well, I've figured out how to hack some simple batching in. Currently testing/debugging the batching logic I've added. | 08:01 |
| poolie | cool | 08:02 |
| poolie | i'll mark it inprogress then? | 08:02 |
| spiv | Oh yes, please do. | 08:02 |
| poolie | all right | 08:02 |
| poolie | have a great weekend | 08:02 |
| poolie | regards to m | 08:02 |
| spiv | With some luck I'll have some useful comments to add to that bug shortly :) | 08:02 |
| vila | have a great weekend poolie ! | 08:03 |
| spiv | Ooh good, looks like it's working when I fetch Launchpad via HTTP, although there is a selftest failure. | 08:04 |
| spiv | Ok, and with that pushed up I'm off. Have a great weekend everyone. | 08:12 |
| spiv | vila: oh, and hello and goodbye :) | 08:12 |
| vila | spiv: bye, have a great weekend | 08:21 |
| * igc dinner | 09:10 | |
| NEBAP|work | can somebody help me out with a conflict? | 09:18 |
| vila | NEBAP|work: Don't ask to ask, ask | 09:19 |
| vila | The answer and the people than can answer can and will be different depending on the question :) | 09:19 |
| NEBAP|work | k | 09:20 |
| NEBAP|work | sorry | 09:20 |
| vila | no worries | 09:20 |
| NEBAP|work | was interrupted while writing the question ^^ | 09:20 |
| NEBAP|work | so | 09:20 |
| NEBAP|work | I´ve removed some cache files in the local branch | 09:21 |
| NEBAP|work | using bzr rm | 09:21 |
| NEBAP|work | also removed the hole folder | 09:21 |
| NEBAP|work | now there is a "content conflict" in one file under the removed folder | 09:21 |
| NEBAP|work | running bzr conflict | 09:21 |
| NEBAP|work | shows the file | 09:21 |
| NEBAP|work | but using bzr resolve FILE tells me "there is no conflict in ...." | 09:22 |
| NEBAP|work | so what should I do? | 09:22 |
| vila | That happens when you merge a branch where FILE has been modified | 09:22 |
| vila | what does 'bzr st' says ? | 09:22 |
| NEBAP|work | one second | 09:22 |
| NEBAP|work | tells me: "removed folder xxx", "unknown folder xxx.moved" and "content conflict in xxx.xxx" (which is the file that makes the problem) | 09:24 |
| vila | so, you'll have to look into xxx and xxx.moved and make sure the files you want are in the right place with the right content and remove the others | 09:25 |
| vila | err, what do you mean with xxx.xxx ? | 09:25 |
| vila | xxx/yyy ? | 09:26 |
| vila | err xxx/FILE ? | 09:26 |
| NEBAP|work | xxx.xxx just an example like "test.txt" | 09:27 |
| NEBAP|work | the file is present | 09:27 |
| NEBAP|work | bazaar created to files | 09:27 |
| NEBAP|work | xxxx.xxx.BASE and xxxx.xxx.OTHER | 09:27 |
| NEBAP|work | using bzr mv didn´t work because the files were removed in the local branch | 09:27 |
| vila | .BASE, .THIS, .OTHER are for text conflicts, these ones get remoed when you do 'bzr resolve' | 09:28 |
| NEBAP|work | so I renamed xxxx.xxx.OTHER to xxxx.xxx and then bzr resolve xxxx.xxx (which worked for one file, but not for a second one) | 09:28 |
| vila | .moved are for content conflicts and 'bzr resolve' does not remove them | 09:29 |
| vila | I think you have a conflict on a directory not on a file | 09:29 |
| NEBAP|work | hmm | 09:29 |
| NEBAP|work | it´s a content conflict (according to bzr conflicts) | 09:29 |
| vila | 'bzr conflicts' will tells you which items are still seen in conflicts by bzr | 09:29 |
| NEBAP|work | yes | 09:30 |
| vila | right, can you paste the output somewhere ? 'bzr st' and 'bzr conflicts' ? | 09:30 |
| NEBAP|work | yes, just give me a second ;) | 09:30 |
| vila | if things are confidential we may do that in PMs if you prefer | 09:30 |
| vila | I'd rather look at the true names than asking you to make them anonymous and risk missing a detail | 09:31 |
| fullermd | You can't reveal your True Names! | 09:35 |
| vila | pff, as long as nobody takes pictures.... | 09:35 |
| NEBAP|work | vila: http://pastebin.com/d1fdc9a0b (just removed my name and email) | 09:36 |
| vila | hmm, PDA/trunk/TX Event/obj is the directory you don't want to version anymore ? | 09:39 |
| NEBAP|work | yes | 09:39 |
| NEBAP|work | I´ve removed it in the local branch | 09:39 |
| vila | is obj.moved empty ? | 09:40 |
| NEBAP|work | no it isn´t | 09:41 |
| NEBAP|work | there is also the file that has the conflict | 09:42 |
| vila | but you don't care about that file anymore right ? And that's the only file there ? | 09:42 |
| NEBAP|work | I don´t need that files anymore | 09:43 |
| NEBAP|work | but there are still more files | 09:43 |
| NEBAP|work | all files that were in the obj folder before | 09:43 |
| vila | are they versioned ? | 09:43 |
| NEBAP|work | but I don´t need them, just cache files | 09:43 |
| NEBAP|work | they were | 09:43 |
| NEBAP|work | but then I´ve removed the hole folder | 09:43 |
| NEBAP|work | and added it to the ingore file | 09:43 |
| vila | ohhhh | 09:44 |
| vila | obj has been deleted is not versioned anymore in the local branch and is in .bzrignore, correct ? | 09:44 |
| vila | can you delete obj.moved without losing anything ? | 09:45 |
| NEBAP|work | yes | 09:45 |
| NEBAP|work | obj is still there (bzr rm obj --keep) but is not versioned anymore | 09:45 |
| vila | do that and try 'bzr resolve <path leading to>obj | 09:45 |
| NEBAP|work | and I´ve added it to .bzrignore | 09:45 |
| NEBAP|work | k | 09:45 |
| vila | wow, anyway, that's worth reporting as a bug (once we get you out of trouble) | 09:46 |
| NEBAP|work | ^^ | 09:47 |
| vila | I may be wrong, but it could be that bzr fails to properly report some info because there is a conflict on a path that is now ignored... or something weird like that | 09:48 |
| lifeless | vila: I suspect the search only looks at one of the paths involved | 09:49 |
| NEBAP|work | k used "bzr rm xxx/obj.moved --force" (-> folder deleted) | 09:50 |
| vila | NEBAP|work: and ? | 09:51 |
| NEBAP|work | then "bzr resolve xxx/obj" (-> no conflicts) | 09:51 |
| vila | \o/ | 09:51 |
| NEBAP|work | then "bzr resolve xxx/xxxx.xxx" no conflicts | 09:52 |
| NEBAP|work | but | 09:52 |
| NEBAP|work | there is still the one confilct using "bzr conflicts" ^^ | 09:52 |
| vila | can you paste again ? | 09:52 |
| NEBAP|work | sure, one moment ;) | 09:52 |
| vila | and tell me precisely what 'bzr resolve PATH' you issued ? | 09:53 |
| NEBAP|work | vila: http://pastebin.com/d314477f4 | 09:56 |
| NEBAP|work | vila: "bzr resolve "PDA/trunk/TX Event/obj/Release/TX Event.csproj.GenerateResource.Cache" | 09:57 |
| vila | try: 'bzr resolve "PDA/trunk/TX Event/obj' | 09:57 |
| vila | lifeless: by the way, can't that be related to your iter_changes patch ? (As in will your patch change anything here ?) | 09:58 |
| NEBAP|work | I also tried "bzr resolve pda/trunk/tx event/obj" which told me: no conflicts | 10:00 |
| vila | PDA not pda ? | 10:00 |
| NEBAP|work | yes used both, but its a windows machine which doesn´t care | 10:00 |
| NEBAP|work | iho | 10:00 |
| NEBAP|work | *imho | 10:00 |
| vila | hmpf | 10:00 |
| lifeless | vila: it wouldn't change merge at all; it might (but I doubt it) change partial-path merges | 10:01 |
| vila | NEBAP|work: 'bzr rm "PDA/trunk/TX Event/obj/Release/TX Event.csproj.GenerateResource.Cache"' | 10:04 |
| NEBAP|work | vila: deleted file | 10:06 |
| NEBAP|work | confilct is still there | 10:06 |
| vila | bzr resolve it now | 10:06 |
| vila | argh, no, we still think there is no conflict there :-/ | 10:06 |
| vila | correct ? | 10:06 |
| fullermd | If the file is gone, a straight 'bzr resolve' should notice and catch it... | 10:07 |
| vila | fullermd: works only for text conflicts no ? | 10:07 |
| fullermd | I thought it caught things like this too,; if it's not there, it can't very well be conflicting. | 10:08 |
| NEBAP|work | vila: you´re my hero, that did the trick ;) | 10:08 |
| vila | what ? | 10:08 |
| NEBAP|work | vila: removed file, solved the conflict, commited and pushed back to the server WITHOUT errors :D | 10:09 |
| vila | ok, so the bug is that 'bzr resolve FILE' saying no conflict here is highly misleading, | 10:10 |
| vila | NEBAP|work: can you file a bug explaining that ? | 10:10 |
| NEBAP|work | puh ^^ | 10:10 |
| NEBAP|work | I don´t understand where the problem was exactly | 10:11 |
| NEBAP|work | I just know the resolve didn´t see the conflict | 10:11 |
| vila | 'bzr resolve FILE' told you: no conflict here, bad resolve, tricked you | 10:11 |
| NEBAP|work | yes | 10:11 |
| NEBAP|work | that´s it :) | 10:12 |
| vila | yes, that's a bug, you were on the right track and bzr tried to derail you | 10:12 |
| NEBAP|work | k | 10:12 |
| vila | it derailed me too :D (I thought totally wrongly that the conflict was related to the directory) | 10:12 |
| NEBAP|work | where should I paste that? | 10:12 |
| NEBAP|work | :D | 10:12 |
| NEBAP|work | but you found the problem yeah | 10:13 |
| vila | https://bugs.launchpad.net/bzr/+filebug | 10:13 |
| NEBAP|work | BIG THANKS if I didn´t said it before | 10:13 |
| vila | Always happy to help (tm) | 10:13 |
| * vila realizes once again that 1) You always found in the last place you search for, 2) Most of the steps that leads to a bug fix are misleading :) | 10:14 | |
| NEBAP|work | ^^ | 10:15 |
| NEBAP|work | oh lunchpad crashed with my request ^^ will try it in a few minutes .. | 10:15 |
| vila | NEBAP|work: thanks | 10:17 |
| NEBAP|work | np, should help other people that face the same problem ;) | 10:17 |
| vila | yup, that's the idea and also ensure we'll fix the problem | 10:18 |
| NEBAP|work | :) | 10:19 |
| bialix | garyvdm, igc: hi guys | 10:45 |
| bialix | hello all as well | 10:45 |
| * fullermd waves at bialix. | 10:46 | |
| vila | hello bialix | 10:46 |
| bialix | fullermd: hi! | 10:46 |
| bialix | vila: bonjour! | 10:46 |
| * bialix waves back | 10:47 | |
| bialix | (I hope it's right) | 10:47 |
| bialix | beuno or whoever: this new UI in edge LP is awesome | 10:47 |
| bialix | vila: about "the size plugins": I've tried to lightly joking on your typo | 10:48 |
| vila | :-D | 10:48 |
| bialix | vila: I hope you get it right ;-) | 10:48 |
| bialix | vila: sorry, was unable to read your patch yesterday. I've tried to kick qbzr 0.14 off | 10:48 |
| vila | no problem, I replied with more info and hopefully a better explanation about why I wanted you to be involved | 10:48 |
| * bialix wonders how I can subscribe on comments for only interesting merge proposals | 10:49 | |
| * bialix don't want to get entire discussions on all proposals | 10:49 | |
| fullermd | It's right below the button to auto-approve good merge proposals :) | 10:49 |
| bialix | auto-approve? interesting | 10:50 |
| bialix | bb:+1 working there? cooooooooool | 10:50 |
| vila | fullermd meets beuno, beuno meets fullermd | 10:50 |
| bialix | :-) | 10:50 |
| * bialix trying to write awesome announcement for qbzr 0.14 | 10:51 | |
| Noldorin | lifeless: hello? | 10:51 |
| bialix | vila: I can answer any questions about windows specific plugins locations | 10:53 |
| bialix | vila: just don't say I need re-read entire discussion of you and jam | 10:53 |
| vila | bialix: no, it's a different email focused only on 'site' directory | 10:54 |
| bialix | vila: yesterday you have questions. today I have time for answers. | 10:54 |
| vila | bialix: I wrote them down in the email | 10:55 |
| vila | roughly: what is a good definition for 'site' on windows for the various installers ? | 10:55 |
| bialix | fullermd: "It's right below the button to auto-approve good merge proposals :)" -- it was joke, heh? | 10:55 |
| vila | but look at the mail | 10:55 |
| bialix | vila: what is the "site" for non-windows then? | 10:56 |
| vila | explained in the mail too :) | 10:56 |
| bialix | so I have to read your recent mail I suspect? | 10:56 |
| vila | that may help keep the S/N ratio high here :) | 10:57 |
| * bialix mutters: why oh why there is no RSS for merge proposals? | 10:57 | |
| fullermd | bialix: Yah; if we can teach LP how to recognize good MP's and auto-merge them, we can make it recognize interesting discussions and send them to you ;> | 10:57 |
| * bialix reads email from vila | 10:57 | |
| bialix | fullermd: ah. yes. brilliant idea! | 10:58 |
| * fullermd nods. | 10:58 | |
| fullermd | I've done my part coming up with the idea. Now we just wait for vila to implement it! | 10:58 |
| * vila not working on lp :) | 10:58 | |
| fullermd | You can't use that as an excuse forever. | 10:59 |
| vila | As long as it works... | 10:59 |
| bialix | LOL | 10:59 |
| vila | but that reminds me that I should play again with mail scoring.... | 10:59 |
| vila | from == fullermd => fun++, from == vila => must_read++++ sort of thing :) | 11:00 |
| bialix | vila: what you expect to hear from me? | 11:01 |
| bialix | vila: q: what if I'm run bzr from sources | 11:03 |
| vila | bialix: what can be used for 'site' for bzr.exe, when running from source, etc | 11:03 |
| vila | bialix: *I* ask the question first !!! | 11:03 |
| === vila is now known as vila-fud | ||
| bialix | vila: bzrlib even don't try to load plugins from C:\Python25\Lib\site-packages\bzrlib\plugins | 11:03 |
| vila-fud | back later | 11:04 |
| bialix | rats | 11:04 |
| vila-fud | yes, that's what I want to change ! | 11:04 |
| * fullermd wishes it wouldn't... | 11:04 | |
| bialix | vila: I don't understand fully all your intents and you run away! | 11:04 |
| bialix | vila: it's not fair! | 11:05 |
| luks | yeah, I had problems with that on linux earlier | 11:06 |
| luks | I had old bzr with old plugins from ubuntu installed in /usr/lib | 11:06 |
| luks | and my local bzr was trying to use those plugins, which of course failed | 11:06 |
| fullermd | It caused me a huge pile of aggravation when I was trying to quantify the cost of loading the lp plugin. | 11:07 |
| fullermd | I'd chmod it off, and it somehow kept loading! Move it out of the way, still loaded! Overwrite the files with exorcistic incantations, then delete them and bury them face-down, still loaded! | 11:07 |
| fullermd | 10 minutes in, figure out it was loading the LP plugin from the installed bzr. Nnnnngh. | 11:08 |
| bialix | excellent | 11:08 |
| bialix | it seems I'm only one happy person with bzr.exe | 11:09 |
| fullermd | Well, bzr.exe has certainly never given me any problems ;) | 11:09 |
| bialix | garyvdm: and again hi | 11:13 |
| bialix | vila-fud: I've tried hard to answer your questions. But in fact it seems I don't quite understand what was your Question? | 11:16 |
| garyvdm | Hi bialix | 11:16 |
| bialix | hi :-) | 11:16 |
| === vila-fud is now known as vila | ||
| vila | ok ok, got some sandwiches and I'm back | 11:17 |
| bialix | Thanks for your work on karmic battle-front. I'm working on announcement for 0.14. So people will cry if they don;t use qbzr yet | 11:18 |
| bialix | garyvdm: ^ | 11:18 |
| * fullermd quickly uses qbzr to avoid tearing up. | 11:18 | |
| vila | same here, never encounter a single problem with bzr.exe :-D | 11:18 |
| bialix | thats good | 11:19 |
| vila | bialix: did you reply by mail or .. ? | 11:22 |
| bialix | I've hit Reply (perhaps I should use Reply-All) and it was went to your inbox | 11:22 |
| vila | fullermd: 'bzr plugins -v' reveals paths no ? | 11:23 |
| fullermd | Sure, if you want to know where it comes from. | 11:23 |
| bialix | vila: sent again and to lp too | 11:24 |
| fullermd | If you think you already know, you wouldn't check, you'd just keep screaming. | 11:24 |
| vila | bialix: ok got it | 11:24 |
| vila | fullermd: with my proposed patch you'll do: 'BZR_PLUGIN_PATH=-core bzr <command>' :D | 11:24 |
| bialix | vila: ya know it won't work on Windows? | 11:25 |
| fullermd | Well, ideally I wouldn't do anything, 'cuz a bzr-from-source reading from an installed-bzr's plugin dir is bogus :p | 11:25 |
| vila | bialix: why ? | 11:26 |
| bialix | 'cuz you can't set env variable for one command | 11:26 |
| vila | fullermd: not always | 11:26 |
| luks | vila: what is a valid use case for that? | 11:26 |
| bialix | bad bad windows | 11:26 |
| vila | bialix: do it ib bzr.bat then :) | 11:26 |
| bialix | hehe | 11:26 |
| bialix | I love this part | 11:27 |
| bialix | I'm using bzr.exe, not bzr.bat | 11:27 |
| vila | luks: fullermd just gave it: obscure way to *not* load a core plugin :) | 11:27 |
| bialix | vila: btw, this is why I've tried to ask you yesterday: why not control this things via global command-line options instead of magic values in BZR_PLUGIN_PATH? | 11:28 |
| vila | bialix: rats, so you have to use a wrapper then | 11:28 |
| vila | haaaa | 11:28 |
| luks | vila: I mean for loading system-installed bzr plugins from local bzr | 11:28 |
| bialix | aaaaaaaaa | 11:28 |
| luks | because I think in most cases the versions will not match | 11:29 |
| garyvdm | bialix, vila: FYI, a proof of concept qcommit that gets a commit message from commit_message_template hook: https://code.edge.launchpad.net/~garyvdm/qbzr/read_commit_message_hook | 11:29 |
| denys | I have been trying to use "selftest --parallel=fork", but I can't make it work :-( | 11:29 |
| bialix | garyvdm: ok, will look at it later | 11:29 |
| vila | luks: that's not true if you use PPAs | 11:30 |
| garyvdm | bialix: there are some problems with it that I need to solve. When I have time. | 11:30 |
| bialix | ok | 11:30 |
| vila | luks: I mean, if you use bzr PPA, you'll get some plugins too, so your system stay up-to-date enough to run bzr from sources while not tracking the plugins | 11:31 |
| vila | denys: you need lp:testtools and lp:subunit in your PYTHONPATH | 11:31 |
| luks | vila: I don't know, I personally think it causes more problems than it solves | 11:31 |
| luks | vila: I was actually even going to submit a patch to disable that some time ago, but I figured it would lead to a long discussion :) | 11:32 |
| vila | luks: right, same here | 11:32 |
| vila | that's why I implement a flexible scheme for BZR_PLUGIN_PATH, I think the default is DWIM and almost correct for almost everybody, so changing the defautl is touchy | 11:32 |
| vila | and having the ability to override it from BZR_PLUGIN_PATH should addres the remaining cases (bzr.exe doesn't it anyway :D) | 11:33 |
| denys | vila: thanks - just found bug #351459 | 11:33 |
| ubottu | Launchpad bug 351459 in bzr "Error in parallel selftest: cannot import name ConcurrentTestSuite" [Undecided,Invalid] https://launchpad.net/bugs/351459 | 11:33 |
| vila | denys: what OS/version are you using ? | 11:33 |
| vila | denys: and what processor is on your host... | 11:34 |
| denys | python 2.6.2 gentoo/linux. why? | 11:34 |
| denys | core 2 duo (xps 1330) | 11:35 |
| vila | denys: mostly curiosity, 5% cautious check that it *can* work :) | 11:35 |
| vila | denys: python -c "import bzrlib.osutils ; print bzrlib.osutils.local_concurrency()" | 11:36 |
| denys | 2 | 11:37 |
| vila | denys: You know about --starting-with selftest option right ? | 11:37 |
| vila | it may help you more than --parallel=fork most of the time | 11:37 |
| denys | I know now ;-) I'll give a try | 11:38 |
| denys | thanks (off to lunch) | 11:39 |
| bialix | luks, garyvdm: about doing heavy work in qbzr in thread/subprocess. luks said yesterday it don't make qbzr faster but more responsive. it's TRUE! I'm really tired for currently semi-frozen UI when it Loading... | 11:39 |
| vila | denys: just try 'bzr selftest -s bb.test_serve' :) | 11:40 |
| bialix | so this makes it "faster" for me | 11:40 |
| vila | denys: quickly, before lunch :) | 11:40 |
| garyvdm | bialix: More processEvents required.. | 11:40 |
| garyvdm | bialix: which dialogs? | 11:40 |
| vila | bialix: I told garyvdm to do so long ago :) | 11:41 |
| vila | but he said luks didn't agree :) | 11:41 |
| vila | . o O (Now, that's starting a flame war :-D ) | 11:41 |
| garyvdm | bialix: I agree that if we had multi threads, it would be better, but It would be a huge amount of work. | 11:42 |
| vila | bialix, luks, garyvdm : BIG REG FLASHING ===> JOKE | 11:42 |
| garyvdm | vila: :-) | 11:42 |
| bialix | vila: LOL, thanks for flash lights, you remember! | 11:42 |
| bialix | garyvdm: More processEvents won;t help | 11:43 |
| bialix | garyvdm: just today hit this: want qcommit pending merge, want to copy commit message from one revision; double click on it; qdiff opens, revision details there I see right now but can't select them and copy because diff still loading | 11:43 |
| garyvdm | bialix: If you see that the throbber stops spinning: this is a case where more processEvents will help. | 11:45 |
| bialix | garyvdm: huge amount of work won't stop the one who want scratch its own itches | 11:45 |
| garyvdm | bialix: yes | 11:45 |
| garyvdm | luks: Thoughts? | 11:46 |
| bialix | garyvdm: current design of running heavy work in the same one thread never provides us more processEvents | 11:46 |
| bialix | bzrlib is so slow sometimes | 11:46 |
| luks | garyvdm: well, since it's unlikely I'll be the one looking for bugs in threaded qbzr, I don't mind :) | 11:48 |
| garyvdm | bialix: If we were to go multi-threaded, we should have 2 threads, 1 for ui, 1 for bzrlib. | 11:48 |
| bialix | garyvdm, luks: actually I mulling the idea about doing [possible] heavy work in several passes. E.g. loading working tree status: quickly get iter_changes and have filenames to propogate UI, and then on next pass get additional info (e.g. icons and so on) | 11:48 |
| luks | garyvdm: you can't run UI in other than the main thread | 11:48 |
| garyvdm | luks: yes | 11:49 |
| bialix | or about qdiff: 1) qbuickly get list of changed files, 2) quickly get diff without syntax highlighting; 3) do highlighting | 11:49 |
| garyvdm | bialix: Yes the type of thing that I've been trying to do. | 11:49 |
| garyvdm | bialix: qlog is very good at that. | 11:49 |
| bialix | qlog could be better | 11:50 |
| luks | all I know from my experience that threading in python is fun, add bzrlib and you have 2x as much fun, add PyQt and you have 3x as much fun :) | 11:50 |
| bialix | if we calculate dotted revnos in 2nd pass | 11:50 |
| bialix | luks: cool, so MUCH FUN! | 11:50 |
| bialix | :-) | 11:50 |
| garyvdm | bialix: yes - vila: when do gdfo? | 11:50 |
| luks | bialix: yeah, much fun for nice long evenings :) | 11:51 |
| bialix | if you're alone | 11:51 |
| garyvdm | bialix: When bzrlib indexes gets gdfo, we will be able to load partial bits of the graph :-) | 11:51 |
| luks | I think that if you ever touch bzrlib from two different threads, bad things will happen | 11:51 |
| bialix | I have written some multithreaded code in python; pyserial + tkinter actually | 11:52 |
| vila | garyvdm: don't hold your breath :-/ | 11:52 |
| luks | so this would have to be a radical change, such as building a RPC API for bzrlib | 11:52 |
| bialix | working with my own devices over COM-port | 11:52 |
| bialix | luks: IIRC bzr-exlipse guys do something like this | 11:52 |
| garyvdm | luks: yes - that's why I'm telling bialix that it would be *lots* of work | 11:53 |
| luks | bialix: it's different when you are working on your code that you can control, and when you are interacting with code that was not designed to work that way | 11:53 |
| bialix | luks: that's right, that's why I'd better use subprocesses here | 11:53 |
| vila | luks: as long as you lock as you should there shouldn't be problems, do you have specifics im mind ? | 11:53 |
| bialix | although they will be slower on windows (noticeable startup delay) | 11:53 |
| luks | vila: honestly, bzrlib is large enough to not trust it by default | 11:54 |
| bialix | but subprocesses will use more than 1 core on mulitcore machines | 11:54 |
| garyvdm | bialix: subprocess/multi thread both require a rpc layer where most of the work is. | 11:54 |
| luks | vila: I know there are a few global variables | 11:54 |
| luks | vila: possible other things | 11:54 |
| bialix | and again I'm lose: I have only 1 core | 11:54 |
| bialix | garyvdm: not exactly | 11:54 |
| vila | luks: almost all the network tests involves threads | 11:55 |
| bialix | garyvdm: threads will share the same memory | 11:55 |
| bialix | supbprocesses won't | 11:55 |
| vila | the smart server use threads (I'm pretty sure) | 11:55 |
| luks | vila: even better | 11:55 |
| bialix | vila: yes | 11:55 |
| luks | vila: so you would be mixing threading libraries | 11:55 |
| bialix | "[13:54]<luks>vila: honestly, bzrlib is large enough to not trust it by default" -- the same here | 11:56 |
| vila | your code, your call, just giving my feeling :-) | 11:56 |
| vila | do you already have use cases where you need to call bzrlib from 2 different threads ? | 11:56 |
| bialix | vila: use case: there is no easy way to stop non-main thread in Python | 11:57 |
| vila | AIUI you want one thread for the GUI and one for bzrlib, no problem at all here even if bzrlib uses globals (which we rarely do anyway) | 11:57 |
| bialix | vila: how you can cancel bzrlib operation then? | 11:57 |
| vila | bialix: that's totally unrelated to the problem of multi threads | 11:58 |
| bialix | related | 11:58 |
| luks | vila: yes, that's a safe thing to do, but it means building a custom API for bzrlib calls | 11:58 |
| vila | not the one luks mentioned about using libraries that may not be thread-safe | 11:58 |
| bialix | this is one of reason why we run actual qbzr actions via qsubprocess | 11:59 |
| vila | anyway, you can at least stop the bzrlib operation via the progress report mechanism, but 1) that's borderline 2) not guaranteed if progress is badly implemented or if there are bugs | 12:00 |
| vila | haaa, that's why luks talks about RPC ? | 12:00 |
| luks | vila: we are already doing that :) | 12:00 |
| vila | luks: sorry :-( I wish I can spend more time participating to qbzr (starting with reading the code) | 12:01 |
| luks | killing the process is done only if we can't stop it via progress report | 12:01 |
| vila | ha, ok | 12:01 |
| luks | the idea here is to run everything that involves bzrlib in a separate thread or process (it doesn't really matter what) | 12:02 |
| garyvdm | by raising an exception, and excepting and ignoring it later... | 12:02 |
| luks | which means you need an API to talk with the bzrlib layer | 12:02 |
| garyvdm | luks: you and I are on the same page :-) | 12:02 |
| garyvdm | luks: and that api would be alot of work... | 12:03 |
| luks | yeah | 12:03 |
| luks | but on the other hand, many other projects would benefit from that | 12:03 |
| luks | because it means you can build native extensions for IDEs, etc. | 12:04 |
| vila | luks, garyvdm : you should discuss with verterok | 12:04 |
| vila | like... *really* | 12:04 |
| luks | bzr-xmloutput is really limited, from that I've seen | 12:04 |
| luks | but I've not seen much of it | 12:05 |
| garyvdm | luks: Would you use QThread + QEvent or something else? | 12:05 |
| vila | bzr-eclipse | 12:05 |
| luks | which uses bzr-xmloutput, no? | 12:05 |
| vila | and verterok thought a lot about the design even if the code is not there | 12:05 |
| vila | luks: I don't know the details sorry :-/ | 12:05 |
| luks | garyvdm: depends, I think I'd try to move it to a separate process rather than thread | 12:05 |
| garyvdm | bzr-eclipse dose use bzr-xmloutput | 12:06 |
| luks | network operations are the main reason for that | 12:06 |
| garyvdm | ? | 12:06 |
| luks | but vila wrote more of them, so maybe they are stoppable | 12:06 |
| vila | luks: lol, not at all ! :) | 12:06 |
| luks | garyvdm: well, they are using blocking sockets, so if it decides to block due to a bug, we couldn't kill the thread | 12:07 |
| garyvdm | luks: If we were to use threads, I would still want to use the method of raising an exception in the progress_report or else where, so that finally's can run and locks can be unlocked. | 12:08 |
| bialix | I've heard bzr-eclipse want to build their own xml-rpc wrapper arounf bzrlib because java code can't call python code directly... | 12:09 |
| luks | garyvdm: sure, there is no other way | 12:09 |
| garyvdm | bialix: yes, bzr-xmloutput | 12:09 |
| luks | garyvdm: but I mean situations when the progress report callback won't be called | 12:09 |
| bialix | garyvdm: no | 12:09 |
| garyvdm | bialix: oh | 12:09 |
| bialix | xmloutput is only provides xml formatted output for bzr commands | 12:09 |
| garyvdm | luks: on timeout kill the thread... | 12:10 |
| bialix | in this sense it similar to qbzr | 12:10 |
| luks | garyvdm: yeah, and that's the problem, you can't kill a thread :) | 12:10 |
| luks | you can kill a process, but not a thread | 12:10 |
| bialix | but! I'm really not expert in eclipse dev! take my words with grain of salt | 12:10 |
| bialix | luks: exactly | 12:11 |
| bialix | verterok is main dev of eclipse plugin? | 12:11 |
| garyvdm | luks, bialix: another reason why I would prefer a bzrlib thread, rather than subprocess: cache. | 12:12 |
| vila | bialix: I think so yes | 12:12 |
| bialix | garyvdm: cache? | 12:12 |
| bialix | verterok from South America IIRC | 12:12 |
| luks | garyvdm: what's the problem with that? | 12:13 |
| bialix | garyvdm: I was wrong it seems | 12:14 |
| bialix | garyvdm: I see something about XMLRPC in xmloutput | 12:14 |
| luks | to be clear, I meant using subprocess as a RPC service, so that you can call it multiple times | 12:14 |
| bialix | garyvdm: sorry for misinformation | 12:14 |
| luks | so cache would be kept in the subprocess | 12:14 |
| garyvdm | luks: ah - ok, similar to tbar | 12:15 |
| garyvdm | *tbzr | 12:15 |
| bialix | yep | 12:15 |
| garyvdm | that would work | 12:15 |
| garyvdm | bilaix, luks: What would the the performance of the rpc be like for lots of data? | 12:16 |
| garyvdm | qlog loads and processes lots of data. | 12:17 |
| garyvdm | and qdiff | 12:17 |
| bialix | I don't have good experience to say. But it will depends on the communication channel | 12:18 |
| bialix | there is good python lib ported from Python 2.6: multiprocesses or something like this | 12:18 |
| bialix | it have faster C code to exchange data between processes via pipes | 12:19 |
| bialix | we propbaly will want to use bencode for serializing data | 12:19 |
| luks | which is blocking, isn't it? | 12:19 |
| bialix | luks: not really | 12:19 |
| bialix | there is emulation layer siomilar to Queue | 12:19 |
| bialix | it won't block | 12:19 |
| bialix | that lib called "multiprocessing" | 12:20 |
| bialix | available in 2.6 and from PyPi for 2.4 and 2.5 | 12:20 |
| luks | oh, I see how it works, but I wonder if it can give us some useful callbacks | 12:20 |
| bialix | it has some issues with Mac, but I don't understand all details | 12:21 |
| bialix | luks: mmm | 12:21 |
| bialix | luks: using periodical polling will work | 12:21 |
| bialix | or! | 12:21 |
| luks | yeah, but seriously suck | 12:21 |
| garyvdm | Couldn't we kill a thread with QThread.Terminate http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/qthread.html#terminate | 12:21 |
| bialix | run blocking communication with subprocess in the thread | 12:22 |
| bialix | it will be 4x fun | 12:22 |
| garyvdm | lol | 12:22 |
| luks | I'd rather use Qt tools for this | 12:22 |
| luks | which are all non-blocking | 12:22 |
| luks | but it would mean we have to write the protocol | 12:23 |
| garyvdm | As you may have detected, I prefer the idead of using threads, rather than subprocesses. | 12:23 |
| bialix | luks: which ones? | 12:23 |
| luks | or use threads and signals/slots | 12:23 |
| bialix | garyvdm: yes, I've detected | 12:23 |
| luks | bialix: QProcess with a custom protocol, if we were using a process | 12:23 |
| denys | vila: (back from lunch) | 12:23 |
| denys | OK | 12:23 |
| denys | tests passed | 12:23 |
| denys | bzrlib.tests.blackbox.test_serve.TestBzrServe.test_bzr_connect_to_bzr_ssh is leaking threads among 2 leaking tests. | 12:23 |
| bialix | QProcess means using stdin/stdout as comm channel? | 12:23 |
| luks | yes | 12:23 |
| bialix | that's my original idea | 12:24 |
| vila | denys: faster than 'bzr selftest test_server' right ? | 12:24 |
| bialix | you simply read my mind | 12:24 |
| luks | but we can use pipes too | 12:24 |
| luks | there is QLocalSocket | 12:24 |
| luks | I mean named pipes | 12:24 |
| bialix | perhaps using stdin/out will be simpler at first stage and more portable | 12:24 |
| bialix | I dunno what beasts there on Macs | 12:25 |
| * bialix recall vila has Mac! | 12:25 | |
| * garyvdm asks again | 12:25 | |
| garyvdm | Couldn't we kill a thread with QThread.Terminate http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/qthread.html#terminate | 12:25 |
| bialix | garyvdm: from the doc: yes | 12:25 |
| vila | bialix: but can't run qbzr there :-/ | 12:25 |
| luks | "The thread may or may not be terminated immediately, depending on the operating systems scheduling policies." | 12:25 |
| bialix | but there is scary warning about dangerous | 12:25 |
| luks | it's like saying, "please please please kill this thread if you can" | 12:26 |
| bialix | :-) | 12:26 |
| vila | bialix: otherwise socket/processes are available on work the same than on linux | 12:26 |
| garyvdm | bialix: We would only use that if stoping the code by rasieing a exception fails. | 12:26 |
| garyvdm | on timeout | 12:27 |
| vila | luks: kill -9 <pid> often behaves like that... | 12:27 |
| vila | bialix: s/on work/ and work/ | 12:27 |
| bialix | garyvdm: I prefer to use subprocesses because it will be much easier to debug | 12:27 |
| bialix | garyvdm: yes it will be much more work | 12:27 |
| bialix | and we need to write debug tools aca terminal program | 12:27 |
| bialix | *aka | 12:27 |
| bialix | but in the end it will be much simpler | 12:28 |
| bialix | but less fun as luks said | 12:28 |
| luks | I think it generally doesn't matter which would be used | 12:28 |
| luks | as that's easy to change | 12:28 |
| garyvdm | Which would be easier to do? | 12:29 |
| bialix | does QThreads use native OS threads? | 12:29 |
| garyvdm | no | 12:29 |
| bialix | or they are affected by GIL | 12:29 |
| garyvdm | I don't think so. | 12:29 |
| luks | with threads you already have API to communicate with it in a non-blocking way => signals | 12:29 |
| bialix | with QProcess you'll signals too | 12:29 |
| bialix | you'llhave | 12:29 |
| bialix | errr | 12:29 |
| luks | yes, but you have to parse the messages | 12:29 |
| garyvdm | bilaix: sorry ignore that. I miss read. I don't know | 12:30 |
| bialix | luks: yes, it will be overhead | 12:30 |
| luks | QThread is a thin wrapper around native thread calls | 12:30 |
| bialix | with QThread we will need to send custom signals? | 12:30 |
| garyvdm | Yes | 12:31 |
| bialix | there is nice thing in Python: Queue | 12:31 |
| bialix | but they are GIL-able | 12:31 |
| luks | which you don't need | 12:31 |
| luks | there is the Qt event loop for this kind of things | 12:31 |
| luks | anything running in the same process will be affected by the GIL | 12:32 |
| bialix | is there someting like QFifo or QQUeue? /me looks | 12:32 |
| bialix | no | 12:32 |
| garyvdm | Relevant doc: http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/threads.html | 12:32 |
| * garyvdm goes to read. | 12:32 | |
| luks | generally, with threads you don't need to worry about the communication layer | 12:33 |
| luks | because Qt has tools for that | 12:33 |
| luks | with processes you need to write a RPC service, either a custom one or something like XML-RPC | 12:33 |
| luks | but the largest part of this is designing the API for interaction with bzrlib | 12:34 |
| luks | not the communication layer | 12:34 |
| bialix | garyvdm: yes, xmloutput has inside implementation of XML-RPC server and client | 12:34 |
| bialix | it seems looks implicitly suggests to use threads | 12:35 |
| bialix | it seems luks implicitly suggests to use threads | 12:35 |
| * garyvdm goes to read the picard code | 12:37 | |
| * bialix really writing announce! | 12:37 | |
| luks | garyvdm: don't, it's horrible :) | 12:43 |
| luks | yes, I was implicitly suggesting to use threads for the first version | 12:43 |
| luks | garyvdm: not only it's horrible, but parts of the thread usage will be replaced by processes | 12:45 |
| lfaraone | Hi, is there any way to have bzr remember the password for a SVN repo I access frequently? | 12:51 |
| NEBAP|work | vila: https://bugs.launchpad.net/bzr/+bug/416903 | 12:51 |
| ubottu | Launchpad bug 416903 in bzr "'bzr resolve FILE' doesn´t recognize conflict" [Undecided,New] | 12:51 |
| luks | lfaraone: I think you can use svn to remember the password, then bzr-svn will use it | 12:52 |
| NEBAP|work | vila: hope that´s ok ^^ | 12:52 |
| vila | Ideally the commands leading to the problem will ensure we can reproduce it... I'm not sure I can from your description (and I was there to help you :-/) | 12:53 |
| vila | but thanks for filing it already ! | 12:54 |
| NEBAP|work | vila: I also have added the commands into the description, if there is anything additional that will help I maybe can add it too :D | 12:54 |
| vila | NEBAP|work: the missing part is: how did you get there ? If you can recreate the problem with a script that would be awesome ! | 12:55 |
| lfaraone | Hm. I check out a branch with svn, and it checks out version 151. I cd into the dir, run svn up, and am told I'm on rev 151. I run bzr up, and I am told I'm on rev 152. | 12:56 |
| lfaraone | s/152/114/ | 12:56 |
| NEBAP|work | vila: hmm I think I cannot create a script but I´ll add the steps that leads to the problem | 12:56 |
| lfaraone | Any idea why? | 12:56 |
| vila | lfaraone: try svn up again just in case something happened on your repo maybe ? | 12:56 |
| vila | NEBAP|work: great | 12:57 |
| luks | lfaraone: aren't you mixing svn and bzr revision numbers? | 12:58 |
| lfaraone | luks: But as a lightweight checkout, shouldn't it use master's revnums? | 12:59 |
| vila | lfaraone: missed your s/152/114/, what luks says | 12:59 |
| lfaraone | vila: http://pastebin.ca/1537585 | 12:59 |
| luks | lfaraone: no, svn and bzr revision numbers are totally separate | 12:59 |
| luks | lfaraone: see bzr log | 13:00 |
| luks | it should tell you both bzr and svn revision numbers | 13:00 |
| igc | hi bialix, garyvdm, luks, vila | 13:04 |
| garyvdm | Hi Ian | 13:04 |
| vila | Errk, go to bed Ian ! :) | 13:05 |
| NEBAP|work | vila: added the "history", hope that will help ;) | 13:07 |
| bialix | igc: I need you help | 13:07 |
| bialix | if you don't sleeping of course | 13:08 |
| igc | bialix: sure | 13:08 |
| vila | NEBAP|work: good, I'll try to write a script from that | 13:09 |
| NEBAP|work | vila: ok, if there are any questions, don´t hesitate to ask ;) | 13:09 |
| igc | vila: it's only 10pm here - few hours left in my day still :-) | 13:09 |
| lfaraone | luks: Thanks. | 13:10 |
| luks | huh | 13:21 |
| luks | bzr pull fails with bzr: ERROR: exceptions.AttributeError: '_known_graph_pyx.KnownGraph' object has no attribute 'topo_sort' | 13:21 |
| garyvdm | luks- you have probably pulled trunk, but not done a make | 13:21 |
| luks | oh | 13:22 |
| luks | that's it, thanks | 13:22 |
| * garyvdm knows that because I was looking at using KnownGraph to make qlog faster. | 13:22 | |
| bialix | garyvdm: what it means: gdfo? | 13:24 |
| garyvdm | greatest distance from origin | 13:24 |
| bialix | you asked vila several pages ago | 13:24 |
| bialix | oh, it's about revnos? | 13:24 |
| garyvdm | Yes | 13:24 |
| bialix | k | 13:24 |
| garyvdm | For a revision, the gdfo stays stable, even if the tip changes. | 13:25 |
| garyvdm | So in theory it can be stored on disk | 13:25 |
| bialix | can it be cached therefore? | 13:26 |
| luks | does it still require the whole graph loaded? | 13:26 |
| vila | gdfo is stable except when ghosts are filled | 13:27 |
| garyvdm | And it can be use it determine what parts of the graph need to be loaded it calculate a revno for a revision | 13:27 |
| vila | revnos requires most of the graph most of the time, we need to change the way we calculate revnos and then we'll be able to calculate revnos without loading all the graph and gdfo will help | 13:28 |
| garyvdm | vila: What is the difficultly with this? Ghosts? | 13:29 |
| vila | yes, the way ghosts are handled today, there is no simple way to know when they are filled | 13:32 |
| garyvdm | bialix: I've just pushed a change to trunk to make qdiff more responsive during loading. | 13:36 |
| bialix | garyvdm: thanks | 13:36 |
| garyvdm | bla - not there yet - branches diverged. | 13:36 |
| luks | sorry :) | 13:37 |
| garyvdm | luks: Just had a look at your latest change. There are lots of other places were we get the revid via .data(). Don't we need to change them to? | 13:39 |
| luks | probably | 13:40 |
| luks | but I can't see any | 13:40 |
| luks | oh, but bzr grep does | 13:41 |
| luks | those are usually str(foo.toString()) | 13:41 |
| luks | so that works fine, but it's not as efficient as it could be | 13:41 |
| garyvdm | ok | 13:42 |
| === mrevell is now known as mrevell-lunch | ||
| vila | NEBAP|work: forgot to ask: what bzr version are you using? | 13:50 |
| vila | NEBAP|work: forgot to ask: what bzr version are you using? | 13:57 |
| NEBAP|work2 | vila: should be 1.16.1 | 13:58 |
| vila | ok | 13:58 |
| === NEBAP|work2 is now known as NEBAP|work | ||
| NEBAP|work | nickserv identify ongbak | 13:58 |
| garyvdm | Time to change your password | 13:59 |
| luks | :P | 13:59 |
| NEBAP|work | ^^ | 13:59 |
| NEBAP|work | what is <key>? | 14:01 |
| NEBAP|work | by changing password? | 14:01 |
| NEBAP|work | ok | 14:03 |
| NEBAP|work | done ^^ | 14:03 |
| === kiko-afk is now known as kiko | ||
| vila | NEBAP|work: I've attached a script to the bug but I fail to reproduce the bug, can you see what I miss ? | 14:22 |
| === mrevell-lunch is now known as mrevell | ||
| bialix | so, what's going on with release announcement mails for bzr itself? | 14:37 |
| bialix | I don't see announcement for 1.18rc1 | 14:37 |
| bialix | but I see there is 1.18 ready | 14:37 |
| bialix | and jam has uploaded windows installers | 14:37 |
| bialix | anybody understand this new release scheme? | 14:38 |
| vila | the RM encoutered problems for 1.18rc1 but we try to stick with the schedule | 14:38 |
| vila | the only visible difference should be that announcements should now be made with installers ready | 14:39 |
| bialix | I'm asking because I'm used to fw announcement to ru_bzr ML | 14:39 |
| vila | hmm | 14:39 |
| bialix | and I don't see anything useful to send there for 1.18rc1 at least | 14:39 |
| vila | well, do you announce the rcs ? | 14:39 |
| bialix | yep | 14:40 |
| vila | hmm, well, nobody got announce for it :D | 14:40 |
| bialix | I can wrote something myself | 14:40 |
| NEBAP|work | vila: maybe the base was also changed after the local branch was created, otherwise I don´t see any missed actions | 14:43 |
| vila | the script modifies base after the branching | 14:44 |
| NEBAP|work | ah sorry missed that | 14:44 |
| NEBAP|work | no so I can´t see any missed actions | 14:44 |
| NEBAP|work | weird | 14:44 |
| vila | the trouble I have is that you mention .BASE .OTHER files, so I'm wondering where they came from in your case | 14:46 |
| vila | or if they are just unrelated to the problem | 14:46 |
| NEBAP|work | don´t know, but the files were create when I tried to push | 14:47 |
| NEBAP|work | or better | 14:47 |
| NEBAP|work | tried to merge after the unsuccessfull push | 14:47 |
| garyvdm | bialix: see http://osdir.com/ml/bazaar/2009-08/msg00356.html | 14:48 |
| garyvdm | bbl | 14:48 |
| NEBAP|work | vila: the file that caused the problem was in the base (server) and local, but I removed it from the history local before merging. Can be possible that both files were changed after branching from the base | 14:50 |
| NEBAP|work | vila: looking into the history I can see that removing the files was done before the last change of the base | 14:52 |
| NEBAP|work | vila: the last changes on the base are also marked with a red dot instead of a grey one | 14:52 |
| vila | ?? | 14:52 |
| vila | red ? grey ? | 14:52 |
| NEBAP|work | using qlog | 14:52 |
| NEBAP|work | maybe because I´ve merged the server branch into the local branch instead of the other way round .. | 14:53 |
| vila | I don't think the colors are meaningful in qlog... Any comment from our beloved qbzr hackers ? | 14:53 |
| NEBAP|work | k | 14:53 |
| NEBAP|work | but here is like the history looks | 14:54 |
| NEBAP|work | rev 30 -> added new files (local) | 14:54 |
| garyvdm | vila: colors are base on the revno, and are stable (if the revno is stable), but don't mean and thing else. | 14:54 |
| NEBAP|work | rev 31 -> removed folder | 14:54 |
| NEBAP|work | rev 29.1.1 -> last changes on the base (server) | 14:54 |
| NEBAP|work | rev 32 -> merged changes | 14:55 |
| vila | rev 32 is the one you created *after* solving the problematic conflict ? | 14:55 |
| NEBAP|work | is this "switch" because I merged in the wrong direction? | 14:56 |
| vila | rev 32 is the one you created *after* solving the problematic conflict ? | 14:56 |
| NEBAP|work | yes | 14:56 |
| NEBAP|work | this is the last (actual) one | 14:56 |
| vila | doesn't look wrong to me, why do you say switch ? | 14:57 |
| NEBAP|work | 30 -> 31 -> 29.1.1 -> 32 | 14:57 |
| NEBAP|work | or is this correct? | 14:58 |
| vila | hooo, wait 29.1.1 means your colleague also added the file ! (since he did that based on revno 29) | 14:58 |
| NEBAP|work | 29.1.1 is a change on the base (server) | 14:59 |
| vila | what does 'bzr st -c 29.1.1' says ? | 14:59 |
| vila | what does 'bzr st -c 29.1.1 -v' says ? | 14:59 |
| NEBAP|work | just a second | 14:59 |
| NEBAP|work | ^^ | 15:00 |
| NEBAP|work | Error: no working tree exists | 15:00 |
| vila | cd `bzr root` | 15:01 |
| vila | i.e. go where your WT is or st is meaningless :) | 15:02 |
| NEBAP|work | ah ok | 15:02 |
| NEBAP|work | I´ve added the tree | 15:02 |
| NEBAP|work | same error | 15:03 |
| NEBAP|work | I´ve added this to the error description | 15:03 |
| vila | where are you ? | 15:03 |
| NEBAP|work | in the root of the wt | 15:03 |
| NEBAP|work | BUT | 15:03 |
| NEBAP|work | when I used bzr push {serverlocation} | 15:04 |
| NEBAP|work | it just pushed the history not the wt, don´t know why | 15:04 |
| NEBAP|work | maybe that is causing the errors | 15:04 |
| vila | do you edit files at {serverlocation} ? | 15:05 |
| NEBAP|work | no because there are no files | 15:05 |
| NEBAP|work | there is just a folder containing the history | 15:05 |
| vila | good, so there can't be conflcits there :) | 15:05 |
| NEBAP|work | but it´s not a shared repo | 15:05 |
| vila | ok got it | 15:05 |
| NEBAP|work | k | 15:05 |
| vila | the file has been added from both sides, I'll attach the updated script | 15:06 |
| NEBAP|work | does it reproduce the error now? | 15:07 |
| igc | goneri ping | 15:07 |
| vila | 3 conflicts encountered. | 15:07 |
| vila | + bzr resolve dir/file2 | 15:07 |
| vila | dir/file2 is not conflicted | 15:07 |
| NEBAP|work | so it does? | 15:07 |
| NEBAP|work | ^^ | 15:07 |
| igc | goneri: re https://code.launchpad.net/~goneri/bzr-fastimport/347729_git-bzr_doesnt_work ... | 15:07 |
| igc | goneri: the commit message doesn't match the code change? | 15:08 |
| igc | gineri: does that fix the bug? | 15:08 |
| vila | NEBAP|work: Hmm, still not exactly because the file itself is not mentioned in conflics, but that's closer | 15:08 |
| igc | goneri: ^^^ | 15:08 |
| NEBAP|work | vila: hmm hard to reproduce ^^ | 15:09 |
| vila | NEBAP|work: can you paste 'bzr log -n0 -r28.. -v' somewhere ? | 15:11 |
| vila | NEBAP|work: can you paste 'bzr log -n0 -r28.. -v --show-ids' somewhere ? | 15:11 |
| goneri | igc: http://bazaar.launchpad.net/~goneri/bzr-fastimport/347729_git-bzr_doesnt_work/revision/210 | 15:12 |
| NEBAP|work | vila: let me check | 15:12 |
| goneri | igc: yes, that's the changes | 15:12 |
| goneri | igc: oh wait i'm on crack | 15:12 |
| NEBAP|work | vila: bzr: Error: sorry, u'..' not allowed in path | 15:13 |
| igc | goneri: :-) | 15:13 |
| goneri | line 247: it should be "self.revid_to_mark[revid] = ':' + str(mark)" | 15:13 |
| igc | goneri: that sounds more reasonable | 15:13 |
| vila | NEBAP|work: no space between 28 and .. | 15:13 |
| NEBAP|work | vila: there is not a space | 15:14 |
| igc | goneri: can you test that and push it? | 15:14 |
| goneri | sure | 15:14 |
| vila | meh | 15:14 |
| NEBAP|work | used: bzr log path -n0 -r28.. -v > bzr_log.txt | 15:14 |
| vila | --show-ids !!! | 15:14 |
| vila | don't forget it it's very important | 15:15 |
| vila | try without redirecting ? | 15:15 |
| NEBAP|work | ah k | 15:15 |
| vila | path ? no path ! cd path first | 15:15 |
| vila | :) | 15:15 |
| NEBAP|work | k | 15:15 |
| NEBAP|work | then he goes one dir up which is not a branch: bzr: ERROR: Not a branch: "path/.." | 15:16 |
| NEBAP|work | ("path/.." is the folder containt the branch) | 15:17 |
| NEBAP|work | should I create a local branch | 15:17 |
| vila | You can specify <path> to log, but only to restrict the log to the specified path, i.e. log will display the log entries related to the versioned <path> | 15:17 |
| NEBAP|work | k | 15:17 |
| vila | NEBAP|work: are you in the folder where the files you edit are ? | 15:17 |
| NEBAP|work | no | 15:17 |
| NEBAP|work | on the server | 15:17 |
| NEBAP|work | files are on a differenc pc which is shutdown at the moment | 15:18 |
| vila | haaaa | 15:18 |
| NEBAP|work | should I create a local branch | 15:18 |
| vila | then yes | 15:18 |
| NEBAP|work | k | 15:18 |
| vila | log should work in a tree less branch though... | 15:19 |
| NEBAP|work | omg | 15:19 |
| NEBAP|work | using pull to retrieve the latest version results in 3 conflicts ^^ | 15:20 |
| NEBAP|work | its the deleted folder | 15:20 |
| NEBAP|work | error: can´t delete because its not empty | 15:20 |
| NEBAP|work | should I use | 15:20 |
| NEBAP|work | bzr rm to remove them from history? | 15:20 |
| vila | where did you create your local branch ? | 15:20 |
| vila | and how ? | 15:20 |
| NEBAP|work | just updated (bzr pull) my local version of the branch | 15:21 |
| vila | where ? | 15:21 |
| NEBAP|work | c:\work\... | 15:21 |
| vila | is that the server ? | 15:21 |
| NEBAP|work | no | 15:21 |
| vila | <shudder> | 15:21 |
| NEBAP|work | I have 1 server + 2 workstation | 15:22 |
| vila | can you issue 'bzr log -r28.. -v --show-ids' there ? | 15:22 |
| NEBAP|work | on the server is a branch without wt | 15:22 |
| NEBAP|work | vila: I just want to update to the latest version on the server (which contains the merged conflicts that caused the errors) | 15:23 |
| vila | NEBAP|work: then do that in a clean context: create a new branch, | 15:24 |
| NEBAP|work | k | 15:24 |
| vila | it looks like you pulled in a wt with actual changes | 15:24 |
| mfer | hello bzr folks | 15:24 |
| vila | a pull in wt where 'bzr st' reports nothing should never produce conflicts | 15:24 |
| NEBAP|work | no, the only conflicts are in the removed folder because he didn´t want to delete it because they are not empty .. | 15:25 |
| NEBAP|work | k | 15:25 |
| NEBAP|work | at first I will create a clear brunch | 15:25 |
| NEBAP|work | *branch | 15:25 |
| mfer | I'm a fairly new bzr user and looking to convert some designers/front end devs from svn. But, many of them use Coda, Textmate, and some other tools like that. They aren't command line folks either. Anyone know if there is any work being done to connect these (plugins?)? | 15:25 |
| NEBAP|work | k | 15:26 |
| NEBAP|work | branched 32 revisions ;) | 15:26 |
| vila | good :) | 15:26 |
| NEBAP|work | so now I try to output your commands | 15:26 |
| NEBAP|work | same error | 15:27 |
| NEBAP|work | he always tries to move a directory up | 15:27 |
| NEBAP|work | which is not a wt | 15:27 |
| vila | bzr don't move | 15:27 |
| NEBAP|work | I´ll try adding quotes | 15:28 |
| vila | do you have some wrapper ? | 15:28 |
| NEBAP|work | yes | 15:28 |
| NEBAP|work | using the quotes it wors ;) | 15:28 |
| NEBAP|work | windoofs ^^ (doof means stupid in german ;) ) | 15:29 |
| vila | where did you have to add quotes ? | 15:29 |
| NEBAP|work | I´ve used: bzr log "-n0" "-r28.." -v --show-ids (looks like windows recognizes the '..' as folder up) | 15:30 |
| NEBAP|work | maybe | 15:30 |
| garyvdm | mfer: I don't think anyone is working on integration with Coda, and Textmate. Have you looked at bzr-explorer? - It is a general purpose GUI | 15:30 |
| NEBAP|work | bzr log -n0 "-r28.." -v --show-ids | 15:30 |
| NEBAP|work | is enough | 15:30 |
| vila | 8-( bialix ? Any idea ^^ | 15:30 |
| NEBAP|work | vila: now the output works ;) | 15:30 |
| vila | NEBAP|work: ok, so, can you paste it somewhere ? | 15:31 |
| NEBAP|work | vila: I´ll send it via email to you if that is ok, because its company data .. | 15:32 |
| mfer | garyvdm: I have a little. I'm a command line guy so I don't dive into the gui tools so much. For designers I'm learning it has to be dead simple and work with their existing tools. There was a textmate bundle but it's not very feature rich, fyi. | 15:32 |
| divokz | I'm getting an error when using "tbzrcommandw --command=getupdates" on Windows XP. "RuntimeError: Where is bzr.exe?" (I've already checked, and it's in my path.) I'm not finding anything about this via Google either. | 15:32 |
| divokz | (Just tested on another box -- it happens in Vista too.) | 15:32 |
| divokz | Any ideas on what's going on? | 15:32 |
| divokz | I'm using this to try to add a "check for updates" command for XP users of an internal tool I'm making | 15:34 |
| divokz | I'd be interested in hearing other options | 15:35 |
| garyvdm | divokz: a option is to just run bzr qgetupdates | 15:41 |
| garyvdm | divokz or bzr qpull or bzr pull. | 15:42 |
| garyvdm | depending on what options you want to give them | 15:42 |
| divokz | garyvdm: well, it needs to be part of a GUI tool. I've tried just using `bzr up` and it just pops up a DOS window without doing much else. (Works fine on Linux, though.) | 15:43 |
| divokz | garyvdm: ah, that does do a GUI thing | 15:44 |
| divokz | nice | 15:44 |
| divokz | didn't know that | 15:44 |
| garyvdm | divokz: wether you do bzr up or bzr pull depends on if the branch is bound or not. | 15:44 |
| garyvdm | divokz: just add q to most commands for a gui | 15:45 |
| divokz | it is bound | 15:45 |
| divokz | well, that's awesome -- still pops up a DOS window (before bringing up the TortoiseBZR one, unlike tbzrcommandw), but I think that's fine | 15:46 |
| divokz | (unless you know a way around that -- I'm calling this from a rubyw script) | 15:46 |
| divokz | thanks, garyvdm | 15:46 |
| garyvdm | Nope no bzrw yet. | 15:47 |
| garyvdm | pleasure. | 15:47 |
| ScriptFanix | Hi | 15:50 |
| goneri | igc: done, lp:~goneri/bzr-fastimport/347729_git-bzr_doesnt_work | 15:50 |
| ScriptFanix | are there any way to generate the debian/changelog file from the bzr history ? | 15:50 |
| goneri | igc: the test script runs fine now | 15:51 |
| igc | goneri: thanks | 15:51 |
| garyvdm | ScriptFanix: no, but if you have bzr-builddeb, it will automatically generate a commit message from debian/changelog. | 15:53 |
| garyvdm | bialix: What does this say. It is a mail I recived. http://paste.ubuntu.com/256944/ | 15:54 |
| ScriptFanix | garyvdm: yes, found that. i want it the other way around. anyway, it's just for internal use, so we don't really care about the debian/changelog file anyway :) | 15:55 |
| garyvdm | bialix: I just realized that I sent a message to ru_bzr, and it is probably telling me you need to approve the message. | 15:56 |
| LeoNerd | If I "bzr branch -r123" to take a branch from an earlier point in history, the new branch seems to contain all the tags of the parent, even those after -r123.. | 15:59 |
| LeoNerd | Known bug? | 15:59 |
| igc | goneri: merged and pushed to rev 218 | 16:01 |
| * goneri send a big thank you to igc | 16:02 | |
| igc | gnoeri: you may want to close bug 347729 now | 16:02 |
| ubottu | Launchpad bug 347729 in bzr-fastimport "git-bzr doesn't work" [Undecided,New] https://launchpad.net/bugs/347729 | 16:02 |
| quicksilver | is there a way to preview a merge without actually doing it? | 16:12 |
| quicksilver | other than (bzr merge ../fx-xyz; bzr diff | less; bzr revert) | 16:12 |
| quicksilver | ah --preview | 16:12 |
| quicksilver | duh | 16:12 |
| quicksilver | I'm blind :) | 16:12 |
| === Chex_ is now known as Chex | ||
| brutimus | I've been trying for the past day to get server-side hooks to fire when i commit over bzr+http (through the smart server using fastcgi). I've installed my hook at set_rh, and post_change_branch_tip. They'll fire of i do a local commit on my repo-server, but they don't fire when i commit from the network. Using Bzr 1.6.1 | 16:31 |
| brutimus | Also.. I put the hooks in /usr/lib/python2.5/site-packages/bzrlib/plugins/ | 16:33 |
| brutimus | Gah.. as luck would have it.. I just ran across a changelog for 1.8 that mentions bzr over http will now load plugins.. This looks like it might fix my problem. | 16:37 |
| vila | quicksilver: works very nicely as shell-command under emacs, you just have to M-x diff-mode the result :) | 16:41 |
| alsuren | is it possible to run bzr serve --allow-writes as a cgi script? | 16:41 |
| quicksilver | vila: *nod* | 16:42 |
| alsuren | it seems that bzr+http is a valid protocol | 16:46 |
| brutimus | alsuren: yes you can run that through fastcgi or mod_python | 16:47 |
| bialix | garyvdm: ru_bzr is restricted group, one need to be joined it to post | 16:47 |
| bialix | garyvdm: your message simply banned by googlegroups | 16:48 |
| alsuren | brutimus: can you point me to some docs? | 16:48 |
| brutimus | finding them :-) | 16:48 |
| alsuren | thanks | 16:48 |
| bialix | garyvdm: never mind | 16:48 |
| brutimus | allenap: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#serving-bazaar-with-fastcgi | 16:49 |
| brutimus | I've personally only done it through mod_python as that's what we had setup on our dev serve | 16:49 |
| bialix | garyvdm: re qdiff: I don't see any changes in its semi-frozen state even with your latest patch. I guess sooner or later threads or subprocesses will be very desirable to have | 16:49 |
| alsuren | s/allenap/alsuren/ | 16:49 |
| brutimus | whoops | 16:49 |
| bialix | garyvdm: bye for now | 16:50 |
| * bialix waves | 16:50 | |
| garyvdm | bye | 16:50 |
| === deryck is now known as deryck[lunch] | ||
| === abentley1 is now known as abentley | ||
| === beuno is now known as beuno-lunch | ||
| === deryck[lunch] is now known as deryck | ||
| sveinung | Is it possible to make bzr-fastimport preserve bug fix metadata? | 18:04 |
| sveinung | Don't know the correct termology by I mean the data you get when you do --fixes during a commit. | 18:04 |
| sveinung | I have tried Google and looking at the source code but since I don't know the termology I could have missed it | 18:05 |
| luks | since it's a format designed for git, I don't think so | 18:07 |
| sveinung | ok, thank you | 18:14 |
| === beuno-lunch is now known as beuno | ||
| === abentley1 is now known as abentley | ||
| === abentley1 is now known as abentley | ||
| manuee | hi all | 19:22 |
| manuee | i've got a problem using bzr upload... looks like ive already removed some files from the target server, but upload stops if it doesnt find a file it needs to remove... anyway around this so it continues? | 19:22 |
| vila | manuee: bzr upload --full | 19:24 |
| manuee | ey vila thanks ill give that a try | 19:25 |
| === vila is now known as vila-afk | ||
| manuee | dont think i saw that option on bzr help upload | 19:25 |
| manuee | :X | 19:25 |
| === abentley1 is now known as abentley | ||
| manuee | ow duh, it just does a full upload | 19:30 |
| jseabold | Hello all, is there a way to copy a file with its file history to another bzr branch? I have some code deep in a branch here path/to/my/old/branch but it is now going to be a standalone package so I need to move it to /path/new/ and preserve file history. Is this possible? | 19:40 |
| === sdboyer_ is now known as sdboyer | ||
| fjalvingh | I am trying to branch from 1.14-rich-root format to 2a format on a disk and bzr is already running for 30mins at 100%CPU and 1GB memory!? Any tips? | 20:42 |
| bialix | thumper: ping | 21:39 |
| bialix | thumer: do you remember problem with SSH keys and access to bzr+ssh from WIndows? | 21:40 |
| bialix | tumper: http://the.earth.li/~sgtatham/putty/0.58/htmldoc/Chapter7.html see section 7.2.2, 4th paragraph: "To avoid being prompted..." | 21:41 |
| bialix | thumper: https://bugs.launchpad.net/bzr/+bug/414743 | 21:45 |
| ubottu | Launchpad bug 414743 in bzr "paramiko should be default client for Windows" [High,Confirmed] | 21:45 |
| phinze | hmm i'm having trouble with getting bzr log to show just the commits i've made in my task branch | 22:31 |
| phinze | it seems to only want to show the last revision i merged with parent | 22:31 |
| phinze | whereas there are a couple of revisions in my local task branch before that i'm interested in seeing | 22:32 |
| LarstiQ | phinze: bzr log -n0 ? | 22:36 |
| phinze | LarstiQ: i'm trying bzr log -rancestor:../mainline ; but it just shows the "merge parent" revision i just made to my task branch | 22:38 |
| phinze | there are two revisions before that point i would want to see | 22:38 |
| phinze | but i want to filter it to show only those revs | 22:38 |
| LarstiQ | phinze: you're not looking for `bzr missing` ? | 22:39 |
| phinze | LarstiQ: i... am an idiot ;P | 22:39 |
| phinze | one of those days... | 22:40 |
| * phinze has used bzr missing like every day | 22:40 | |
| LarstiQ | well, missing and log could use some refactoring | 22:40 |
| phinze | yeah i always get the spec mixed up | 22:41 |
| phinze | --forward vs --reverse etc | 22:41 |
| * LarstiQ meant them doing similar things | 22:42 | |
| phinze | mmm | 22:44 |
| kfogel | What's the latest best recommendation for commit emails from a bzr repository? I'm trying bzr-hookless-email right now, but so far haven't gotten it to work. | 22:52 |
| lifeless | I would still recommend bzr-email | 22:54 |
| lifeless | unless you're expecting people to commit via sftp/nfs. | 22:54 |
| lifeless | (can't run code on the server via dumb protocols) | 22:55 |
| kfogel | lifeless: well, that's the thing. I'm pretty sure they won't, but am not positive (this is for Emacs), and hate to have a system that's brittle in that way. | 22:56 |
| kfogel | Because we'll never remember this, when the time comes (in two years) to debug why commit emails aren't working for so-and-so. | 22:56 |
| lifeless | kfogel: don't permit sftp then | 22:57 |
| kfogel | lifeless: sure, but are we going to remember why we're not permitting it? (Aside from the fact that some may object.) | 22:57 |
| lifeless | kfogel: I hear that you're pretty good at writing docs. | 22:57 |
| lifeless | :) | 22:57 |
| kfogel | lifeless: what I'm trying to say is, one way is formally less fragile than the other... but only if it works. | 22:57 |
| lifeless | so, hookless is differently fragile | 22:58 |
| kfogel | lifeless: one of the things you quickly learn from writing docs is that no one reads them :-) | 22:58 |
| kfogel | lifeless: ah, is it? | 22:58 |
| lifeless | it depends on a long term server process/cron | 22:58 |
| kfogel | lifeless: OIC | 22:58 |
| lifeless | it does mail by polling | 22:58 |
| kfogel | lifeless: true. But I think of that as less fragile because it's the only method by which commit emails go out. In other words, if they break, we'll quickly figure out where to look. | 22:59 |
| lifeless | bzr-email depends on being invoked by bzr, which then works both locally and remotely, as long as it /is invoked/ - and bzr on the server only actually runs if you push via a bzr*:// flavour protocol | 22:59 |
| kfogel | whereas with the sftp, your commit emails seem to work fine when you test them, it's just this user who said "it's not working for me" | 22:59 |
| kfogel | lifeless: yes, I understand the hook-vs-poll thing. | 22:59 |
| lifeless | kfogel: for emacs I suspect sftp would be noticable slow too | 23:00 |
| lifeless | you've got a massive database and users with all sorts of latency | 23:00 |
| lifeless | and you're not trying to host on dreamhost or some itty bitty windows-centric webhost | 23:00 |
| kfogel | lifeless: note they're also using bzr-hookless-email already, apparently https://savannah.gnu.org/support/index.php?106531 | 23:01 |
| lifeless | they really need to get a proper certificate | 23:01 |
| kfogel | lifeless: also, bzr-hookless-email is restartable. if the cron job drops, you just start it up, it will catch up. | 23:01 |
| lifeless | kfogel: sounds like you'd prefer to use bhe.. so do so :) | 23:02 |
| kfogel | merely exhaustively analyzing, in the channel :-) | 23:03 |
| Noldorin | hi lifeless | 23:34 |
| Noldorin | lifeless: heh, it must seem like i'm bothering you every night. i have little better to do at the moment though :) | 23:37 |
| lifeless | Noldorin: hi. No - its my sat morning is all, I'm not really here. | 23:41 |
| Noldorin | heh, yeah. morning for you :P | 23:42 |
| Noldorin | lifeless: does that mean i should catch you another time then? :)\ | 23:44 |
| lifeless | well, I can still answer questions and so on but there is likely to be long gaps as I wander off and do stuff ;) | 23:46 |
| lifeless | basically you need to take the minimal trace + log and make a demo showing the problem you can show your admins | 23:46 |
| Noldorin | actually, i don't really have a question at the moment | 23:46 |
| Noldorin | lifeless: did you see my updates? | 23:46 |
| Noldorin | i did a lot of testing this morning | 23:46 |
| lifeless | no, I hadn't - work mail is shelved till monday :) | 23:46 |
| lifeless | whats the summary | 23:47 |
| Noldorin | https://bugs.launchpad.net/bzr/+bug/412244 | 23:47 |
| ubottu | Launchpad bug 412244 in bzr "unlock fails to unlock over FTP with Windows FTP server (Microsoft FTP Service IIS6)" [Medium,Confirmed] | 23:47 |
| lifeless | so, get your admins to read that ;) | 23:48 |
| lifeless | its pretty hard to argue that 'a renamed and deleted file should be readable' | 23:49 |
| Noldorin | yep lol | 23:49 |
| Noldorin | they replied once saying "FTP on this server is working fine by methods we recommend are used for FTP." | 23:50 |
| lifeless | !!! | 23:51 |
| Noldorin | but yeah, i'm trying to push it. they're just being stubbornly blind. | 23:51 |
| Noldorin | at least we're 100% sure there's nothing wrong with bzr now | 23:52 |
| Noldorin | so you're welcome to close it, if you wish | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!