| vila | hi all ! | 07:44 |
|---|---|---|
| === vila changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | ||
| jelmer | yo vila | 07:58 |
| vila | jelmer: hey ! | 07:58 |
| poolie | hi all | 08:03 |
| jelmer | hi poolie | 08:07 |
| mgz | morning all | 08:09 |
| vila | mgz: hey | 08:09 |
| poolie | hi mgz, jelmer | 08:10 |
| poolie | :) | 08:10 |
| vila | mgz, jelmer: 'bzr st' says 'bzrlib/locale' is unknown, any idea where it's coming from ? | 09:28 |
| mgz | the build | 09:28 |
| mgz | it should probably be added to ignores | 09:28 |
| mgz | mo files get put in there | 09:29 |
| mgz | (otherwise it's a pain to test locale stuff in place) | 09:29 |
| vila | ooooh, and a full test suite run triggers a build... | 09:29 |
| vila | bad isolation :-/ | 09:30 |
| vila | ok, thks | 09:30 |
| vila | yeah, probably worth adding it to .bzrignore | 09:30 |
| mgz | hm, yeah, selftest really shouldn't build mo files in place | 09:30 |
| jelmer | mo files mo problems | 09:30 |
| vila | LOL | 09:31 |
| vila | jelmer: in other words: config options are good to test command-line parameters before making them official, I'm far from convinced that --overwrite-tags should be an official cmdline parameter (which is totally different from being convinced that *right* now (including 2.5) we *need* a way to overwrite tags) | 09:51 |
| mgz | vila: do you have any idea why doing -Olaunchpd_username= isn't enough to revert from bzr+ssh to http? | 09:52 |
| mgz | also, is there a way of unsetting a value, rather than using an empty string? | 09:52 |
| fullermd | launchpd? | 09:52 |
| mgz | ...irc tyop only | 09:53 |
| fullermd | Oh, right, I missed that you were talking to vila. Yeah, gotta keep it in his dialect ;p | 09:53 |
| vila | mgz: the missing 'a' is a typo right ? | 09:54 |
| vila | mgz: ha ! authentication.conf ! lp-login creates a section there :-/ | 09:54 |
| vila | crap, read the log before replying vila... | 09:55 |
| mgz | aha, and authentication.conf is still a special case. | 09:56 |
| jelmer | vila: I disagree, if we add a configuration option for something before making it official then that means that we have to update all format implementations twice, plus all of the skew that comes with API changes | 09:58 |
| vila | jelmer: meh, your're assuming it will become official... | 10:02 |
| jelmer | vila: you did :) | 10:02 |
| jelmer | 10:51 < vila> jelmer: in other words: config options are good to test command-line parameters before making them official, | 10:02 |
| vila | test doesn't imply success | 10:03 |
| jelmer | what do you want to test in that case? | 10:03 |
| vila | that pull and push are the right place to add the parameter for example which is not obvious 'bzr tags' or something along the way to versioned tags may well be better suited | 10:04 |
| vila | ghaa, miss punctuation | 10:05 |
| vila | that pull and push are the right place to add the parameter for example ; which is not obvious. 'bzr tags', or something along the way to versioned tags, may well be better suited | 10:05 |
| vila | if push and pull is not appropriate your arguments about API skew will then apply to the removal | 10:06 |
| * fullermd finds the whole discussion a little bizarre... | 10:06 | |
| vila | fullermd: see https://code.launchpad.net/~jelmer/bzr/overwrite-tags/+merge/91277 and https://code.launchpad.net/~jelmer/bzr/overwrite-tags/+merge/94551 | 10:07 |
| jelmer | vila: I really don't see why this would need be tested in that way | 10:07 |
| jelmer | vila: if you think pull and push are inappropriate for this option, then I think it's fair to bring that up during review | 10:07 |
| jelmer | vila: I don't see why this is something we would want to test and then perhaps later revert, or why 'bzr tags' might be more appropriate | 10:08 |
| vila | without a better definition of versioned tags, I can't | 10:08 |
| fullermd | Oh, I've seen the discussion. It just seems wacky. | 10:08 |
| jelmer | fullermd: what's wacky about it? | 10:08 |
| vila | since there is a way to bring in the feature *without* adding a parameter that may be removed later, I prefer the less intrusive path which address the issue now and leave us room to decide later | 10:09 |
| fullermd | The whole idea of using the "config option" tool for the "vary how the command works this one time I invoke it" job leaves me wanting a drink. | 10:09 |
| jelmer | vila: I don't see why the configuration option leaves us more room to remove it later. | 10:09 |
| vila | removing the cmdline param | 10:10 |
| jelmer | vila: what about removing the cmdline param? | 10:10 |
| jelmer | removing the cmdline parameter and configuration option both break backwards compatibility. | 10:10 |
| vila | not adding the cmdline param means we won't have to remove it | 10:11 |
| jelmer | vila: but then we'll have to remove the configuration option | 10:12 |
| jelmer | Using a configuration option is just a slightly implicit way of passing the information along from the command-line to the underlying code | 10:12 |
| vila | which is less intrusive, opt-in and less work overall than a cmdline param in term of support down the road | 10:13 |
| jelmer | vila: how is it any less intrusive *or* opt-in? | 10:13 |
| jelmer | in both cases the backends will need to be updated to support the new functionality | 10:14 |
| vila | but not the front-ends | 10:14 |
| jelmer | the frontend change is trivial, and without it it is really hard to discover this functionality | 10:14 |
| vila | you may consider it trivial but its fallouts are not | 10:16 |
| jelmer | which fallouts? | 10:16 |
| vila | If we have --overwrite-tags, I can argue that during pull in a dirty wt, I also want an option that will overwrite my local changes if they conflict with the versions I'm pulling | 10:17 |
| vila | there is no end to that | 10:17 |
| vila | --overwrite-tags is a work-around for lack of versioned tags, can we agree on that ? | 10:18 |
| jelmer | vila: partially, overwrite tags makes perfect sense with versioned tags too | 10:18 |
| jelmer | vila: I don't see how a working tree is relevant here, tags are associated with branches | 10:19 |
| vila | if you go that route, --take-other on bzr pull also makes perfect sense, where do you draw the line ? | 10:19 |
| vila | the working tree analogy is relevant in the context of versioned tags where bzr provides a way to resolve tag conflicts | 10:20 |
| vila | --overwrite-tags is a simplification, I may well cherry pick which tags I want to override | 10:20 |
| jelmer | vila: so is --overwrite, which currently *already* overwrites tags | 10:20 |
| fullermd | That whole really sounds like a perfect-enemy-of-the-good sort of argument. | 10:22 |
| fullermd | Pull is already a bit of a mess of confused branch-vs-wt actions. This sorta continues in that vein and doesn't really make it better. But I'm not sure that it really makes it _worse_. | 10:22 |
| vila | jelmer: no, --overwrite will works the same with versioned tags, it resets the branch tip | 10:22 |
| jelmer | vila: it would also reset the tags, I hope | 10:23 |
| vila | jelmer: me too | 10:24 |
| jelmer | vila: so I don't see why it's so odd to also allow people to *just* overwrite the tags, not the branch tip | 10:24 |
| vila | because it's only one out of several choices which only make it more obvious that the UI is broken until we have versioned tags | 10:25 |
| * quicksilver wonders if jelmer recommends any *particular* drink for working with bzr config options. | 10:26 | |
| vila | so rather than adding one option now and another (or several later), I'd rather say: look, we know we have an issue there, this option will address the most obvious shortcoming *until* we have a more complete solution | 10:26 |
| jelmer | vila: by that reasoning, we should have never added the current unversioned tags in the first place | 10:27 |
| vila | no | 10:27 |
| vila | :) | 10:27 |
| vila | tags are they exist today address valid uses cases | 10:28 |
| jelmer | vila: This still brings us down to the same basic question: how is a configuration option less permanent than a command-line option? | 10:28 |
| vila | because we can say so :) | 10:28 |
| jelmer | vila: We can do so with a command-line option too. | 10:29 |
| jelmer | quicksilver: :) | 10:29 |
| vila | it doesn't carry the same weight | 10:29 |
| jelmer | vila: Why not? | 10:30 |
| vila | and doesn't have to be tighted to a particular command | 10:30 |
| vila | if you call it tags.overwrite for example it can be used by both pull and push today and by tags tomorrow and will better reflect the feature itself rather than the command behavior | 10:31 |
| jelmer | vila: I don't see how you would want to use this with 'bzr tags' tomorrow, even with versioned tags. Why does that matter if people are going to specify this on the command-line to push and pull? | 10:32 |
| vila | jelmer: bzr tags or whatever command we add to deal with versioned tags | 10:33 |
| jelmer | vila: why does that even matter? It will still require code changes to the backends *and* it will require users to change their use of bzr, both with a command-line option and with a configuration option. | 10:34 |
| jelmer | I'm sorry, this whole point just seems surreal to me. | 10:35 |
| vila | we're running into circles if you keep ignoring my objection about adding a parameter to commands which shouldn't have to handle tags in the first place :-/ | 10:36 |
| vila | the distinction seems pretty clear to me: an option makes it clearer that we working around an issue, it feels dirty to add official parameters for each and every workaround | 10:37 |
| vila | whatever is needed for the front-ends, the backends should be updated to address the issue, split that part and the issue is addressed | 10:37 |
| mgz | vila: tags are clearly a special case, and pull isn't drowning in switches | 10:37 |
| vila | mgz: good, let's not start then | 10:38 |
| mgz | in many ways I think a config option is worse | 10:38 |
| mgz | this is likely to be something most people will only want to do on occasion | 10:38 |
| mgz | whereas encouraging them to turn it on all the time without thinking is likely to lead to mistakes | 10:38 |
| vila | hold on, where did I encourage anyone to turn it on all the time ? | 10:39 |
| fullermd | In the term 'config option'. | 10:39 |
| mgz | by suggesting a config option rather than a switch, that's the direction we're poking people in | 10:40 |
| vila | .. which doesn't say anything about the default value :) | 10:40 |
| fullermd | It may functionally be a distinction without a difference, but it's still conceptually a distinction. | 10:40 |
| mgz | it's an encounter problem once, set config option, forget you did it, kind of scenario | 10:40 |
| mgz | whereas with a switch you need to pass it every time you want the different effect | 10:40 |
| vila | -O is not persistent and should be the recommended use | 10:41 |
| vila | mgz: this perfectly applies to -O | 10:41 |
| mgz | we have this even with https cert optionss where we suggest -O in errors but people are unsuprisingly setting the option globally | 10:42 |
| vila | the distinction I make between the cmdline param and the option is that the cmdline param says: we will support it for this cmd, whereas the option is more blurry about being tighted to the cmd or not | 10:42 |
| vila | mgz: that's yet another bug (already filed) that we don't provide a way to set it on a per-host basis, different use case | 10:43 |
| jelmer | vila: a configuration option should apply to all things where it is relevant | 10:43 |
| vila | jelmer: exactly, that doesn't mean the set of things can't evolve | 10:44 |
| jelmer | vila: the point is, 'bzr pull' and 'bzr push' already deal with tags. my branch isn't changing anything about that, it just gives users a bit more control over how tags are handled. | 10:45 |
| mgz | I think --overwrite-tags is the right thing for now, and it's not that hard to deprecate switches if we completely change how tags work in the future, especially one that basically becomes a noop | 10:45 |
| vila | and that's my objection: we don't know yet whether it will always apply to push/pull and we already know it doesn't really fit well there, it's the only reasonable place today | 10:46 |
| jelmer | vila: sure, but how is a configuration option better in that regard? | 10:46 |
| vila | read above | 10:47 |
| mgz | my objection is the reverse, the mp is too worried about how things may change, rather than just fixing the tags problem :) | 10:47 |
| jelmer | vila: if we remove tag dealing from bzr pull then whether users use 'bzr pull -Otags.overwrite=true' or 'bzr pull --overwrite-tags', we'll have to break backwards compatibility. | 10:48 |
| vila | jelmer: and it will be less work for an option than for a cmdline param, that's the point | 10:50 |
| vila | well, one point | 10:50 |
| vila | the other being that we won't have added an option fully knowing it wasn't the right place for it | 10:50 |
| jelmer | vila: we probably don't want to silently ignore that option but print some sort of warning; I'm not sure if a configuration option is easier in that regard | 10:50 |
| vila | grr a cmdline param not an option | 10:51 |
| jelmer | vila: either way, it shouldn't really be a big difference either way | 10:51 |
| jelmer | s/either way// | 10:51 |
| mgz | vila: but you also would want a -Ooverwrite=true config option? That's asking people to make mistakes. | 10:51 |
| mgz | this isn't a configy thing. | 10:51 |
| vila | mgz: no, --overwrite makes perfect sense for a branch | 10:52 |
| vila | there were discussions when tags were introduced with concerns about leaks, this is one more leak | 10:52 |
| vila | people are already sometimes confused because you can pull (or even push locally) into a dirty tree, this will add to the confusion | 10:54 |
| jelmer | vila: pull and push *already* deal with tags, this doesn't make it any worse, it just gives users more control. | 10:54 |
| vila | using an option recognizes that we know this is a workaround | 10:55 |
| mgz | I'm with fullermd, I don't really thing it makes the current status worse | 10:55 |
| vila | well, obviously we're not making progress and we can't reach a consensus, to me, this means there is something wrong. I don't see what I can add to clarify further :-/ | 10:58 |
| fullermd | That generally means we're all pointing at somewhat different things as being The Problem. | 11:00 |
| fullermd | There _are_ various differences in the implications of removing command line options vs. config options. I don't think they're particularly relevant though (partly because I just don't see how removal gets on the forseeable horizon anyway). | 11:02 |
| fullermd | But I'm outside the circle that really gets a say in it, and I've got a meeting in ~9 hours I really should get some sleep before, so... | 11:06 |
| vila | fullermd: enjoy your sleep ! | 11:07 |
| jelmer | fullermd: Thanks for trying to help resolve it | 11:07 |
| jelmer | We indeed don't seem to be making much headway | 11:07 |
| vila | fullermd: you have a say in it | 11:08 |
| jml | if I want to fetch a get a local tree for a particular revision of a remote branch, what's the fastest way to do that? checkout? export? | 12:01 |
| jelmer | jml: it should be export | 12:03 |
| === Ursinha` is now known as Ursinha | ||
| === beuno is now known as beuno-lunch | ||
| === beuno-lunch is now known as beuno | ||
| === yofel_ is now known as yofel | ||
| === 17WAAYI1Q is now known as zyga | ||
| === r0bby is now known as robbyoconnor | ||
| mgrandi | hi, wondering if anyone could answer a question about bzr-git for me : | 19:18 |
| jelmer | mgrandi: sure | 19:30 |
| mgrandi | so, you probably remember i was pushing a bzr branch to github | 19:31 |
| mgrandi | when i branched it originally, it had some git commits, then i made some in bzr | 19:31 |
| mgrandi | and those commits had bzr revision ids | 19:31 |
| mgrandi | and then when i pushed to github, those were replaced with the git-v1:<sha> revision ids | 19:31 |
| mgrandi | i was just wondering if the bzr ones were saved somewhere or they revision ids just changed when you start pushing to a git repo? | 19:32 |
| jelmer | mgrandi: the original revisions are still in the repository, just no longer in the branch | 19:34 |
| mgrandi | so the branch essentially just has two sets of revisions, the bzr ones and the git ones? | 19:34 |
| mgrandi | err repo* | 19:34 |
| jelmer | mgrandi: the new revisions are created by fetching the changes that were pushed into git back into bzr | 19:34 |
| jelmer | mgrandi: the bzr ones are no longer used after 'bzr dpush' | 19:35 |
| jelmer | mgrandi: you can keepusing the bzr revisions in your local branch by using 'bzr dpush --no-rebase' | 19:35 |
| jelmer | but if you do that, your local branch and the remote git branch will have diverged | 19:35 |
| mgrandi | ah ok | 19:35 |
| mgrandi | so this way you are theoretically the same as the git branch, albiet being in bzr | 19:36 |
| jelmer | mgrandi: yes - and using 'bzr dpush' will discard all information that can not be represented in git | 19:36 |
| mgrandi | it will discard it in the local branch as well? | 19:36 |
| jelmer | mgrandi: unless you specify --no-rebase | 19:37 |
| === KombuchaKip1 is now known as KombuchaKip | ||
| mgrandi | ok. is it necessarily a bad thing if you use --no-rebase ? will it still show up as one branch on the git side or will it show as merges from another branch sorta | 19:38 |
| jelmer | mgrandi: if you use --no-rebase then your local branch will diverge from the remote git branch | 19:38 |
| jelmer | because the revisions have different contents and different revision ids | 19:38 |
| mgrandi | yeah, but all i'm doing is really just mirroring my changes on github | 19:38 |
| mgrandi | and pushing to github occasionally | 19:39 |
| mgrandi | so in that case it wouldn't really matter if my local branch diverged since i'm working in bzr mostly | 19:39 |
| jelmer | in that case 'bzr dpush --no-rebase' should probably work sufficiently well | 19:39 |
| mgrandi | ok. cool =) | 19:39 |
| jelmer | mgrandi: but you'd have trouble pulling in changes from people who base their work on your git branch | 19:39 |
| mgrandi | keyword "probably" =P | 19:39 |
| mgrandi | ah. | 19:40 |
| jelmer | mgrandi: at some point bzr-git will support 'bzr push' itself and just store bzr metadata in git revisions for things that can't be natively represented in git | 19:40 |
| mgrandi | in that case i'll just leave it be. what sort of things cannot be represented in git, just curiously? | 19:40 |
| mgrandi | ah thats cool! | 19:40 |
| mgrandi | would it be stored as a file or something or does git have a metadata thing | 19:41 |
| jelmer | mgrandi: revision ids, file ids, revision properties, ghost revisions | 19:41 |
| jelmer | it would be stored as a magic file and in git notes | 19:41 |
| mgrandi | magic file as in just a file that only bzr uses? | 19:41 |
| jelmer | yeah | 19:42 |
| mgrandi | thats cool =) thanks, i was just curious | 19:42 |
| mgrandi | and something to keep in mind if i ever care about the revision ids | 19:42 |
| jelmer | mgrandi: well, you care about the revision ids if you e.g. want to use 'bzr dpush --no-rebase' and merge in contributions from people using git :) | 19:44 |
| mgrandi | yeah | 19:44 |
| mgrandi | cause then it gets all confused im assuming | 19:44 |
| jelmer | mgrandi: well, not really confused; they are in fact different revisions :) | 19:45 |
| mgrandi | yeah, which would make merging harder then it should be | 19:45 |
| mgrandi | so i'll just leave it without the --no-rebase thing for now in case i ever need to merge something back in it | 19:46 |
| mgrandi | also, i'm intereted in perhaps participating in the GSoC thing, even if i don't actually 'offically' participate in it, but it would be cool to work on something | 20:00 |
| mgrandi | i dunno if anyone decided on what stuff to do for it, although i saw people on the list were talking about netbeans support, which i assume is a java ide, and i know java fairly well | 20:00 |
| jelmer | mgrandi: there is a page with GSoC ideas | 20:10 |
| jelmer | let me find the link | 20:10 |
| mgrandi | (although i feel an eclipse plugin might be better, since many things use eclipse, android, flashbuiler, eclipse itself, etc) | 20:11 |
| jelmer | mgrandi: http://wiki.bazaar.canonical.com/SummerOfCode2012 | 20:11 |
| jelmer | mgrandi: I think we would be happy to mentor you, whether as part of SoC or outside of it | 20:11 |
| mgrandi | yeah. | 20:12 |
| mgrandi | quick question, what in bzr uses CPython? | 20:12 |
| mgrandi | re the 'porting bzr to python 3' | 20:12 |
| jelmer | mgrandi: apparently bzr works reasonably well in pypy, LarstiQ should know the details | 20:13 |
| mgrandi | well i mean | 20:13 |
| mgrandi | bzr is written in python, so i dont see why it was saying good knowledge of cpython is needed unless there are C excentions or something | 20:14 |
| mgrandi | unless its referring to porting bzr to pypy or something, not just making it work with python3 | 20:15 |
| jelmer | mgrandi: well, there are a bunch of implementation details in Python3 you have to know about to do the porting | 20:16 |
| jelmer | especially regarding character encoding handling | 20:16 |
| mgrandi | true | 20:16 |
| mgrandi | thats always fun | 20:16 |
| LarstiQ | note that while pypy has 3.x support in the works it currently implements python 2.7 api | 20:31 |
| LarstiQ | so working in pypy doesn't help with working in python 3 | 20:31 |
| LarstiQ | imo the two paragraphs under "Alternative Python implementations" are unrelated | 20:32 |
| mgrandi | yeah | 20:32 |
| mgrandi | thats what confused me xD | 20:32 |
| LarstiQ | mgrandi: there are, afaik, two eclipse plugins | 20:34 |
| === zyga_ is now known as zyga | ||
| mgrandi | last i heard they didn't work too well | 20:34 |
| * LarstiQ nods | 20:35 | |
| LarstiQ | not that I'm an eclipse user, but that is indeed my impression | 20:36 |
| mgrandi | might be good to start with. although eclipse is a beast within itself haha | 20:38 |
| thomi | Hi. I have a bzrlib Branch object, a relative path within that branch, and some line numbers, and I'd like to work out who wrote those lines (essentially like annotate, but only for certain lines in a file). | 22:48 |
| thomi | it looks like I need a VersionedFile object from a branch, but I can't see any easy way to get one. Any hints? | 22:49 |
| spiv | thomi: you should be able to resolve the path to a versionedfile via branch.repository | 22:51 |
| spiv | Although I forget the exact method | 22:51 |
| thomi | spiv: ok, thanks. I'll poke around :) | 22:52 |
| spiv | But basically it's the branch's repository that actually holds all the records about the history | 22:52 |
| spiv | (You may need the current revision ID, branch.last_revision(), to pass to whatever repo API you need) | 22:53 |
| spiv | I'd start by looking at how annotate works :) | 22:53 |
| thomi | cheers | 22:55 |
| === ubot5` is now known as ubot5 | ||
| thomi | spiv: I'm so close to having this working - the problem I have now is that bzrlib.annotate.annotate_file_tree calls _print_annotations, but I just want to get the annotation information... | 23:30 |
| thomi | I could reimplement annotate_file_tree in my code I guess.. | 23:31 |
| spiv | thomi: yeah, the core of it is just a call to branch.repository.texts.annotate((file_id, file_rev_id)) | 23:44 |
| spiv | thomi: (as you might have already found, file_rev_id might not be branch.last_revision(), you need to consult the branch.repository.inventory to map your file path to the file_id,rev_id pair to use) | 23:45 |
| thomi | yeah. | 23:46 |
| spiv | Er, not quite literally branch.repository.inventory, but you know what I mean I think :) | 23:46 |
| thomi | I hadn't seen the repo.texts thing, i was trying to do it some other way | 23:46 |
| spiv | (I'm getting rusty at bzrlib clearly!) | 23:47 |
| thomi | yep | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!