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