[00:05] no one :( [00:31] Noldorin: its 1am or something for Jelmer === jamesh__ is now known as jamesh [00:31] Noldorin: and you were addressing your discussion to him, so its not surprising :) [00:31] lifeless: 1am is the middle of the day for me :) [00:34] Best time to lay out and work on your startan. [00:34] startan? [00:35] Well, with my skin, it's more of a starburn, but... [00:35] oh [00:35] heh [01:11] fullermd: what's the 'index' in bzr btw? === zyga-afk is now known as zyga [08:16] morning === frankoid_ is now known as frankoid [14:41] mgz: jelmer wondered if maybe you'd take a look at this MP: https://code.launchpad.net/~abentley/bzr/branch-store/+merge/115618 [14:46] will have a look. [14:46] (relook) [14:51] mgz: ty. === AfC1 is now known as AfC [16:34] hi, I want to understand the "branches" command. I just created a branch using "bzr branch repo1 repo2". If I execute "bzr branches", on both, will show the following message "* (default)". What this means? [16:34] pfsmorigo: each of those directories has only one branch in it, the default branch [16:35] jelmer: so, how do I create another branchs in it? [16:36] pfsmorigo: if you have a shared repository with multiple branches in it, they should show up in 'bzr branches' [16:37] or you can create new colocated branches (in newer versions of bzr), by running "bzr branch . co:newbranch" or "bzr switch -b newbranch" (which will switch to the new branch too) [16:44] jelmer: the "co:" command doesnt worked by the second worked (at least the branch now have a new name) [16:45] jelmer: so, I have two options. create a directory copy using "bzr branch oldcopy newcopy" or this colocated option. I'm right? [16:47] jelmer: two directories for each branch or one for both, right? [16:50] pfsmorigo: yes, and the one-directory-per-branch approach is used most commonly [16:52] jelmer: I was reading bzr use guide and there is just the "two directories" approach... http://doc.bazaar.canonical.com/latest/en/user-guide/organizing_branches.html [16:52] pfsmorigo: colocated branches (multiple branches in a single directory) is still experimental, and therefore not yet documented or recommended [16:52] jelmer: hmm... now the parent branch is "." [16:53] pfsmorigo: if you use the shared repository approach (which should be documented), "bzr branches" will report sibling branches [17:25] jelmer: how can I keep the default branch with the original parent branch? [17:33] pfsmorigo: how do you mean? [17:33] pfsmorigo: the parent branch is the branch that a particular branch was based off [17:34] jelmer: https://gist.github.com/753752177417d6c5b03c [17:34] jelmer: there isn't a default branch anymore... [17:44] pfsmorigo: the defualt branch is like HEAD in git [17:44] pfsmorigo: it's only shown if it isn't referring to one of the named colocated branches [17:50] jelmer: ok. I will read a bit more the help and test some commands. tks for the support! [19:09] hello [19:10] hello [19:11] what is the best way to move a commit (someone else's) from one branch to another? [19:11] I need to backport a commit from emacs-trunk to emacs-24. [19:11] merging? [19:12] make another branch of the branch from emacs-trunk at the commit you want to move, then merge it into emacs24? [19:24] sounds a bit too heavy for just one commit. [19:26] leo2007: it sounds like you want to cherrypick a single commit ? [19:26] jelmer: yes [19:29] how to do that? [19:30] leo2007: bzr merge -c REV-TO-CHERRYPICK BRANCH-TO-CHERRYPICK-FROM [19:30] leo2007: bzr commit -m "Cherrypick REV-TO-CHERRYPICK" [19:32] so that just takes the diff/changes of that revision and merges that, rather then trying to merge the entire tree at that revision? [19:33] mgrandi: yes [19:35] jelmer: that seems to work but it didn't keep the authorship [19:36] leo2007: right, it doesn't - you can use the --author argument to respecify the author [19:37] a lot of hassle. [19:38] leo2007: there is the 'bzr replay' command that's part of bzr-rewrite too, but it doesn't deal with conflict [19:59] Possible to get bzr to use diff3 for merge conflicts? [19:59] jelmer: Do you have an unpushed revision for lp:~jelmer/ubuntu/precise/bzr/2.5.1-sru for the -0ubuntu2 upload? [19:59] luke-jr: bzr merge --diff3 ? [19:59] --diff3 Merge using external diff3. [19:59] jelmer: I tried that, it doesn't seem to work [20:00] I still get non-diff3 conflicts [20:00] do you have diff3 installed? [20:00] yes [20:00] slash can it find it? (look in .bzr.log to see if it reported anything) [20:00] luke-jr: ah, you mean diff3 as a command line utility?> [20:00] the log doesn't suggest it tried [20:00] luke-jr: bzr merge --using=diff3 perhaps? [20:01] jelmer: I mean showing me TREE, common ancestor, and merging branch [20:01] luke-jr: ah, --show-base will do that [20:01] aha [20:02] maxb: lp:~jelmer/ubuntu/precise/bzr/2.5.1-sru was just for the -0ubuntu1 [20:02] I don't think I used UDD for the -0ubuntu2 upload [20:08] fair enough [20:08] just assessing how best to represent things in the ppa-oneiric branch === yofel_ is now known as yofel [20:54] ooh, busy tonight :) [20:56] hey Noldorin [20:57] heya [20:57] jelmer: was takign a look at some bzr-git stuff yesterday after you were gone [20:57] jelmer: i'm tempted to say the way forward is using bzr-fastimport actually [20:57] in combination with git import [20:57] and whatnot [20:57] it's quite versatile in fact [20:57] can be extended to hg and other VCSs too in fact [20:58] there are some derivative projects that do cool things actually [20:58] Noldorin: bzr-fastimport is not bzr-git :) [20:58] jelmer: no but they can accomplish many of the same things ;) [20:58] this is my point [20:59] and bzr-fastimport has versatility on my side [20:59] just found out about it [20:59] but it seems like an interesting way to do various vcs-interop tasks. [20:59] Noldorin: bzr-fastimport is mostly interesting if you're using git and want to interoperate with bzr [21:00] jelmer: it can be used to mirror branches both ways [21:00] it's bidirectional ability is very good actually [21:00] just saying :) [21:02] Noldorin: git->bzr only works if you're importing into the same bzr branch you originally exported from [21:11] Noldorin: so it's mostly useful if you're the only one using bzr, or if you're the only one merging from git [21:11] jelmer: it's good enough in the vast majority of cases [21:12] Noldorin: depends on your use case [21:12] only for intricate cross bzr-git workflows do you need more [21:12] jelmer: well i've not seen one person lamenting the lack of features so far :) [21:12] more than enough for me [21:12] in fact [21:12] it's really nice [21:12] heh [21:18] Noldorin: for e.g. contributing a simple fix for an existing git project, bzr-fastimport is suboptimal [21:19] you just use git for that :P [21:19] ha [21:19] no point using anything else [21:19] you first have to clone the git repository, then git fast-export it, then bzr-fastimport it, then make your change, then bzr-fast-export your change and git-fast-import it [21:19] Noldorin: That's the use case dpush was designed for [21:19] yeah but dpush is horribly broken as we know :) [21:19] https://github.com/alexreg/git-bzr-ng [21:19] really nice ^ [21:20] simplifies import/export tasks [21:20] Noldorin: dpush doesn't handle a few corner cases well [21:20] Noldorin: but the same is true for bzr-fast-import [21:20] mate, stop calling them corner cases [21:20] w [21:20] e [21:20] we know that's not true [21:20] bzr-git fails on the bzr branch itself, and two of my branches [21:20] git-bzr-ng and fastimport works on all of them :) [21:20] it has to be said [21:21] Noldorin: if you're just pushing one or two changes (and don't care about renames, since you're contributing to a git repo anyway) that's unlikely to matter [21:21] yeah but git-bzr-ng is just as easy [21:21] to be fair [21:26] Noldorin: isn't git-bzr-ng a git plugin? [21:27] yep [21:27] so? [21:28] Noldorin: if you're happy using the git executable and are storing your main code in git, what are you using bzr for? [21:28] haha [21:28] jelmer: no-one said anything about storing main code in git [21:32] Noldorin: that doesn't make much sense to me, but okay [21:32] explain then [21:32] if you're confused [21:33] Noldorin: that's okay, that bit doesn't really interest me; it's more the different approaches for exporting to git [21:33] jelmer: this *is* an approach for exporting to git :P [21:38] Noldorin: it's the different approaches for exporting to git I'm interested in, not really on why your main branch is in the 2a format rather than in the git format [21:38] this is a different approach [21:39] so i don't get you [21:39] Noldorin: anyway, I seem to be the de-facto maintainer for both bzr-fastimport and bzr-git; I just think bzr-git is the cleaner approach [21:39] yeah i saw that ;) [21:39] so it's not like i'm slagging off one over the other [21:39] fastimport just seems rather more reliable at htem oment [21:39] at the moment* [21:39] and indeed versatile [21:41] There are some rather perplexing test failures for bzr-builddeb in oneiric and natty :-/ [21:41] maxb: can you give an example? [21:41] IOError: [Errno 21] Is a directory: u'/tmp/testbzr-LexZzZ.tmp/bzrlib.plugins.builddeb.tests.test_util.TreeContainsUpstreamSourceTests.test_empty/work/.bzr/checkout/dirstate' [21:41] ! [21:42] and some sort of treetransform fallout in natty: [21:42] OSError: [Errno 20] Not a directory: '/tmp/testbzr-kPYNe4.tmp/bzrlib.plugins.builddeb.tests.test_revspec.TestRevisionSpec_package.test_from_string_package/work/tree2/.bzr/checkout/limbo/new-1' [21:43] that second one looks vaguely familiar [21:43] maxb: I mean, the "Not a directory" bit looks vaguely familiar [21:44] I'm afraid I don't remember specifics though :-/. [21:44] * maxb reviews some previous versions [21:46] The same test failed in a different way in the previous bzr-builddeb release on natty [21:46] and before that, a string of failures for other reasons [21:48] I think it had something to do with tarballs or zip files [21:48] From the oneiric failure: [21:48] 101.551 trying to create missing lock '/tmp/testbzr-LexZzZ.tmp/bzrlib.plugins.builddeb.tests.test_util.TreeContainsUpstreamSourceTests.test_empty/work/.bzr/checkout/dirstate' [21:48] err... what? Something's amusingly confused there ! [21:57] urgh, yep :) [21:59] Hm, looks like the dulwich testsuite has hung on maverick & lucid too [21:59] There was I thinking this series of PPA updates was going OK [22:03] maxb: that's probably one of the compat tests [22:03] maxb: you might need a minimal version of git-core in order to be able to run it [22:32] jelmer: hmm is colocated stuff still in a separate plugin? [22:32] on the latest version i have on mac, i don't see it there [22:41] The bzr-builddeb failures are feeling like tests that don't properly support concurrency [22:45] Also these builds would be a lot faster if they didn't run the tests 4 times [22:48] lifeless: hye [22:49] lifeless: just saw http://doc.bazaar.canonical.com/developers/colocated-branches.html… [22:49] lifeless: you may want to update that re: the branch separator… even though i prefer the simple ',' ;) [23:12] Noldorin: it's in core, but only 2.6 [23:12] ah right [23:13] jelmer: was just curious why it wasn't included as a default plugin in 2.5... [23:13] Noldorin: bzr-colo is very different from the colocated branch support in the core [23:13] oh i see [23:13] how so, briefly? [23:13] Noldorin: bzr-colo was designed to not depend on any changes to the core [23:14] but it's a bit of a hack, it adds an entire new set of commands to deal with colocated branches and has more overhead than the native colocated branches [23:15] right [23:15] jelmer: not to worry. i presume colo branches will be adequately documented when 2.6 comes out :) [23:16] Noldorin: note that the ocument you just linked to is the spec for colocated branches, not the user documentation [23:16] indeed [23:17] i knew that was just a whitepaper heh [23:17] jelmer: only thing i'm curious about… did you decide on the "," seperator (as in the spec) or ",branch=" as before? [23:18] Noldorin: at the moment it's ",branch=foo" [23:18] oh [23:18] okay [23:18] Noldorin: we decided to use that as it's the safer option [23:18] that's unfortunate… i'm sure you have a reason though [23:18] it's always possible to add support for ",foo" in addition to ",branch=foo" later [23:18] indeed [23:18] that's true [23:18] Noldorin: there are other situations in which you might want to use , [23:19] Noldorin: e.g. "file:///tmp/bzr,revision=43 [23:19] Noldorin: e.g. "file:///tmp/bzr,revision=43" [23:19] hmm, yeah [23:19] does that already work? [23:20] i would suggest file:///temp/bzr?r=43 is better [23:20] but fair enough [23:20] Noldorin: what happens when things are nested? [23:21] like? [23:21] Noldorin: if you hasve a bzr tree inside another bzr tree [23:21] ha [23:21] you might want to specify the revision of the inner tree [23:21] then you've fucked up? ;) [23:21] this is the reason we picked , - that's what's specified by std66 for per-path-element parameters [23:21] Noldorin: also, ? is interpreted by shells and often can't be used without quoting i [23:22] fair enough [23:22] jelmer: so maybe simply ,b= and ,r= would be better [23:22] at least [23:22] a [23:22] s [23:22] as aliases* [23:22] Noldorin: those aliases can always be added later [23:22] yes that's what i just said [23:22] Noldorin: also, that's a fair bit less readable [23:22] :P [23:23] jelmer: ah, but is readability the key here? to me, definitely not [23:23] succinctness is preferable [23:23] Noldorin: to occasional bzr users coming across these for the first time [23:23] Noldorin: another issue is whether "r" is going to be short for revno or for revid [23:23] yes but weigh it up against the verboity [23:23] verbosity [23:23] definitely worth considering [23:24] it shouldn't be dismissed quickly! [23:24] Noldorin: let's worry about that when it actually becomes an issue - colocated branch support has to be finished first [23:24] i'm not worried [23:24] i'm just throwing ideas at you! [23:24] thought you might be grateful [23:24] *shrug* [23:24] I'm not working on this stuff :) [23:24] jelmer: you replied to me :P [23:25] was initially at lifeless [23:25] but yeah [23:25] Noldorin: you asked about my design considerations for colocated branches [23:25] either way is cool [23:25] anyway, time for some sleep! [23:25] g'night [23:25] yes, after lifeless was away [23:25] jelmer: you reply, you involve yourself! ;) [23:26] just try and be more receptive [23:26] bureaucracy is the downfall of all entreprises [23:26] after all [23:26] Noldorin: what's bureucratic here? [23:26] i'll let you figure that out for yourself mate [23:27] * jelmer sighs [23:27] hah, go sleep on it or something [23:27] don't sigh [23:27] *think* [23:27] it's good. [23:27] I don't care :) [23:27] /me sleeps [23:27] good [23:27] then don't ask [23:27] else you'll give people conflicting views [23:27] *laughs* [23:30] * maxb looks at distro-info for the first time [23:31] * maxb boggles that anyone ever thought writing it in Haskell was a good idea [23:45] maxb: writing anything practical in haskell is probably a bad idea [23:56] Hi, I'd like to copy a configuration file from a template whenever I make a new branch of a repository. Ideally the behaviour would be embedded in the repository itself, rather than my user configuration. Is this something I can do with a plugin?