| === beuno_ is now known as beuno | ||
| === 13WAAIDLL is now known as wallyworld | ||
| === wallyworld is now known as Guest76072 | ||
| nigelb | hi! | 04:10 |
|---|---|---|
| nigelb | I just ran into https://bugs.launchpad.net/bzr/+bug/375013 with tarmac. | 04:11 |
| ubot5 | Ubuntu bug 375013 in Launchpad itself "Cannot commit directly to a stacked branch" [High,Fix released] | 04:11 |
| nigelb | the solution is to unstack the branch I presume? | 04:11 |
| lifeless | nigelb: newer bzr should work | 04:34 |
| nigelb | lifeless: hrm, its a lucid server. let me hunt for a ppa. thanks. | 04:36 |
| mgz | morning all | 09:01 |
| vila | hi all <cough> <cough> ! | 10:09 |
| * mgz pats vila on the back | 10:12 | |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| vila | and then use: bzr push `bzr config mypush` so that I can *still* set push_location in branch.conf | 10:28 |
| vila | yeah, nick again... | 10:29 |
| jml | brb | 10:30 |
| vila | in theory (hand wawe), 'nickname' should be a branch option defaulting to branch.nick or something (evil is in the details) | 10:32 |
| jml | I guess I don't really understand the theory | 10:38 |
| 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:39 |
| 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:40 |
| 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:42 |
| vila | urgh, looking at branch._get_nick, it seems to be a bit more complex, but anyhow, the config option can be involved ;) | 10:43 |
| 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:45 |
| 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 | 10:46 |
| jml | vila: I never use bzr config. | 12:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| jml | mgedmin: I don't know enough about git to answer that | 12:57 |
| jelmer | mgedmin: I don't see how the staging area would help in that regard | 13:03 |
| mgz | hm, 500 again from wiki.bazaar.canonical.com page | 13:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:45 |
| === yofel_ is now known as yofel | ||
| 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:47 |
| vila | but generally you get more changes and your branch tip is updated to the previous version | 13:48 |
| mgedmin | is it possible to undo an accidental uncommit? | 13:49 |
| jelmer | mgedmin: yes, "bzr uncommit" will tell you how to do so | 13:51 |
| mgedmin | cool | 13:53 |
| 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:54 |
| 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:55 |
| abentley | jml: in 2.5, the name of the current branch in a colo is the default for 'bzr nick'. | 13:58 |
| 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. | 13:59 |
| jml | abentley: cool. | 14:07 |
| abentley | jelmer: I think I may have been unclear in bug #933178. Does it make sense now? | 14:12 |
| ubot5 | Launchpad bug 933178 in Bazaar "switch doesn't find sibling branches when colocated" [Undecided,New] https://launchpad.net/bugs/933178 | 14:12 |
| 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:13 |
| jml | in 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 |
| 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? | 15:06 |
| === Quintasan_ is now known as Quintasan | ||
| === jordan__ is now known as jordan | ||
| 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:01 |
| mandel | mainly because I'd like to have a prefix per member of my team since some of them have very long nicknames.. | 18:02 |
| mgedmin | mandel, http://doc.bazaar.canonical.com/plugins/en/bookmarks-plugin.html might help you | 18:06 |
| mandel | mgedmin, thx! | 18:14 |
| poolie | hi barry? | 21:04 |
| === lifeless_ is now known as lifeless | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!