| gour | morning | 07:43 |
|---|---|---|
| gour | i've few programs for which i keep their config files under dvcs...now we are going to switch to bzr and wonder whether you recommend to use lightweight checkouts for 'working trees' and keep repos separately with --no-trees ? | 07:44 |
| mgz | morning | 08:10 |
| jelmer | hi | 08:17 |
| * jelmer is having fun fighting with pbuilder chroots | 09:36 | |
| mgz | and I thought you had debian packaging entirely tamed jelmer... are the chroots defeated yet? | 10:29 |
| jelmer | ish | 10:29 |
| jelmer | the fact I'm running quantal seems to be breaking me up :) | 10:29 |
| jelmer | mgz: what mischief are you up to? | 10:29 |
| jelmer | also, we still seem to have a fair number of issues with encodings in 2.6 :( | 10:32 |
| mgz | the usual silliness, and seeing what hacks need fixing or documenting before I can post the mp I promised last week | 10:32 |
| mgz | jelmer: just need to merge all our branches up I think | 10:32 |
| jelmer | mgz: from where? | 10:33 |
| mgz | 2.2->2.3 and 2.5->2.6 and some of the ones inbetween | 10:34 |
| jelmer | k | 10:35 |
| gour | /q | 10:50 |
| mgz | jelmer: I see you've started the merge up, but 2.3 doesn't seem to have landed and you've got 2.3->2.4 up? | 11:18 |
| === zyga is now known as zyga-food | ||
| abentley | jam, is anyone patch-piloting? I have a couple MPs I'd like reviewed. | 13:59 |
| jam | abentley: I think we're watching the queue, but nobody is specifically focused on it. You're welcome to request reviews. | 13:59 |
| === zyga-food is now known as zyga | ||
| === yofel_ is now known as yofel | ||
| gour | i just played a bit with bzr's lightweight co-s emulating "Switching a lightweight checkout" section (http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/reusing_a_checkout.html) and i had a feeling that this feature should enable me to create sandboxed directory wich is goingto be populatd by different working trees based on the 'switch' command | 15:21 |
| gour | now i see that it works this way :-) | 15:21 |
| gour | but i must say that the code example was (is) a bit misleading to me...so i propose the following one... | 15:22 |
| gour | http://pastebin.com/cRi6vYgB | 15:25 |
| gour | conclusion: treeless branches in (no-tree) shared repo, feature branches, lightweight checkouts...easy switching between them...great stuff and we love bzr's simplicity & power :-) | 15:27 |
| mgz | gour: note also `bzr switch -b NAME` to create sibling feature branches is handy | 15:31 |
| gour | mgz: hmm, does it mean, if i'm e.g. on master branch, that bzr switch -b feature1 branch will 'clone' a master branch into feature1 and switch on it? | 15:33 |
| mgz | yup. | 15:35 |
| gour | very handy...thumbs up | 15:35 |
| gour | it seems to me that bzr is really nicely designed despite changing its format (too) often in the past, so understanding why so many people are enamored by git is well beyond me :-} | 15:37 |
| LeoNerd | Format changes should have been prettymuch invisible to users, though | 15:40 |
| gour | LeoNerd: well, it was a bit irritating in the past | 16:04 |
| LeoNerd | Eh.. it was a mild inconvenience at times but I don't recall ever being actually uspet by it | 16:05 |
| jelmer | gour: the last format change is more than three years ago at this point | 16:08 |
| gour | i know that 2a is stable and do not complain...just sayign that | 16:13 |
| gour | foramt changes in the past created a feeling that bzr is not stable...that's all | 16:14 |
| gour | otherwise i wouldn't be here today ;) | 16:14 |
| mgz | jelmer: bug 1014626 / 1014627 should still be dupes of bug 966934 I think, were they from after you did the 2.5 merge to dev? | 16:32 |
| ubot5 | Launchpad bug 1014626 in Bazaar "UnicodeEncodeError formatting translated message during merge" [Medium,Triaged] https://launchpad.net/bugs/1014626 | 16:32 |
| ubot5 | Launchpad bug 966934 in Bazaar "[i18n] bzr commands affected working tree crashed with unicode error in non-english locale" [High,In progress] https://launchpad.net/bugs/966934 | 16:32 |
| JordiGH | How do you checkout/update to a past revision? | 17:38 |
| mgz | use -r, see `bzr help update` | 17:40 |
| JordiGH | I did see it, but I couldn't figure out what -r meant. | 17:40 |
| JordiGH | Am I using the right word? | 17:40 |
| mgz | depending on exactly what you're trying to do, you may want revert instead. | 17:40 |
| JordiGH | I want my working tree to be at a specified revision. | 17:41 |
| mgz | did you try it? | 17:41 |
| JordiGH | Yeah, but I don't know if it worked. | 17:41 |
| JordiGH | How do I know at what revision I'm currently in? | 17:41 |
| mgz | `bzr revno --tree` | 17:41 |
| JordiGH | Okay, is that done with revert or update? I did both. | 17:42 |
| mgz | revert changes the state of the tree (files on disk), but not the branch, update changes both | 17:43 |
| mgz | so, after a revert, `bzr st` will tell you stuff has changed from the current branch state | 17:43 |
| JordiGH | But update seems to try to merge changes... | 17:44 |
| JordiGH | I ended up with merge conflict markers. | 17:44 |
| JordiGH | I don't want that. | 17:44 |
| mgz | did you have local changes? | 17:44 |
| mgz | changing the tree always means you may get conflicts | 17:45 |
| mgz | if you're sure there's nothing in the current state you want keep, a plain bzr revert will throw everything out | 17:46 |
| JordiGH | I didn't make any, but I don't know if bzr decided I had changes because there's been updates and reverts. | 17:47 |
| mgz | perhaps, if you're not sure, you can always look at your .bzr.log to see exactly what happened | 17:47 |
| mgz | `bzr version` will tell you where to find it. | 17:48 |
| === zyga is now known as zyga-afk | ||
| JordiGH | Ooh, nice feature. | 17:48 |
| mgz | and you can always get a copy of an older revision cleanly by creating a new tree, `bzr checkout --lightweight -r-6 . ../old_rev` for instance | 17:48 |
| JordiGH | So, just to make sure I have the right terminology... | 17:49 |
| JordiGH | if I do "bzr update -r foo" that means change the state of the current directory to whatever is stored in that branch? | 17:50 |
| JordiGH | What happens if you commit there? Do you just painlessly branch off? | 17:50 |
| JordiGH | Wait, what is a "branch" in bzr? | 17:50 |
| JordiGH | It's not a path in the DAG, is it? | 17:50 |
| JordiGH | It's also a working directory? | 17:50 |
| mgz | see <http://doc.bazaar.canonical.com/beta/en/user-guide/core_concepts.html> | 17:51 |
| mgz | if you try to commit it will prevent you from doing so by default | 17:53 |
| mgz | what you probably want is two branches, but just work in the one directory | 17:56 |
| mgz | as that's what I imagine you're used to with other tools | 17:57 |
| mgz | if you describe the actual task you're trying to do, rather than just the step, that might help | 17:58 |
| JordiGH | No, what I'm used to with hg is to commit wherever I want and for things to branch off naturally. | 18:17 |
| JordiGH | "branch" in bzr also seems to mean "working tree". | 18:17 |
| JordiGH | Or directory. | 18:17 |
| jelmer | JordiGH: a branch is a line of history | 18:18 |
| JordiGH | Does "branch" also mean "clone" in bzr? You even use the branch command when you want to clone a repo. | 18:25 |
| jelmer | JordiGH: a branch and a clone are the same thing at the moment | 18:34 |
| jelmer | JordiGH: since each control directory usually holds a single branch, and not multiple like in git or hg | 18:35 |
| JordiGH | Alright. | 18:36 |
| JordiGH | So how do you branch off at a past revision? | 18:36 |
| JordiGH | You update to a past revision, and you do a special kind of commit? | 18:37 |
| jelmer | JordiGH: update the branch to a past revision or update the working tree state to the same state as in a past revision? | 18:44 |
| jelmer | "bzr up -rREV" for the first, "bzr revert -rREV" for the latter | 18:44 |
| JordiGH | So "update the branch" means... what? | 18:45 |
| jelmer | JordiGH: resetting the branch to an older revision | 18:45 |
| jelmer | I guess the equivalent in git would be "git reset COMMITTISH" | 18:45 |
| JordiGH | And "the branch" means the working directory? | 18:45 |
| JordiGH | I don't do git. | 18:45 |
| jelmer | JordiGH: no, the branch is the history | 18:45 |
| JordiGH | So reset the history? | 18:46 |
| jelmer | JordiGH: so "bzr up -rREV" would make the branch look like the history ended at REV | 18:46 |
| JordiGH | How do I see the DAG? | 18:48 |
| jelmer | JordiGH: bzr log | 18:48 |
| JordiGH | That's just the log entries. | 18:48 |
| JordiGH | How do I see what's an ancestor of what? | 18:48 |
| jelmer | or for a more graphical one, "bzr qlog" or "bzr viz" | 18:48 |
| JordiGH | bzr: ERROR: unknown command "viz" | 18:48 |
| JordiGH | But qlog seems to be doing something... | 18:49 |
| jelmer | JordiGH: the log will show that (right hand side ancestors are shown indented) | 18:49 |
| JordiGH | Starting Qt? | 18:49 |
| jelmer | JordiGH: viz is part of the bzr-gtk plugin, qlog is part of the qbzr plugin | 18:49 |
| JordiGH | So it's like git that when you update to an earlier revision, it looks like later revisions disappear? | 18:49 |
| jelmer | JordiGH: well, that's if you use "bzr up -rREV" | 18:52 |
| jelmer | if you just want to reset the working tree to the same state as in a previous revision, use "bzr revert -rREV" | 18:52 |
| JordiGH | But then bzr st thinks I modified all files. | 18:52 |
| jelmer | JordiGH: right, because the last revision didn't have those changes | 18:53 |
| jelmer | JordiGH: and bzr st by default shows the changes between the working tree and the last revision | 18:53 |
| jelmer | if you just want to create a new revision that resets the state of the tree, just commit chose changes | 18:54 |
| jelmer | e.g. bzr commit -m "Revert back to rREV." | 18:54 |
| JordiGH | How does bzr keep revisions centralised? | 19:28 |
| JordiGH | heh, idgi | 19:28 |
| jelmer | JordiGH: they're in the control directory (.bzr/repository) | 19:31 |
| santagada | I want to see a graph of two branches, what they have in common and what differs in terms of commits, how can I do that with bzr? | 19:42 |
| jelmer | santagada: bzr missing | 19:50 |
| santagada | jelmer: thanks | 19:51 |
| santagada | :) | 19:51 |
| santagada | jelmer: docs don't mention missing... or I didn't find it | 19:51 |
| santagada | but thanks a lot if really did solve my problem | 19:54 |
| santagada | now I will slowly merge revisions that are missing | 19:54 |
| JordiGH | A pull also updates, right? | 20:18 |
| JordiGH | And an update also merges, right? | 20:18 |
| jelmer | JordiGH: in the hg terminology, pull indeed also updates the working tree | 20:18 |
| JordiGH | How can you pull revisions without touching the working directory? | 20:19 |
| MvG | Hi! IWe've got a Windows machine here with TortoiseBzr which reports a lot of x-bit changes for a working tree. I'm a bit confused about this, as I didn't think Windows NTFS had such a thing. I guess most regular Windows users would be even more confused. Can someone around here tell me what could give bzrlib the idea of such changes? | 22:25 |
| mwhudson | is there some cute way i can suppress this message: | 22:25 |
| mwhudson | <doanac> I also finished the conversation with some advice I told him I realized he didn't have to pay attention to. | 22:25 |
| mwhudson | <doanac> i said - if i were you, I'd focus on making zach happy (even in spare time), because that's the best thing you could do for your career right now | 22:25 |
| mwhudson | <doanac> he said he understood, but I don't think he can resist this urge. | 22:25 |
| mwhudson | <mwhudson> heh | 22:25 |
| mwhudson | <mwhudson> he really is a strange guy | 22:25 |
| mwhudson | <doanac> I think he's wanting to create an entirely new community that's a "fork" of LAVA | 22:25 |
| mwhudson | <doanac> I asked "fork"? he said - well, a rewrite is a kind of fork | 22:25 |
| mwhudson | <doanac> i found that part a bit amusing | 22:25 |
| mwhudson | <doanac> its not like anybody can stop him, but I had to be clear he can't use "lava" in the branding of what he does | 22:25 |
| mwhudson | <mwhudson> good idea | 22:25 |
| mwhudson | <doanac> and maybe we'll come crawling back to him some day. as he said, finishing up the rest of porting stuff to lava-core was easy :) | 22:25 |
| mwhudson | oh ffs | 22:25 |
| mwhudson | ! | 22:25 |
| mwhudson | You have not informed bzr of your Launchpad ID, and you must do this to | 22:25 |
| mwhudson | write to Launchpad or access private data. See "bzr help launchpad-login". | 22:25 |
| lifeless | mwhudson: which message :P | 22:31 |
| mwhudson | lifeless: the one about launchpad :( | 22:31 |
| lifeless | bzr launchpad-login mwhudson, I think. | 22:32 |
| mwhudson | lifeless: without doing that | 22:32 |
| lifeless | don't use lp: urls. | 22:32 |
| mwhudson | lifeless: i have been using bzr and launchpad for a /little/ while after all... | 22:33 |
| mwhudson | yeah, that might be easiest | 22:33 |
| lifeless | or use bzr's library | 22:38 |
| lifeless | whats the use case ? | 22:38 |
| mwhudson | lifeless: just avoiding spam when running a script | 22:38 |
| mwhudson | lifeless: just half a thought that there might be some config option i could set | 22:38 |
| === jelmer is now known as Guest12454 | ||
| Guest12454 | mwhudson: you can set launchpad_username ? | 22:58 |
| mwhudson | Guest12454: i want to use the http transport, but don't want to be nagged about it | 22:59 |
| Guest12454 | ah | 22:59 |
| Guest12454 | we discussed having a lp+http:// URL scheme at some point | 22:59 |
| Guest12454 | but that never emerged | 22:59 |
| === Guest12454 is now known as jelmer | ||
| mwhudson | jelmer: ok | 23:01 |
| mwhudson | jelmer: i guess if that itch strikes again i know what to do... | 23:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!