[04:10] <nigelb> hi!
[04:11] <nigelb> I just ran into https://bugs.launchpad.net/bzr/+bug/375013 with tarmac.
[04:11] <nigelb> the solution is to unstack the branch I presume?
[04:34] <lifeless> nigelb: newer bzr should work
[04:36] <nigelb> lifeless: hrm, its a lucid server. let me hunt for a ppa. thanks.
[09:01] <mgz> morning all
[10:09] <vila> hi all <cough> <cough> !
[10:12]  * mgz pats vila on the back
[10:24] <jml> vila: hello!
[10:24] <jml> so, another thing about colo branches
[10:24] <jml> is that I would like to have a better default push location
[10:25] <jml> when I was using directory-per-branch, then I could easily have an appendpath policy for ~/src such that ~/src/some-project/fix-a-thing would have a push location of lp:~jml/some-project/fix-a-thing
[10:25] <vila> jml: in locations.conf you mean ?
[10:26] <jml> what I'd like is for my colo branch of file:///home/jml/src/some-project,branch=fix-a-thing to have a default push location of lp:~jml/some-project/fix-a-thing
[10:26] <jml> vila: yes
[10:26] <jml> if you'll excuse a multi-line paste...
[10:26] <jml> [/home/jml/repos]
[10:26] <jml> public_branch = lp:~jml
[10:26] <jml> public_branch:policy = appendpath
[10:26] <jml> push_location = lp:~jml
[10:26] <jml> push_location:policy = appendpath
[10:26] <vila> jml: did you look at {dirname} in recent bzr versions ? Hmm, not it will work for colos though
[10:26] <jml> that's what I have in locations.conf and it works great for directory-per-branch
[10:27] <vila> err, basename not dirname
[10:27] <jml> vila: is that a substitution variable thing?
[10:27] <vila> yes
[10:27] <vila> I use it this way:
[10:27] <vila> [/home/vila/src/udd]
[10:27] <vila> mypush = lp:~vila/udd/{basename}
[10:27] <jml> vila: perhaps all that's needed then for what I want is another substitution variable for branch name / nick?
[10:28] <vila> and then use: bzr push `bzr config mypush` so that I can *still* set push_location in branch.conf
[10:29] <vila> yeah, nick again...
[10:30] <jml> brb
[10:32] <vila> in theory (hand wawe), 'nickname' should be a branch option defaulting to branch.nick or something (evil is in the details)
[10:38] <jml> I guess I don't really understand the theory
[10:39] <jml> partly because I don't really understand what 'bzr branches' does.
[10:39] <vila> jml: as of today, 'nickname' exists in branch.conf only when you use 'bzr nick' or bzr-loom
[10:39] <vila> so it's not a registered config option and cannot be tweaked like 'basename' is
[10:40] <vila> hmm, 'basename' is not a registered option either, but that irrelevant (bad faith hand waving)
[10:40] <jml> vila: should I care about nickname being configurable?
[10:40] <jml> I don't right now.
[10:42] <vila> jml: the actual implementation *relies* on nickname being a config option
[10:42] <jml> vila: oh. implementation. pshaw. :)
[10:42] <vila> jml: i.e. if 'nickname' exists in branch.conf, that's what it's used ;)
[10:42] <vila> s/it's/is/
[10:43] <vila> urgh, looking at branch._get_nick, it seems to be a bit more complex, but anyhow, the config option can be involved ;)
[10:45] <vila> roughly (IIRC) the current implementation will query the master branch to get its nick, we've discussed using the config option as authoritative and update it when needed instead
[10:45] <vila> jml: getting there will mean you'll be able to rely on it always being right and as such use it as {nickname}
[10:46] <jml> vila: ok. I don't think I've ever noticed it being wrong though :)
[10:46] <vila> jml: it depends on how you looked at it :)
[10:46] <vila> bzr nick or bzr config
[12:52] <jml> vila: I never use bzr config.
[12:53] <vila> jml: give it a try ;)
[12:53] <jml> is there a consensus on what's best practice: to merge, resolve conflicts, commit, fix tests, then commit; or to merge, resolve conflicts, fix tests and then commit only once for the whole thing
[12:54] <vila> jml: I think it's still an open debate and a personal taste, I tend to do the later even if I would prefer the former
[12:55] <vila> ideally bzr should provide a way to look at how what was done during the 'fix conflicts, tests and code' phase as sometimes there can be non-trivial changes there
[12:55] <jml> vila: yeah. I just had quite a fiddly merge to do, and I sort of wished I had a diff of the things I was doing to fix the tests, so I could verify their correctness
[12:56] <jml> vila: right.
[12:56] <mgedmin> jml: would something like git's staging are be useful for this?
[12:56] <mgedmin> s/are/area/
[12:57] <jml> mgedmin: I don't know enough about git to answer that
[13:03] <jelmer> mgedmin: I don't see how the staging area would help in that regard
[13:04] <mgz> hm, 500 again from wiki.bazaar.canonical.com page
[13:05] <mgz> I guess I should bug #is or something? seems random rather than completely reproducable
[13:05] <mgedmin> well, the staging area separates the changes you've done (merging conflicts) from the changes you're still working on (fixing tests)
[13:05] <mgedmin> you can see either diff separately
[13:06] <mgedmin> s/see/review/
[13:06] <jelmer> mgedmin: at that point, but not once the commit has happened
[13:06] <mgedmin> right
[13:06] <jelmer> hmm, or was that what jml was saying?
[13:06] <mgedmin> "I sort of wished I had a diff of the things I was doing to fix the tests, so I could verify their correctness"
[13:07] <mgedmin> yeah, that would be possible before commit, but not after
[13:07] <jelmer> mgedmin: right, but while you're doiung those things or if you're reviewing somebody else's merge?
[13:07] <jml> I guess the way I think of it is like a little nested line of revisions
[13:07] <jml> which I guess is what a branch is
[13:07] <jelmer> I guess something like the staging area helps for the first but not the latter
[13:45] <vila> jml: I think the following should be quite close: merge, fix conflicts, commit, fix tests, uncommit, commit
[13:45] <vila> the uncommit is optional ;)
[13:47] <jml> vila: yeah, that would be quite close.
[13:47]  * mgedmin was wondering what happens if you uncommit when you have changes in your working tree
[13:47] <vila> mgedmin: you get more or less changes depending on your changes ;)
[13:48] <vila> but generally you get more changes and your branch tip is updated to the previous version
[13:49] <mgedmin> is it possible to undo an accidental uncommit?
[13:51] <jelmer> mgedmin: yes, "bzr uncommit" will tell you how to do so
[13:53] <mgedmin> cool
[13:54] <jml> huh
[13:54] <jml> the name of the current branch in a colo is not 'bzr nick'
[13:54] <jml> is there any command line for getting the name of the current branch?
[13:55] <jelmer> jml: 'bzr branches'
[13:55] <jml> jelmer: just the name of the current branch
[13:55] <jelmer> no, there isn't anything that can tell you that at the moment
[13:55] <jml> jelmer: ta
[13:58] <abentley> jml: in 2.5, the name of the current branch in a colo is the default for 'bzr nick'.
[13:59] <jml> abentley: I'm using 2.6.0dev1, apparently
[13:59] <abentley> jml: I landed it last week, so it should hit dev the next time someone merges.
[14:07] <jml> abentley: cool.
[14:12] <abentley> jelmer: I think I may have been unclear in bug #933178.  Does it make sense now?
[14:13] <jelmer> abentley: ah, I think I understand what you mean now
[14:13] <jelmer> abentley: I think we agree on what the right behaviour should be
[14:13] <abentley> jelmer: great.
[14:50] <jml> in a colo, how would I 'revert' a file to match the file in another branch?
[14:51] <jml> (in dir-per-branch, I'd just copy the file)
[15:06] <LarstiQ> jml: `bzr cat` it from the other branch?
[15:06] <jml> LarstiQ: that's what I ended up doing. not ideal.
[15:06] <james_w> can you use -r branch: to refer to a colo branch?
[18:01] <mandel> is there a way to add custom prefixes to bzr? I'd like to be able to branch from lp like the following bzr branch mandel:ubuntu-sso-client/branch
[18:02] <mandel> mainly because I'd like to have a prefix per member of my team since some of them have very long nicknames..
[18:06] <mgedmin> mandel, http://doc.bazaar.canonical.com/plugins/en/bookmarks-plugin.html might help you
[18:14] <mandel> mgedmin, thx!
[21:04] <poolie> hi barry?