| thomi | spiv: hmmm, I can't see how to get a rev_id for a give file_id in the branch.repository inventory | 00:01 |
|---|---|---|
| thomi | ahhh, this works (bug is kind of ugly): dict(inv.entries())[relpath].revision | 00:03 |
| thomi | spiv: got it! Are you able to tell me if I;m doing anything really wrong in this: http://pastebin.ubuntu.com/882561/ please? | 00:09 |
| lifeless | thomi: inv[inv.path2id(relpath)].revision | 00:19 |
| lifeless | I think there is a more direct one still | 00:19 |
| thomi | ahh, I didn't realise the inventory was usable like a dictionary :) | 00:21 |
| Pikkachu | hi, how can I keep an up-to-date reference in my code to submit or push branch? | 01:05 |
| Pikkachu | in the specific case, it's the branch url used as project home | 01:05 |
| Pikkachu | does bazaar allow to create a commit hook at least? | 01:06 |
| Pikkachu | or is it better to just write an enclosing shell script which performs the changes before committing (for example using sed)? | 01:07 |
| spiv | Pikkachu: you can create commit hooks, yes | 01:15 |
| spiv | Pikkachu: I don't entirely follow what you're asking for, though | 01:15 |
| spiv | Pikkachu: you want the text you commit to contain the location of the submit or push branch? | 01:16 |
| Pikkachu | no, I want every commit to trigger the references in code to be updated before the commit is performed | 01:38 |
| Pikkachu | I think I can enclose the commit with a previous look into .bzr and subsequent update of required files... | 01:48 |
| Pikkachu | with a shell script, I mean | 01:48 |
| === Pikkachu is now known as PikkachuAway | ||
| === PikkachuAway is now known as Pikkachu | ||
| === Pikkachu is now known as PikkachuAway | ||
| === r0bby is now known as robbyoconnor | ||
| Kamping_Kaiser | is it possible to diff one bzr branch against another branch at an arbitrary revision? | 02:44 |
| Kamping_Kaiser | i want to find out if foo/ (at rev 13) was merged into bar (at rev 191) at any point | 02:44 |
| spiv | Kamping_Kaiser: bzr help revisionspec, see revno: | 02:46 |
| spiv | Kamping_Kaiser: e.g. -r revno:13:foo/..revno:191:bar/ I think | 02:46 |
| Kamping_Kaiser | spiv: i'll have a try, thanks. | 02:47 |
| === PikkachuAway is now known as Pikkachu | ||
| Pikkachu | thanks spiv anyway | 03:02 |
| spiv | Oh! It sounds a bit like Pikkachu wanted keyword expansion. | 03:37 |
| mwhudson | noone really wants keyword expansion do they? | 03:40 |
| bob2 | lots of people think they do though | 03:40 |
| * fullermd does. | 03:55 | |
| * bob2 expands fullermd's keywords into merge conflicts | 03:58 | |
| fullermd | I didn't say I want a crap implementation of keywords :p | 03:59 |
| bob2 | haha | 04:00 |
| poolie | hey all | 08:46 |
| vila | hmm, internet access issues here :-/ Rare but painful event, seems to to come from ADSL itself which is worrying | 09:06 |
| ggherdov | vila: totally OT, but you hit a point that bothers me when I have unstable connections: i am conversating over IRC, then I am cut off from the internet, the person I'm talking with continues writing, but I miss part of the chat. Is there any kind of "IRC buffering thing" I can install on a remote server I have (which has reliable internet), in order to proxy my IRC connection thru a "stabilyzer"? | 09:10 |
| mgz | morning all! | 09:11 |
| vila | ggherdov: probably what IRC proxies are about, I don't use one myself :-/ (On the other hand, since I'm connected via ADSL I think the availability have been like 99.999999% or something...) | 09:12 |
| vila | mgz: hey ! | 09:12 |
| * ggherdov IRC proxies... interesting. | 09:13 | |
| Peng | ggherdov: They're frequently known as bouncers. | 09:13 |
| ggherdov | Peng: good to know. thx. | 09:13 |
| Peng | ggherdov: Personally, I prefer to run a command-line IRC client, and I usually run it on something with a stable connection that I have SSH access to. (That's what I'm doing now.) | 09:14 |
| ggherdov | Peng: I see your point. But is the SSH part of the connection is faulty, you risk to miss stuff. You still need you remote-cmd-line-irc-client to buffer stuff for you, and send all the stuff you missed when it sees you again. | 09:16 |
| ggherdov | s/is/if | 09:16 |
| Peng | ggherdov: I use GNU screen, so the SSH connection doesn't have to be reliable. | 09:17 |
| Peng | Sorry, I should've said so, but I think of screen/tmux as a given when using SSH. | 09:17 |
| * ggherdov Peng got game | 09:17 | |
| ggherdov | Peng now I see. wow a powerful combination | 09:17 |
| ggherdov | btw, using tmux since 2 months and it's a great util. | 09:18 |
| Peng | I've never tried tmux. screen's good enough for me. | 09:18 |
| ggherdov | Peng: I use tmux in order to split my terminal in several shell in a tiledfashion. didn't know of the fault tolerance thing untill now. | 09:19 |
| ggherdov | shells* | 09:19 |
| Peng | Ah. I don't tile stuff. | 09:19 |
| * ggherdov nobody's perfect :-) | 09:20 | |
| Peng | :( | 09:22 |
| nigelb | Peng: tiling irssi leads to really really claustrophobic typing space :) | 09:41 |
| Peng | But but I need to IRC in six channels at once. | 09:43 |
| nigelb | haha | 09:44 |
| ggherdov | there was an option to 'bzr rm' in order to bzr-remove a file that you had already bash-removed. what was that ? | 11:02 |
| jelmer | ggherdov: there is no special option necessary | 11:03 |
| jelmer | ggherdov: 'bzr rm' (without other arguments) should also pick that up | 11:04 |
| ggherdov | ah good. | 11:04 |
| ggherdov | thx jelmer | 11:04 |
| ggherdov | I was mixing up with 'bzr mv --after' | 11:04 |
| jelmer | vila: hah, the main user of .revision_history() is bzrlib.tests.per_branch.test_bound_sftp, but all tests there seem to be skipped for some reason | 11:29 |
| vila | jelmer: hmm, did I tyoped set_revisions_history ? | 11:31 |
| vila | in the line above ? yes :) | 11:31 |
| mgz | "Not a local URL" | 11:31 |
| mgz | fun. | 11:31 |
| vila | mgz: huh ? | 11:33 |
| vila | jelmer: so, having read your review (thanks !), I'm talking about *set_revision_history* not revision_history, probably related but still different beasts | 11:35 |
| mgz | we don't really have a way of detecting test success->skip regressions | 11:35 |
| mgz | without carefully watching babune test counts across runs | 11:35 |
| vila | jelmer, mgz: By the way, I didn't touch code deprecated in 2.5.0, I can't remember what our rule is ? n+1, n+2 ? | 11:35 |
| vila | meh, rule to delete code deprecated in series n that is | 11:36 |
| mgz | vila: what you did seems fine, 2.4 gone in 2.6 seems right | 11:36 |
| vila | anyway, there is still a bunch to remove before touching code deprecated in 2.5 | 11:36 |
| vila | k, thought it was a bit conservative but since there is still a bunch to do before touching that... | 11:37 |
| vila | I think I saw code that was deprecated without any version attached which is... bad :) | 11:37 |
| vila | but again, let's get rid of what we can safely remove first | 11:43 |
| mgz | jelmer: those tests seem too be skipping all the way back to 2.2 | 11:44 |
| mgz | it might make more sense to work out what they're trying to do, write new tests, and delete the module | 11:46 |
| mgz | there's already bug 728252 for those tests skipping, so just proposed deleting them to reduce the chance of us rediscovering that again in future | 12:36 |
| ubot5 | Launchpad bug 728252 in Bazaar "All tests in bzrlib.tests.per_branch.test_bound_sftp are skipped always" [Low,Confirmed] https://launchpad.net/bugs/728252 | 12:36 |
| mgz | "Ran 1 test in 102.260s" heh... | 12:55 |
| ams_cs | bzr: ERROR: bzrlib.errors.BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps | 13:08 |
| ams_cs | anybody know what I can do about that? | 13:08 |
| jelmer | hi ams_cs | 13:12 |
| jelmer | ams_cs: can you provide some more background? | 13:12 |
| ams_cs | I'm trying to merge lp:gcc/4.7 into (a clone of) lp:gcc-linaro/4.7 | 13:13 |
| ams_cs | I've tried it on two machines and get the same result, so it doesn't appear to be some local corruption | 13:13 |
| jelmer | ah, hmm | 13:18 |
| jelmer | I didn't realize those two branches had related history | 13:18 |
| jelmer | that usually indicates branches having a slightly different view on shared history | 13:19 |
| jelmer | can you file a bug? I'll try to look into it. | 13:19 |
| ams_cs | hmm, lp:gcc-linaro/4.7 was originally branched from lp:gcc/trunk | 13:19 |
| ams_cs | upstream branched 4.7 from trunk (in SVN) a week or two ago | 13:20 |
| ams_cs | doko imported the new branch as lp:gcc/4.7, but they should share history right up to the svn branch point | 13:21 |
| ams_cs | and lp:gcc-linaro/4.7 has not diverge far from lp:gcc/trunk | 13:21 |
| ams_cs | jelmer: any luck? | 13:39 |
| jelmer | ams_cs: still fetching the branches | 13:41 |
| ams_cs | jelmer: yeah, that'll take a while. BTW, there's no need to have a local copy of lp:gcc/4.7 to reproduce the problem ... although maybe to debug it | 13:43 |
| jelmer | ok | 13:53 |
| mgz | vila: did you file a bug for the bzrlib/locale thing? | 14:23 |
| vila | mgz: nope, sry | 14:23 |
| vila | mgz: this test_bound_sftp stuff is... worrying :-/ | 14:24 |
| mgz | I think it's less worrying than it looks. | 14:24 |
| vila | how d'you know we're not reducing coverage here ? | 14:25 |
| mgz | because the tests have never (at least since 2.0) actually been run. | 14:25 |
| mgz | we certainly lack functional style testing on various real world things with both the smart server and other remote branches | 14:26 |
| vila | revno 5030 (2.1 => 4857, 2.2 => 5120) says otherwise (but I can't run the tests there due to some testtools/subunit issue) | 14:26 |
| vila | well, not 5030 but rather 5017.3.33 | 14:27 |
| vila | but what worries me is that we didn't notice it earlier | 14:27 |
| mgz | we did! | 14:27 |
| mgz | spiv filed a bug :) | 14:27 |
| vila | # ? | 14:28 |
| mgz | linked from the mp. | 14:28 |
| mgz | bug 728252 | 14:28 |
| ubot5 | Launchpad bug 728252 in Bazaar "All tests in bzrlib.tests.per_branch.test_bound_sftp are skipped always" [Low,Confirmed] https://launchpad.net/bugs/728252 | 14:28 |
| vila | gha, I parsed that as added by lp :-) | 14:28 |
| mgz | anyway, deleting these certainly doesn't reduce coverage, and I don't think there's much worth salvaging from their logic | 14:29 |
| vila | ... color me confused but how to you know these doesn't reduce coverage ? | 14:30 |
| vila | s/to you/do you/ | 14:30 |
| mgz | we have pretty good unit testing for bound stuff, and we know we have holes for functional testing | 14:31 |
| vila | ha, ok | 14:32 |
| mgz | vila: eg. bt.per_branch.test_branch.TestBound | 14:34 |
| jelmer | it does seem kindof odd to have these kinds of tests in bt.per_branch | 14:35 |
| mgz | we're not testing against remote branches, but that's been true for... ages | 14:35 |
| vila | yeah, yeah, I mis-interpreted :) | 14:35 |
| vila | indeed, looks like very old bb tests | 14:35 |
| vila | approved by the way | 14:36 |
| jelmer | uhoh | 14:38 |
| jelmer | I guess that means https://code.launchpad.net/~jelmer/bzr/remove-branch-history/+merge/97411 will conflict | 14:38 |
| * vila reviewing, was about to mention | 14:38 | |
| mgz | jelmer: you made them run again? | 14:40 |
| vila | nope, he made them keep skipping ;) | 14:41 |
| vila | instead of erroring :) | 14:41 |
| mgz | well, I better win the race then :) | 14:41 |
| jelmer | well, I kept them around but at least avoided the calls to the functions I was removing | 14:42 |
| vila | which is a bit unfortunate :-/ | 14:42 |
| vila | err, I mean, it's unfortunate you spend time on them not knowing they were skipped anyway | 14:44 |
| jelmer | vila: in what way? It should be trivial to resolve the conflict.. | 14:44 |
| jelmer | ah | 14:44 |
| jelmer | well, not the worst thing in the world :) | 14:44 |
| Pikkachu | what a straightforward way to make automated pre-commit (1) validations and/or (2) source code modifications? I'm just thinking of using shell script or the like | 15:06 |
| LarstiQ | Pikkachu: you could look at how the bzr-text-checker plugin works | 15:11 |
| === zyga is now known as zyga-afk | ||
| ams_cs | jelmer: any news? | 15:31 |
| jelmer | ams_cs: I'm still looking, but I'm pretty sure it'll take a couple of days squash this bug. I'm not really familiar with this bit of the code. | 15:38 |
| jelmer | ams_cs: I'll file a bug about it and subcribe you - who are you on Launchpad? | 15:38 |
| ams_cs | ams-codesourcery | 15:38 |
| ams_cs | jelmer: thanks, I was hoping there'd be a work-around :( | 15:39 |
| alansaul | If I push over the top of a respository, can get get the previous one back? | 15:40 |
| jelmer | alansaul: yes, by using "bzr pull -rREV ." | 15:45 |
| jelmer | alansaul: yes, by using "bzr pull -rREV . --overwrite" | 15:45 |
| mgz | one jelmer always tells the truth, and the other jelmer always lies | 15:47 |
| mgz | how can you tell which command to run? | 15:47 |
| alansaul | Lol | 15:47 |
| alansaul | Uh oh | 15:47 |
| mgz | okay, so maybe I'm an idiot, and someone would have pointed the problem out by now if it was actually the case but... | 15:48 |
| mgz | don't the .mo files never actually get installed? | 15:48 |
| mgz | so... all that translation stuff we did for 2.5 isn't actually enabled? | 15:49 |
| vila | mgz: as in: on debian/ubuntu you mean ? | 15:50 |
| mgz | well, I'm looking at the code in setup.py | 15:50 |
| vila | I thought we had bug reports about that and that you even fixed some of them... may be we are 2 idiots :) | 15:51 |
| mgz | it may be that the way debian builds it the files are included, but they don't seem to be in the windows installer | 15:51 |
| LarstiQ | how does gettext on windows work btw? | 15:51 |
| mgz | badly. | 15:51 |
| mgz | ehem... | 15:52 |
| vila | it misses a leg or two may be... | 15:52 |
| mgz | python has it's own implementation, so you just point it at a directory of specially arranged .mo files | 15:52 |
| vila | . o O (post-install tests) | 15:54 |
| mgz | hm, there are .mo files in python-bzrlib | 15:55 |
| mgz | so, however we're building for debian works somehow at least | 15:55 |
| vila | WARNING: gnome-keyring:: couldn't send data: daemon closed connection | 15:55 |
| vila | while running the full test suite | 15:56 |
| vila | does that ring a bell ? | 15:56 |
| mgz | but the code seems to need the build artefact to exist at setup.py invocation to include it | 15:56 |
| mgz | which... implies you must run setup.py twice for it to function | 15:56 |
| jelmer | mgz: translations seem to work here.. | 16:01 |
| mgz | jelmer: how do you build for debian exactly? | 16:02 |
| mgz | the intersection of makefile and setup.py is a little confusing | 16:02 |
| mgz | I'm trying to fix the inplace creation of .mo files but don't want to accidentally break you. | 16:03 |
| jelmer | mgz: don't worry about that | 16:04 |
| mgz | oh but I do :) | 16:08 |
| Pikkachu | sorry, pidgin crashed, who was talking to me? | 16:24 |
| Pikkachu | the text checker plugin seems overkill | 16:24 |
| === zyga-afk is now known as zyga | ||
| LarstiQ | Pikkachu: sure, but the interest for you is the pre-commit machinery? | 16:39 |
| wgz | what was that thing from lifeless about not using "should" in bug titles? | 16:41 |
| wgz | I'm struggling to phrase things without it | 16:42 |
| jelmer | wgz: I think the point was mainly that bug reports should primarily describe problems | 16:43 |
| jelmer | as opposed to a ticket tracker I think | 16:44 |
| LarstiQ | wgz: I find that hard too | 16:45 |
| * LarstiQ looks it up | 16:45 | |
| wgz | I think it was on google+ so good luck ever finding it again... | 16:47 |
| Pikkachu | LarstiQ: I don't want a machinery that's why it's overkill, I want some simple concept | 16:51 |
| Pikkachu | LarstiQ: I don't need to set up and configure any machinery for using an enclosing shell script with the custom rules for each branch, for example | 16:52 |
| Pikkachu | wgz: maybe because it's implied | 16:53 |
| wgz | Pikkachu: that's contradictory | 16:53 |
| Pikkachu | how so? | 16:54 |
| wgz | you want to do something pre-commit, but not have to worry about any machinery for doing things in response to actions? | 16:54 |
| LarstiQ | wgz: actually, it is the second hit on "bug should" in my circles | 16:54 |
| Pikkachu | wgz: I mean for example "Bazaar should grep revisions from diffs" => "Grep revisions from diffs in Bazaar" | 16:55 |
| LarstiQ | wgz: https://plus.google.com/u/0/105660309458564946897/posts/BLhnbgoouXV | 16:55 |
| Pikkachu | wgz: ah you mean my case, ok | 16:55 |
| wgz | LarstiQ: logging in and being in Robert's circle is cheating :) | 16:55 |
| Pikkachu | wgz: it's not contradictory, it's you who's not understanding | 16:55 |
| LarstiQ | wgz: isn't that how you find stuff on g+? ;P | 16:56 |
| LarstiQ | Pikkachu: could you explain some more what you're trying to do? | 16:56 |
| wgz | Pikkachu: I mean, sure you can write a shell script that does something and then calls bzr commit, and use that rather than commit itself | 16:57 |
| Pikkachu | wgz: doing complex things may require a machinery setup or not, making the former case unnecessarily complex, that's what I mean. In this specific case, I don't want to depend on some plugin installed and configured for anyone willing to commit to the branch. This can be completely avoided | 16:57 |
| Pikkachu | wgz: the shell script has the advantage of not requiring any installation, it's self-contained in the branch and ready for use for anyone who branches the repo | 16:58 |
| wgz | provided they remember to run it instead of using commit | 16:59 |
| Pikkachu | wgz: READE.BEFORE.COMMITING :) | 16:59 |
| Pikkachu | wgz: or seriously, for a single file branch, commit.sh will call user's attention unless he's dumb | 17:00 |
| wgz | doesn't seem that different from having an instruction in there to cp commit_hook.py to ~/.bazaar/plugins | 17:00 |
| wgz | but whichever you like. | 17:01 |
| wgz | it would be nice to have a better mechanism for branch-specific thingies, but there are reasons it hasn't happened | 17:01 |
| Pikkachu | wgz: that's why I was looking for a even better solution, but pre-steps like installing and configuring stuff *so that* I can achieve what I want is a non-go. This step can be completely replaced with a shell script already there and ready for using | 17:02 |
| wgz | mostly because the idea of branching something then meaning it automatically runs arbitrary code when you do some operation is scary | 17:02 |
| Pikkachu | wgz: I think a more straightforward solution was if I was able to register a commit hook natively within the branch without any external setup required | 17:02 |
| wgz | there are a few threads on the bazaar list on this topic | 17:02 |
| lamalex | jml, with testtools, what's the proper matcher to ensure something is not None? | 17:03 |
| jml | lamalex: assertThat(x, Not(Is(None))) | 17:03 |
| Pikkachu | wgz: I'd be really surprised that bzr does not support commit hooks though | 17:04 |
| wgz | it does, you just need to manually install them, for the above reason. | 17:04 |
| jml | lamalex: I guess if you wanted to you could define 'IsNotNone = Not(Is(None))' and then do assertThat(x, IsNotNone) | 17:04 |
| lamalex | ha right | 17:05 |
| lamalex | thanks | 17:05 |
| lamalex | i wasn't reading carefully and skipped over Not :P | 17:05 |
| lamalex | whoope | 17:05 |
| Pikkachu | wgz: manually install? how so? | 17:10 |
| wgz | as mentioned, `cp commit_hook.py ~/.bazaar/plugins/commit_hook.py` or similar. | 17:13 |
| wgz | probably want `mkdir -p ~/.bazaar/plugins` first. | 17:14 |
| wgz | if you desperately want to write your checking logic in shell you'd have to use subprocess from the commit hook callback | 17:16 |
| wgz | jelmer: you're the man today. or maybe the page? | 17:22 |
| Pikkachu | wgz: I have no idea what to put within that file | 17:25 |
| Pikkachu | wgz: besides a hook should be a hook not what the hook holds | 17:25 |
| Pikkachu | wgz: a hook is supposed to just trigger something, not be that very something | 17:25 |
| jelmer | wgz: eheh | 17:26 |
| jelmer | wgz: This coming from somebody with surname that's just begging for VCS-related puns? | 17:26 |
| jelmer | *a | 17:27 |
| Pikkachu | wgz: I mean something like $bzr add-hook --pre-commit --system "commit-validation.sh" | 17:27 |
| LarstiQ | Pikkachu: in my hazy memory something like that exists | 17:27 |
| jelmer | Pikkachu: that is what this is, except it is in Python, not shell. | 17:28 |
| wgz | Pikkachu: LarstiQ was trying to help you earlier linking an example | 17:28 |
| Pikkachu | wgz: or $bzr add-hook --post-commit afterCommitting => afterCommitting.py, run it directly from within python instead of catching output/return value from a system executable | 17:28 |
| jelmer | Pikkachu: hooks are installed per-user, perchance using per-branch configuration data. They don't live in the branch itself, for security reasons. | 17:28 |
| Pikkachu | jelmer: if it's like wgz is saying, then it's not really a hook, it's a plugin which catches commit events | 17:29 |
| LarstiQ | Pikkachu: branch.Branch.hooks.install_named_hook('pre_commit', pre_commit_hook, 'text-check') | 17:29 |
| wgz | apart from a slightly different wrapper, I don't see the difference | 17:29 |
| Pikkachu | LarstiQ: 'text-check'? | 17:30 |
| LarstiQ | Pikkachu: that is from bzr-text-checker, it is the analog of your `bzr add-hook --pre-commit text-check.py` | 17:30 |
| Pikkachu | jelmer: what reasons | 17:30 |
| jelmer | Pikkachu: if I download a branch from somewhere, tweak it and then run "bzr commit" I don't want to run arbitrary code that came from that branch. | 17:30 |
| Pikkachu | LarstiQ: no it's not, mine is a command line, yours is python code | 17:30 |
| LarstiQ | Pikkachu: hence, analog | 17:31 |
| Pikkachu | LarstiQ: no | 17:31 |
| Pikkachu | LarstiQ: it may be analog but not in the sense I mean | 17:31 |
| === yofel_ is now known as yofel | ||
| LarstiQ | Pikkachu: and as I also said, I remember there being something to run arbitrary commands for hooks | 17:31 |
| Pikkachu | jelmer: that's easy to fix | 17:31 |
| Pikkachu | LarstiQ: ah thanks...that would be interesting.... | 17:32 |
| jelmer | LarstiQ: there is bzr-shell-hooks, which allows you to define shell commands to run in .bzr/branch/branch.conf | 17:32 |
| jelmer | I haven't updated it in a long time though, so it may have bitrotted | 17:32 |
| LarstiQ | Pikkachu: apparently, it is called bzr-shell-hooks ;) | 17:32 |
| Pikkachu | jelmer: so you're the author? cool... by shell you mean any system command or the underlying shell like bash etc? | 17:33 |
| Pikkachu | is it my imagination or can plugins be installed within a branch? | 17:33 |
| LarstiQ | Pikkachu: you can have configuration for them in a branch | 17:34 |
| jelmer | Pikkachu: plugins can't be installed within a branch, they're installed in the users home directory | 17:34 |
| jelmer | Pikkachu: bzr-shell-hooks installs trivial hooks that can run commands configured in the branch | 17:34 |
| LarstiQ | jelmer: or well, you _could_ point BZR_PLUGIN_PATH at a branch | 17:35 |
| jelmer | LarstiQ: that's true | 17:36 |
| lamalex | hi im trying to write a push hook, and i want to get the author of the last commit | 17:37 |
| lamalex | really i want all the authors for each commit since the point where its parent was branched | 17:37 |
| lamalex | but just the one is fine for now :P | 17:37 |
| jelmer | lamalex: your hook should receive the relevant revision ids, which you can use to retrieve the revision metadata | 17:37 |
| lamalex | anyone have a tip? i see i can get the revision easily, but i dont see what i can actually do with that | 17:37 |
| jelmer | lamalex: The revision object has a .committer attribute which is just a string with the author name and email, and it has a .get_apparent_authors() method which returns a list of strings with authors | 17:38 |
| lamalex | ah nice | 17:38 |
| lamalex | so would i take that from my target branch | 17:39 |
| Pikkachu | LarstiQ: the BZR_PLUGIN_PATH seems a good idea if bzr-shell-hooks is lightweight, this way users would not be required to install it | 17:41 |
| jelmer | lamalex: yeah, usually. since you're sure the revision is present there | 17:42 |
| Pikkachu | lamalex: how are you writing a bzr hook? | 17:42 |
| LarstiQ | Pikkachu: on the other hand, you might not want to forcefully override their plugin path | 17:42 |
| lamalex | Pikkachu, http://doc.bazaar.canonical.com/beta/en/user-guide/hooks.html | 17:42 |
| Pikkachu | jelmer: well, wasn't you who said about security risks? and yet has such a plugin like bzr-shell-hooks? :P | 17:43 |
| lamalex | jelmer, so do i just take that id and make a new revision? | 17:43 |
| LarstiQ | Pikkachu: are you confusing me with jelmer? | 17:43 |
| lamalex | Revision(id).get_apparent_authors | 17:44 |
| jelmer | Pikkachu: that's exactly why bzr-shell-hooks is a plugin, and not part of the core | 17:44 |
| jelmer | Pikkachu: also, I don't actually use bzr-shell-hooks myself.. it was just a quick hack a couple of years ago | 17:44 |
| Pikkachu | lamalex: that looks like non-branch specific | 17:46 |
| Pikkachu | no LarstiQ: "jelmer: Pikkachu: hooks are installed per-user, perchance using per-branch configuration data. They don't live in the branch itself, for security reasons." | 17:46 |
| lamalex | Pikkachu, i have no idea what you're talking about. i'm guessing you pinged me due to a misunderstanding | 17:47 |
| Pikkachu | lamalex: we're talking about commit hooks, coincidently | 17:47 |
| jelmer | lamalex: e.g. something like target_branch.repository.get_revision(id) will return the revision object | 17:47 |
| lamalex | ah, im talking about push hooks | 17:47 |
| lamalex | but totally unrealted | 17:47 |
| Pikkachu | lamalex: I want a commit hook on a specific branch, not wherever I typ bzr commit | 17:48 |
| LarstiQ | Pikkachu: that's easily controllable with configuration | 17:48 |
| * LarstiQ eats dinner | 17:53 | |
| Pikkachu | actually I will explain the exact problem: | 18:16 |
| Pikkachu | I have a pidgin plugin written in C which needs to provide an URL, I didn't care to register a project in LP so the URL is basically [...]/+junk/branch-name. But it happens that this URL is already contained in .bzr as push/submit branch. I want to keep source code always up-to-date with what's in .bzr. Any ideas? | 18:19 |
| Pikkachu | well, actually I think it doesn't matter that much it being in source code, more in the resulting builds... | 18:19 |
| Pikkachu | therefore I could implement this as a build step not a commit hook... but I don't want to use make because I would duplicate code from pidgin build environment which is mostly required anyway in windows | 18:20 |
| Pikkachu | so any ideas? thanks | 18:20 |
| jelmer | re | 18:23 |
| jelmer | Pikkachu: I'm not sure I follow what you mean; are you talking about changing the default locations for 'bzr pull' and 'bzr push' ? | 18:25 |
| Pikkachu | no... nevermind I think I'll resolve the problem myself | 18:32 |
| LarstiQ | Pikkachu: at build time you want to say "this code came from <here>"? | 18:48 |
| Pikkachu | at build time it would be like: | 18:54 |
| Pikkachu | plugin.c => #define URL "@@PLUGIN_URL@@", then | 18:55 |
| Pikkachu | something like using sed for replacing @@@PLUGIN_URL@ from what's within .bzr before compiling it | 18:56 |
| LarstiQ | right | 18:56 |
| LarstiQ | sort of like the `bzr version-info` use case, but with different data | 18:56 |
| Pikkachu | seems like not | 18:57 |
| LarstiQ | Pikkachu: where would the url come from? Is `bzr config parent_location` sufficient? | 18:57 |
| Pikkachu | $ bzr help version-info => Show version information about this tree. | 18:57 |
| Pikkachu | shows, does not change anything | 18:57 |
| LarstiQ | Pikkachu: read on | 18:57 |
| Pikkachu | ah sorry... | 18:58 |
| Pikkachu | nice to know about $ bzr config, I'm not sure if it's submit or push branch, but yes it's either of it | 18:59 |
| Pikkachu | unfortunately the submit/push urls are not available there :( | 19:01 |
| LarstiQ | Pikkachu: if they're not set probably not | 19:01 |
| LarstiQ | Pikkachu: but it depends on your workflow what will be in there | 19:01 |
| Pikkachu | the ones listed are {date} {build_date} {revno} {revision_id} {branch_nick} {clean} | 19:02 |
| LarstiQ | Pikkachu: e.g., in my bzr.dev copy submit_branch is not set, but in my 2.5-fixes branch it is | 19:02 |
| LarstiQ | Pikkachu: ah, in version-info? | 19:02 |
| LarstiQ | right, that is what I meant with "different data" | 19:03 |
| LarstiQ | Pikkachu: I wonder if it makes sense for version-info to include this data | 19:03 |
| Pikkachu | it includes the branch nick already | 19:03 |
| LarstiQ | Pikkachu: yeah, but that is more portable | 19:04 |
| LarstiQ | Pikkachu: it's actually contained in the commit data | 19:04 |
| Pikkachu | I don't get this command though, the example says it will *generate* a C header file? | 19:04 |
| LarstiQ | Pikkachu: in the example the template will give valid C syntax | 19:05 |
| LarstiQ | Pikkachu: and then you'd direct the output to, say, build_info.h | 19:05 |
| Pikkachu | but I don't think it meant to " produce a C header **file**", just a valid header string | 19:06 |
| Pikkachu | anyway, I think I can simply seek into .bzr anyway | 19:07 |
| LarstiQ | Pikkachu: that is more fragile, but if you want, yes | 19:07 |
| LarstiQ | Pikkachu: sure, the example is a valid header *fragment*. The common use of it would be as a single header file though. And of course your template can be more complicated | 19:08 |
| Pikkachu | I think the help message needs a small fix | 19:09 |
| Pikkachu | fragile in which sense, just missing to be there? | 19:09 |
| LarstiQ | Pikkachu: that, and in theory subject to change | 19:10 |
| LarstiQ | Pikkachu: what fix to the help message do you propose? | 19:11 |
| Pikkachu | LarstiQ: change what, the config format/location? | 19:11 |
| LarstiQ | Pikkachu: yeah | 19:11 |
| LarstiQ | Pikkachu: you're poking around in internals | 19:11 |
| LarstiQ | Pikkachu: that's always at ones own risk | 19:11 |
| Pikkachu | LarstiQ: fix: not mentioning it will generate a file, it just generates text output which is supposed to be placed separately into a file (from what I've got of what the command does) | 19:12 |
| Pikkachu | LarstiQ: I just forgot, I can use cd branch; url=$(bzr config push_location) | 19:13 |
| LarstiQ | Pikkachu: or even `url=$(bzr config -d branch push_location)` | 19:14 |
| Pikkachu | oh I tried without -d, cool! | 19:17 |
| Pikkachu | now the problem is: I reuse the whole pidgin build infrastructure, because most of it is required anyway | 19:18 |
| Pikkachu | a pidgin windows build environment contains everything a regular plugin requires, plus the ability to build them if you place them in the correct place | 19:19 |
| Pikkachu | I could duplicate the makefiles and make them point to pidgin root, but I think it's overkill | 19:20 |
| Pikkachu | hmm I just had an idea | 19:20 |
| Pikkachu | something like build.sh: | 20:02 |
| Pikkachu | url=$(bzr config push_location | sed 's/\//\\\//g') | 20:02 |
| Pikkachu | cat plugin.c | sed s/@url@/$url/ > "$devroot/pidgin-$version/pidgin/plugins/plugin.c" | 20:02 |
| Pikkachu | cd "$devroot/pidgin-$version/pidgin/plugins" && make... | 20:03 |
| LarstiQ | Pikkachu: right. | 20:03 |
| LarstiQ | Pikkachu: stylistically I would go for including a header instead of rewriting plugin.c, but that's a small niggle | 20:04 |
| Pikkachu | LarstiQ: it's overkill to split the plugin into a separate files, and it doesn't rewrite the plugin itself, but the copy from which it will be built | 20:08 |
| Pikkachu | the above would be the same as copying the plugin to there then sed -i | 20:09 |
| Pikkachu | hmm actually I could use your suggestion to avoid build.sh not being used (if one copy the file to there and $ make it, then the url will remain as "@url@" in the binary) | 20:11 |
| * LarstiQ nods | 20:11 | |
| Pikkachu | if I use #include "plugin.url.h" then 'URL' instead of @url@, compilation will fail if build.sh is not used and no header is manually created...sounds interesting, thanks for the tip LarstiQ | 20:14 |
| Pikkachu | thanks all for the constructive discussion! | 21:19 |
| poolie | hi all | 21:45 |
| poolie | hi lifeless | 21:45 |
| * jelmer waves to poolie | 22:42 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!