=== beuno_ is now known as beuno
=== 13WAAIDLL is now known as wallyworld
=== wallyworld is now known as Guest76072
nigelbI just ran into https://bugs.launchpad.net/bzr/+bug/375013 with tarmac.04:11
ubot5Ubuntu bug 375013 in Launchpad itself "Cannot commit directly to a stacked branch" [High,Fix released]04:11
nigelbthe solution is to unstack the branch I presume?04:11
lifelessnigelb: newer bzr should work04:34
nigelblifeless: hrm, its a lucid server. let me hunt for a ppa. thanks.04:36
mgzmorning all09:01
vilahi all <cough> <cough> !10:09
* mgz pats vila on the back10:12
jmlvila: hello!10:24
jmlso, another thing about colo branches10:24
jmlis that I would like to have a better default push location10:24
jmlwhen 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-thing10:25
vilajml: in locations.conf you mean ?10:25
jmlwhat 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-thing10:26
jmlvila: yes10:26
jmlif you'll excuse a multi-line paste...10:26
jmlpublic_branch = lp:~jml10:26
jmlpublic_branch:policy = appendpath10:26
jmlpush_location = lp:~jml10:26
jmlpush_location:policy = appendpath10:26
vilajml: did you look at {dirname} in recent bzr versions ? Hmm, not it will work for colos though10:26
jmlthat's what I have in locations.conf and it works great for directory-per-branch10:26
vilaerr, basename not dirname10:27
jmlvila: is that a substitution variable thing?10:27
vilaI use it this way:10:27
vilamypush = lp:~vila/udd/{basename}10:27
jmlvila: perhaps all that's needed then for what I want is another substitution variable for branch name / nick?10:27
vilaand then use: bzr push `bzr config mypush` so that I can *still* set push_location in branch.conf10:28
vilayeah, nick again...10:29
vilain theory (hand wawe), 'nickname' should be a branch option defaulting to branch.nick or something (evil is in the details)10:32
jmlI guess I don't really understand the theory10:38
jmlpartly because I don't really understand what 'bzr branches' does.10:39
vilajml: as of today, 'nickname' exists in branch.conf only when you use 'bzr nick' or bzr-loom10:39
vilaso it's not a registered config option and cannot be tweaked like 'basename' is10:39
vilahmm, 'basename' is not a registered option either, but that irrelevant (bad faith hand waving)10:40
jmlvila: should I care about nickname being configurable?10:40
jmlI don't right now.10:40
vilajml: the actual implementation *relies* on nickname being a config option10:42
jmlvila: oh. implementation. pshaw. :)10:42
vilajml: i.e. if 'nickname' exists in branch.conf, that's what it's used ;)10:42
vilaurgh, looking at branch._get_nick, it seems to be a bit more complex, but anyhow, the config option can be involved ;)10:43
vilaroughly (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 instead10:45
vilajml: getting there will mean you'll be able to rely on it always being right and as such use it as {nickname}10:45
jmlvila: ok. I don't think I've ever noticed it being wrong though :)10:46
vilajml: it depends on how you looked at it :)10:46
vilabzr nick or bzr config10:46
jmlvila: I never use bzr config.12:52
vilajml: give it a try ;)12:53
jmlis 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 thing12:53
vilajml: I think it's still an open debate and a personal taste, I tend to do the later even if I would prefer the former12:54
vilaideally 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 there12:55
jmlvila: 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 correctness12:55
jmlvila: right.12:56
mgedminjml: would something like git's staging are be useful for this?12:56
jmlmgedmin: I don't know enough about git to answer that12:57
jelmermgedmin: I don't see how the staging area would help in that regard13:03
mgzhm, 500 again from wiki.bazaar.canonical.com page13:04
mgzI guess I should bug #is or something? seems random rather than completely reproducable13:05
mgedminwell, the staging area separates the changes you've done (merging conflicts) from the changes you're still working on (fixing tests)13:05
mgedminyou can see either diff separately13:05
jelmermgedmin: at that point, but not once the commit has happened13:06
jelmerhmm, 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:06
mgedminyeah, that would be possible before commit, but not after13:07
jelmermgedmin: right, but while you're doiung those things or if you're reviewing somebody else's merge?13:07
jmlI guess the way I think of it is like a little nested line of revisions13:07
jmlwhich I guess is what a branch is13:07
jelmerI guess something like the staging area helps for the first but not the latter13:07
vilajml: I think the following should be quite close: merge, fix conflicts, commit, fix tests, uncommit, commit13:45
vilathe uncommit is optional ;)13:45
=== yofel_ is now known as yofel
jmlvila: yeah, that would be quite close.13:47
* mgedmin was wondering what happens if you uncommit when you have changes in your working tree13:47
vilamgedmin: you get more or less changes depending on your changes ;)13:47
vilabut generally you get more changes and your branch tip is updated to the previous version13:48
mgedminis it possible to undo an accidental uncommit?13:49
jelmermgedmin: yes, "bzr uncommit" will tell you how to do so13:51
jmlthe name of the current branch in a colo is not 'bzr nick'13:54
jmlis there any command line for getting the name of the current branch?13:54
jelmerjml: 'bzr branches'13:55
jmljelmer: just the name of the current branch13:55
jelmerno, there isn't anything that can tell you that at the moment13:55
jmljelmer: ta13:55
abentleyjml: in 2.5, the name of the current branch in a colo is the default for 'bzr nick'.13:58
jmlabentley: I'm using 2.6.0dev1, apparently13:59
abentleyjml: I landed it last week, so it should hit dev the next time someone merges.13:59
jmlabentley: cool.14:07
abentleyjelmer: I think I may have been unclear in bug #933178.  Does it make sense now?14:12
ubot5Launchpad bug 933178 in Bazaar "switch doesn't find sibling branches when colocated" [Undecided,New] https://launchpad.net/bugs/93317814:12
jelmerabentley: ah, I think I understand what you mean now14:13
jelmerabentley: I think we agree on what the right behaviour should be14:13
abentleyjelmer: great.14:13
jmlin a colo, how would I 'revert' a file to match the file in another branch?14:50
jml(in dir-per-branch, I'd just copy the file)14:51
LarstiQjml: `bzr cat` it from the other branch?15:06
jmlLarstiQ: that's what I ended up doing. not ideal.15:06
james_wcan you use -r branch: to refer to a colo branch?15:06
=== Quintasan_ is now known as Quintasan
=== jordan__ is now known as jordan
mandelis 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/branch18:01
mandelmainly because I'd like to have a prefix per member of my team since some of them have very long nicknames..18:02
mgedminmandel, http://doc.bazaar.canonical.com/plugins/en/bookmarks-plugin.html might help you18:06
mandelmgedmin, thx!18:14
pooliehi barry?21:04
=== lifeless_ is now known as lifeless

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!