| mathrick | Peng: all important repos are signed anyway, so that removes the ability to change anything | 00:08 |
|---|---|---|
| AuroraBorealis | how do you sign a repo? | 00:08 |
| mathrick | well, you sign commits | 00:08 |
| AuroraBorealis | never heard of it | 00:08 |
| AuroraBorealis | this | 00:08 |
| mathrick | bzr help sign-my-commits | 00:09 |
| mathrick | http://doc.bazaar.canonical.com/latest/en/user-guide/gpg_signatures.html | 00:10 |
| AuroraBorealis | i'm still a bit confused on how this prevents malicious tampering | 00:11 |
| mathrick | AuroraBorealis: simple, a commit has a signature, which is a cryptographic certificate of authenticity | 00:11 |
| mathrick | you can't modify a commit without invalidating the signature | 00:11 |
| mathrick | so chains of hashes or not, it doesn't match up | 00:12 |
| mathrick | though I believe bzr would catch that without explicit rechecking too even without signatures | 00:12 |
| mathrick | because tree states are referred to by sha1 | 00:12 |
| mathrick | it's just not ordinarily visible | 00:12 |
| mathrick | but it'd still cause any related branch to fail to sync | 00:13 |
| AuroraBorealis | because what happens if you change the repo so the commit is no longer signed, or changed the author (so you can use a different gpg key to sign it) | 00:14 |
| AuroraBorealis | yeah | 00:14 |
| AuroraBorealis | but what if you change the commit, and the signature? | 00:14 |
| AuroraBorealis | does it have a chain of hashes? | 00:14 |
| AuroraBorealis | hmm. | 00:14 |
| mathrick | bzr's signatures are not as robust and integrated with everything else as could be wished for yet, but they definitely give you the ability to say that commits are what they claim to be with absolute certainty (barring physically stolen keys) | 00:14 |
| AuroraBorealis | but does it have a 'chain of hashes', like one commit refers to the next one's sha1 (with the signature) | 00:14 |
| mathrick | AuroraBorealis: the point of having signatures is that you can't forge one | 00:15 |
| mathrick | to sign a commit you need to have the private key | 00:15 |
| mathrick | only the original author does | 00:15 |
| mathrick | otherwise it wouldn't be much of a signature | 00:15 |
| AuroraBorealis | yeah, but what if you just straight up replace the commit, and not really 'forging' it, you are just creating a whole new one and putting that in there | 00:15 |
| mathrick | people would notice when pulling / merging | 00:15 |
| AuroraBorealis | yeah, i was just thinking because i quoted kernel.org saying that this wouldn't work in git since it seems to have a 'chain' of hashes and that one wouldn't match up | 00:16 |
| mathrick | that's the case in bzr too | 00:16 |
| mathrick | but bzr can also sign things | 00:16 |
| AuroraBorealis | k | 00:16 |
| mathrick | meaning you get to know not only that things weren't changed, but that they come precisely from whom they claim to come | 00:17 |
| AuroraBorealis | ok, just curious :3 | 00:18 |
| AuroraBorealis | andddd off to class | 00:18 |
| === AuroraBorealis is now known as aurora|afk | ||
| mwhudson | what is the secret decoder ring for using meld to resolve conflicts with bzr again? | 02:03 |
| mwhudson | ah, extmerge | 02:06 |
| poolie | hi mwhudson, all | 02:06 |
| poolie | yes, but i thought that was being moved in | 02:06 |
| poolie | maybe not yet | 02:06 |
| poolie | jam, hi? | 05:06 |
| vila | hi all ! | 06:44 |
| vila | poolie: have you requeued imports on jubany in the last hour ? | 06:44 |
| vila | by the way, a_r_o have been reverted on jubany: http://webnumbr.com/ubuntu-package-import-failures.from%282011-08-29%29 | 06:45 |
| vila | a_r_o == append_revisions_only, sry for the obfuscated TLA ;) | 06:45 |
| jam | hi poolie | 07:07 |
| poolie | hi jam | 07:09 |
| poolie | hi vila, i have not | 07:09 |
| poolie | thanks for doing thhat | 07:09 |
| vila | weird, someone else ? maxb ? | 07:09 |
| bradm | poolie: you about? | 07:10 |
| poolie | hi brad, i am but i'm on the phone | 07:11 |
| bradm | poolie: no worries | 07:11 |
| bradm | poolie: when you're done, we need to upgrade wiki.bazaar.canonical.com to the new moin at some point, do you have any preferences as to what sort of times that can be done? | 07:11 |
| poolie | hi there | 07:27 |
| poolie | do you want us around for it, or not? | 07:27 |
| poolie | i don't have any strong feeling so it's just whatever's easiest for you | 07:28 |
| vila | 2.4.1 and 2.2.5 were planned to be frozen today, given the delay on 2.4.0, I think we should postponed 2.4.1 to next week and just freeze 2.2.5, thoughts ? | 07:29 |
| bradm | poolie: mm, I'm not sure there's any need for you to be around, and we'll have backups etc | 07:29 |
| bradm | poolie: although it's very likely going to be me doing it during .au working hours | 07:29 |
| vila | see https://launchpad.net/bzr/+milestone/2.4.1 https://launchpad.net/bzr/+milestone/2.2.5 for the pending bug fixes | 07:30 |
| bradm | poolie: unless there's a preference for otherwise | 07:30 |
| bradm | poolie: ok, I'll let you know, likely will be next week sometime, thanks. | 07:32 |
| Riddell | hola chicos | 07:52 |
| maxb | vila: not me | 07:55 |
| vila | Riddell: hey ! | 07:55 |
| poolie | ahoy | 07:55 |
| vila | hmm, I may have been confused by mass_import querying lp *just* when I was looking... | 07:55 |
| vila | poolie: 2.2.5 ? 2.4.1 ? Thoughts ? | 07:56 |
| vila | poolie: by the way, ironically, make check stamps worked but the landing encountered a spurious failure ;) | 07:58 |
| jam | vila: makes sense to me to push back 2.4.1, I don't really know what is in 2.2.5 that is specifically worth releasing | 07:59 |
| vila | jam: that's why I pasted the relevant milestones urls above ^ | 07:59 |
| vila | bug #609187 may be a good flagship for SRU | 08:00 |
| ubot5 | Launchpad bug 609187 in Ubuntu Distributed Development "users are not warned when branching ubuntu:foo (or lp:ubuntu/foo) and the package import of foo is out of date" [High,Fix released] https://launchpad.net/bugs/609187 | 08:00 |
| vila | and 2.2.4 was released on 2011-02-04, i.e. almost 7 months ago | 08:01 |
| vila | also note that pushing 2.4.1 back more or less implies also pushing 2.5b1 from 2011-09-08 to 2011-09-15 | 08:03 |
| vila | ... or not | 08:03 |
| vila | worth discussing at least IMHO | 08:03 |
| Riddell | any thoughts on how I can write tests for i18n? Is it possible for a test to run ./setup build_mo ? | 09:15 |
| vila | Riddell: if the input set is small enough yes, but you may want to directly run what ./setup build_mo does no ? | 09:27 |
| vila | Riddell: i.e. less blackbox, more unit kind of test | 09:27 |
| Riddell | aye | 09:27 |
| vila | Riddell: also, there are already some tests around i18n somewhere | 09:28 |
| Riddell | yes, looking at those now | 09:28 |
| vila | bzrlib.tests.test_help.py | 09:29 |
| vila | some refactoring may be needed there to reduce duplication though :-/ | 09:29 |
| jam | vila: btw, think I should try to land get_parent_map before 2.4.1? Or should we have more time shaking it out in trunk? | 10:25 |
| vila | jam: good question, no idea about who shaked it nor how... but nobody complained either | 10:27 |
| vila | jam: btw, when you say "I don't really know what is in 2.2.5 that is specifically worth releasing", you mean "nothing there worth releasing" or "no idea what is worth releasing there" ? | 10:28 |
| jam | "no idea what is worth releasing there" | 10:28 |
| vila | ha ok | 10:29 |
| vila | so, since nobody objected and on the basis that 7 months is long enough, I'll freeze 2.2.5 after lunch | 10:30 |
| * vila away for lunch | 10:30 | |
| jelmer | vila: we already support expanding variables in config options? | 10:42 |
| === Quintasan_ is now known as Quintasan | ||
| jelmer | Riddell, hi | 11:05 |
| Riddell | hi jelmer | 11:05 |
| jelmer | Riddell, does launchpad pick up the pot file from the bzr branch? | 11:05 |
| Riddell | yes it does | 11:05 |
| Riddell | https://translations.launchpad.net/bzr/trunk/+pots/bzr/ | 11:06 |
| jelmer | Riddell: your recent patches update export_pot.py but don't rerun it, is that for a particular reason? | 11:06 |
| Riddell | jelmer: which patch? (probably I just didn't want to make a massive diff) | 11:07 |
| jelmer | Riddell, i18n-topic-help | 11:07 |
| Riddell | yeah, I would update the .pot file before sending to PQM | 11:07 |
| jelmer | Riddell: works for me | 11:09 |
| vila | jelmer: via bzr.config.expand = True in bazaar.conf so revno 5684 | 12:12 |
| vila | jelmer: 2.4b1 | 12:12 |
| jelmer | ah, cool.. didn't realize that | 12:14 |
| jonathanj | is it possible to prepopulate the commit message? | 12:35 |
| jonathanj | something like the normal launch-your-editor mode combined with -F | 12:36 |
| jelmer | jonathanj: bzr plugins can provide templates for the commit message | 12:41 |
| vila | jelmer: option expansion is opt-in only as review raised issues about false positive with people using {xxx}, so feedback welcome if you use it | 12:53 |
| neoZ7 | I try to add Trac Bazaar Plugin to my Bazaar Explorer (win32), downloaded an .egg file and can't find a tutorial what to do with it. Could someone please point me to a place to read up on it? Thank you. | 13:41 |
| jelmer | neoZ7: see the README file | 13:48 |
| jelmer | vila: what would be the appropriate thing to report to in PullResult/PushResult ? | 13:50 |
| jelmer | we should be reporting to stderr, but is there anything on Command that represents sys.stderr? | 13:51 |
| vila | ha | 13:51 |
| vila | good question :) | 13:52 |
| mgz | jelmer, neoZ7: the README in the egg if you unpack it as a zip? | 13:54 |
| vila | the *result* makes sense on stderr since -v will use stdout (self.outf)... but it seems we currently display both on self.out | 13:54 |
| jelmer | mgz, I guess so. I don't really know where trac-bzr ships an egg | 13:55 |
| vila | jelmer: so, I'd say self.outf for both which is already used for -v | 13:55 |
| vila | jelmer: both push and pull I mean | 13:55 |
| jelmer | neoZ7, actually, see http://pypi.python.org/pypi/TracBzr | 13:55 |
| neoZ7 | jelmer: I understand about putting plugins in their respective directories, but the egg file is a renamed zip file and differs from the plugins I find already installed. Will read up your link next. | 13:56 |
| mgz | jelmer, vila: just need to use ui.stderr directly maybe? | 13:56 |
| mgz | ui.thingy.stderr even | 13:57 |
| vila | wfm but I suspect some tests will fail | 13:57 |
| jelmer | well, some tests will fail anyway as "bzr pull" currently writes to stdout and "bzr push" currently writes to stderr | 13:57 |
| vila | jelmer: you mean for the result ? | 13:58 |
| vila | jelmer: if my tweak become too invasive, better file a bug so the issue is discussed there, I noticed the weird duplication and mentioned it but I didn't realize the fallouts | 13:59 |
| vila | jelmer: if you end up de-duping by passing 'trace.note' and 'self.outf.write' to a helper, the result may be uglier ;) | 14:00 |
| neoZ7 | jelmer: maybe I'm following a wrong direction, my goal is to change the way my diff view is displayed, I like the way unidiff shows up but I like trac's view more. My goal is to get this style into bazaar explorer -> http://dev.ryzom.com/projects/ryzom/repository/diff?rev=dfb7fa26474c&rev_to=9f3f37337a56 and someone suggested the trac plugin to get this done. But I think it might be too much since all I want is a different diff result formatting. | 14:02 |
| mgz | hm. | 14:04 |
| vila | jam: thanks for the review ! | 14:04 |
| mgz | neoZ7, you mean, in bzr explorer (really qdiff), you want a single panel view rather than old and new side by side? | 14:04 |
| mgz | in which case yeah, installing the trac plugin won't help you. | 14:04 |
| vila | jam: hmm, {} has no meaning why would you want to warn/error instead of just leaving it alone ? | 14:05 |
| neoZ7 | mgz: I have a single panel diff already, by checking the (o) unidiff option on bottom, but it doesn't look as nice as the one I posted. I have @, + and - signs, that's too raw for my taste. | 14:07 |
| mgz | neoZ7: I suggest filing a bug against qbzr (which is what supplies the diff window for bzr explorer) saying exactly what improvements you'd like to the single panel view | 14:08 |
| jelmer | vila, hmm, yeah. I think I'll file a separate bug about it. | 14:10 |
| vila | jelmer: mention it in a comment && approve ;) | 14:11 |
| jelmer | vila, merci | 14:11 |
| mgz | neoZ7: you can also set it to use an external program to do the diff, if you can find one that does what you want | 14:11 |
| mgz | neoZ7: like in https://launchpad.net/bzr-difftools but qbzr has its own mechanism (I think you can set it in the explorer options somewhere) | 14:13 |
| mgz | that link has a list of like ten programs you could try | 14:13 |
| davi_ | jelmer, hi, regarding bug 544776, when changing the mapping registry to git-experimental, do i also have to remove the existing idmap or it can be re-used? | 14:17 |
| ubot5 | Launchpad bug 544776 in Bazaar Git Plugin "no roundtripping support" [Wishlist,In progress] https://launchpad.net/bugs/544776 | 14:17 |
| jelmer | davi_: You should be able to reuse it. | 14:19 |
| jelmer | emphasis on should :) | 14:19 |
| davi_ | yeah, i tried some weeks ago and it failed, was checking whether it should work or not :) | 14:19 |
| davi_ | anyway, will try again (just for fun, it won't work because all of the memory usage in the later stage..). thanks | 14:20 |
| jelmer | davi_: You were trying to push mysql into git right? | 14:21 |
| davi_ | jelmer, right | 14:21 |
| jelmer | davi_: You should be able to use "bzr push -r10" to push just ten revisions, but it will still try to update the full git map beforehand | 14:21 |
| davi_ | jelmer, that should work then, updating the git map is feasible. thanks | 14:22 |
| jelmer | davi_: let me know how/if it works | 14:24 |
| vila | urgh, can't run the test suite for 2.2.5 ? Like... not even one test : AttributeError: 'module' object has no attribute '_WritelnDecorator' | 14:55 |
| vila | I'm good to dig into testtools/subunit ancestry... | 14:55 |
| vila | or may be just ask which are used on pqm | 14:55 |
| mgz | use Python 2.6 vila. | 15:09 |
| vila | mgz: hmm, yeah, a bit better | 15:10 |
| vila | AttributeError: 'module' object has no attribute 'Feature' 8=) | 15:11 |
| vila | ha, better with BZR_PLUGIN_PATH=-site | 15:12 |
| vila | AttributeError: 'module' object has no attribute 'ExtendedTestResult' | 15:12 |
| vila | capture = testtools.tests.helpers.ExtendedTestResult() | 15:12 |
| jelmer | vila, for new options, what do I need to do other than just registering them in the option registry? | 15:13 |
| vila | 2.2 was requiring >= 0.9.2 | 15:13 |
| vila | jelmer: depends on where you expect to find them | 15:13 |
| vila | jelmer: if it's only in bazaar.conf, register and then use GlobalStack where GlobalConfig was used before | 15:14 |
| vila | jelmer: what kind of option is it ? | 15:15 |
| jelmer | vila: It's a branch (or global) option | 15:15 |
| jelmer | vila: where do I obtain a BranchStack? | 15:15 |
| vila | jelmer: nowhere, yet :-/ | 15:16 |
| jelmer | vila: Ah, ok | 15:16 |
| jelmer | vila: I'll just use get_user_option for the moment | 15:16 |
| vila | jelmer: fine | 15:16 |
| vila | as long as the option name makes sense it won't be hard to migrate | 15:17 |
| vila | jelmer: is it just a string or some more specific type (bool, int) ? | 15:17 |
| jelmer | vila: what are the plans for BranchStack? | 15:17 |
| jelmer | vila, it's just a string (default_bugtracker) | 15:17 |
| vila | argh | 15:17 |
| jelmer | hmm? | 15:18 |
| vila | well, stacks supports defaults, it's a shame you add to create a new option for that :-/ | 15:18 |
| vila | the plan for all stacks is to be obtained from a registry | 15:19 |
| jelmer | it's not really a default default, perhaps I should just call it "bugtracker" | 15:19 |
| jelmer | it's default in the sense that that's what's used if no bugtracker was specified on the command-line | 15:19 |
| vila | jelmer: bug #823036 | 15:19 |
| ubot5 | Launchpad bug 823036 in Gephi "AttributeRangeFilter returns main graph when nothing matches filter" [Undecided,Confirmed] https://launchpad.net/bugs/823036 | 15:19 |
| jelmer | euhm, sure..? | 15:19 |
| jelmer | :P | 15:20 |
| vila | >-/ | 15:20 |
| vila | jelmer: bug #832036 | 15:20 |
| ubot5 | Launchpad bug 832036 in Bazaar "Needs a config stack registry" [High,In progress] https://launchpad.net/bugs/832036 | 15:20 |
| vila | haaa :) | 15:20 |
| jelmer | vila: I think Branch needs a get_store() option, rather than defaulting to BranchStore, which is bzr specific. | 15:23 |
| jelmer | s/option/method/ | 15:24 |
| vila | jelmer: hmm, because foreign branches cannot provide the necessary... what... transport, lock, branch.conf ? | 15:53 |
| vila | jelmer: it's already fine if branch.conf doesn't exist though | 15:54 |
| jelmer | vila: yes, but they'd want to provide something else | 15:54 |
| jelmer | vila: they currently have a custom implementation of BranchConfig | 15:55 |
| === beuno is now known as beuno-lunch | ||
| vila | jelmer: oh, I didn't know that | 15:58 |
| vila | jelmer: well, the stack registry should returns a factory, and this factory will receive a branch object and be responsible for returning a config stack, so that could be addressed here (including via a branch.get_store() for that matter) | 15:59 |
| vila | jelmer: I'll have a look at the custom impls. which plugin is it ? | 16:00 |
| jelmer | vila: e.g. bzrlib.plugins.svn.config | 16:00 |
| jelmer | I think that's the most advanced one at the moment | 16:00 |
| jelmer | bzr-git is supposed to support something similar in the future, but dulwich doesn't do config files jus tyet | 16:01 |
| vila | jelmer: wow, I didn't read it for quite some time... looks similar to what stacks are targetting (including the uuid matching), what is use_global ? | 16:11 |
| vila | jelmer: uuid are unique inside a given .conf file right, .bazaar/svn.conf and one section by uuid ? | 16:12 |
| jelmer | vila: svn has per-repository UUIDs | 16:13 |
| vila | yup | 16:13 |
| jelmer | vila: but yeah | 16:13 |
| jam | Riddell: are you still around? One comment about the 'release-notes' file, we generally sort the entries alphabetically | 16:13 |
| vila | and you use them a shared conf options for all the branches in a given repo ? | 16:13 |
| jelmer | [a9308255-753e-0410-a2e9-80b3fbc4fff6] | 16:13 |
| jelmer | layout = trunk2 | 16:13 |
| jam | that way we conflict less when merging | 16:14 |
| jam | (since my news entry is Foo is faster, and yours is Bar is less buggy, they end up in different sorted spots.) | 16:14 |
| Riddell | jam: oh really, I hadn't noticed that | 16:14 |
| jelmer | vila: that's useful as some repositories are accessible using multiple URLs | 16:14 |
| jam | Riddell: I'll fix up the ones I see | 16:14 |
| vila | jelmer: right, and you use that as defaults or overrides ? Hmm, not even that, you use that as a 1-1 relationship for a repo.conf except it's not stored in svn, correct ? | 16:15 |
| jelmer | vila: it's one of the stores in the stack, so to speak | 16:16 |
| vila | exactly | 16:16 |
| jelmer | less important than locations.conf, more important than the global conf | 16:16 |
| vila | right, so defaults (not overrides), except that you never redefine 'layout' in a branch right ? | 16:17 |
| vila | jelmer: so, yeah definitely worth a separate store where sections are the uuids | 16:17 |
| vila | jelmer: I'd like the general case to be path for sections, but I'm all for specific stores if needed so this case fits nicely | 16:19 |
| jelmer | vila: cool | 16:19 |
| === Meths_ is now known as Meths | ||
| vila | jelmer: the missing bits for you to switch are: the stack registry, migrating the config command and supporting --section --store | 16:26 |
| vila | jelmer: which are high on my config TODO list | 16:26 |
| vila | jelmer: just below my current work on expansion in fact | 16:26 |
| jelmer | vila: being able to provide the stack and store from Branch too | 16:27 |
| vila | jelmer: well, you will be able to define any key you need in the registry and any context too | 16:27 |
| jelmer | vila: other plugins need to be able to access a bzr-svn-specific stack without having to know about the special UUID store, for example | 16:28 |
| vila | jelmer: should be possible | 16:29 |
| jelmer | vila: what is the purpose of the registry exactly? | 16:29 |
| vila | jelmer: get the right config stack for a given context | 16:29 |
| vila | jelmer: for most of the cases, a branch will need a single stack, but there may be exceptions for some options | 16:30 |
| vila | jelmer: the uuid store targets some specific options right ? | 16:31 |
| jelmer | vila: no, it's usable for any options | 16:31 |
| jelmer | I've used it to set append_revisions_only, for example | 16:32 |
| vila | jelmer: hmm | 16:32 |
| jelmer | vila: BranchStack seems to hardcode BranchStore at the moment, which isn't usable for foreign branches | 16:32 |
| vila | jelmer: right | 16:32 |
| vila | jelmer: the *Stack are helpers for now | 16:33 |
| vila | jelmer: restricted to the migration needs | 16:33 |
| vila | jelmer: if bazaar.conf was supporting sections as path to provide default values, would you still need the uuid store for a_r_o ? | 16:34 |
| vila | jelmer: path or URL for that matter | 16:36 |
| jelmer | vila: yeah, because the svn repository can be accessible over multiple protocols | 16:37 |
| jelmer | typically anonymous access over svn:// and authenticated over svn+ssh:// or http:// and https:// | 16:38 |
| vila | wow | 16:38 |
| vila | jelmer: but if you define it for a uuid, it means it applies for all branches right ? You don't have a way to discriminate between branches ? | 16:39 |
| jelmer | vila: no | 16:39 |
| vila | jelmer: though this problem is also true for locations.conf and remote branches accessed via http: or bzr+ssh: | 16:40 |
| jelmer | but that's still useful as it's typically one project per repository | 16:40 |
| vila | yup, got that | 16:40 |
| jelmer | vila: I can imagine other situations where it might be useful manipulate the stack | 16:41 |
| vila | jelmer: hmm, so, that still fall under the stack registry scope | 16:41 |
| vila | jelmer: may be, but have you considered using multiple stacks instead ? | 16:41 |
| jelmer | vila: how do you mean? | 16:41 |
| vila | jelmer: what manipulations are you thinking about ? | 16:42 |
| vila | hehe :) | 16:42 |
| vila | jelmer: well, compare BranchStack and RemoteBranchStack | 16:42 |
| jelmer | vila: The problem is, bzr-svn can't control what stacks its users would use | 16:42 |
| vila | jelmer: the later is targeted at a single option (which name escapes me at the moment, the one spiv migrated) | 16:42 |
| vila | jelmer: in which case ? | 16:43 |
| vila | jelmer: if a bzr-svn branch is involved the registry can query the branch for a given context | 16:43 |
| jelmer | vila: either way - I can't make people look at ~/.bazaar/subversion.conf when they e.g. retrieve their username, while I can atm | 16:44 |
| vila | jelmer: don't consider BranchStack as a definitive answer ;) | 16:44 |
| vila | jelmer: that should be fixed then | 16:44 |
| jelmer | that's what I was hoping for :) | 16:45 |
| vila | hehe | 16:45 |
| vila | jelmer: right now, I don't know exactly what the factory returned by the stack registry will work, but the idea is that since it's a registry, you can perfectly override the 'branch' key there to insest your own that will take subversion.conf into account and provide the relevant section iff an uuid is available around | 16:47 |
| vila | jelmer: the section list itself is built lazily so you don't even have to answer the uuid matching until an option is queried | 16:48 |
| jelmer | cool | 16:48 |
| vila | jelmer: there may be edge case where this breaks :) | 16:48 |
| vila | jelmer: like needed a branch with enough state which can be obtained only with a given option but from an bird's eye view such cases sound broken by design | 16:49 |
| vila | jelmer: and should already break today anyway ;) | 16:50 |
| vila | jelmer: ho, and was is use_global=False ? | 16:51 |
| vila | s/was/what/ | 16:52 |
| === beuno-lunch is now known as beuno | ||
| jelmer | vila: whether to look at the global config or not | 16:52 |
| jelmer | (I think) | 16:53 |
| vila | jelmer: look or write ? | 16:53 |
| jelmer | vila, read | 16:53 |
| vila | yeah, it looks like you use it for your specific options... | 16:54 |
| vila | haaaa, so you can get the relevant one based on the uuid ? | 16:54 |
| vila | jelmer: anyway, we should definitely pair when you start migrating ;) | 16:55 |
| jelmer | vila: heh, sure | 16:56 |
| vila | jelmer: hmm, waitasec, do you know other options than a_r_o that can be defined in subversion.conf ? | 17:02 |
| vila | jelmer: or are there *all* the options that can be defined in branch.conf ? | 17:03 |
| jelmer | vila: all the options that can be in branch.conf can also be in subversion.conf | 17:03 |
| vila | ouch | 17:03 |
| vila | hehe, ok | 17:03 |
| vila | EOD here, food for dreams ;) | 17:04 |
| jelmer | :) | 17:04 |
| jelmer | bon appetit :) | 17:04 |
| vila | thanks ;) | 17:04 |
| === santagada_ is now known as santagada | ||
| santagada | is there any graphical ui for interactive merges? | 17:31 |
| santagada | qmerge and bazaar explorer don't have this | 17:31 |
| santagada | everyone does --interactive only? | 17:34 |
| jam | santagada: I know some people do the merge, when it generates a conflict, they resolve it with a gui like kdiff3 or meld | 17:56 |
| jam | using the .BASE, .OTHER, THIS files on disk | 17:56 |
| jam | santagada: I thought "bzr-extmerge" also had support for defining a custom merge program that would fire during 'bzr merge' | 17:58 |
| AuroraBorealis | the bzr docs mention a 'verify signatures' command for verifying signed commits, but my bzr doesn't have it, did it get removed? | 18:00 |
| AuroraBorealis | also, after signing commits, the branch doesn't say that it was changed, so what exactly did it do? o.o | 18:03 |
| === zyga is now known as zyga-afk | ||
| === Noldorin is now known as Noldorin2 | ||
| === Noldorin2 is now known as Noldorin | ||
| === mwhudson_ is now known as mwhudson | ||
| === yofel_ is now known as yofel | ||
| davi_ | jelmer, fwiw, push with a existing idmap failed with a assertion error: Invalid sha for <Commit […] | 21:23 |
| davi_ | jelmer, bzr push -r n still tries to push all revisions | 21:26 |
| jelmer | davi_: what bzr are you using? | 21:28 |
| jelmer | davi_: it does update the id map for all revisions here, but it doesn't push more than I specify with -r | 21:29 |
| davi_ | jelmer, bzr 2.4.0 | 22:44 |
| jelmer | davi_, are you sure it's the push that tries to do the full set of revisions, and not the id map update? | 22:45 |
| davi_ | jelmer, huh, could be. i left a bzr push running which will make a new id map | 22:45 |
| jelmer | davi_: just running "bzr git-objects" in the bzr branch should update the idmap | 22:46 |
| jelmer | after that the push shouldn't have to touch it unless more bzr revisions are added | 22:46 |
| davi_ | ok. let me try... | 22:46 |
| davi_ | davi@skynet:~/repo/5.5$ bzr push -r 10 ~/git-repo/ | 22:48 |
| davi_ | \ determining revisions to fetch 30199 | 22:48 |
| davi_ | davi@skynet:~/repo/5.5$ bzr push -r 2 ~/git-repo/ | 22:49 |
| davi_ | \ pushing revisions 5/69505 | 22:49 |
| davi_ | jelmer, ^ | 22:49 |
| jelmer | hmm | 22:50 |
| * jelmer tries locally | 22:50 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!