| bob2 | why did you version things you don't want to keep | 00:08 |
|---|---|---|
| === lifeless_ is now known as lifeless | ||
| mgz | morning | 08:09 |
| jam | hi mgz | 08:25 |
| jelmer | jam, mgz: hi | 08:57 |
| mgz | morning jelmer, feeling any better this morning? | 09:01 |
| jelmer | mgz: Somewhat, fever seems to be gone but still having an aching head. | 09:02 |
| mgz | cut it off! | 09:02 |
| fullermd | Cut off his head, or cut off his body? | 09:03 |
| mgz | just the achy bit | 09:04 |
| vila | doh, sorry about that jelmer, I didn't know that kind of virus can propagate via IRC... | 09:12 |
| jelmer | :P | 09:12 |
| mgz | vila: on bug 996401 | 09:16 |
| ubot5 | Launchpad bug 996401 in Bazaar "'bzr config' fails to display config templates referring to "unknown" options" [High,Fix released] https://launchpad.net/bugs/996401 | 09:16 |
| vila | yes ? | 09:16 |
| mgz | as far as I can see, there's still no way for gordon to store the line needed for the merge tool without config trying to expand things that don't exist when just using `bzr config OPTION`? | 09:16 |
| vila | let's split your remark into 1) no way to store 2) just using bzr config OPTION | 09:17 |
| vila | 1) is not true, there is no expansion when storing a value | 09:17 |
| mgz | there's no way of quoting the { to say "this is a { in the option, not an config template"? | 09:17 |
| vila | 2) is not applicable for a template that will provide the missing options | 09:18 |
| vila | there is no need for quoting | 09:18 |
| vila | the trick is that most options are expanded by default, but *some* should not (templates for examples) | 09:19 |
| mgz | currently it seems like any config option that might have {} in it will behave oddly in some circumstances | 09:19 |
| vila | hehe, name one :) | 09:19 |
| mgz | well, the merge tool, it's using {} for its own templating, not done by config | 09:20 |
| vila | but that's a template so when dealing with config you should ask for no expansion | 09:20 |
| vila | that's the point of templates... | 09:20 |
| mgz | but it's not a *config* template, it's a string config stores that happens to be a template | 09:21 |
| vila | config provide (now, not when gordon wrote his stuff) .expand_options() for exactly this purpose | 09:21 |
| mgz | ah, so you now want the config lookup to do the resolution? | 09:22 |
| vila | dig the review of gordon's proposal, it was a known missing feature and I didn't want to block him | 09:22 |
| mgz | that's a little complicated by merge needing to know what arguments are present to know what files to create on disk | 09:22 |
| mgz | as different merge tools expect different inputs | 09:22 |
| vila | no, templates should use expand_options(string, env={the needed additional options that are not config options}) | 09:23 |
| vila | the additional options do not need to be registered, each template can define whatever it sees fit | 09:24 |
| vila | the only drawback is that 'bzr config TEMPLATE' needs to specify --all to *avoid* expansion, small price to pay for an edge case IMHO | 09:25 |
| mgz | right, but merge tool needs to know what the additional options are specifically (which vary for different merge tools), before doing work | 09:26 |
| vila | err, it cannot deduce unknown options from thin air, there is only a limited supported set | 09:26 |
| vila | it's unrelated to config but specific to mergetool | 09:27 |
| mgz | right | 09:27 |
| mgz | so, mergetool should really have a way of just escaping the templating entirely... | 09:27 |
| vila | it has, config.get('template', expand=False) | 09:27 |
| vila | and I'm pretty sure it already uses it | 09:28 |
| mgz | this is an edge case, but having magicstring syntax without a way to say in the string that the next bit isn't syntax is odd | 09:28 |
| vila | YAGNI | 09:28 |
| vila | so better keep that stuff simple | 09:28 |
| mgz | it'd be like having \0 mean something but \\0 meaning \ + NUL rather than \ + 0 | 09:29 |
| vila | yeah, I know the rationale and generally dislike the absence of escape notation, but there is just no need here | 09:29 |
| vila | at least I've yet to see a case where it's needed | 09:30 |
| mgz | I find the story from the question linked to that bug a pretty persuasive one, and it's not fixable from the mergetool side | 09:37 |
| jelmer | mgz: still there? | 09:37 |
| vila | mgz: url ? | 09:37 |
| vila | mgz: sry, missed 'from the bug' | 09:37 |
| mgz | https://answers.launchpad.net/bzr/+question/196441 <- ftr | 09:38 |
| vila | right, the misunderstanding there is that template can be used with 'bzr config TEMPLATE' as said above, that's an edge case where you should indeed use 'bzr config --all TEMPLATE' | 09:39 |
| vila | why will an escape mechanism address that ? | 09:40 |
| vila | you may as well say that templates should use a different reference format | 09:40 |
| vila | and a different expansion framework | 09:40 |
| mgz | but from the user perspective, that series of steps seems sensible, but the output makes it look like you've messed up | 09:41 |
| vila | doc bug then | 09:42 |
| mgz | it's not really, why should they read documentation for that? | 09:42 |
| vila | where did they hear about mergetool ? | 09:42 |
| vila | how would they find which parameters they need to provide to their new mergetool without a description of {this} {other} {result} {tmp-whatever-I-can-never-remember-that-one} | 09:43 |
| mgz | what do we add to <http://doc.bazaar.canonical.com/bzr.2.5/en/user-reference/configuration-help.html#bzr-mergetool-name> to make it clear that using mergetool breaks config? | 09:44 |
| vila | oh come on, using mergetool do not break config, mergetool *cannot* be used without config | 09:45 |
| vila | and you just found where the fix should go :) | 09:45 |
| vila | also note that this piece of doc mentions that some arguments need to be quoted (yeah, a different issue than the config escape mechanism) | 09:46 |
| vila | I mean, I'd rather add an escape mechanism to config than deal with users confusion when they need to use it :) | 09:47 |
| vila | bah, bzr.mergetool.kdiff3 is not even registered :-/ | 09:50 |
| vila | mgz: https://pastebin.canonical.com/74784/ | 09:54 |
| mgz | vila: in unrelatedness, the progress bar config option is nice | 09:56 |
| vila | in itself you mean ? Or how the proposal fixes the bug so trivially ? | 09:57 |
| mgz | both! | 09:57 |
| === mmrazik is now known as mmrazik|lunch | ||
| vila | right, you know, my new config proposal started with: "Not all needs can be addressed by the default values used inside bzr and | 09:58 |
| vila | bzrlib, no matter how well they are chosen (and they are ;)." | 09:58 |
| vila | progress bar is the canonical example: we went through several iterations to dwim... but in the end, there are always edge cases where the user should be able to set the Right Thing | 09:59 |
| vila | ... and without needing to write a single line of code | 10:00 |
| mgz | vila: so, apart from "the following will (rightly) break"... that doc change is okay | 10:03 |
| vila | hehe | 10:04 |
| vila | so s/(rightly)// ? | 10:04 |
| vila | https://code.launchpad.net/~vila/bzr/mergetool-doc/+merge/125150 | 10:04 |
| vila | by the way | 10:04 |
| mgz | I'm not sure you want to give the broken example at all | 10:05 |
| fullermd | If we don't give broken examples, how will people know it's open source software? | 10:05 |
| vila | well, then the working one makes less sense as --all requirement is less clear | 10:06 |
| vila | fullermd: pff | 10:06 |
| mgz | if we don't give "you're doing it wrong you silly user" documentation, how will people know... | 10:06 |
| fullermd | ... that they're using git? But this is for bzr, isn't it? | 10:07 |
| vila | well, I'm pretty sure simone (the guy/girl) asking the question read that doc you cited and mergetool templates can be tricky... | 10:07 |
| * fullermd has got his snark burner running on overdrive tonite. | 10:07 | |
| vila | lunch break, bbl, daughters hate it when they prepare it and I'm late ;) | 10:08 |
| mgz | girl I think, but that sounds so much more condecending that guy | 10:08 |
| mgz | there's not a good equivalent, so guy should just become gender neutral | 10:08 |
| fullermd | "motile sack of mostly water"? | 10:09 |
| vila | I think simone can be a male italian first name | 10:10 |
| fullermd | Anyway, it's English; the masculine has always been the gender mixed-or-indeterminate form for pronouns, at least up 'till the last couple decades of rampaging. | 10:11 |
| mgz | ...blasted continentals, I'm still not used to andrea being a male name, or anne | 10:11 |
| fullermd | Many years ago, in my youth, I knew this guy named Jamie, who was dating this girl named Jamie. | 10:12 |
| mgz | everyone needs sensible, obviously masculine names, like matthew. | 10:12 |
| fullermd | (I'm pretty sure that was the _only_ reason they dated, briefly as it was) | 10:12 |
| fullermd | No, only the most handsome and brilliant people should have named like Matthew. | 10:13 |
| bob2 | haha | 10:13 |
| bob2 | I knew a couple of James's | 10:14 |
| ant384 | Hello. | 10:43 |
| mgz | hey | 10:44 |
| ant384 | Just starting with Bazaar. I set up a repository on a server, checked out a trunk, and now I'm playing with stuff. I managed to get info on all subjects except creating a header with keywords such as $Date$, $Author$, etc. I installed bzr-keywords, but can't figure out how to make it work. I used the version-info command to generate a version.py, but don't know where to place it. Please help. :) | 10:45 |
| mgz | so, in general keywords are a bad habit from older vcses that you want to drop for other ways of doing things with a dvcs | 10:46 |
| fullermd | For the former, the keywords plugin functions mostly at a PoC level. For the latter, it depends what you want to do with the version.py ;) | 10:47 |
| mgz | putting that info into your build system rather than your versioned source is generally advisable | 10:47 |
| ant384 | I'm only working on python and shell scripts so far, so I'd like to have a header in them, in order to know what I'm testing / working on. Is it a bad idea in itself ? | 10:50 |
| mgz | ant384: yes, you can just get that info from the vcs itself | 10:51 |
| mgz | with a fancy editor, you can even have a call out to bzr to display that stuff to you alongside the file | 10:51 |
| mgz | fullermd may have suggestions on that front | 10:51 |
| ant384 | So if I have a script that does X things on serveral machines, how do I make sure it's updated to the last version, if all I see is the code itself, with no version information ? | 10:52 |
| fullermd | In probably a good 75% or so of the cases where you'd use keywords in CVS, there are better choices in modern systems. | 10:52 |
| fullermd | In the other 25 or 20 or 10 or whatever percent... well, you suffer. | 10:52 |
| mgz | ant384: so, for example in that case, seeing the revno/date of last commit to the branch you're working on by the file would solve that | 10:54 |
| === mmrazik|lunch is now known as mmrazik | ||
| ant384 | So simply compare the script creation date with the date of the last commit to the branch ? | 10:58 |
| fullermd | That wouldn't tell you anything definitive, at least absent very particularly constrained workflows. | 10:59 |
| fullermd | One common simple setup would just be that you don't throw the script around by itself, you just have real branches or checkouts or whatever of it on each system, so you have all the VCS info right there to see. | 11:00 |
| ant384 | Aiee. | 11:00 |
| ant384 | Well, here's my current situation: maintaining / developing some bash and python scripts for my employer, aside from my real job. They're generally unique to the machine they're deployed on. I "develop" on my workstation, and use "header" type information in each file. Now I got a server that's usable as a central repository for code (among other things). | 11:02 |
| ant384 | The idea was to get everything on that server in Bazaar, then checkout scripts when I work on them, commit, and then deploy. | 11:03 |
| ant384 | Are you suggesting that it's a sane (you can tell I'm not really a programmer :) ) solution to check out each script on each machine it's used on ? | 11:03 |
| mgz | what would you do otherwise, scp? | 11:04 |
| fullermd | It can be. A very situational thing. | 11:04 |
| mgz | the real question is whether it's sane to have a branch per independant script | 11:04 |
| mgz | and I do do that for some things (again, with a few helpers to making using bzr-as-rcs a bit nicer) | 11:04 |
| ant384 | Some of the scripts get very large. I would love to use a versioning system to track changes and plan work. | 11:05 |
| fullermd | The alternative, assuming the keywords PoC isn't sufficiently there for you (which I expect it isn't) is that the "deploy" process has to do whatever rewriting to stash the info somewhere convenient. | 11:05 |
| ant384 | I see. | 11:06 |
| fullermd | (e.g., with sed(1), as I do in one project) | 11:06 |
| ant384 | So instead of linking version info to the source file, I should link it to the deployment process, and only generate it as needed. | 11:06 |
| mgz | yes, or just have checkouts as your deployment | 11:07 |
| ant384 | I'll give it some more thought. Thanks a lot for the opinions, guys. :) | 11:09 |
| === zyga_ is now known as zyga | ||
| === mmrazik is now known as mmrazik|otp | ||
| === mmrazik|otp is now known as mmrazik | ||
| === beuno_ is now known as beuno | ||
| === Guest70664 is now known as slank | ||
| === slank is now known as Guest79513 | ||
| SamB_MacG5 | okay, I've got a run_bzr()-based test, and I want to look at the output of a bzr command for debugging purposes ... what can I stick into the test temporarily to do that ? | 13:48 |
| SamB_MacG5 | hmm, "assert False" after a selft.run_bzr *almost* works, but it has "\n"s instead of actual newlines | 13:48 |
| mgz | so, run_bzr returns (out, err) as strings | 13:51 |
| mgz | one way to develop is to do `out, err = self.run_bzr(...); self.debug()` | 13:51 |
| mgz | which will drop you into pdb and you can look at the locals | 13:52 |
| mgz | or you can `self.assertEqual("", out)` and work from there | 13:52 |
| SamB_MacG5 | ah, cool | 13:58 |
| SamB_MacG5 | darn, something is wrong with "bisect run" ... | 14:21 |
| * SamB_MacG5 wonders if he can have broken it? | 14:22 | |
| mgz | SamB_MacG5: more specifically? or have you worked it out? | 14:53 |
| SamB_MacG5 | Well, at least, I'm confused about my attempts to write a grep-using testcase for the -r feature I'm adding ... | 15:00 |
| mgz | SamB_MacG5: if you stick some code in a branch or pastebin I'd be happy to give pointers | 15:01 |
| mgz | the hiccough is probably that the current tests aren't that great | 15:02 |
| SamB_MacG5 | well, it doesn't seem to make a difference whether I tell it to run "grep one test_file_append" or "grep -v one test_file_append" in my attempt at a test ... | 15:04 |
| SamB_MacG5 | lp:~naesten/bzr-bisect/683822-bisect-start-range-argument/ and https://gist.github.com/3750150 | 15:05 |
| SamB_MacG5 | and yes, I know it's kind of silly to use gist for bzr stuff, but I had an Emacs command for it handy, so ... | 15:05 |
| * SamB_MacG5 has to run | 15:05 | |
| * SamB_MacG5 will check back for tips later, though: thanks for offfering! | 15:06 | |
| SamB_MacG5 | mgz: so long! | 15:07 |
| mgz | later! | 15:08 |
| mgz | SamB_MacG5: so, run_bzr doesn't actually start a shell subprocess, so you can't just use grep | 15:12 |
| mgz | bisect has support for running a script, but that's as a seperate command | 15:12 |
| mgz | ...which you're using, but not with an actual script, but directly? | 15:13 |
| mgz | bisect is somewhat arcane here, what's it actually doing | 15:13 |
| mgz | SamB_MacG5: your grep is just wrong I think, you want it to only match on rev 3 but not rev 4 and 5 | 15:35 |
| mgz | but test_file_append alwasy has 'one' in it... it gets appended to, not replaced | 15:36 |
| mgz | SamB_MacG5: and more specifically, -v is not useful because there's always at least one line that doesn't match -> returncode 0 | 15:42 |
| ls3_ | Hello. How can I find out where 'bzr push' is going to push to by default? (ie with no push args) | 16:03 |
| LeoNerd | bzr info | 16:04 |
| ls3_ | ah wow, thanks. | 16:04 |
| mgz | what LeoNerd said, or `bzr config push_location` for just that | 16:05 |
| ls3_ | Do you mean 'parent_location' ? I get push_location does not exist. | 16:05 |
| mgz | right, that. :) | 16:06 |
| mgz | hm, no, push_location | 16:06 |
| mgz | but it might not be set | 16:06 |
| mgz | in which case `bzr push` will tell you that | 16:07 |
| === deryck is now known as deryck[lunch] | ||
| === deryck[lunch] is now known as deryck | ||
| SamB_MacG5 | mgz: oh, duh, always one line that doesn't match ... | 18:16 |
| SamB_MacG5 | thanks! | 18:16 |
| SamB_MacG5 | oh, he's gone | 18:17 |
| jelmer | ... and there's no wgz atm :( | 18:17 |
| SamB_MacG5 | anyway, yes, the documentation for "bzr bisect run" should mention that the command is run through the shell... | 18:18 |
| === yofel_ is now known as yofel | ||
| === Guest79513 is now known as slank | ||
| === Lasall- is now known as Lasall | ||
| delinquentme | hey all .. I want to add a single file to a commit | 23:16 |
| delinquentme | and bzr decided to add every file that was changed to the commit | 23:16 |
| delinquentme | i used $ bzr add /path/to/file.rb | 23:16 |
| delinquentme | and then $ bzr commit -m "som merssage" | 23:17 |
| delinquentme | then i get this: https://gist.github.com/60ff7b7c9c6f886e1946 | 23:18 |
| delinquentme | am I doing something wrong here? | 23:18 |
| SamB_MacG5 | delinquentme: bzr assumes you want to commit everything unless told otherwise | 23:18 |
| SamB_MacG5 | lately I've been using the qcommit command, which lets you uncheck what you don't want | 23:19 |
| delinquentme | how can I only add files which I specify to be committed | 23:19 |
| SamB_MacG5 | "bzr help commit" probably says? | 23:20 |
| delinquentme | looking ... | 23:21 |
| delinquentme | and how about to drop back to the previous commit? | 23:21 |
| delinquentme | something akin to $ git reset --hard HEAD^ | 23:22 |
| * SamB_MacG5 forgot | 23:23 | |
| delinquentme | bzr help qcommit giving me nothing | 23:26 |
| delinquentme | in the event of a conflict | 23:34 |
| delinquentme | which file is the one that is .moved | 23:34 |
| delinquentme | the one which was previously committed to the repo is the normal one ... right? | 23:35 |
| delinquentme | and the local copy which differed... is renamed with .moved | 23:35 |
| fullermd | As for the former, you're reading 'add' in a git way. In bzr it just adds the file to the list of those being tracked. If you want to commit only a subset, you list them in the commit command line. | 23:39 |
| fullermd | "previous committed to the repo" is pretty ambiguous. .moved comes about because a new file (dir, etc) was created independently in the local and the remote branch. I believe the one called .moved is the one that came about locally. | 23:40 |
| lifeless | git add really should be git stage | 23:41 |
| lifeless | calling it add just breaks folks brains if they use svn/cvs/bzr/hg/monotone/tla/darcs | 23:42 |
| fullermd | Sure, but it's great for those p4 people! | 23:42 |
| lifeless | all three of them? | 23:42 |
| fullermd | It's a question of quality over quantity. At least, it better be... | 23:43 |
| bjp | is there a way to specify a revision range after (but not including) a tag? | 23:52 |
| bjp | like -rtag:sometag.. without the tag | 23:53 |
| bjp | *without the tagged revision | 23:53 |
| delinquentme | fullermd, example of the " If you want to commit only a subset, you list them in the commit command line. " | 23:59 |
| delinquentme | ? | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!