| KhaZ | Hrmm. I'm trying to use 'bzr launchpad-login' and I get a crash within urllib2_wrappers.py. Anyone not going wrong? Am I running an inappropriate version of Python for use with bzr? (2.5.2?) | 00:22 |
|---|---|---|
| Peng_ | KhaZ: bzr version, and pastebin the traceback | 00:25 |
| KhaZ | I'm running 1.12 dev. Let me get on that pasetbin. | 00:28 |
| KhaZ | *pastebin | 00:28 |
| KhaZ | http://pastebin.com/m38be0452 | 00:29 |
| Peng_ | KhaZ: That's a known bug. It's been discussed on the mailing list a bit. | 00:30 |
| KhaZ | Ah. Is there a workaround? | 00:30 |
| Peng_ | KhaZ: Well, you could revert to an older revision, or apply the patch on the list. | 00:31 |
| Peng_ | KhaZ: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/52120 | 00:31 |
| KhaZ | AH, thanks for the thread. I'll dig around a bit. I wonder why the patch isn't in dev? | 00:32 |
| Peng_ | KhaZ: Cuz it only came up today. | 00:33 |
| KhaZ | Outrageous. Turn around time in bzr isn't instantaneous? I'm apalled. | 00:33 |
| KhaZ | ;) Anyhow, thanks Peng_. | 00:34 |
| yml | hello good evening | 01:07 |
| yml | I have put some file on the shelve : bzr shelve file1 file2 file3 | 01:09 |
| yml | in order to do an automic commit | 01:10 |
| yml | now I would like to bring them back into my working tree | 01:11 |
| yml | I found that bzr unshelve do what I want but I can have several shelve I would like to know if it is possible to : list them, name each shelf wit a meaning full name, explore their content ? | 01:13 |
| === abadger19991 is now known as abadger1999 | ||
| bob2 | yml: bzr help shelve/bzr help unshelve | 01:51 |
| yml | bob2 I read them both but I haven't find answer to my questions | 02:40 |
| Peng_ | jelmer: Is bzr-svn's "discovering revisions" progress bar supposed to say the progress is a negative number? | 06:32 |
| Lo-lan-do | Oooh, network <3 | 08:38 |
| Peng_ | ? | 08:39 |
| Lo-lan-do | FOSDEM wireless. | 08:39 |
| Peng_ | Ah. | 08:40 |
| Lo-lan-do | Let us say it hasn't proved very reliable yesterday. | 08:40 |
| Lo-lan-do | LarstiQ: I pushed the current (almost empty) results of what we did yesterday at http://bzr.debian.org/bzr/users/lolando/misc/bzr-gc | 09:02 |
| jelmer | Peng_, Nope, that's a bug. | 11:50 |
| AfC | Uh | 12:02 |
| AfC | $ bzr info | 12:02 |
| AfC | Repository branch (format: 1.12-preview or 1.9) | 12:02 |
| AfC | ... | 12:02 |
| AfC | what the hell? | 12:02 |
| jelmer | AfC, Hi! | 12:05 |
| jelmer | AfC, ? | 12:05 |
| jelmer | AfC: What is the problem there? The fact that it mentions two formats? | 12:06 |
| jelmer | AfC, this is because those formats are the same except for the working tree format | 12:06 |
| AfC | I'm asking what's with the "or" in the statement given by `info` about the format in place in the branch. Given that it was created with --format="1.9" I have no idea what that statement means,. | 12:06 |
| AfC | But worse is that it sounds like Bazaar doesn't know. | 12:06 |
| jelmer | the problem is that if there is no working tree, there is no way to distinguish between the two formats | 12:07 |
| AfC | I cannot believe the core developer of a tool that purports to be a clean user experience exposed that kind of uncertainty in the UI. | 12:07 |
| AfC | jelmer: perhaps I could suggest that if there is no Working Tree present to not report about such things then. If it doesn't know, it doesn't know. | 12:08 |
| jelmer | AfC: In that case, it couldn't print a format at all if you are in a shared repository | 12:09 |
| jelmer | AfC, there is technically no difference between the two formats if you don't have a working tree, so I don't think there is any uncertainty here | 12:09 |
| jelmer | AfC, I can agree it's a bit strange, but I don't see a good way to fix this.. | 12:10 |
| jelmer | AfC, what would you rather see? | 12:10 |
| jelmer | bzr could just show you one format I guess, that would be technically less accurate but less confiusing too | 12:10 |
| AfC | I just don't want Bazaar embarrassing itself in front of users. We made so much of the premise that bzr was a better user experience than other tools, but this is precisely the sort of thing that causes us to squander such branch equity. | 12:11 |
| AfC | ... such brand* equity. | 12:12 |
| AfC | :) | 12:12 |
| Peng_ | Can we file that under "yes, we know bzr has too many formats" and ignore it? :D | 12:28 |
| LarstiQ | Jc2k: you around somewhere? | 12:32 |
| bialix | Peng_: what? again? | 12:34 |
| Peng_ | bialix: It was about "bzr info" showing stuff like "Repository branch (format: 1.12-preview or 1.9)" :) | 12:35 |
| bialix | oh | 12:35 |
| bialix | wait | 12:35 |
| bialix | how about this: | 12:35 |
| bialix | Lightweight checkout (format: 1.6 or 1.6.1-rich-root or 1.9 or 1.9-rich-root or dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack) | 12:35 |
| bialix | IMO there is stil the room for dozen formats | 12:36 |
| Peng_ | Hahaha. That's excellent. :) | 12:36 |
| Peng_ | Too bad the subtree formats are hidden. | 12:36 |
| bialix | yeah | 12:36 |
| Peng_ | I think we scared AfC away. | 12:38 |
| bialix | :-D | 12:38 |
| bialix | lol | 12:38 |
| LarstiQ | poor guy :) | 12:38 |
| Peng_ | Wait a minute, why is the lightweight checkout list in that order? In order of age, that's like 5, 5, 6, 6, 1, 2, 3, 4, 3. | 12:40 |
| Peng_ | Err, that should be 5, 5, 6, 6, 1, 2, 4, 3, 4. | 12:40 |
| Peng_ | ...Oh, alphabetical. | 12:40 |
| * Peng_ bonks himself on teh head | 12:40 | |
| bialix | we need add randomizer I guess | 12:42 |
| bialix | so there will be everytime something new | 12:43 |
| Peng_ | That's a horrible, evil, excellent idea. | 12:43 |
| Peng_ | ...It'd make blackbox tests a bit tricky though. | 12:43 |
| bialix | put them in a set? | 12:44 |
| bialix | and check the set | 12:44 |
| * bialix don't think there is blackbox for light checkout info | 12:45 | |
| Peng_ | Good point. It would still be slightly more complicated though. | 12:45 |
| Jc2k | LarstiQ: im at the front of the cross desktop room | 13:32 |
| Adys | This sounds stupid, but I cant find how to refetch a folder I deleted by mistake from the remote working branch | 15:52 |
| Adys | er, make that, refetch the folder from the remote working branch, which I deleted locally | 15:53 |
| Adys | right, bzr revert * | 16:06 |
| === ja1 is now known as jam | ||
| bialix | what is the equivalent to os.path.join in bzrlib? osutils.join? | 17:23 |
| * bialix found osutils messy | 17:24 | |
| santagada | bialix: http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.osutils.html | 17:25 |
| santagada | I think it is joinpath | 17:25 |
| pi_m | Hi. Can I ask you? I am new to Bazaar and I really, really can't understand one thing (yes, I have read the user guide and the user reference manual first). It is shared repository. In the texts mentioned above is written that shared repository is created after "init-repo" command. New branches could be created by "init" command executed from the shared repo. Can you tell me what the branches share and if they depend on other branches in the shared repo? | 17:25 |
| bialix | share history | 17:26 |
| pi_m | bialix: History? Do you mean the commits? | 17:27 |
| nevans | yep. all of the commits are stored in the shared repo. so if two branches have the same commits, then they won't be duplicated | 17:27 |
| nevans | it becomes a little bit more obvious if you sneak a peek into the .bzr directories. | 17:28 |
| bialix | yep | 17:28 |
| nevans | normally, a branch's .bzr dir will contain a branch, checkout, and repository subdirs | 17:29 |
| nevans | for a standalone branch, that is. | 17:29 |
| santagada | in the end the result is the same as the common working of svn I think | 17:29 |
| santagada | is you copy files around it will not copy history | 17:29 |
| santagada | copy/branch | 17:29 |
| pi_m | nevans: So it is good to have a shared repo if you have some branches that have some common code (uh)? | 17:30 |
| santagada | pi_m: only if they share the same commits | 17:30 |
| nevans | pi_m: common history. I use shared repos whenever I expect to work on many branches of the same project. | 17:30 |
| santagada | pi_m: which is the usual thing when you work on branches | 17:31 |
| bialix | santagada: joinpath -> Undocumented :-P | 17:31 |
| bialix | I guess pathjoin actually is right | 17:31 |
| nevans | actually, I've got a single shared repo for all of my work projects... even though some of them don't share commits. it's just simpler than having a shared repo per project. | 17:31 |
| pi_m | santagada: Yes. So placing the different project's branches to shared repo has no sense, I think... | 17:31 |
| santagada | bialix: at least you know the name :D | 17:31 |
| bialix | problem is: there are 2 functions: joinpath and pathjoin | 17:32 |
| santagada | pi_m: it doesn't help... but it is not a performance problem either (i'm guessing here) | 17:32 |
| nevans | pi_m: if you look into a branch's .bzr (under a shared repo), you'll only see branch and checkout dirs. and the shared repo's .bzr will contain the repository. | 17:32 |
| nevans | and if you run du on any .bzr dir, you'll see that the repo dir is always the largest. | 17:33 |
| bialix | santagada: pathjoin = os.path.join | 17:34 |
| bialix | :-P | 17:34 |
| * bialix anyway thinks osutils.py is messy | 17:34 | |
| santagada | bialix: thanks... i'm also trying to learn the bzr api | 17:34 |
| nevans | pi_m: so if you have 5 branches that are fairly similar (and most branches within a project are), and their working trees take ~20MB, and their repos each take ~100MB, then it would take ~600MB to store them without a shared-repo, and ~200MB with a shared repo | 17:35 |
| * bialix using this api for several years and anyway it's messy | 17:35 | |
| nevans | and since there's less disk usage, certain operations will also run more quickly with a shared repo (e.g. bzr branch) | 17:36 |
| pi_m | Thank you, your advices were very useful! | 17:37 |
| KhaZ | Can I ask why there is an osutils versus using the os.path stuff? | 17:40 |
| === asac__ is now known as asac | ||
| bialix | KhaZ: cross-platform support | 17:45 |
| santagada | let's just be franc that os.path.join is cross platform | 17:46 |
| santagada | what is diffente on osutils? stat? | 17:46 |
| KhaZ | Aye, I thought os.path.join *is* cross platform. Although I do realize that a lot of stuff in Python wraps it nicely but doesn't necessarily yield the same results.. | 17:48 |
| bialix | the difference is: osutils try to canonicalize the path after transformation to one standard | 17:49 |
| bialix | always / as path separator, even on windows | 17:50 |
| bialix | fix drive letter for windows and some other small details | 17:50 |
| KhaZ | Ah, gotcha. Hrmm. I'm sure the patch I submitted'll be rejected based on that alone. ;) | 17:50 |
| bialix | what? | 17:50 |
| KhaZ | Heh, just that I ended up using os.path and stuff directly in the patch I submitted w/RFC. | 17:51 |
| bialix | don't worry, you'll get detailed review and precise hints what to use instead | 17:52 |
| * bialix son't remember all gory details | 17:52 | |
| bialix | s/son't/don't/ | 17:53 |
| KhaZ | Just be gentle. ;) | 17:55 |
| bialix | sorry | 17:59 |
| Phill | Hey guys, I'm confused on how to use bzr, what should I be doing... (bzr add, commit, and then push?) or should I have done merge? It's a two person project, and now we seemingly messed it up with conflicts in some auto-gen files. I'm thoroughly confused. | 18:33 |
| bialix | if the files auto-generated you'd probably better re-generate them? | 18:38 |
| Phill | I can't seem to do that? | 18:38 |
| bialix | I don't understand | 18:38 |
| Phill | Well, I don't know why, but it seems bzr thinks there was a conflict and put it's TREE, MERGE etc things into the file. | 18:39 |
| Phill | The file was created once... I don't think it should've ever changed, so I don't know why Bzr says it changed, here, one second, let me look at it's diff. | 18:39 |
| bialix | do you know how to solve 3-way merge conflicts? | 18:39 |
| Phill | Nope! | 18:39 |
| Phill | I don't know how to solve 2-way merge conflicts :) | 18:40 |
| Phill | Ignorance ain't bliss. | 18:40 |
| bialix | read `bzr help conflicts` first, please | 18:40 |
| Phill | Aight. | 18:40 |
| bialix | you're interested in text conflicts section | 18:41 |
| Phill | Yeah, reading that now. | 18:42 |
| Phill | I think, I can actually auto-gen this file, but not the others, let's give the auto-gen a shot. | 18:42 |
| bialix | yep | 18:43 |
| Phill | Ok, so, it just to make sure I have this clear, it sticks two files into each other if it doesn't know what to do? | 18:49 |
| Phill | Like, the earlier revision, and then the later one? | 18:49 |
| bialix | no | 18:50 |
| bialix | it tries to be intelligent and combine common parts together | 18:50 |
| Phill | Then why does it look like the same xml document twice over? | 18:50 |
| bialix | if you have 2 files entirely in conflict there is different line-endings perhaps | 18:50 |
| Phill | Mmm. | 18:51 |
| bialix | check .THIS and .OTHER in binary mode | 18:51 |
| Phill | I just deleted the second one and hope it works ;-) (That's bad practice!) | 18:51 |
| bialix | you can repeat merge ;-) | 18:51 |
| bialix | `bzr resolve` will delete this junk automatically | 18:51 |
| Phill | Ok, so I'm taking it my usual, "Bzr add, commit, pull" isn't the way to do stuff? | 18:52 |
| Phill | Not pull, push I mean. | 18:52 |
| Phill | bzr add, commit, push | 18:52 |
| Phill | I always thought push and merge were the same thing... | 18:53 |
| Phill | bialix: Or let me rephrase, I Thought pushing merged as well - automatically, take it as a no? | 18:56 |
| bialix | no | 18:56 |
| bialix | you should get 'branches are diverged' error -- then you need to merge locally and then push again | 18:57 |
| Phill | They weren't diverged (I assume, I never got that error), it was 20-21 21-22, etc. Basically, I worked on it, then my friend did, we just kept our code base in sync... | 18:57 |
| Phill | He worked at home, I worked at school, so - that's why we never merged. | 18:58 |
| bialix | you're pull when you need get his changes | 18:59 |
| Phill | Yep, that's what I did. | 18:59 |
| bialix | and push when you need to publish your changes | 18:59 |
| Phill | and then I pushed when I had changes. | 18:59 |
| bialix | so? | 18:59 |
| Phill | Why the conflicts? | 18:59 |
| bialix | you did pull? | 19:00 |
| Phill | Yep. | 19:00 |
| bialix | you had uncommitted changes in your branch | 19:00 |
| Phill | Yeah, About to say that. | 19:00 |
| Phill | And then I pulled. | 19:00 |
| Phill | = Errors. | 19:00 |
| Phill | Right? | 19:00 |
| Phill | Should I always commit before pulling then? | 19:01 |
| bialix | bzr did merge for you because you had uncommitted changes | 19:01 |
| Phill | Then merge before pushing? | 19:01 |
| Phill | Ahh, that's nice of it. | 19:01 |
| bialix | you'd better have 2 branches | 19:01 |
| bialix | 1 branch is exact mirror of remote | 19:01 |
| bialix | 2nd branch for your own work | 19:01 |
| bialix | you did pull only in 1st branch | 19:02 |
| Phill | I didn't even know I had two branches. | 19:02 |
| bialix | no | 19:02 |
| bialix | sorry | 19:02 |
| bialix | may be my English is not ideal | 19:02 |
| Phill | Nah; not your fault, I don't know what I'm doing. (That's my fault) :) | 19:02 |
| bialix | will be better if you create 2 branches to work on | 19:02 |
| Phill | Yeah. | 19:02 |
| Phill | and then merge them, right? | 19:03 |
| bialix | if they are diverged -- yes merge | 19:03 |
| Phill | Yeah. | 19:03 |
| bialix | if not diverged -- just pull from 1 to 2 | 19:03 |
| Phill | Yeah. | 19:03 |
| Phill | Diverged means, mismatched revision numbers - right? | 19:03 |
| bialix | you can do `bzr merge --pull` and bzr selects appropriate action to you | 19:03 |
| bialix | not exactly numbers | 19:04 |
| bialix | say you have revision 20, and your friend too | 19:04 |
| bialix | your branches are full mirror of each other | 19:04 |
| bialix | then you change say file foo.txt and commit | 19:05 |
| bialix | but in the same time your friend change file bar.txt and also commit | 19:05 |
| bialix | you both will have revision 21, but they are different | 19:05 |
| Phill | so, I should do bzr merge -pull from now on? So it just does whatevers right for us? | 19:05 |
| bialix | ok? | 19:06 |
| Phill | bzr merge --pull | 19:06 |
| Phill | Yeah, that's cool. | 19:06 |
| Phill | I get it now :) | 19:06 |
| bialix | yes, it's safe choice | 19:06 |
| bialix | you can create alias | 19:06 |
| Phill | Boy do I need that one then ;-) | 19:06 |
| * bialix is not boy | 19:07 | |
| Phill | Er, figure of speech. | 19:07 |
| bialix | creating alias will save you typing this everytime | 19:07 |
| bialix | check `bzr alias -h` for details | 19:07 |
| Phill | I don't have alias? | 19:08 |
| Phill | bzr alias -h bzr: ERROR: unknown command "alias" | 19:09 |
| bialix | bzr version | 19:09 |
| bialix | what is your bzr version? | 19:10 |
| Phill | Bazaar (bzr) 1.3.1 | 19:10 |
| Phill | I take it, that that is old. | 19:10 |
| bialix | very old | 19:10 |
| Phill | :) | 19:10 |
| Phill | I probably got it from the repo long ago. | 19:10 |
| bialix | you'd better upgrade | 19:10 |
| Phill | Yep, yep. | 19:10 |
| Phill | Haha. | 19:10 |
| bialix | I bet you're on Ubuntu | 19:10 |
| Phill | Haha. | 19:10 |
| bialix | no? | 19:11 |
| Phill | Wow, Ubuntu is going to be what Windows was to the world. "Oh, you're on "UBUNTU". | 19:11 |
| Phill | Yeah I am. | 19:11 |
| bialix | I'm on Windows | 19:11 |
| bialix | hehe | 19:11 |
| Phill | I never upgraded the newest version of Ubuntu, I don't really care for it - waiting for 9.10 (I think) in April. | 19:11 |
| bialix | read instructions on how to update bzr at bazaar-vcs.org | 19:12 |
| Phill | And I think I installed this through a .deb package so it doesn't auto-update. =/ | 19:12 |
| Phill | I can't uninstall/reinstall newest? | 19:12 |
| bialix | go to Download page, look for Ubuntu and read instructions | 19:12 |
| Phill | kk | 19:12 |
| bialix | you should be able to aapt-get | 19:13 |
| Phill | Oh cool, it has it's own apt server. | 19:13 |
| Phill | Didn't know this. | 19:14 |
| bialix | many people don't know | 19:18 |
| Phill | I don't get it... bzr is worked on by conical - why don't they just put it in the main repo branch? | 19:19 |
| Phill | Bazaar (bzr) 1.11 | 19:19 |
| Phill | Now what? | 19:19 |
| bialix | where? | 19:20 |
| Phill | Huh? That's what my up-to-date bzr is. | 19:20 |
| Phill | 1.11, rather than whatever it use to be. | 19:20 |
| bialix | now `bzr alias` will work :-) | 19:20 |
| Phill | Cool. | 19:21 |
| bialix | :-D | 19:21 |
| Phill | Ok, so if I do bzr resolve, it delete the >>TREE stuff, right? | 19:22 |
| bialix | yep | 19:23 |
| bialix | np | 19:23 |
| bialix | no | 19:23 |
| bialix | sorry | 19:23 |
| Phill | Confused, what? | 19:24 |
| bialix | you need to resolve conflict (with meld e.g.) and then run `bzr resolve` | 19:24 |
| Phill | meld? | 19:24 |
| bialix | if the file has no '<<<< >>>>' markers then .THIS .BASE .OTHER files will be deleted | 19:25 |
| Phill | Yeah, it's just a properties file that I don't care about, so I removed the <<<< markers and called it a day. ;-) | 19:25 |
| Phill | Probably not a good thing, but whatever. | 19:25 |
| Phill | Ok, here's a good one. | 19:26 |
| Phill | Text conflict in pangea/nbproject/genfiles.properties | 19:26 |
| Phill | That file doesn't exist? | 19:26 |
| Phill | Found out why, I deleted it, my bad. Nevermind. | 19:27 |
| Phill | Ok, so all my conflicts are gone, thanks to ya' :) Though, here's what I need help with, sorta? It'll take a second to type it down - ready? | 19:30 |
| Phill | I've branched from revision 20 (the last one that worked) and pulled to 21, and then fixed the conflicts. The latest revision however is 23. | 19:31 |
| Phill | How can I merge with 22-23? | 19:32 |
| bialix | brrr | 19:37 |
| bialix | again | 19:37 |
| bialix | bzr commit your current state | 19:37 |
| Phill | Did so | 19:38 |
| bialix | then bzr merge | 19:38 |
| Phill | I did... | 19:38 |
| Phill | bzr merge --pull | 19:38 |
| bialix | so? | 19:38 |
| bialix | bzr st | 19:38 |
| Phill | actually, I did bzr merge --pull -r 22 | 19:38 |
| Phill | I don't want rev 23 atm. | 19:38 |
| Phill | Two conflits. | 19:38 |
| Phill | Conflicts* | 19:38 |
| bialix | resolve them | 19:38 |
| bialix | then commit | 19:39 |
| Phill | Ok, this is a different conflict though. | 19:39 |
| Phill | Conflict adding file pangea/build/classes/pangea/resources/New Folder. | 19:39 |
| Phill | The other thing is I have "PangeaVIew.class" to PangeaView$39.class, (Using Netbeans) but I think these files were from bzr. Do I need them? | 19:42 |
| Phill | Nevermind, I answered my own question, Yes I do need them. | 19:42 |
| Phill | bialix: Ok, so - here's one more thing I want to know how to do, remove stuff from bzr version control. | 19:56 |
| Phill | I have a lot of junk classes and old images I no longer want bzr to keep track of, in fact, I wanted them deleted. | 19:56 |
| Phill | What do I do? | 19:56 |
| bialix | either just delete them | 19:59 |
| bialix | or use bzr remove | 19:59 |
| bialix | with bzr remove you have fine grained control, read `bzr remove -h` | 20:00 |
| Phill | I used bzr remove. | 20:00 |
| Phill | Deleting them made bzr just throw them back up when I pull again. | 20:01 |
| bialix | delete + commit | 20:01 |
| bialix | but `bzr remove` is better way | 20:01 |
| Phill | Mmk. | 20:01 |
| bialix | "explicit" | 20:01 |
| Phill | Off hand, what's the better thing about it? | 20:01 |
| bialix | explicit is better than implicit | 20:02 |
| bialix | just don't forget commit | 20:02 |
| bialix | Phill: try this `python -c "import this"` :-D | 20:03 |
| Phill | I've learned not to use commands that I don't know, but hey, you can try rm -r / | 20:04 |
| * bialix on Windows | 20:04 | |
| Phill | Oh right. | 20:04 |
| Phill | Darn. | 20:04 |
| bialix | :-P | 20:04 |
| Phill | Open up fdisk and figure out how to nuke your cdrive, I'm to lazy. ;-P | 20:04 |
| bialix | format c: | 20:05 |
| bialix | it's easy | 20:05 |
| Phill | Yeah, I've since forgotten 90% of the commands that aren't related to the Cisco IOS. | 20:05 |
| Phill | It's a bummer. | 20:05 |
| bialix | ok | 20:05 |
| Phill | Ok, now this is the last thing, bzr alias? | 20:07 |
| thumper | morning | 20:08 |
| bialix | just remembered: if you like the risk in life, try to run format c: drive | 20:08 |
| Phill | Thumper? | 20:08 |
| thumper | Phill: I may have missed some context, but aliases aren't exactly new | 20:08 |
| Phill | Oh no, I think I recognized you from another form. | 20:08 |
| Phill | forum* | 20:08 |
| bialix | Phill: last thing for what? | 20:08 |
| bialix | thumper: hi | 20:08 |
| Phill | Thumper: Ever been on the Firefox support forums? | 20:09 |
| thumper | Phill: no | 20:09 |
| Phill | Thumper: Wrong thumper then. | 20:09 |
| bialix | no, he's right thumer | 20:09 |
| thumper | Phill: just different :) | 20:10 |
| Phill | Ahh. | 20:10 |
| Phill | What's a good alias for bzr merge --pull ... | 20:11 |
| bialix | maybe: get-the-new-stuff | 20:11 |
| bialix | ;-) | 20:11 |
| Phill | Mmm. | 20:12 |
| Phill | get-new | 20:12 |
| Phill | OR, sync. | 20:12 |
| bialix | not bad | 20:12 |
| Phill | get-sync | 20:12 |
| bialix | actually I think "sync" is good | 20:12 |
| Phill | yep | 20:13 |
| Phill | and the command was "merge --pull" right? | 20:13 |
| bialix | right | 20:13 |
| Phill | Neeto. | 20:13 |
| Phill | That's not a word. | 20:13 |
| bialix | не то? | 20:14 |
| bialix | or не это? | 20:14 |
| Phill | I don't know? | 20:14 |
| Phill | Ok, so, when I push back up, I can just run bzr push right? | 20:15 |
| bialix | never mind | 20:15 |
| Phill | Or should I do "bzr merge --push" ? | 20:15 |
| bialix | yes | 20:15 |
| bialix | no | 20:15 |
| Phill | ok | 20:15 |
| bialix | merge is when you get the new stuff | 20:15 |
| bialix | you can't do merge for remote server | 20:16 |
| bialix | just push | 20:16 |
| Phill | Oh ok. | 20:17 |
| Phill | Well thanks. | 20:17 |
| Phill | Any other cool things you could teach me about launchpad and bzr? lol | 20:17 |
| bialix | tomorrow | 20:18 |
| Phill | haha | 20:19 |
| Phill | sure ;-) | 20:19 |
| lifeless | Adys: just revert foldername | 20:25 |
| lifeless | Adys: or if you want to revert everything, just 'revert' | 20:25 |
| tro | did anyone end up volunteering for that editor thing kfogel proposed on the ml? | 20:53 |
| Stavros | hello | 20:57 |
| Stavros | i tried to do bzr shelve and bzr is crapping out now | 20:57 |
| Stavros | i have 1.11 | 20:57 |
| garyvdm | Stavros: crapping out -> how? Can you pastebin a traceback? | 21:03 |
| Stavros | it's not crashing, but bzr shelve tells me that it can't acquire a lock and then does strange stuff like telling me to break a lock before telling me again it can't acquire another | 21:03 |
| Stavros | bzr: ERROR: Could not acquire lock "repo/.bzr/checkout/dirstate" | 21:04 |
| garyvdm | It should tell you who created the lock that is blocking you. | 21:04 |
| Stavros | i'm the only user | 21:04 |
| tro | Stavros: are you using windows? | 21:04 |
| Stavros | yes | 21:04 |
| tro | i think you may be using the new shelf (shelf2) which doesn't work with windows yet | 21:05 |
| Stavros | oh | 21:05 |
| Stavros | hmm | 21:05 |
| Stavros | shouldn't it print something, then? :/ | 21:05 |
| tro | there's probably a way to use shelf1. maybe someone else knows? | 21:05 |
| Stavros | it's okay, i just wanted to shelve one file, so i committed it, but the errors were odd | 21:05 |
| tro | i'm still using an older version of bzr, so i don't know what the solution is, sorry :/ | 21:06 |
| Stavros | ah, thanks anyway | 21:06 |
| thumper | you could alias shelve to shelf1 (if that is the command) | 21:15 |
| * thumper wonders why the new shelve doesn't work with windows | 21:16 | |
| * thumper looks at abentley | 21:16 | |
| thumper | abentley: should the new shelve have problems with windows? | 21:16 |
| bialix | 1.12 should work fine | 21:17 |
| bialix | jam fixed it | 21:17 |
| garyvdm | Hi bialix | 21:49 |
| bialix | Hi Gary | 21:50 |
| bialix | I've edited NEWS | 21:50 |
| bialix | you'd better look at it with fresh eye | 21:50 |
| garyvdm | Ok - will do | 21:50 |
| bialix | because difftools is not mandatory thing | 21:50 |
| bialix | as you said | 21:51 |
| bialix | Do you have specific question to me? | 21:51 |
| garyvdm | I've been trying to build a deb - but I got frustrated - move on to more intresting things. | 21:51 |
| garyvdm | I'm looking at how I can use igc's revno-cache plugin to improve qlog's startup performance | 21:51 |
| bialix | ouch | 21:51 |
| bialix | garyvdm, we can skip the deb, I guess | 21:52 |
| bialix | at least people don't poke us everyday | 21:52 |
| bialix | as they are do about bzrtools | 21:52 |
| bialix | ;-) | 21:52 |
| garyvdm | And the deb can come after the release - hopefully shortly | 21:52 |
| bialix | garyvdm: about revno-cache | 21:53 |
| garyvdm | If we use revno-cache - we would have to stop showing the children in the revision plane | 21:53 |
| bialix | igc told me it's working mostly as revno->revid map today | 21:53 |
| garyvdm | because you have to walk the whole tree to find the children. | 21:54 |
| bialix | um? sorry, can you explain | 21:54 |
| garyvdm | In the bottom plane of qlog - we show parent and children for the selected revisions | 21:54 |
| garyvdm | *revision | 21:54 |
| bialix | yes | 21:54 |
| bialix | we show both revno and revid | 21:55 |
| garyvdm | To find the parents - you just have to make one call to the graph | 21:55 |
| bialix | I think it should simplify walking through the history | 21:55 |
| garyvdm | but to find the children - you have to load the parents for every revisions. | 21:56 |
| garyvdm | Right now - we have to do that anyway to create merge_sorted_revisions | 21:56 |
| kfogel | tro: no, but people have been writing the scenarios, and I've been using them to help with, e.g., http://www.emacswiki.org/emacs-en/EmacsBzrSwitchover | 21:57 |
| bialix | wait, I'm running qlog to follow you | 21:57 |
| kfogel | tro: I suspect I'll just end up editing them myself | 21:57 |
| kfogel | tro: unless... you're volunteering to help? :)- | 21:57 |
| kfogel | :-) | 21:57 |
| garyvdm | revno-cache caches merge_sorted_revisions | 21:57 |
| garyvdm | I can do all the other functionality just from the data from merge_sorted_revisions - with out loading the whole graph | 21:58 |
| * bialix ran qlog with LANG=C and sees now what garyvdm means | 21:58 | |
| garyvdm | except displaying children | 21:59 |
| bialix | this is qreat idea | 21:59 |
| garyvdm | qreat - intentional mistake? | 21:59 |
| bialix | no, by Freud | 21:59 |
| garyvdm | ha ha | 21:59 |
| bialix | so | 21:59 |
| bialix | we'll lose the ability to find branched history? | 22:00 |
| bialix | I can't say I'm use the parent/children links too much | 22:01 |
| garyvdm | No - qlog will be able to do everything it currently does, except display children in the revision plane. | 22:01 |
| bialix | so I'm probably even did not notice if they disappear | 22:01 |
| garyvdm | And only load the parent for the revisions that are diaplayed | 22:01 |
| bialix | garyvdm: I mean no more click on children will go to that revision | 22:02 |
| garyvdm | Yes | 22:02 |
| bialix | may be it's better to post this as rfc to qbzr ml. if luks won't object -- I'll be fine | 22:02 |
| garyvdm | Ok - WIll do | 22:03 |
| bialix | in theory we can load this data lazily in the background after main history has loaded? | 22:03 |
| garyvdm | Yes - we can do that to | 22:03 |
| bialix | how we'll behave without revno-cache? | 22:04 |
| garyvdm | Good idea | 22:04 |
| garyvdm | Same as before | 22:04 |
| bialix | I like it | 22:04 |
| bialix | qbzr reuse many goodness already exisiting in bzr world | 22:04 |
| garyvdm | And it will only do this if you are loading 1 branch. | 22:04 |
| bialix | btw Gary, I'd like to discuss with you dichotomy with 1/several branches | 22:05 |
| garyvdm | If you are loading more than 1 branch - It will have to load everythin. | 22:05 |
| bialix | ah | 22:05 |
| * garyvdm looks up the meaning of dichotomy | 22:05 | |
| jelmer | Jc2k, I fixed dpush into git on the train, it's working now :-) | 22:05 |
| bialix | garyvdm: I want to add more actions to context menu | 22:06 |
| garyvdm | ok | 22:06 |
| bialix | like tags, push, merge | 22:06 |
| garyvdm | revert | 22:06 |
| bialix | but those actions should know the branch | 22:07 |
| bialix | I need either allow actions for 1 branch mode | 22:07 |
| poolie | lifeless: why did you approve johnf for bzr-beta-ppa? | 22:07 |
| bialix | garyvdm: or to have the proper way detect/select branch in multi mode | 22:08 |
| garyvdm | It's easy to get from a revision to a branch/repository | 22:08 |
| bialix | garyvdm: this is also related to bug about taga on multibranches | 22:08 |
| bialix | s/taga/tags/ | 22:08 |
| garyvdm | but a revision may have more than one branch. | 22:08 |
| bialix | this is *the* problem | 22:09 |
| bialix | can you suggest easy way to detect if qlog started in multibranch mode? | 22:09 |
| garyvdm | My re-factored branch is much better at this. | 22:10 |
| bialix | IIRC t should landed shortly | 22:10 |
| garyvdm | len(log_list.graph_provider.branches) | 22:10 |
| garyvdm | Yes - I'll land it after we release 0.9.7 | 22:11 |
| bialix | poolie: hi, plans about 1.12 is the same? we need to release QBzr in sync with bzr | 22:11 |
| poolie | bialix: still planning to do rc1 tomorrow my time and final friday | 22:11 |
| poolie | synchronized release would be nice | 22:11 |
| bialix | garyvdm did very good job to support new progress bar | 22:12 |
| bialix | he's our release manager for 0.9.7 :-) | 22:12 |
| * garyvdm is nervous | 22:12 | |
| poolie | ah great :) | 22:12 |
| bialix | poolie: your time is about? | 22:13 |
| poolie | utc+11 | 22:13 |
| poolie | ie it's monday morning now | 22:13 |
| garyvdm | Down under? | 22:13 |
| bialix | garyvdm: ? | 22:13 |
| garyvdm | Slang for Australia/New Zeeland | 22:14 |
| bialix | ah | 22:14 |
| garyvdm | reference to it's position on the world map | 22:14 |
| bialix | garyvdm: I think you can release it anytime soon | 22:15 |
| bialix | even tonight, if you like | 22:15 |
| garyvdm | Ok | 22:15 |
| bialix | I'll be there couple of hours, coding scmproj | 22:15 |
| bialix | so you can ping me if needed | 22:16 |
| garyvdm | Thanks | 22:16 |
| bialix | I'm usually simply follow the instruction | 22:16 |
| lifeless | poolie: because he's going to help keep the ppa up to date? | 22:20 |
| garyvdm | bialix: Should I mention updated translations in NEWS.txt? | 22:37 |
| bialix | garyvdm: I never do this, only new ones | 22:38 |
| garyvdm | Ok | 22:38 |
| bialix | the list of updated could be loong sometimes | 22:38 |
| poolie | lifeless: is he? | 22:40 |
| garyvdm | poolie: do you think this will land before 1.12? http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090126072506.GA30864%40steerpike.home.puzzling.org%3E | 22:40 |
| garyvdm | It causes a bug in qbzr. | 22:41 |
| poolie | lifeless: ok i see your reply to jam about that | 22:41 |
| poolie | did he suggest it offline? | 22:41 |
| poolie | i'm just asking because people seem to randomly request to join groups all the time | 22:42 |
| lifeless | poolie: yes, he chatted here on friday about that; he packages stuff elsewhere in Debian format (I don't recall if he's a DD offhand), etc | 22:42 |
| poolie | because of poor ui i guess | 22:42 |
| poolie | great | 22:42 |
| lifeless | poolie: so, randoms I would have declined :P | 22:42 |
| poolie | also iwbn if the 'request to join' let people specify a rationale | 22:42 |
| poolie | i realize he's not very random | 22:42 |
| poolie | lifeless: ah, bug 4976 | 22:45 |
| ubottu | Launchpad bug 4976 in launchpad-registry "When trying to join a team, user should be able to give comment" [Wishlist,Triaged] https://launchpad.net/bugs/4976 | 22:45 |
| garyvdm | ls | 22:50 |
| lifeless | abentley: if you could review http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1233892193.12070.112.camel%40lifeless-64%3E that would be lovely | 22:50 |
| lifeless | abentley: its a shelve/treetransform bug and I'm on shaky ground there | 22:50 |
| bialix | poolie: can you help gary? | 22:52 |
| * poolie looks | 22:53 | |
| poolie | garyvdm, bialix: i approved it (enthusiastically :-) so we need to poke spiv | 22:54 |
| poolie | i think vila's approach is a bit better, of hooking in at the socket level | 22:54 |
| poolie | but we can unify them later | 22:54 |
| garyvdm | Actualy - I'm hoping it's not going to land :-( | 22:54 |
| garyvdm | >It causes a bug in qbzr. | 22:54 |
| poolie | oh i see | 22:55 |
| poolie | i thought you meant lack of it causes a bug | 22:55 |
| Jc2k | jelmer: awesome! | 22:55 |
| lifeless | garyvdm: whats the bug | 22:56 |
| garyvdm | Bug 325924 | 22:57 |
| ubottu | Launchpad bug 325924 in qbzr "TooManyConcurrentRequests with traffic reporting for smart media." [Medium,Confirmed] https://launchpad.net/bugs/325924 | 22:57 |
| poolie | srsly | 22:57 |
| poolie | that exception should be shot | 22:58 |
| bialix | garyvdm: it affects on;y qlog? | 23:00 |
| bialix | only | 23:00 |
| garyvdm | In theroy no - but in pratice - I have not seen it any where else | 23:01 |
| garyvdm | Let me do some testing | 23:01 |
| spiv | garyvdm: I find it odd that the traffic-smart branch would cause that. | 23:02 |
| spiv | Unless it's because of some side-effect like the GUI blocking without it? | 23:02 |
| lifeless | spiv: or not blocking | 23:03 |
| lifeless | garyvdm: does qbzr use threads, or is it synchronous? | 23:03 |
| garyvdm | synchronous | 23:03 |
| === kiko is now known as kiko-afk | ||
| garyvdm | It's really a bug with qbzr - not that branch | 23:04 |
| garyvdm | When we get notified of transport activity - we do a processEvents() | 23:04 |
| garyvdm | Which would allow more than 1 simultaneous request. | 23:05 |
| bialix | garyvdm: what's there before? | 23:07 |
| bialix | maybe we need temporarily disable monitoring of transport activity in qbzr? | 23:08 |
| spiv | garyvdm: ah, in that case I'd expect vila's patch for HTTP traffic reporting would cause the same issue with bzr+http:// | 23:12 |
| lifeless | garyvdm: so processEvents handles an aritrary amount of user input ? | 23:13 |
| garyvdm | spiv: I'm not sure - I don't know the transport code to well. | 23:13 |
| garyvdm | spiv: It will happen with any transport that does not allow concurrent requests, and reports traffic. | 23:14 |
| lifeless | we have a sync api to transport | 23:15 |
| lifeless | garyvdm: can you not call processEvents? | 23:15 |
| garyvdm | lifeless: Then it won't display the transport activity | 23:16 |
| garyvdm | lifeless: processEvents is normally called in the event loop, but you can also call it during long running processes to keep the ui responsive. | 23:17 |
| garyvdm | http://doc.trolltech.com/3.2/qeventloop.html#processEvents | 23:18 |
| garyvdm | Newer version: http://doc.trolltech.com/4.0/qeventloop.html#processEvents | 23:18 |
| bialix | garyvdm: but I see you've disabled user input. this is not enough? | 23:22 |
| garyvdm | Was just about to give some detail on that - just a sec | 23:22 |
| * bialix waits | 23:22 | |
| garyvdm | That fixes that bug in 99% of cases | 23:23 |
| garyvdm | In qlog: when you click on a rev - we set a timer to load the delta to show that changed files. | 23:24 |
| bialix | yes | 23:25 |
| garyvdm | That timer may get called from a processEvents called during notify_transport_activity | 23:25 |
| bialix | got it | 23:25 |
| bialix | imo we have hidden problem there | 23:27 |
| bialix | even for concurent transports | 23:27 |
| bialix | as a quick fix we can use some flag at qlog instance to prevent loading delta untill we finishing with main request | 23:28 |
| garyvdm | bialix: What's that? | 23:28 |
| garyvdm | (hidden problem) | 23:29 |
| bialix | we don't have a way to reuse connection? | 23:29 |
| garyvdm | bialix: We do reuse connections | 23:29 |
| bialix | but anyway we got the error | 23:30 |
| bialix | I think simple queue may help as you wrote in bug report | 23:31 |
| bialix | but it'snot quick fix | 23:31 |
| bialix | we talk about log.py update_revision_delta? | 23:33 |
| garyvdm | Yes | 23:33 |
| bialix | and uifactory? | 23:33 |
| garyvdm | With my patch to not allow user event - it very difficult to reproduce. | 23:34 |
| garyvdm | Yes | 23:34 |
| bialix | mmm | 23:35 |
| poolie | (out for a little bit) | 23:35 |
| garyvdm | http://pastebin.com/d26b9c3b1 | 23:36 |
| garyvdm | bialix: log.py update_revision_delta is the only place I've been able to reproduce it. | 23:38 |
| * bialix looks | 23:39 | |
| garyvdm | bialix: How about - in update_revision_delta - try... execpt TooManyConcurrentRequests reschedule the timer | 23:39 |
| garyvdm | as a quick fix. | 23:40 |
| bialix | but the traceback actually points to logmodel | 23:40 |
| garyvdm | Ahhhh | 23:40 |
| bialix | i'm thinking about using simple lock | 23:41 |
| bialix | and if the lock is acquired -- then reshedule the timer | 23:41 |
| bialix | this will affects any transport | 23:42 |
| bialix | ? | 23:42 |
| garyvdm | Yes- as a quick fix | 23:42 |
| bialix | thread.Lock | 23:42 |
| bialix | from std lib | 23:43 |
| garyvdm | That won't work | 23:43 |
| bialix | ? | 23:43 |
| garyvdm | Here is a different traceback from my .bzr.log: http://pastebin.com/d7d18c473 | 23:43 |
| garyvdm | bialix: we are not using threading. | 23:44 |
| garyvdm | A simple is_loading_revisions will do though. | 23:44 |
| bialix | IMO this lock should not require real threading | 23:45 |
| bialix | ok, fine | 23:45 |
| bialix | re 2nd traceback: yep, i guess it's 50%-50% effect | 23:46 |
| === UdontKnow is now known as ObiWanQueNoob | ||
| bialix | anyway we disable input | 23:47 |
| mwhudson | hm | 23:47 |
| garyvdm | Long term fix - have a queue - re-enable input | 23:47 |
| mwhudson | i remember bzr has some knob you can twiddle wrt decorators like @needs_read_lock | 23:47 |
| mwhudson | do you get fast or pretty ones by default? | 23:48 |
| lifeless | fast by default I beleve | 23:48 |
| mwhudson | oh goof | 23:49 |
| mwhudson | good! | 23:49 |
| garyvdm | mwhudson: All the requests that qbzr make allready have read_locks. It unfortunately does not prevent TooManyConcurrentRequests | 23:51 |
| bialix | garyvdm: agree. we can live with current situation for a while | 23:51 |
| garyvdm | Anyway - we don't want to prevent the request - we want to make it happen later. | 23:51 |
| === ObiWanQueNoob is now known as root | ||
| * bialix mutters: although for local branch we can avoid locking | 23:53 | |
| mwhudson | garyvdm: i'm worrying about my own problems, not yours :) | 23:53 |
| * bialix out of good ideas | 23:53 | |
| garyvdm | bialix: Not necessary to not lock for local - because local does not report transport. | 23:54 |
| garyvdm | mwhudson: oh! | 23:54 |
| bialix | garyvdm: it's a bit late for me. sometimes morning is smarter than evening. don't worry too much about 1% bug tonight | 23:55 |
| garyvdm | I'm a night owl... I'm sure I can put a quick fix in. | 23:55 |
| * garyvdm ignores irc for a while. | 23:56 | |
| * bialix too, but he needs to sleep sometimes | 23:56 | |
| bialix | garyvdm: bye | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!