| dvheumen | poolie, I'm working on an 'easy' bug (patch pilot program), and I've got a question for you regarding the approach to take to set up a test for this change. The bug is 498409, (https://bugs.launchpad.net/bzr/+bug/498409) Do you, by any chance, have some time? | 00:00 |
|---|---|---|
| ubottu | Launchpad bug 498409 in bzr "bzr revert takes a branch lock" [Medium,In progress] | 00:00 |
| poolie | hi dvheumen | 00:00 |
| poolie | sure, happy to | 00:00 |
| * poolie looks | 00:00 | |
| poolie | i just finished a call, i'll get some coffee and be back in a minute | 00:01 |
| dvheumen | k | 00:01 |
| dvheumen | tnx | 00:01 |
| dvheumen | okay, well, fixing the bug seemed pretty simple, and jelmer had some said it seemed reasonable to him, so that gives me some confidence. He also gave me a hint on how to approach this particular type of test, which helped greatly. But it seems I've got some sort of a special case (or lack of understanding of python code, which is more or less a given :P) | 00:02 |
| dvheumen | This is what I have at the moment (scrambled together) as a test: http://paste.ubuntu.com/391380/ . I know: 1. that this doesn't work, 2. I've chosen the wrong test file for this particular test. 3. I didn't finish the test exactly, but I wanted to compare the content self.locks. But I think that this approach, using this lock helper, doesn't work since cmd_revert creates its own branch instance. And that's where I'm currently stuck :P | 00:09 |
| dvheumen | * I wanted to compare the locks history, although now I'm not sure if that was stored in self.locks, but you get the idea | 00:10 |
| poolie | hi | 00:12 |
| poolie | so, right, actually fixing the bug will be pretty trivial | 00:12 |
| dvheumen | Oh, btw, I do think there's a way to work around this, by adding an optional parameter to cmd_revert's run-method in which you can pass on the branch. But I don't like that approach | 00:12 |
| poolie | one line probably | 00:12 |
| dvheumen | poolie, that's the easy part :P | 00:13 |
| dvheumen | I'll get the diff for you | 00:13 |
| poolie | so the choice of test location should probably be guided by whether the fix is in cmd_revert or elsewhere | 00:14 |
| dvheumen | http://bazaar.launchpad.net/~danny.vanheumen/bzr/bug-498409-bzr-revert-takes-a-branch-lock/revision/4740 | 00:14 |
| poolie | if it's changed in branch.py, per_branch would be an appropriate place to test it | 00:14 |
| poolie | i'm glad you asked for help btw | 00:14 |
| dvheumen | it's changed in builtins.py, so the preferred location seemed to be: tests/commands/test_revert.py probably | 00:15 |
| poolie | right | 00:15 |
| dvheumen | although that one doesn't exist, at least not in the 2.0 branch | 00:15 |
| poolie | so i think there is test framework support to record all locks that are taken? | 00:15 |
| dvheumen | poolie, right, found that one too | 00:15 |
| dvheumen | but it requires you to use a branch instance that is wrapped in this helper that records the history | 00:16 |
| lifeless | not all conceptual locks, but all actual locks, yes. | 00:16 |
| lifeless | dvheumen: hmm, I think you're missing the lock tracker | 00:16 |
| poolie | i thought there was a way to do it globally | 00:16 |
| poolie | but this may be only in my head | 00:17 |
| lifeless | look at bzrlib.tests.TestCase._track_locks | 00:17 |
| lifeless | thats uses the lock hooks to check some test characteristics - that locks are matched during tests | 00:17 |
| dvheumen | poolie, I've been using the tests in tests/per_branch/test_locking.py | 00:18 |
| lifeless | a single test can hook into Lock.hooks additionally to get extra callbacks | 00:18 |
| dvheumen | lifeless, okay, this is interesting. I hadn't seen that yet. | 00:20 |
| poolie | dvheumen: what he said is correct: you should be able to just do the test then inspect _lock_actions i think | 00:20 |
| dvheumen | poolie, do you by any chance know if they are recorded by default, or should I activate this in some way? | 00:20 |
| poolie | it looks like it's on by defaulct | 00:21 |
| dvheumen | okay, thanks, in that case I'll give it a try (tomorrow) | 00:21 |
| poolie | we should add this to the testing guide | 00:21 |
| dvheumen | +1 :P | 00:22 |
| dvheumen | poolie, btw, I'm glad you're helping. I've wanted to dive into python for some time, and this provides some goals to tackle :) | 00:27 |
| poolie | if there are any bugs tagged 'easy' where it's not obvious how to begin, that's a meta-bug | 00:27 |
| poolie | ask someone here and they will add a comment explaining it | 00:27 |
| poolie | or tag it -easy :-) | 00:27 |
| dvheumen | okay, will do | 00:30 |
| dvheumen | hmmm ... maybe I'm asking too fast here, but ... it seems to me that _lock_actions only records lock + unlock, but does not make a distinction between tree, branch and repository locks | 00:36 |
| dvheumen | ow w8, I'm asking too fast. There is a distinction made. nevermind, I'll continue puzzling | 00:39 |
| poolie | if i were you i'd print the whole thing and look at what happens now | 00:45 |
| dvheumen | poolie, yeah, I know. I'm first setting up a test file at the correct location | 00:49 |
| dvheumen | btw, maybe it's something to add to the Bazaar Testing Guide documentation too, but I wasn't sure. I was running the selftest of a local 2.0 branch, but the plugins that are tested are taken from the system-wide library patch, and those are of version 2.1.0. Maybe it's a useful remark. | 00:50 |
| dvheumen | *path | 00:50 |
| poolie | hm, that's no good | 00:52 |
| poolie | these are system-wide plugins? | 00:52 |
| dvheumen | uhhmm.. well maybe you understand. I ran './bzr selftest' in a local branch in my home dir. But it tried to run tests for the bzr 2.1.0 that was installed with some plugins. One of the plugins wasn't supported in bzr < 2.1.0 so that's how I noticed the error | 00:53 |
| dvheumen | *when | 00:53 |
| dvheumen | too late, too many errors in my sentences :P | 00:54 |
| dvheumen | okay, now a decent clarification: the bzr core tests are ran without problems. But the tests for the plugins are taken from the system-wide library path | 00:56 |
| poolie | ok, i see what you mean | 00:57 |
| dvheumen | so './bzr selftest --no-plugins' works as expected, but without '--no-plugins' I immediately get the error that one of the plugins can not be loaded | 00:57 |
| poolie | right | 00:57 |
| poolie | so | 00:57 |
| poolie | probably it's a bug in that plugin if it doesn't cleanly declare that it can't work with bzr 2.0 | 00:57 |
| poolie | it may arguably be a bug in bzr too that it's even trying to load plugins if they're meant for 2.1 | 00:58 |
| poolie | iow if they're installed underneath the bzrlib directory of a different copy of bzr | 00:58 |
| dvheumen | no it's more that, if I just run the unit tests, especially as someone without experience with bzr (or python dev) it seems that the unit tests fail, but it's actually a plugin, not the code in the local branch | 00:58 |
| dvheumen | so my first idea was: how can the unit tests fail on a stable release?, while it's actually because of the plugins, not bzr itself | 00:59 |
| dvheumen | but it's pretty obvious now, so maybe it's not worth mentioning | 01:00 |
| poolie | what i think should be happening is: you get a message 'plugin blah needs bzr 2.1 and can't work with bzr2.0.4' | 01:00 |
| poolie | and then the tests pass | 01:00 |
| poolie | there are many cases where it is not this clean | 01:00 |
| poolie | we should fix them | 01:00 |
| lifeless | poolie: dvheumen: you can also hook in explicitly. | 01:00 |
| lifeless | because it can be disabled in the test suite, I wouldn't look at self._lock_actions; rather I'd hook it yourself | 01:00 |
| lifeless | that way your setup doesn't get recorded, only the bit where you are doing the actual test. | 01:00 |
| poolie | how should he do that? | 01:01 |
| dvheumen | lifeless, hmmm, I think you're going too fast for me. Do you, by any chance, have an example I can look at? | 01:02 |
| lifeless | # prep the test now | 01:02 |
| lifeless | #... | 01:02 |
| lifeless | locks_taken = [] | 01:02 |
| lifeless | def gather_lock(result): locks_taken.append(result) | 01:02 |
| lifeless | bzrlib.lock.Lock.hooks.install_named_hook('lock_acquired', gather_lock, None) | 01:03 |
| poolie | mm | 01:03 |
| lifeless | self.run_bzr('revert') # or whatever you want your test code to be | 01:03 |
| poolie | it's a bit gross to write this into the particular test | 01:03 |
| lifeless | self.assertLength(1, locks_taken) | 01:03 |
| poolie | dvheumen: rather than writing your own hook, maybe you should just look at _lock_actions before and after running revert | 01:03 |
| poolie | look at what has been added to it | 01:04 |
| lifeless | poolie: if disable_lock_checks is disabled, that variable will be untouched always | 01:04 |
| lifeless | poolie: its really not meant to be 'user' visible. | 01:04 |
| lifeless | I don't think inspecting it from subclasses is a good idea. I think its a bad idea in fact. | 01:04 |
| poolie | ok | 01:04 |
| poolie | so perhaps we should add to the base class a similar or identical implementation that can be reused? | 01:05 |
| poolie | hm | 01:05 |
| lifeless | in fact, the hook in this case can be: | 01:05 |
| lifeless | locks_taken = [] | 01:05 |
| lifeless | bzrlib.lock.Lock.hooks.install_named_hook('lock_acquired', locks_taken.append, None) | 01:05 |
| lifeless | its two lines :) | 01:05 |
| poolie | or perhaps we should always record them, and just disable the actual _checks | 01:06 |
| poolie | the point is to make it easier for people like danny to write these tests | 01:06 |
| lifeless | thats possible too | 01:06 |
| lifeless | I do think we should make it easier for people like danny to write tests | 01:07 |
| dvheumen | lifeless, I can follow that, but do you know by any chance if I can make a distinction between read/write lock and tree/branch/repository level? Because I got this info, http://paste.ubuntu.com/391407/ and I only see a filename, but it's probably more | 01:07 |
| lifeless | however, the _lock_actions is orthogonal infrastructure; it will have noise in it, and clearing it will make cleanups fail | 01:07 |
| lifeless | dvheumen: only write locks will show up | 01:08 |
| dvheumen | aha, nice :) | 01:08 |
| lifeless | dvheumen: its a bit dirty, but you can see the '/branch/' and '/repository/' in the paths. | 01:09 |
| dcoles | G'day. Does any know if bzr-svn honours $http_proxy? | 01:09 |
| lifeless | these locks are at the lowest layer; Repository and Branch build on top of them: the hook is reporting on things that don't know they are a branch/repository/etc | 01:09 |
| poolie | dcoles: it should | 01:09 |
| lifeless | dcoles: I think it might | 01:09 |
| poolie | in pre-2.0 versions there are problems resolving lp: urls through proxies | 01:09 |
| dvheumen | lifeless, yeah I saw that, but it seems like a filename to me, with LockResult around it, I thought this might be some python notation of something like a data structure or so | 01:10 |
| dcoles | poolie: Thanks. I'm using 2.1 at the moment, though can't seem to get it to work | 01:10 |
| dvheumen | it seems a bit tricky to just search for 'Repository' or 'Checkout' in this string | 01:10 |
| lifeless | dvheumen: nope ;) its just that we've given things on disk reasonably sensible names. | 01:11 |
| dcoles | poolie: Is there a way to enable debugging so I can see the requests made in the log? | 01:11 |
| poolie | dcoles: what in particular? and use -Dhttp | 01:11 |
| lifeless | dvheumen: I think its a little tricky too - OTOH this is relatively simple; we can add a higher layer hook later (and i you wanted to do that I'd be happy to mentor) | 01:11 |
| poolie | actually those filenames do look pretty strange | 01:11 |
| poolie | why is there randomness directly appended to the name? | 01:12 |
| lifeless | poolie: the first one is the metadir lock; called branch because of its starting back in 0.0.x; and this is the 'initialise data structure on disk' stage - the lockdirs may not actually exist yet. | 01:12 |
| dcoles | poolie: Just like to be sure that I'm actually trying to use the HTTP server - at the moment I get DavRequestFailure - could not connect to HTTP server | 01:12 |
| dcoles | poolie: Cheers - I'll take a look | 01:13 |
| poolie | lifeless: what i mean is, why is it .bzr/repository/lockyxb3rn4sw1oyx1jzkt45 not .bzr/repository/lock | 01:13 |
| poolie | is it still stuck with a temporary name used during creation? | 01:13 |
| poolie | it seems strange it would still have that name at least at the time it is released. | 01:14 |
| lifeless | poolie: right, thats what I'm saying; I'm guessing it that its during the bootstrap of the lock. | 01:14 |
| lifeless | poolie: and we want the release path to match, for the lock checking code | 01:14 |
| lifeless | ah actually | 01:15 |
| poolie | so i propose to add http://paste.ubuntu.com/391411/ to the guide | 01:15 |
| lifeless | poolie: return '%s(%s%s)' % (self.__class__.__name__, | 01:15 |
| lifeless | self.lock_url, self.details) | 01:15 |
| poolie | looks like a bad repr or something | 01:15 |
| poolie | mm thought so | 01:15 |
| poolie | that will at least give people a clue | 01:15 |
| poolie | adding a better method +1 | 01:15 |
| lifeless | poolie: I really don't like suggesting people look at _lock_actions | 01:15 |
| lifeless | poolie: can we just given a two-line example of capturing to a list? | 01:16 |
| poolie | it's just going to encourage that to be copy-and-pasted | 01:16 |
| poolie | how about if we add a common method and call that? | 01:16 |
| lifeless | sure, though that is more work than simply documenting what can be done today. | 01:17 |
| lifeless | at two lines long I'm not personally concerned by copy and paste | 01:17 |
| dvheumen | or I could add it after I created a decent example? | 01:17 |
| lifeless | anyhow - either is fine with me. Just poking at private stuff in the base class isn't. | 01:17 |
| dvheumen | I don't mind | 01:17 |
| * lifeless puts nose back into C code for indicator-sound | 01:18 | |
| poolie | dvheumen: that'd be good | 01:18 |
| dvheumen | I'm already contacting you after I've written a (more or less) decent test :P | 01:18 |
| dvheumen | okay, created a TODO list. I'd like to do this in a decent way, so I can actually learn something, so I don't mind :) (Could take a couple of days though) | 01:21 |
| lifeless | dvheumen: cool | 01:21 |
| dvheumen | lifeless, and you can expect a pm after I get how the lower level hook works ;) | 01:21 |
| dvheumen | Tnx guys, I'm gonna go find my bed, it's pretty late/early in the Netherlands | 01:22 |
| poolie | cheerio | 01:22 |
| lifeless | dvheumen: just ask here - if I'm asleep or whatever I'll see it, but someone else may answer too | 01:22 |
| poolie | thanks for working on this | 01:22 |
| dvheumen | okay, no prob, bye | 01:23 |
| === Adys is now known as Addybot | ||
| === Addybot is now known as Adys | ||
| dcoles | poolie: Looks like something isn't working for bzr-svn | 01:26 |
| dcoles | `http_proxy=... bzr -Dhttp info http://bazaar.launchpad.net/~bzr/bzr/trunk` works | 01:27 |
| dcoles | `http_proxy=... bzr -Dhttp info svn+https://clir.googlecode.com/svn/trunk` does not :S | 01:27 |
| dcoles | I guess it depends on how bzr-svn's transport works | 01:28 |
| poolie | dcoles: maybe you need to set https_proxy? | 01:28 |
| dcoles | poolie: If that works I'll feel very silly. :p | 01:30 |
| dcoles | Uh.. no dice. *sigh* | 01:30 |
| poolie | hm | 01:32 |
| poolie | maybe this is a limit in the svn libraries we're calling into | 01:32 |
| poolie | anyhow you could file a bug | 01:32 |
| dcoles | Just found https://answers.edge.launchpad.net/bzr-svn/+question/101399 | 01:32 |
| dcoles | So yes, that might be the case | 01:33 |
| dcoles | poolie: Ok, so the trick is you have to set it in ~/.subversion/servers | 01:53 |
| dcoles | I understand why (since subversion ignores http_proxy, yay!), but a bit obscure to find | 01:54 |
| dcoles | Aaaaand... awesome! That works. Thanks for your help poolie | 02:04 |
| poolie | great | 02:04 |
| poolie | dcoles: see bug 534794 | 02:06 |
| ubottu | Launchpad bug 534794 in bzr-svn "svn connections should inherit proxy settings" [Low,Triaged] https://launchpad.net/bugs/534794 | 02:06 |
| dcoles | Haha. I was about to complain that the FAQ entry for 'behind a proxy' was a bit poor, but then again jelmer only created it 31 mins ago :p | 02:12 |
| dcoles | But yes. Look forward to that feature. | 02:13 |
| lifeless | poolie: bug 534724 - I think you've sidetracked it | 02:15 |
| ubottu | Launchpad bug 534724 in bzr "Large Repository.insert_stream_1.19 call when pushing new stacked branch with no new revisions" [Medium,Confirmed] https://launchpad.net/bugs/534724 | 02:15 |
| lifeless | poolie: its not about new branches, its about trivial commits on existing branches | 02:15 |
| * wgrant was going to say that. | 02:23 | |
| wgrant | Although the initial push is slow too, that wasn't why I filed it. | 02:23 |
| lifeless | wgrant: I think you added confusion by including a full test case :) | 02:34 |
| lifeless | / example | 02:34 |
| wgrant | lifeless: Yeah, I considered clarifying that after I filed it, but elected not to :/ | 02:35 |
| === NyRy is now known as R-H | ||
| R-H | Just testing | 03:56 |
| R-H | Changed my nick but I thought it was harder than that | 03:56 |
| Peng | Who what? Changing your nick takes a /nick. | 04:01 |
| Peng | Aside from dealing with the registration, which is an additional 50 seconds of work (mostly reading NickServ's help) | 04:01 |
| chx | how can i make a file the same as it is in lp:drupal ? my tree has a real lot of various changes so lp:drupal is not really a parent or anything... | 04:15 |
| bob2 | is it a parent or not? | 04:16 |
| lifeless | chx: bzr revert -r branch:lp:drupal FILENAMe | 04:18 |
| chx | oh tricky | 04:18 |
| chx | thanks | 04:18 |
| chx | never knew the revisionspec could contain a branch: | 04:18 |
| chx | one always learns | 04:18 |
| lifeless | bzr help revisionspec | 04:19 |
| chx | lifeless: bad news, the Drupal community decided on git :( I am using bzr at my workplace still. | 04:21 |
| lifeless | :( | 04:26 |
| R-H | Peng: where do I issue the /nick command? Terminal, my IRC client? | 05:11 |
| bob2 | your irc client | 05:12 |
| bob2 | since it's an irc command | 05:12 |
| R-H | does anyone else see it or just the server? | 05:12 |
| SamB_XP | we see the change of nick happen | 05:12 |
| SamB_XP | we don't see this | 05:12 |
| SamB_XP | /nick not_SamB | 05:13 |
| R-H | so if I type /msg nickserve register ... you don't see it? | 05:13 |
| SamB_XP | indeed | 05:14 |
| SamB_XP | which is good, or we'd know your password! | 05:14 |
| R-H | but you just saw it??? | 05:14 |
| SamB_XP | nope! | 05:14 |
| SamB_XP | I just know that that command takes a password | 05:14 |
| R-H | Cool, got it changed. Thanks | 05:22 |
| Peng | R-H: /parting the channel and /quitting the server are unnecessary, although it is nice to test that your auto-identify command still works. | 05:31 |
| R-H | Peng; Good to know. Just was exploring around the client really. | 05:32 |
| vila | hi all ! | 07:23 |
| codygman | I'm doing the bazaar in 5 mins tutorial, and bzr diff isn't showing differences | 09:39 |
| donri | codygman, the changes you have made since the last commit, are they made in committed files? | 09:40 |
| donri | what does "bzr status" give | 09:41 |
| codygman | one second | 09:41 |
| codygman | i deleted it and redid the mini tutorial | 09:41 |
| codygman | donri: here you go | 09:44 |
| codygman | http://dpaste.com/169810/ | 09:44 |
| codygman | oh wait, you can only look at differences before commit then? | 09:45 |
| codygman | aha... how would you look at differences between commits? | 09:46 |
| donri | bzr diff -rX..Y | 09:46 |
| idnar | or bzr diff -cN | 09:46 |
| donri | as i suspected, you didn't make any changes *since the last commit* :) | 09:46 |
| donri | that's the default for diff and status: changes made since committing | 09:47 |
| idnar | -rX..Y shows you the changes between revision X and revision Y, -cN shows you the changes made in revision N | 09:47 |
| codygman | rofl silly mistakes.. they always happen | 09:47 |
| donri | codygman, "help" is a useful command also, e.g. bzr help diff | 09:48 |
| codygman | yeah.. i did that actually | 09:48 |
| codygman | reading man now | 09:48 |
| codygman | does bzr have a release folder, or a place where I can put only working versions? | 09:53 |
| donri | maybe you want branches, or tags? | 09:53 |
| codygman | you mean once I verify that my changes didn't break anything, I can commit them to a certain brance? | 09:54 |
| codygman | branch* | 09:54 |
| donri | branches are separate lines of development, usually sharing past commits; tags are named commits. (does these definitions apply to bazaar, people?) | 09:56 |
| idnar | codygman: in a lot of projects, each new feature / bug fix / whatever will be made on a branch, and then merged to "trunk" once it's ready (for example, the code might have to go through a code review process, or whatever) | 09:56 |
| codygman | alright.. that's what i'm wanting to do.. I don't want to upload module and brake everything.. lol | 09:57 |
| bob2 | donri: yes | 09:59 |
| en1gm4 | hi all | 10:03 |
| awilkins | codygman, It's just social convention in Bazaar as well as SVN (I'm inferring that you are coming from SVN) | 10:03 |
| codygman | actually i'm coiming from no version control.. but have read more about SVN than others | 10:03 |
| donri | what do you mean by uploading, though? | 10:03 |
| codygman | well after my module has been updated and I know it works | 10:04 |
| codygman | i'll upload it to my djangos custom-modules direcotry | 10:04 |
| codygman | directory | 10:04 |
| en1gm4 | in a project I'm working on there is a pre-commit test used like bazaar plugin, the problem is that each developer has to link or copy that plugin in ~/.bazaar, is there any way to distribute it in the <branch>/.bzr ? or some repo setting? | 10:04 |
| Peng | en1gm4: Not really -- general arbitrary code execution is considered unwise. :P | 10:08 |
| Peng | en1gm4: There is work on doing it in a more-safe way, and it might even be usable, but I don't know. | 10:09 |
| awilkins | en1gm4, I'm getting security-hives about a project that just distributes serialized objects in the VCS folder for later deserialization and execution... | 10:10 |
| donri | codygman, you should automate your deployment (with e.g. fabric) and have pip pull dependencies from a requirements.txt file, where you can list the path to your module's bazaar branch | 10:11 |
| codygman | ahh alright.. i've been looking at fabric | 10:12 |
| codygman | thanks donri, think its time for me to shutdown the shell tonight though | 10:18 |
| donri | you rest that overworked brain! | 10:19 |
| acezar | hi. i have a corruption problem with bzr branch. for some reason, when i branch almost all line with "foo: stuff $bar" become "foo$bar". i can figure if it's a bug or if there is a functionality that i don't know | 10:50 |
| acezar | i have no plugins and this is the same with either version 2.0.4 or 2.1.0 | 10:52 |
| Peng | acezar: "bzr plugins" doesn't list anything? | 10:53 |
| Peng | acezar: Are you using some incredibly bizarre file system? | 10:53 |
| Peng | acezar: I'm suspicious you may have keyword replacement enabled. | 10:53 |
| acezar | i have now fastimport launchpad netrc_credential_store news_merge as plugins. fastimport was'nt installer when i tested. the others are installed as default (i use archlinux) | 10:55 |
| acezar | i suspected keywords too but cant find it | 10:55 |
| acezar | i work whith sshfs mounted volumes | 10:56 |
| acezar | is there any keymord replacement when the keywords plugin is not installed? | 10:57 |
| Peng | acezar: The keywords extension uses the content filtering feature built into bzr, but that doesn't do anything by default. | 10:58 |
| Peng | Honestly, I've got no idea. :-\ Probably something obvious, but... | 10:58 |
| acezar | is the keywod plugin is installed in the repository when used once? it was present on the first branch opration | 11:00 |
| Peng | acezar: Ah. No, but the changes it made won't be automagically reverted. Does "bzr diff" show these changes? | 11:02 |
| acezar | no | 11:03 |
| Peng | um. | 11:06 |
| Peng | I don't know much about how content filtering works. :-\ It's possible it does do something permanent. | 11:06 |
| acezar | i found | 11:07 |
| acezar | the keywords plugin did somthhing to the repository. i don't know what, but a fresh repository witch as never seen the plugin branch perfectly | 11:08 |
| acezar | the keywords plugin seems to leave somthing event when uninstalled | 11:09 |
| Peng | Oh. | 11:16 |
| Peng | Here's what might have happened: someone disabled the keyword plugin, did not revert the changes it had made, and then accidentally committed them. | 11:17 |
| Peng | Now they're just normal data. You could use annotate to see what it happened and revert the damage. | 11:17 |
| acezar | i dont think. there was a trunk branch exported from cvs. when branched this to test some files were corrupted not the trunk. the keywords plugin was installed (bzr explorer windows). then we try to do the same without the plugin. corruted again | 11:19 |
| acezar | so i tryed on my own computer commandline archilux. same result | 11:20 |
| acezar | so we tryed to restart from scratch. export form cvs no plugin installed. then branch. no more problems | 11:21 |
| Peng | Huh. | 11:22 |
| Peng | You said "CVS", so my brain is shutting down to prevent contamination. ;P | 11:22 |
| acezar | lol | 11:24 |
| bytee | hi! does anyone know if there's an app that can graph bzr commit histories ? i.e. something good for making charts as to who's committed the most in the last year? | 11:24 |
| Peng | It's entirely possible something weird happened between the keyword plugin and the CVS converter. | 11:24 |
| Peng | bytee: I dunno. Ohloh.net probably does. | 11:25 |
| Peng | bytee: If by "graph" you mean "ASCII list", the bzr-stats plugin should be able to do that. | 11:25 |
| bytee | Peng: ah ok. let me try bzr-stats | 11:25 |
| neaj | hi all .. how do i time-travel my working directory back to revision 2? | 11:31 |
| Peng | neaj: bzr revert -r 2 | 11:33 |
| Peng | neaj: bzr update -r 2 (if your bzr is new enough) | 11:33 |
| Peng | neaj: You can also "bzr cat -r 2 some/file" if you just want an old version of one file dumped to stdout | 11:34 |
| Peng | neaj: You could even make a new branch, "bzr branch -r 2 some_branch time_travel" | 11:34 |
| neaj | Peng: bzr: ERROR: no such option: -r | 11:35 |
| neaj | that's for update | 11:35 |
| neaj | Bazaar (bzr) 2.0.4 | 11:36 |
| neaj | won't revert throw away intervening commits? | 11:36 |
| neaj | it's a big ol' tree i want to time travel | 11:36 |
| Peng | neaj: I guess bzr 2.0.4 isn't new enough, then. :P Must be new in 2.1. | 11:37 |
| * neaj kicks Jaunty | 11:38 | |
| neaj | doing revert .. | 11:38 |
| Peng | neaj: What do you mean by "throw away intervening commits"? Revert just meddles with the contents of the working tree; it doesn't change any meta data. | 11:38 |
| neaj | phase:comparing files 43229/45619 | 11:38 |
| neaj | Peng: ah, cool | 11:38 |
| Peng | neaj: Even "update" will only meddle with the working tree's contents and meta data; it won't change the branch | 11:38 |
| neaj | Peng: i thought reverted reverted a commit to make it like it never happened | 11:38 |
| Peng | neaj: uncommit does that | 11:39 |
| neaj | Peng: yes, that's what i would expect from update | 11:39 |
| Peng | neaj: If you mean "completely remove all traces of it from history". | 11:39 |
| neaj | OK, now revert left me with 1000s of files which it's refusing to delete because they're not empty | 11:43 |
| neaj | how do i go back to "now" now? | 11:45 |
| neaj | how can bzr tell me "Tree is up to date at revision 6." if i just did a 'bzr revert -r 2'? | 11:46 |
| neaj | trying bzr revert -r 6 | 11:47 |
| Peng | neaj: "bzr revert" if you did revert, or "bzr update" if you did update, or "bzr pull -r revid:something" if you did bzr uncommit or bzr branch. :D | 11:47 |
| cayblood | I'm getting an error trying to run bzr after installing the Bazaar-2.1.0-2.1 package for OSX: http://gist.github.com/326509 | 11:47 |
| Peng | (Just FYI, you can find that revid with bzrtools' "bzr heads" command. bzr uncommit will also tell you.) | 11:47 |
| neaj | got about a million like this: Conflict adding file zeocluster/src/theme. Moved existing file to zeocluster/src/theme.moved. | 11:47 |
| Peng | Yikes. | 11:48 |
| Peng | ("bzr pull . -r revid:something", I should have said.) | 11:48 |
| Peng | (Unless you did "bzr branch". Anyway this is off-topic.) | 11:48 |
| neaj | i just did the revert commands i pasted | 11:48 |
| Peng | neaj: Did it mention any conflicts when you did the original revert? | 11:48 |
| neaj | well, you & i pasted | 11:48 |
| neaj | yes, revert left me with 1000s of files which it's refusing to delete because they're not empty | 11:49 |
| neaj | those were reported as conflicts | 11:49 |
| neaj | and now going back to now they were all reported as conflicts again | 11:49 |
| Peng | neaj: Right. You had files that bzr isn't tracking (text editor backups, .pyc files, compiled code, etc.), so it refused to delete the directories. Now it's trying to create the directories, but they don't exist, so it's unhappy again. | 11:49 |
| Peng | Err, sorry. | 11:49 |
| Peng | but they already exist* | 11:49 |
| neaj | that doesn't make sense ;-) | 11:50 |
| neaj | if it isn't tracking them, how can it be trying to create them? | 11:50 |
| neaj | it was tracking them alright | 11:50 |
| Peng | When you did "bzr revert -r 2", it deleted all of the stuff it tracked. However, you had files it wasn't tracking lying around, so it couldn't delete all of the directories it wanted to. | 11:51 |
| Peng | Now you're doing "bzr revert" and it wants to create those directories -- because it tracks them -- but it's finding that directories with the same names already exist and gets unhappy. | 11:51 |
| Peng | (Bazaar tracks directories as first-class objects, just like files.) | 11:51 |
| Peng | I'm sorry, but I don't know of a good magic cleanup button for this. | 11:51 |
| cayblood | Anyone have any idea what the problem is here? http://gist.github.com/326509 | 11:52 |
| cayblood | Error I'm getting is "'module' object has no attribute 'SIGWINCH'" | 11:52 |
| neaj | Peng: it's OK, it's a sandpit for learning bzr .. | 11:53 |
| Peng | cayblood: Oh shoot. Other people have been reporting that too. | 11:53 |
| Peng | Err, wait, they might have been on Windows though. | 11:53 |
| Peng | cayblood: What OS? | 11:53 |
| cayblood | OSX | 11:53 |
| Peng | Oh, duh, shoulda looked at the paths... | 11:53 |
| cayblood | snow leopard, to be precise | 11:54 |
| cayblood | Been trying to get this working with various versions of python and bzr for a couple days now | 11:54 |
| cayblood | running into various problems. | 11:54 |
| Peng | cayblood: Bazaar assumes that the SIGWINCH signal exists on all non-Windows platforms. Perhaps it is mistaken. | 11:55 |
| cayblood | Finally decided to go with the a plain vanilla setup, remove macports and just try to get the built-in python working | 11:55 |
| cayblood | I think it is mistaken | 11:55 |
| cayblood | let me investigate | 11:55 |
| Peng | Well, the error message states quite obviously that OS X doesn't have that signal, or at least Python doesn't think it does. | 11:57 |
| cayblood | Looks like there is support for SIGWINCH in OSX: http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man3/is_term_resized.3x.html | 11:57 |
| cayblood | But maybe python doesn't expose it? | 11:58 |
| cayblood | I mean, maybe Python is not making the right declarations or something? Just a guess | 11:58 |
| Peng | Python should expose it. | 11:58 |
| Peng | AFAIK, anyway. But it obviously isn't. | 11:58 |
| Peng | There may be a Python bug here, but this is definitely something bzr can fix as well -- it could exclude OS X, or actually check whether SIGWINCH exists instead of assuming based on the OS. You should file a bug. | 11:59 |
| vila | cayblood: try: python -c 'import signal; print signal.SIGWINCH' | 12:00 |
| cayblood | jussec | 12:00 |
| Peng | Err, good point. | 12:00 |
| vila | Peng: I tried the above on OSX 10.6.2 and it worked | 12:00 |
| Peng | Awesome. | 12:00 |
| cayblood | Peng: Here is the result: | 12:00 |
| cayblood | http://gist.github.com/326518 | 12:00 |
| Peng | As a workaround, you can pretty easily hack bzrlib/osutils.py:watch_sigwinch to just return or something. | 12:00 |
| Peng | cayblood: Just to be sure, could you: python -c 'import signal; print signal.__file__' | 12:01 |
| vila | cayblood: try changing your current dir (wild guess)... hehe like Peng said :) | 12:01 |
| cayblood | Could it be a problem with the built-in python version? Apparently it's 2.4.6 | 12:02 |
| Peng | Maybe. | 12:02 |
| cayblood | vila: changing current dir did nothing | 12:03 |
| vila | if your PYTHONPATH includes '.' or '' the current directory is searched for modules, environment bug | 12:03 |
| Peng | cayblood: What about the command I asked you to run? | 12:03 |
| vila | python -v ? | 12:03 |
| cayblood | Peng: I got 'module' object has no attribute '__file__' | 12:03 |
| vila | I've got python-2.6.1 here | 12:03 |
| vila | and AFAICT, it's a stock install | 12:04 |
| cayblood | vila: hmm weird | 12:04 |
| Peng | cayblood: OK. | 12:04 |
| cayblood | vila: only thing I can assume is that my python was not upgraded when I upgraded to Snow Leopard, but I highly doubt that | 12:04 |
| Peng | So you _are_ getting the right signal module (almost certainly python -c 'import signal; print signal' would confirm it for sure). | 12:05 |
| cayblood | jussec | 12:05 |
| Peng | certainly;* | 12:05 |
| cayblood | Peng: I get <module 'signal' (built-in)> | 12:05 |
| Peng | cayblood: Yeah, OK. | 12:05 |
| cayblood | I can check what version of python is running on my colleagues' machines. Jussec... | 12:06 |
| Peng | Python's signal module is about as simple as it can be: #ifdef SIGWINCH | 12:07 |
| * vila needs food | 12:08 | |
| cayblood | Looks like fresh installs of snow leopard have 2.6.1 | 12:08 |
| * Peng has pizza! :D | 12:08 | |
| neaj | bzr branch -r 2 PlonePIMS-ready PlonePIMS-ready-r2 # <- this worked fine | 12:08 |
| neaj | mv PlonePIMS-ready PlonePIMS-ready-orig | 12:08 |
| cayblood | For some reason mine has 2.4.6. I will investigate further and see if I can start from a clean baseline. | 12:09 |
| neaj | bzr branch -r 6 PlonePIMS-ready-orig PlonePIMS-ready-r6 # <- bzr: ERROR: Not a branch: "/home/jean/PlonePIMS-ready-orig/". | 12:09 |
| neaj | ?! | 12:09 |
| Peng | neaj: ls PlonePIMS-ready-orig | 12:10 |
| Peng | neaj: Maybe it already exists, so your branch is at PlonePIMS-ready/PlonePIMS-ready-orig | 12:10 |
| Peng | Err, other way around, sorry. | 12:10 |
| Peng | neaj: PlonePIMS-ready-orig/PlonePIMS-ready | 12:10 |
| neaj | nope | 12:10 |
| cayblood | looks like macports reared its ugly head | 12:10 |
| Peng | neaj: ls PlonePIMS-ready-orig/.bzr | 12:11 |
| Peng | neaj: Sure you aren't in the wrong directory? | 12:11 |
| neaj | lecking again .. | 12:11 |
| neaj | checking, sorry .. | 12:12 |
| cayblood | for some reason my messages are vanishing from my irc window. is this getting through? | 12:12 |
| Peng | cayblood: Yes. | 12:12 |
| neaj | cayblood: yes | 12:12 |
| cayblood | \/usr\/bin\/python was really pointing to macports (2.4 version) | 12:12 |
| Peng | Oh, nice. | 12:13 |
| cayblood | Had to backslash this dir because it was being interpreted as a regex | 12:13 |
| Peng | cayblood: Maybe your IRC client was assuming it was a command because it starts with /. | 12:13 |
| cayblood | yeah probably right How can I escape that? | 12:13 |
| Peng | cayblood: Depends on the client. | 12:14 |
| cayblood | Not start a command with slash? | 12:14 |
| Peng | cayblood: Often something like //foo, / /foo, /say /foo. | 12:14 |
| cayblood | ok | 12:14 |
| Peng | cayblood: Or that, yes. | 12:14 |
| Peng | cayblood: Which client? | 12:14 |
| cayblood | colloquy | 12:14 |
| neaj | Peng: yay! it was indeed something like you suspected. thank u .. | 12:14 |
| Peng | neaj: Oh, whew. | 12:14 |
| Peng | cayblood: Ah, dunno about that, sorry. | 12:14 |
| Peng | (Some clients are even smart enough to recognize file paths and send them through without you having to do anything extra.) | 12:15 |
| cayblood | Yay!!! Switching to python 2.6.1 fixed the problem | 12:16 |
| Peng | cayblood: So...this is a MacPorts bug. :D | 12:16 |
| cayblood | This happened because I was trusting the macports python_select utility, which wasn't really choosing the version of python that I was telling it to. | 12:17 |
| cayblood | But it silently failed. | 12:17 |
| Peng | Fun. | 12:17 |
| * Peng files a bzr bug. Though actually fixing it would be just as easy... | 12:20 | |
| maxb | Is there documentation on per-file merge configuration? Specifically is there any better way of stopping bzr-builddeb's debian/changelog merger being used other than --no-plugins? | 12:43 |
| jelmer | maxb: there is a configuration option somewhere | 12:44 |
| maxb | indeed... :-) | 12:44 |
| maxb | If only I could find where | 12:44 |
| jelmer | maxb: try "deb_changelog_merge_files = " | 12:46 |
| maxb | aha, thanks | 12:49 |
| === mm-mysql is now known as mark|autoconnect | ||
| === asac_ is now known as asac | ||
| vila | maxb: file bugs so it can be improved too | 13:27 |
| === beuno is now known as beuno-afk | ||
| jam | morning vila | 14:22 |
| vila | morning jam ! | 14:23 |
| jam | jelmer: ping | 14:23 |
| jelmer | hey jam, vila | 14:23 |
| vila | jam: I just made tests pass for bug #531967... that was quite a journey :-/ | 14:24 |
| ubottu | Launchpad bug 531967 in bzr "bzr resolve --take-this or --take-other fails for PathConflict if a dir is deleted" [High,Confirmed] https://launchpad.net/bugs/531967 | 14:24 |
| jam | hey jelmer. I'm working on refactoring some of the pack-collection internals so that we can re-use some of the logic for other stuff | 14:24 |
| jam | (like bzr-search, annotate cache, etc) | 14:24 |
| vila | jam: I'll clean up a bit and submit a proposal | 14:24 |
| vila | jelmer: hey | 14:24 |
| jelmer | jam: ah, neat | 14:24 |
| jam | I wanted to check and see if I understood what you were thinking for the bzr-svn/git/hg maps | 14:24 |
| jam | vila: it certainly seemed more involved than one might expect | 14:24 |
| jam | jelmer: so are you essentially just looking for a (key,value) index, or do you need real content? | 14:25 |
| jam | A pack file is generally, 'generic data' storage, + indexes into that | 14:25 |
| jam | and I'm wondering if you just need the last bit, or the whole thing? | 14:26 |
| jelmer | jam: for all three we need key/value indexes, bzr-svn additionally also needs generic storage for the "svn log" cache | 14:26 |
| vila | jam: well, the most annoying part is that deleting a path always win and left no trace, so restoring the other side was... tricky (especially since that shouldn't be versioned anymore) | 14:26 |
| jam | jelmer: what would the key be for retrieving the log data? | 14:26 |
| jelmer | jam: a revision number | 14:26 |
| jam | so you would cache the svn log -r X keyed by UUID + X ? | 14:26 |
| jam | (UUID probably being implicit) | 14:27 |
| jelmer | jam: We currently have one directory per UUID and that seems to work quite well, so the UUID would indeed be implicit | 14:27 |
| jelmer | jam: yeah | 14:27 |
| Peng | This could be relevant for Loggerhead too, though I don't know the details. | 14:27 |
| jelmer | jam: all of this stuff is write-once, once a particular key is set its value will never change | 14:28 |
| jam | jelmer: sure, the issue is just figuring out how tweeze apart our current design | 14:28 |
| jam | currently RepositoryPackCollection knows what indexes are there, etc. | 14:28 |
| jam | And I think we want a more abstract "there is some data" and "there are some indexes" | 14:29 |
| jam | and if all you have is indexes | 14:29 |
| jam | figuring out when they need to be repacked | 14:29 |
| jam | needs a knob to figure out what data is there | 14:29 |
| jam | etc | 14:29 |
| jam | anyway, I think I have a handle on the requirements | 14:29 |
| jam | just need to keep working away at it. | 14:30 |
| jelmer | jam: Cool | 14:30 |
| jam | Peng: potentially, though I'm not really sure how loggerhead is doing its caching, and whether it would really want to store it in yet another structure | 14:30 |
| Peng | Me neither. :D | 14:31 |
| jelmer | jam: I'm not very familiar with the way packs/indexes are managed at the moment so I'm just trying to provide you with sufficient data :-) | 14:31 |
| jelmer | jam: Actually, I did work on a pack-based cache for bzr-git a while back, lp:~jelmer/bzr-git/index-based | 14:31 |
| jam | jelmer: yeah. I'm quite familiar :) Though I'm trying to also improve some bits | 14:31 |
| jam | taking some ideas from bzr-search, etc | 14:32 |
| jelmer | jam: if you're wondering what sort of calls bzr-git needs to do on indexes that code should give you a good idea | 14:32 |
| jam | jelmer: what is the 'X' ? | 14:35 |
| jam | ah, just a placeholder | 14:35 |
| jelmer | jam: yep | 14:35 |
| jam | you could probably have used '' | 14:35 |
| jelmer | jam: no, '' raises an exception somewhere | 14:36 |
| jam | interesting | 14:36 |
| jam | jelmer: so basically, you created indexes, but just never combine them in that code, right? | 14:37 |
| jelmer | jam: yeah | 14:37 |
| mrand | Howdy. I pushed a change, but it is not showing up on launchpad. Could anyone tell me what I did wrong? http://pastebin.org/107411 | 14:37 |
| jam | so for what you need, that is actually pretty easy | 14:38 |
| jelmer | jam: each time you pull from git you end up with a new index file | 14:38 |
| jam | you can use "for index in self._index._indices: index.key_count()" | 14:38 |
| jam | to determine if/when you want to rebuild | 14:38 |
| jam | and then just | 14:38 |
| jam | self._index.iter_all_entries() => self._builder.add_node() | 14:38 |
| jam | I would actually consider doing: | 14:38 |
| jam | if num_indexes > 20: rebuild | 14:39 |
| jam | and just grow from 1 => 20, then pack down to 1 | 14:39 |
| jam | you could be 'smarter', but I honestly don't expect huge overheads there | 14:39 |
| jelmer | jam: I tried to steal the code from bzr-search for repacking, but it was too much code to duplicate imo | 14:39 |
| jam | maybe I'm wrong | 14:39 |
| jam | jelmer: yeah, bzr-search is doing lots of other stuff | 14:39 |
| jam | and I find the code pretty confusing | 14:39 |
| jam | mostly because it is handling "indexes" which are stored as the *data* in a pack, which is then indexed, and then the pack files themselves are indexed | 14:40 |
| jelmer | jam: How hard would rebuilding be ? Or could we perhaps have a helper function in bzrlib to ship the rebuilding off to ? | 14:40 |
| jelmer | jam: ahh | 14:40 |
| jam | jelmer: you aren't rebuilding content | 14:40 |
| jam | so rebuilding the indexes | 14:40 |
| jelmer | jam: no wonder I had trouble understanding that code | 14:40 |
| jam | is just iterating over what you have and adding them to a new builder | 14:40 |
| jelmer | jam: ah, ok | 14:41 |
| jam | jelmer: something like: http://paste.ubuntu.com/391802/ | 14:45 |
| Peng | mrand: 1.) Launchpad doesn't allow you to do lp:~user/project/directory/branch. It's a flat namespace, just lp:~user/project/branch. | 14:45 |
| jelmer | jam: thanks! I'll give it a try this evening. It'd be really nice if we can get rid of the other cache backends. | 14:46 |
| Peng | mrand: Secondly, for the successful push, you left off the "lp:", so it actually pushed to a local directory. | 14:46 |
| mrand | Peng: oops! Thanks. | 14:46 |
| Peng | mrand: bzr push lp:~mrand/mythplugins/fix-repeated-file-ext-511653 or something similar | 14:46 |
| mrand | Peng: bzr: ERROR: Invalid url supplied to transport: "lp:~mrand/mythplugins-trunk/fix-repeated-file-ext-511653": No such project: mythplugins-trunk | 14:47 |
| Peng | mrand: That's exactly what it says -- the project is called "mythplugins", not "mythplugins-trunk". | 14:48 |
| mrand | I thought that --create-prefix would take care of the project part. | 14:48 |
| mrand | oh, I didn't realize it validated that. Ok. | 14:48 |
| mrand | worked. Thanks Peng! | 14:49 |
| Peng | :D | 14:49 |
| RobOakes | Hi, does anyone know how to continue a bzr push request? I was making an initial commit to launchpad with a big SVN repository (23990 revisions). The bzr client stalled halfway through and I *really* don't want to start over from scratch. | 15:35 |
| RobOakes | The error message says something about finish_writing / finish_reading ... | 15:35 |
| RobOakes | The initial error was: The medium 'SmartSSHClientMedium(connected=True, username=u'robertsoakes', host='bazaar.launchpad.net', port=None)' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request. | 15:35 |
| Peng | Yeah, the data got nuked. | 15:36 |
| RobOakes | Alternatively, is there a way to do a "shallow" push, similar to a shallow checkout. The repository has some 15 years of commits, and I only need the most recent history. | 15:36 |
| Peng | RobOakes: I don't think you can do that. Using shared repositories or stacked branches, you'll only have to push it once, though. | 15:38 |
| RobOakes | Okay. I was afraid of that. This particular push had been running for nearly 24 hours, and I was hoping that I wouldn't lost all of that time. | 15:38 |
| RobOakes | I guess I should try and convert it locally, then try and push the resulting branch. | 15:40 |
| Peng | For what it's worth, you can push part of it at a time, e.g. "bzr push -r 500; bzr push -r 1000; ..." | 15:40 |
| Peng | That way it'll be less catastrophic if it fails. | 15:40 |
| RobOakes | Oh, that's a really good idea. Thanks, I didn't realize ou could do that. | 15:41 |
| RobOakes | (Still painfully new to Bazaar, but I really like it so far. And the GUI released last month is *awesome*) | 15:41 |
| === salgado is now known as salgado-lunch | ||
| vila | jam: damn, collateral failing test :-/ | 15:44 |
| jam | vila: need help? | 15:45 |
| vila | jam: I think I understand the problem and know the solution, the needed help is more in the teddy bear area :) | 15:45 |
| jelmer | ??? | 15:46 |
| jam | well, cuddle up, and let Teddy know what you need | 15:46 |
| vila | So, on path conflicts, when one side delete the item and the other rename it, the bug was that you couldn't do --take-other, the file-id was gone and the item too | 15:47 |
| vila | so I fixed that by leaving .OTHER item (resp .THIS when sides are reverted) and just version that when --take-other is involved | 15:47 |
| vila | but now, there is one failing test because for *files* we appear to create 2 conflicts in that case, one path conflict and one content conflict and now both want to create a .OTHER file | 15:48 |
| vila | The solution seems to be to *not* create a path conflict for files... | 15:49 |
| jam | vila: so for files, we would probably have only 1 conflict if they didn't actually change the content, but just deleted (vs rename), however you can certainly have renamed + modified vs deleted | 15:49 |
| jam | however, if both sides rename a file | 15:49 |
| jam | that certainly should be a *path* conflict, regardless the content of the file | 15:49 |
| jam | right? | 15:49 |
| jam | tbh, I'm not sure why a path conflict needs a .OTHER file, versus just having the file_id around in the conflict list | 15:50 |
| vila | as soon as you have a deletion I'm pretty sure a content conflict is created | 15:50 |
| vila | this sounds more in line with what we do elsewhere, that way, if the user modifies it, that's taken into account | 15:51 |
| vila | Doesn't make a lot of sense for dirs, but for symlinks it does | 15:52 |
| vila | Also, creating several conflicts for the same file-id/path raises many UI issues: what if the user resolve one ? Should the other be resolved at the same time ? | 15:55 |
| jam | vila: http://paste.ubuntu.com/391853/ | 15:55 |
| vila | The failing test above just exhibit another aspect: helpers for several conflicts on the same path | 15:55 |
| jam | only a path conflict | 15:55 |
| jam | you only get contents conflict if there was a modification vs a deletion | 15:56 |
| jam | so helpers for multiple conflicts is problematic | 15:56 |
| jam | but that doesn't mean there *aren't* multiple conflicts | 15:56 |
| jam | rename + mod can conflict with a different rename + mod | 15:56 |
| jam | it is a bit problematic, but i think we need to present both problems | 15:57 |
| vila | right, so my fix is incorrect :-/ | 15:57 |
| vila | hmm | 15:57 |
| vila | And I still haven't all the needed tests for all conflicts to cover my decisions :-/ | 15:58 |
| vila | At least with the ones I've added the problems become more apparent | 15:58 |
| vila | jam: So, another possible fix is to use a different suffix than OTHER... | 15:59 |
| jam | so why do you need .OTHER? | 15:59 |
| vila | or no helper at all.. | 15:59 |
| jam | (or .THIS) | 15:59 |
| jam | why can't the helper say "oh in that tree it had content X, lets restore it" | 16:00 |
| jam | well "content X at path Y" | 16:00 |
| jam | it *feels* like the problem is that the Conflict record doesn't include enough information for you | 16:00 |
| jam | why not fix it there | 16:00 |
| jam | oh, and of course we need to see what happens with older clients in these circumstances | 16:01 |
| vila | ha ! Because I don't want to break backward compatibility *now* ? :) | 16:01 |
| jam | vila: isn't adding .OTHER going to break it a bit? | 16:01 |
| jam | (if you don't version the file, then you don't know its file_id anyway) | 16:02 |
| jam | if you have a path, then you can use other_tree.path2id() to get the file_id | 16:02 |
| vila | it breaks one test, but I handled file-id None to detect older conflict objects | 16:02 |
| jam | if you don't have a path or a file_id, how do you know there is a problem... | 16:02 |
| vila | jam: hehe, for the later, I discover the problem by adding a tests dir_deleted, dir_renamed and realized I hadn't enough info to resolve it cleanly | 16:03 |
| vila | hence I filed bug #531967 | 16:03 |
| ubottu | Launchpad bug 531967 in bzr "bzr resolve --take-this or --take-other fails for PathConflict if a dir is deleted" [High,Confirmed] https://launchpad.net/bugs/531967 | 16:03 |
| vila | synchronicity.... | 16:05 |
| vila | jam: so without the helpers, I have to find back the right revision tree by iterating tree.get_parent_ids(), | 16:07 |
| vila | I'm a bit worried about what could happen if there are more than two parents... | 16:07 |
| jam | vila: you are pretty far off in edge-case land | 16:07 |
| jam | I wouldn't worry too much about perfect resolution for a missing directory after merging a 2nd parent | 16:08 |
| jam | (having to use --force) | 16:08 |
| jam | vila: besides, what does '--take-other' really mean if you have multiple OTHERs? | 16:08 |
| jam | what if the conflict was that parent 2 conflicted with parent 3 | 16:08 |
| vila | it means the other at the time of the conflict generation | 16:08 |
| jam | tbh, I would rather not trust the actual content of a file on disk | 16:09 |
| jam | rather than grabbing in from the repo | 16:09 |
| vila | so for THIS, the rparent is the first one, no problem | 16:09 |
| vila | right, but we are resolving anyway, not committing yet | 16:09 |
| jam | echo new content > foo.OTHER, #oops, bzr resolve --take-other | 16:10 |
| vila | bzr remerge foo | 16:10 |
| jam | in my undereducated opinion, relying on crums being left in the working tree isn't a great way forward | 16:11 |
| jam | crumbs | 16:11 |
| jam | it could work | 16:11 |
| jam | and don't let the best prevent better | 16:11 |
| jam | just doesn't feel ideal | 16:12 |
| vila | ok, I'll go the no-helper route and see | 16:12 |
| jam | vila: I certainly feel that you've gotten more exposure to this area. So if you feel strongly, don't let me overrule you | 16:12 |
| vila | on this particular point no, outside view is good, I ran into too many bumps to get there to trust my final solution | 16:13 |
| vila | as being the most.... appropriate instead of ad-hoc :) | 16:13 |
| vila | I had the feeling that resolve actions had to remain simple, but this delete stuff may just be the exception for good reasons | 16:14 |
| jam | vila: it is possible that we don't want a helper, but I also get the feeling that this is the sort of place where people will be the most confused | 16:15 |
| jam | partially because our ContentsConflict sort of sucks | 16:15 |
| jam | it doesn't tell you "conflict because you modified X and X was deleted" | 16:15 |
| jam | it just says "conflict" | 16:15 |
| jam | This came up when I was fixing some of the per-file graph issues for mysql | 16:16 |
| vila | yeah, that's part of what I want to address, I just get diverted by this bug | 16:16 |
| jam | not only did we have invalid conflicts, they told users basically nothing | 16:16 |
| jam | I worked on the former | 16:16 |
| jam | vila: oh, and you've probably already spent more than enough time on it ,given its chance to occur, etc. | 16:17 |
| vila | yet, I wonder if this bug is not a cause of multiple adds: "Oh, my file is gone, let's bzr add it again" | 16:17 |
| jam | finding a resolution would be nice, but don't let it block you too much | 16:17 |
| jam | at least, IMO, this could be an XFAIL case | 16:19 |
| vila | yeah, I partly blame 'test after' being harder and taking more time than 'test before' :-P | 16:19 |
| jam | i still do a bit of both | 16:20 |
| jam | especially when exploring an area | 16:20 |
| jam | as I don't really know what I want to test before I get there | 16:21 |
| === IslandUsurper is now known as IslandUsurperAFK | ||
| emmajane | jml, ping? | 16:44 |
| emmajane | jml, define "hanging"? | 16:44 |
| emmajane | jml, your site is created... | 16:44 |
| jml | emmajane, w/ Chrome, nothing happens after the submit button changes to "Creating..." | 16:48 |
| jml | emmajane, works fine on firefox | 16:48 |
| emmajane | jml, *nod* thanks. | 16:48 |
| emmajane | jml, We think it may be an issue with the way webkit handles button disabling. | 16:48 |
| emmajane | thanks. :) | 16:49 |
| jml | emmajane, my pleasure. | 16:49 |
| emmajane | jml, I owe you a bug sometime. ;) | 16:49 |
| emmajane | no wait. Beer. I owe you a beer. ;) | 16:49 |
| jml | emmajane, :D | 16:49 |
| === salgado-lunch is now known as salgado | ||
| emmajane | gah. You and your blacked out faces on twitter. /me was too quick on the reply, jml :) | 16:55 |
| jml | emmajane, I need more time | 16:57 |
| emmajane | generally in the world? | 16:57 |
| jml | to do things like change avatars | 16:59 |
| jml | move my blog off blogspot | 16:59 |
| jml | come up with a new theme | 16:59 |
| emmajane | jml, ah yes. | 17:00 |
| emmajane | jml "personal branding" time? | 17:01 |
| jml | emmajane, yeah, that. | 17:01 |
| emmajane | jml, If you figure out where that time comes from, can you let me know? I could do with some of it too. | 17:02 |
| jml | emmajane, will do. | 17:02 |
| emmajane | jml, ta :) | 17:03 |
| emmajane | ok. lunch time. | 17:03 |
| vila | jam: meh, from a tree treansform, I get a DirStateRevisionTree for one parent tree but I can't get my hands on a deleted entry as it appears to be blocked by the dirstate one: | 17:21 |
| vila | [('a', '', 0L, 0, ''), ('a', '', 0L, 0, ''), ('d', '', 0L, 0, 'other')] | 17:21 |
| vila | jam: I want the 'd' in the third tuple ('other'), I get the 'a' in the second tuple | 17:22 |
| vila | jam: id2path and path2id give the expected results... is that a bug ? | 17:25 |
| jam | vila: it is certainly possible there is a DSRT bug | 17:26 |
| jam | are you sure you have the tree for the third parent? | 17:26 |
| vila | 'other' is the expected revid, and id2path/path2id are correct for my file-id (i.e. it exists) | 17:27 |
| vila | what do you mean by third ? | 17:27 |
| jam | what does DSRT._get_parent_index() return | 17:28 |
| vila | 2 | 17:28 |
| vila | meh | 17:28 |
| jam | so I think it is "working, basis, merge_parent" | 17:28 |
| jam | as for the indexes | 17:28 |
| jam | I'm trying to understand what you mean by "deleted entry" are you trying to "_get_entry()" ? | 17:29 |
| jam | or Inventory[file_id] or ? | 17:29 |
| vila | I got it from: tt._tree.get_parent_ids()[-1] | 17:29 |
| vila | I got the DRST tree that is | 17:29 |
| jam | vila: you wouldn't get a tree from 'get_parent_ids()' | 17:29 |
| jam | you mean "_tree.revision_tree(tree.get_parent_ids()[-1])" ? | 17:30 |
| jam | regardless | 17:30 |
| vila | yeah, right, sry, tt._tree.revision_tree(revid) | 17:30 |
| vila | yeah | 17:30 |
| jam | I still don't know what you mean by "I can't get my hands on a deleted entry" | 17:30 |
| jam | what is "entry" | 17:30 |
| vila | self._get_entry(file_id=file_id)[1] | 17:30 |
| jam | vila: doesn't that need to be [2] ? | 17:31 |
| vila | as used in kind() | 17:31 |
| jam | or more accurately | 17:31 |
| jam | [_get_parent_index()] | 17:31 |
| === IslandUsurperAFK is now known as IslandUsurper | ||
| jam | specifically, _get_entry(...)[1] is getting the value in the *basis* tree, IIRC | 17:31 |
| jam | maybe I'm thinking wrong | 17:32 |
| jam | just a sec | 17:32 |
| jam | unfortunately, there are multiple _get_entry() possibilities :( | 17:32 |
| jam | oh, and why are you using that anyway ? | 17:32 |
| jam | certainly you shouldn't be doing "tree._get_entry()" | 17:33 |
| vila | http://paste.ubuntu.com/391926 for context | 17:33 |
| vila | jam: because it's called by transform.create_from_tree | 17:33 |
| vila | which I use to restore the old content | 17:33 |
| jam | so, I'm pretty sure DSRT.kind is broken, but I don't have proof yet | 17:34 |
| jam | looking at it, I'm pretty sure that _dirstate._get_entry() is supposed to return the row for that record | 17:34 |
| jam | for the tree specified, but it includes all records | 17:35 |
| jam | it will take a bit to explain | 17:35 |
| jam | DirState._get_entry(tree_index) | 17:35 |
| jam | returns a record | 17:35 |
| jam | for the file_id + path that matches in the given index | 17:35 |
| jam | well, parent 'offset' | 17:35 |
| jam | however, that record should include the info for *each* parent | 17:36 |
| jam | and the issue is that entry[1][0] is going to always return the kind in the WT | 17:36 |
| jam | I think it should be | 17:36 |
| jam | http://paste.ubuntu.com/391931/ | 17:37 |
| jam | this is one of the major problems using tuples + lists as your data structure | 17:37 |
| jam | I really need to drop into pdb to know for sure | 17:37 |
| vila | jam: that seems correct, using 2 instead of 1 makes the mirror test fail, | 17:39 |
| vila | using _get_parent_index make both tests succeed | 17:39 |
| jam | rows in dirstate | 17:40 |
| jam | are stored using | 17:40 |
| jam | (dirpath, name, file_id) keys | 17:41 |
| jam | so the lookup returns the row matching that for the given tree | 17:41 |
| jam | but the 'value' is the whole role for all records | 17:41 |
| jam | so a renamed object shows up in 2 rows | 17:41 |
| jam | with an 'r' record in certain columns | 17:41 |
| vila | jam: should I file a specific bug ? | 17:42 |
| vila | err | 17:42 |
| jam | looks like a bug to me | 17:43 |
| vila | what could be the consequences in your opinion ? | 17:43 |
| jam | Tree.kind() returning the wrong value for objects which change kind | 17:43 |
| jam | however, note that we don't really use Tree.revision_tree() for anything other that Tree.basis_tree() | 17:43 |
| jam | *today* | 17:43 |
| jam | other than | 17:44 |
| jam | And we are planning on getting rid of the extra parent trees being cached in the Dirstate file in the next dirstate revision | 17:44 |
| vila | well, except for merge, revert and friends no ? | 17:44 |
| jam | nope | 17:44 |
| jam | merge + revert only care about the basis tree | 17:45 |
| jam | generally | 17:45 |
| jam | well, your new revert starts caring about other trees | 17:45 |
| vila | oh, because they use trees that aren't cached in the dirstate so they get correct ones ? | 17:45 |
| jam | new *resolve* | 17:45 |
| jam | vila: right, the tree cached in the dirstate is currently not 100% correct for objects that aren't the basis tree | 17:45 |
| jam | but they aren't really used :) | 17:45 |
| jam | but for merge, that tree isn't in the dirstate yet | 17:46 |
| vila | yup | 17:46 |
| vila | and wasn't when I use that code to create the helpers :) | 17:46 |
| jam | (note, I think the data stored is correct, but obviously we have a bug) | 17:46 |
| jam | we basically decided that caching parent>basis is not wortwhile | 17:47 |
| jam | !=basis | 17:47 |
| vila | hehe, I knew I was in a mine-field I just didn't realized how big it was :) | 17:47 |
| jam | we should have fast enough access to RevisionTrees in chk formats | 17:47 |
| vila | sure | 17:47 |
| jam | and we don't really need it for *status* | 17:47 |
| jam | the only place it would have been a win is for 'commit.record_iter_changes()' after a merge | 17:48 |
| jam | but IIRC we solved that without using a multi-way iter_changes | 17:48 |
| jam | we had *thought* we wanted iter_changes against multiple parents, but we never implmeneted it | 17:48 |
| jam | thus we have cruft that we never use | 17:48 |
| jam | and is scheduled for removal :) | 17:49 |
| jam | except now *you* are trying to use it :) | 17:49 |
| jam | it is very useful for *basis* because we want to compare working vs basis often, and do it based on path | 17:49 |
| jam | for the rest, we tend to compare based on file_id anyway | 17:49 |
| jam | and RevisionTree does that well | 17:49 |
| vila | jam: well, I don't use it explicitly I just ask for a revision tree from a working tree :) | 17:50 |
| jam | vila: that will raise NoSuchRevision if it isn't present | 17:50 |
| vila | I don't care whether it's cached or not (yet and may be never) | 17:50 |
| jam | long discussion a while ago | 17:50 |
| vila | in the DRST ? | 17:51 |
| jam | in WT4 | 17:51 |
| vila | Argh, should I go to the repo instead ? | 17:51 |
| jam | http://paste.ubuntu.com/391940/ line 10 | 17:51 |
| jam | so... if you are going to be going to the basis tree, I'd use WT.basis_tree() | 17:51 |
| jam | otherwise, *I* would go to the repo | 17:51 |
| jam | but certainly file a bug | 17:52 |
| vila | ok, I'll fix that then, not worth leaving such a controversial code in place | 17:52 |
| jam | prob high priority, except we've had that bug for a long time, and nobody has hit it :) | 17:52 |
| vila | I'll do | 17:52 |
| vila | well, we have the fix... | 17:52 |
| jam | but we need a test, etc | 17:53 |
| jam | and it shows test coverage holes | 17:53 |
| jam | that we don't have tests against a DSRT that isn't the basis, etc | 17:53 |
| jam | (should be a tree_impl test) | 17:53 |
| jam | etc | 17:54 |
| jam | and all of that probably isn't worth your time | 17:54 |
| jam | espec at 8pm | 17:54 |
| jam | :) | 17:54 |
| vila | 7pm but I'm EODing anyway | 17:54 |
| jam | well, I figured by the time you actually wound down... | 17:55 |
| jam | as for "needs a test" | 17:55 |
| jam | it doesn't really | 17:55 |
| jam | it *should* have one, but it is clearly broken | 17:55 |
| jam | and I'd rather have it fixed than tested | 17:55 |
| jam | vila: Probably worth a tiny amount of time to add a test, but prob also a fair amount of work to get it covered properly. | 17:56 |
| vila | jam: I'm pasting that discussion in the code and look at it tomorrow first thing | 17:56 |
| jam | k | 17:57 |
| vila | the test are passing again so I have a better fix for #531967 anyway | 17:57 |
| vila | I'll go with the repo for the final version and address the DRST bug in parallel | 17:57 |
| vila | jam: thanks again | 17:58 |
| jam | k | 17:58 |
| jam | vila: I'm glad you're working on it, shame to uncover so many chained bugs | 17:58 |
| vila | jam: but the more bugs I uncovered the more confident I became, that's the good side of the story, | 18:00 |
| vila | I'm pretty sure I've run into some others without realizing it in some explorations I did for this fix | 18:01 |
| vila | ...or not, TT are not obvious, sometimes they are really painful to use, sometimes they just magically works very simply... | 18:02 |
| === radoe_ is now known as radoe | ||
| lifeless | moin | 19:05 |
| codygman | would it be recommended to make an svn of my entire website? | 19:55 |
| Kohlrabi | no, a bzr :) | 19:57 |
| JFo | how would I list any uncommitted changes for perusal? | 20:19 |
| JFo | so that I can see them in a terminal | 20:19 |
| IslandUsurper | bzr status | 20:25 |
| IslandUsurper | bzr diff | 20:25 |
| IslandUsurper | JFo, ^^ | 20:25 |
| JFo | thanks much IslandUsurper | 20:26 |
| IslandUsurper | "bzr help commands" is your friend :) | 20:26 |
| jpds | JFo: I like bzr commit --show-diff too. | 20:46 |
| JFo | thanks jpds | 20:46 |
| JFo | I'll check that out | 20:46 |
| poolie | hi there | 21:13 |
| dvheumen | hi | 21:13 |
| poolie | hello dvheumen | 21:13 |
| dvheumen | that's a coincidence, I just got here :) | 21:13 |
| poolie | how did you go with the tests? | 21:13 |
| dvheumen | I finished up a test that I think it's decent enough | 21:14 |
| dvheumen | I've pushed the branch, so you can have a look if you're interested | 21:14 |
| dvheumen | https://code.launchpad.net/~danny.vanheumen/bzr/bug-498409-bzr-revert-takes-a-branch-lock | 21:14 |
| === beuno-afk is now known as beuno | ||
| poolie | sure | 21:16 |
| poolie | you can propose a merge if you think it's ok | 21:16 |
| dvheumen | I was thinking of waiting until the higher level test is complete too | 21:18 |
| dvheumen | and I've got a question about the merge process actually | 21:18 |
| poolie | ? | 21:19 |
| poolie | sure, what is it? | 21:19 |
| dvheumen | I started with this patch on the 2.0 branch, with the idea that it could be merged with earlier branches if needed | 21:19 |
| poolie | right | 21:19 |
| dvheumen | but just out of curiosity I tried to merge with bzr.dev, and this 1 line fix actually conflicts :P | 21:20 |
| dvheumen | so how do you go about if I would propose this branch for merging and it's actually conflicting. Because if I would merge changes between 2.0 and 2.2, then it wouldn't be suitable for merging in 2.0 anymore | 21:21 |
| poolie | just propose it to 2.0 | 21:21 |
| dvheumen | not that I want it too or so, I'm just curious how you would approach this thing :P | 21:21 |
| poolie | and whoever eventually merges it to bzr.dev will fix the conflicts | 21:21 |
| poolie | they're probably just mechanical not conceptual conflicts | 21:21 |
| poolie | if you wanted to do it yourself | 21:21 |
| poolie | make a separate branch off bzr.dev, merge your thing, fix the conflicts, then propose that for bzr.dev | 21:21 |
| poolie | but it's not really worth it because we regularly merge all of 2.0->2.1->trunk anyhow | 21:22 |
| poolie | so it will happen implicitly | 21:22 |
| poolie | however | 21:22 |
| dvheumen | okay | 21:22 |
| poolie | this approach might be good if eg you want to write the tests in a really different way in trunk if for example there was better infrastructure there | 21:22 |
| dutchie | is there anything like "git grep" for searching for content in past revisions? | 21:23 |
| poolie | https://launchpad.net/bzr-search | 21:23 |
| poolie | dutchie: ^^ | 21:23 |
| lifeless | morning poolie | 21:23 |
| dvheumen | hey lifeless | 21:23 |
| lifeless | hi dvheumen | 21:23 |
| dvheumen | lifeless, can you give me a hint for those higher level locking hooks? so I can have a look at those | 21:25 |
| lifeless | dvheumen: well they don't exist; I was saying we could write them | 21:25 |
| dvheumen | ah okay, that's fine too. But in that case it'll probably be a different branch, so I'll propose the current one for merge | 21:26 |
| lifeless | yup | 21:28 |
| lifeless | I need new shorts. Just saying. | 21:29 |
| poolie | ! | 21:29 |
| dvheumen | hehe, luckily no web cam support for IRC :P | 21:30 |
| lifeless | thread at the bottom is unwinding, tickling the back of my legs :) | 21:30 |
| dvheumen | lifeless, could you give an idea on what you have in mind? Maybe something like the lock helpers used in the per_branch locking tests? | 21:34 |
| lifeless | dvheumen: something like the lock.Lock.hooks, but for objects-that-are-lockable rather than locks themselves. | 21:35 |
| lifeless | there are a few shades of meaning here too - | 21:35 |
| lifeless | write locks | 21:35 |
| lifeless | read locks | 21:35 |
| lifeless | tree-only write locks | 21:35 |
| lifeless | critical section locks (only taken as part of implementing some method) | 21:35 |
| dvheumen | yep, I get the idea, that sounds good | 21:36 |
| lifeless | Tree objects, Branch object, Repository objects | 21:36 |
| lifeless | maybe others. | 21:36 |
| dvheumen | looking at those at the moment | 21:37 |
| lifeless | back shortly; grabbing subway :) | 21:38 |
| dvheumen | okay | 21:39 |
| poolie | igc, is there a good guide that answers https://answers.launchpad.net/bzr/+question/103773 about bzr and svn? | 21:48 |
| dvheumen | poolie, thanks for your help. The branch is now proposed for merging into 2.0. I'm going to give the higher level lock hooks a try | 21:53 |
| poolie | cool, thanks | 22:01 |
| poolie | it may help if you add to testing.txt too | 22:01 |
| poolie | i saw you took my sample text yesterday | 22:01 |
| poolie | explaining it to other test developers may help get the api nice | 22:01 |
| poolie | btw i don't know if you saw on the list but we're going to have a sprint fairly near you in may | 22:02 |
| poolie | in Brussels | 22:02 |
| dvheumen | I did see that mail come by | 22:02 |
| dvheumen | do you think it'd be useful for me to have a look there? | 22:03 |
| dvheumen | don't get me wrong, it sounds interesting | 22:03 |
| dvheumen | but I don't have that much experience with python and such ... on the other hand, ... it's in May, i may have learned a lot by then :P | 22:04 |
| dvheumen | is this sprint all week? 'cause I may come and visit one day | 22:07 |
| dvheumen | one day ==> a single day | 22:09 |
| dvheumen | poolie, do you want me to put the additional information about testing in the same branch? and only some information about what I used, or also the part you proposed yesterday? | 22:31 |
| poolie | dvheumen: coming for one day would be fine, and yes, i think you'd find it fun/useful | 22:36 |
| poolie | dvheumen: if it's just a bit more documentation the same branch is fine | 22:37 |
| slangasek | I'm looking to extend bzr-email to support adding arbitrary extra headers to the outgoing mails, as specified in .bazaar/locations.conf | 22:37 |
| dvheumen | okay, I'll do that | 22:37 |
| slangasek | (required for integration with the Debian PTS) | 22:37 |
| slangasek | is there a convention for multiline values in locations.conf that I should be following? | 22:38 |
| slangasek | (since ideally, this should support adding more than one header...) | 22:39 |
| james_w | slangasek: python-configobj is used to parse it, so the documentation of that may provide some clues | 22:42 |
| slangasek | james_w: looking, thanks | 22:43 |
| slangasek | oh, haha, it uses """ to mark multiline values :) | 22:47 |
| lifeless | slangasek: as james_w says :) | 22:51 |
| lifeless | slangasek: you could encode something differently if you wanted, but I'd go with the config obj standard by default | 22:51 |
| slangasek | indeed | 22:51 |
| slangasek | I just didn't know what the standard was - now I do :) | 22:51 |
| slangasek | though, I see it also supports a list syntax; maybe that would be more idiomatic than making it a multiline variable and split()ing in my code.. | 22:52 |
| lifeless | well, what are you doing | 22:53 |
| slangasek | adding a new 'post_commit_headers' option that can contain one or more headers to be added when sending the mail | 22:53 |
| lifeless | please don't call it post_commit | 22:53 |
| lifeless | as bzr-email also does emails on push and pull and so on | 22:54 |
| lifeless | revision_mail_headers | 22:54 |
| lifeless | slangasek: what will be in these headers. | 22:54 |
| slangasek | that seems to be inconsistent with all the other options currently used? | 22:54 |
| slangasek | lifeless: whatever one specifies in the config | 22:54 |
| lifeless | slangasek: yes, but what will be in the settings someone usng it with debian PTS sets | 22:54 |
| slangasek | post_commit_to, post_commit_mailer, post_commit_push_pull... | 22:55 |
| lifeless | slangasek: its different yes | 22:55 |
| slangasek | lifeless: X-PTS-Approved: 1 | 22:55 |
| lifeless | slangasek: that the old ones are misleading/confusing is not a good reason to make new ones the same. | 22:55 |
| jelmer | lifeless: and whose fault is that ? :-P | 22:56 |
| lifeless | mine | 22:56 |
| lifeless | which is why I get to say the name for the new ones ;) | 22:56 |
| slangasek | heh | 22:56 |
| poolie | lifeless https://bugs.edge.launchpad.net/malone/+bug/535390 would have saved me embarrassment :/ | 22:57 |
| ubottu | Launchpad bug 535390 in malone "show duplicate status changes inline on page" [Undecided,New] | 22:57 |
| slangasek | lifeless: so when will the other variable names be fixed? | 22:57 |
| lifeless | slangasek: possibly never, though we could add aliases to look up better names and fallback. | 22:57 |
| lifeless | slangasek: so, X-PTS-Approved:1 - thats all ? | 22:58 |
| lifeless | slangasek: would it make sense to have that added by bzr-builddeb ? | 22:58 |
| lifeless | poolie: heh, and me some enamel :P | 22:59 |
| slangasek | well, IMHO, it's worse to have 3 vars using the old scheme and 1 using the new scheme than to have 4 using the old naming scheme - more misleading, but less confusing to users trying to navigate from scratch | 23:00 |
| slangasek | lifeless: bzr-builddeb> hum, how would it add it? | 23:00 |
| lifeless | slangasek: the names are only discoverable by docs anyway, so I don't think it makes any odds there. Nevertheless, if you want to write it the same, thats fine.... I can change when I merge it to trunk. | 23:00 |
| slangasek | do you think it's not generally useful to let users add headers? | 23:00 |
| lifeless | slangasek: I'm fine with the feature; I'm speculating that we can do a better job for this use case than manually setting a variable based on the branch URL. | 23:01 |
| lifeless | slangasek: but I can't really think about it as you haven't opened up much about the project/logic | 23:01 |
| lifeless | :) | 23:01 |
| slangasek | my use case is that, when pushing to a particular branch, I want emails to be sent to the PTS (using the special address that triggers the PTS 'cvs' keyword for the package) | 23:03 |
| lifeless | ok | 23:03 |
| slangasek | to send mail there, you either have to send the mail from a debian.org machine, or use the s3kr1t X-PTS-Approved header | 23:03 |
| lifeless | and should these replace or be done in parallel normal notification mails for the branch ? | 23:03 |
| lifeless | ^to | 23:04 |
| slangasek | and I don't see a way to have a mail hook run on the server side when pushing to the repo, so I'm configuring this all client-side | 23:04 |
| slangasek | lifeless: what normal notification mails? the ones generated by bzr-email? | 23:04 |
| lifeless | right | 23:04 |
| slangasek | it's one and the same | 23:05 |
| spiv | Good morning. | 23:05 |
| slangasek | [bzr+ssh://bzr.debian.org/bzr/pkg-samba] | 23:05 |
| slangasek | email = Steve Langasek <vorlon@debian.org> | 23:05 |
| slangasek | post_commit_to = samba_cvs@packages.qa.debian.org | 23:05 |
| slangasek | post_commit_mailer = smtplib | 23:05 |
| slangasek | post_commit_push_pull=True | 23:05 |
| slangasek | post_commit_headers=X-PTS-Approved: 1 | 23:05 |
| lifeless | slangasek: yes, but is that byb design or ease-of-doing-this | 23:05 |
| lifeless | slangasek: do you have skype? | 23:06 |
| slangasek | no, sorry | 23:06 |
| slangasek | is what part by design? | 23:06 |
| slangasek | I have bzr-email installed for precisely this | 23:06 |
| lifeless | a regular phone? I'd like a little more bandwidth to clarify this, then I can switch focus | 23:06 |
| slangasek | sure, sec | 23:06 |
| dorins | Hi all. When I 'bzr pull' from a svn branch I get garbage in a specific revion that gets pulled. 'bzr pull' doesn't report any errors and 'bzr check' doesn't find any problems either. | 23:11 |
| igc | morning | 23:13 |
| dorins | I'd report a bug but I don't know what info I could attach to the bug report. Is there any documentation on how to report a bug? | 23:13 |
| dorins | I can reproduce the issue, but I'm not sure how to get bzr to output debug info while I reproduce it so that I could attach it to the bug report | 23:16 |
| === dutchie_ is now known as dutchie | ||
| igc | poolie: I'm yet to file that RT ticket. I'm happy to do it though I'm not sure exactly what to ask for | 23:27 |
| igc | poolie: is installing on escudero enough? Or does it need to go into a chroot as well? | 23:28 |
| poolie | on phone | 23:28 |
| poolie | probably needs to be in the chroot on escudero | 23:28 |
| poolie | because hardy may be too old | 23:28 |
| igc | poolie: hardy looks ok fwiw: http://packages.ubuntu.com/hardy/python-feedparser | 23:30 |
| wgrant | poolie: That bug isn't about pushing a new branch. It's about pushing a new revision to an existing stacked branch. | 23:30 |
| jelmer | 'evening igc, poolie, wgrant | 23:30 |
| igc | hi jelmer | 23:30 |
| wgrant | Morning jelmer, poolie, igc. | 23:30 |
| jelmer | is there any chance either of you could review https://code.edge.launchpad.net/~jelmer/bzr/remote-addinvdelta/+merge/20846 ? I've got one "approve" vote already, but from somebody is not a reviewer | 23:31 |
| * slangasek seconds jelmer's request | 23:31 | |
| slangasek | fix my git-import, plz :) | 23:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!