| === marienz_ is now known as marienz | ||
| icule | Hi, gang! I'm in the process of learning / trying Bazaar. My background is Git, so I'm trying to reformulate my Git habits with Bazaar. One thing I miss is, having many branches over a shared repository, seeing them all at once (a bit like I do with gitk). Any hint or idea? | 00:32 |
|---|---|---|
| AuroraBorealis | bazaar explorer can do that | 00:33 |
| AuroraBorealis | which is the GUI written in qt4 | 00:33 |
| icule | I start it at the level of the shared repository? | 00:33 |
| AuroraBorealis | are you using it right now? | 00:34 |
| icule | Yes. But I'm pretty new to all this, so you might have to take me by the hand a bit :-). | 00:34 |
| AuroraBorealis | so you just go to "open exisiting location" | 00:34 |
| AuroraBorealis | and open up the shared repo | 00:34 |
| AuroraBorealis | and it should list all the branches that are under it | 00:34 |
| icule | (I have to find the equivalent translation for the terms you use. Maybe I'll restart explorer with the English locale. A minute! :-)) | 00:35 |
| icule | Do I open the top-level .bzr? | 00:37 |
| AuroraBorealis | http://i.imgur.com/uMX4l.png | 00:37 |
| AuroraBorealis | that button | 00:37 |
| AuroraBorealis | in bazaar explorer | 00:37 |
| AuroraBorealis | no you just open the folder that "is" the repositiory | 00:37 |
| AuroraBorealis | (that has the .bzr folder ) | 00:37 |
| icule | You're quick! :-) | 00:38 |
| icule | I then get a list of branches. | 00:38 |
| AuroraBorealis | yeah | 00:38 |
| AuroraBorealis | there might be a way to do it via the command line too | 00:39 |
| icule | But now, I would like the common DAG. | 00:39 |
| icule | I mean, the graph from with which I could see all branches. | 00:39 |
| icule | All DAGs of all branches combined into a single DAG. | 00:39 |
| icule | That would allow me to visually have an idea of how the branches are inter-related, the amount of commonality between them. | 00:40 |
| AuroraBorealis | DAG? | 00:40 |
| icule | (Directed Acyclic Graph) I mean, the drawing full of circles (one per commit) and the lines showing the parental relationship between them. | 00:41 |
| icule | This is at least shown with "bzr viz" and "bzr qlog". | 00:41 |
| AuroraBorealis | http://i.imgur.com/3jZfM.png | 00:41 |
| AuroraBorealis | you mean that? | 00:41 |
| icule | Yes, exactly. Currently, I can only see one branch at a time. | 00:42 |
| AuroraBorealis | well i think you only see stuff related to that branch | 00:42 |
| AuroraBorealis | like in the screenshot | 00:42 |
| AuroraBorealis | thats just one branch (the main one) | 00:42 |
| AuroraBorealis | but you can see other branches were split off and were eventually merged back into it | 00:42 |
| icule | I would like to see all branches at once, and where various branches fit in that dag. Like with gitk. | 00:42 |
| icule | (if you know it) | 00:42 |
| AuroraBorealis | so it only shows the other branches if it got merged back into | 00:43 |
| AuroraBorealis | the branch you are looking at | 00:43 |
| AuroraBorealis | but i dont think there is something like what you are talking about, which i think is the github like view | 00:43 |
| AuroraBorealis | which is a shame cause it would be awesome to have :< | 00:43 |
| icule | Hmph! I thought about merging branches randomly before examining them, but that's not negligible overhead, both human and machine. | 00:44 |
| AuroraBorealis | but yeah, unlike github (and i guess whatever else) it doesn't show the other branches if they haven't been merged back | 00:44 |
| icule | If I have many branches, and do not know how they relate to one another, there would be a lot of exploratory work and comparison to get the overall picture. So I wondered if there is any (easy) tool for that. | 00:45 |
| AuroraBorealis | https://github.com/a-musing-moose/morph/network | 00:45 |
| AuroraBorealis | is that what you mean? | 00:45 |
| AuroraBorealis | what you want at least | 00:45 |
| icule | Because one needs the overall picture *before* merging. | 00:45 |
| AuroraBorealis | but is that what you are wanting ^ like the github network grapbhs | 00:47 |
| icule | Yes, that GitHub graph shows it in some way, yet the graphics is not as clever as gitk, and the tips are a bit randomly selected (GitHub explains somewhere its algorithm). | 00:47 |
| AuroraBorealis | i dont think there is a tool that does that currently | 00:47 |
| icule | bzr viz does it nicely (more nicely than GitHub in my opinion), but a single branch at a time. | 00:47 |
| AuroraBorealis | but it would be really nice to have one. is there an paper on how they do that? cause it would be an interesting feature to work | 00:48 |
| AuroraBorealis | in | 00:48 |
| AuroraBorealis | on* | 00:48 |
| icule | OK. I just wanted to ask here. | 00:48 |
| fullermd | qlog can show multiple branches at once... | 00:48 |
| AuroraBorealis | can it? | 00:48 |
| icule | I studied Git a bit deeply, years ago, it is quite simple internally. I do not know the internals of bzr structure. Do you know if there is a document about it? | 00:48 |
| AuroraBorealis | i have no idea, but i probably should ask since i'm messing around in the code haha | 00:49 |
| icule | Git is simple enough that I understand how it is possible to merge all branches in a single place. Bazaar, I do not know. | 00:49 |
| icule | I'm slower than you. Let my try qlog. | 00:49 |
| icule | Oh, before going further, "bzr explorer" does not show graphs, does it? | 00:50 |
| AuroraBorealis | graphs? | 00:50 |
| icule | The circles and lines, like you showed me in one of your (blazing fast) screenshots. | 00:51 |
| icule | Hey hey! "bzr qlog" does it, if I start it above branches! :-) :-) | 00:51 |
| AuroraBorealis | yeah | 00:52 |
| AuroraBorealis | bazaar explorer has a "log" button | 00:52 |
| AuroraBorealis | and that starts qlog | 00:52 |
| icule | Oh, thanks for this bit of info! Nice. | 00:52 |
| AuroraBorealis | and oh crap it does. nice work whoever makes bazaar explorer hehe | 00:52 |
| icule | Another question, which may look like a criticism, but I do not mean it that way. | 00:53 |
| fullermd | A lot of what Explorer does is just launch other q-commands. | 00:53 |
| AuroraBorealis | and yeah, it works with multiple branches. i think this is what you want: http://i.imgur.com/8vgwm.png | 00:55 |
| icule | I compared "bzr viz" and "bzr qlog" a bit. Both are slow, but in a different way. "viz" preconditions its work, and is reasonable afterwards. "qlog" starts faster, but crawls more and more if I keep opening branch expansions. I guess it abuses the graphical toolkit. (Maybe both do). Is there any trick to know to regain more speed, with either of them? | 00:55 |
| AuroraBorealis | probably not. its probably just the code being a bit rough i guess | 00:55 |
| AuroraBorealis | dunno about 'viz' but qlog uses qt4, which is in c++ so qt4 isn't slow | 00:55 |
| icule | Exactly what I want. It allows me to get an overall idea of the interrelation between branches. | 00:55 |
| icule | Well, if *all* tens of thousands of commits are drawn all at once, even a C++ program would crawl. Normally, the drawing shold open lazily around the visible part of it. | 00:56 |
| fullermd | viz is gtk | 00:56 |
| icule | gtk, qt4, are likely both C or C++. Oh, you mean, with a Python wrapper or not? | 00:57 |
| * fullermd doesn't know that he'd classify qt4 as 'not slow' :p | 00:57 | |
| AuroraBorealis | bzr viz opened up in like a few seconds and drew the graph in 5 seconds | 00:58 |
| AuroraBorealis | which is pretty good considering the number of revisions... | 00:58 |
| icule | For small graphs, it likely does not matter. The repositories I'm playing with have many tens of thousands commits. | 00:58 |
| icule | I guess there is not much to do, but I do not know that much about Bazaar, so I thought that I might ignore some tricks :-). | 00:59 |
| AuroraBorealis | the bazaar trunk branch has 37,890 revisions soo | 00:59 |
| icule | AuroraBorealis: Amusing nick! :-) | 01:00 |
| AuroraBorealis | so i feel thats a fair number =P | 01:00 |
| AuroraBorealis | amusing D: | 01:00 |
| AuroraBorealis | and bzr viz is kinda crappy, you can't resize the columns so they dissapear to where you can't see them... | 01:00 |
| icule | You say, 5 seconds for 30000 commits? Nice indeed. I got the impression that qlog quickly gets slow (hmph, pun not intended) if I keep expanding merges. | 01:01 |
| icule | Thanks a lot for helping me on these things, and not bashing me over my newbeeness! | 01:02 |
| AuroraBorealis | hehe | 01:03 |
| AuroraBorealis | i mean im playing with the qlog graph | 01:03 |
| AuroraBorealis | and i see that some expansions are slow but its not unusable | 01:03 |
| AuroraBorealis | i mean, if it takes half a second to expand then...thats fine xD | 01:03 |
| icule | I should confess I've been rotten by Git, which is instantaneous in most circumstances. | 01:04 |
| AuroraBorealis | lol | 01:04 |
| icule | But then, after the expansion (which is fast) the scrolling crawls. | 01:04 |
| AuroraBorealis | i mean every program can always be faster | 01:04 |
| AuroraBorealis | its usable for me, but then again i have a pretty good video card so i dunno =P | 01:04 |
| icule | The machine I use, while not being so slow, has a few years already. It could also be part of the problem. | 01:05 |
| icule | So far, Bazaar has been reasonably fast. I was expecting worse (because of what I read). One thing which surprised me is that Bazaar repository compression is as good as Git. | 01:06 |
| AuroraBorealis | yay! | 01:06 |
| icule | How does garbage collection go in Bazaar? | 01:07 |
| AuroraBorealis | garbage collection? | 01:07 |
| icule | Suppose I have a share repositoy, and in one branch, I "bzr add" many movies :-). Then I scrap the branch. How does the space taken by the movies, in the respository, gets reclaimed? | 01:08 |
| AuroraBorealis | i am not sure. | 01:08 |
| Kamping_Kaiser | icule: are you suggesting they should be removed from the history? | 01:08 |
| AuroraBorealis | someone more knowledgeable then me will have to ask hehe | 01:08 |
| AuroraBorealis | well if he just deleted the branch | 01:09 |
| AuroraBorealis | is what i think he means | 01:09 |
| icule | Kamping_Kaiser: Should it not? | 01:09 |
| icule | In my understanding, if there is no branch, and no tag, reaching a set of commits, there is no need to retain the space they describe. | 01:10 |
| Kamping_Kaiser | i've not worked with shared repositories, so don't know how they behave | 01:10 |
| icule | Kamping_Kaiser: You never work on more than one branch at a time? | 01:11 |
| icule | Is there a formal bzr command to get rid of a branch? | 01:11 |
| Kamping_Kaiser | correct. on the rare occasion i have multiple branches i simply branch again | 01:11 |
| icule | I tried this exactly, a few hours ago, and the repository seems to be automatically shared. | 01:12 |
| icule | (Given you used init-repo to start with. This is the natural thing to do if you intend to branch many times, so I think.) | 01:13 |
| AuroraBorealis | here seems to be | 01:13 |
| AuroraBorealis | http://doc.bazaar.canonical.com/bzr.2.4/en/user-reference/remove-branch-help.html | 01:13 |
| AuroraBorealis | remove-branch | 01:13 |
| icule | AuroraBorealis: Thanks! You're the king of the screenshot, my friend! :-) | 01:14 |
| icule | I should learn to imitate you. Should get a bit more speedy on the mouse, I guess :-). | 01:14 |
| Kamping_Kaiser | hm, remove-branch. guess i have used shared repos then, in some sense (the sense that i removed a lot :p) | 01:15 |
| AuroraBorealis | well thats the actual documentation page hehe | 01:15 |
| AuroraBorealis | brb~ | 01:16 |
| icule | I tried "bzr branch" on unrelated places. There is first the stream of commits, and in a second phase, the building of the file tree. If I "bzr branch" in a neighbouring directory in the same "init-repo", the stream of commits is nearly instantaneous, it immediately switches to the tree extraction. | 01:16 |
| icule | brb~ ?? | 01:16 |
| icule | May I ask another question. If you reply, you encourage me to ask more. That's your fault! | 01:17 |
| Kamping_Kaiser | just ask, if he/she/it can reply (or someone else can reply), they will | 01:18 |
| icule | Suppose we have a "master" repository and we branch out of it. When we merge back, the version numbers get a bit more complicated, and this is later reflected in other branchers. Now, let's presume we *loose* the master repository. We restore it from one of the copies. Is there a way to "renumber" or "simplify" the version numbers then? Or do they get forever dirty? | 01:19 |
| icule | (OK, dirty is a bit strong. Let me say "compound without reason".) | 01:20 |
| fullermd | Numbers are dependent on the head. If the head is the same, the numbers are the same. | 01:20 |
| icule | fullermd: Maybe my fear is unjustified. I'll have to experiment more to get a more firm idea. It's more intuition than knowledge right now. | 01:21 |
| fullermd | http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/RevNumbering | 01:22 |
| icule | fullermd: Thanks for the link. I read a lot of pages today, but I do not remember having seen this one. | 01:23 |
| icule | OK, thanks again everybody. It was a pleasure to meet you. Have a good end of day! | 01:23 |
| fullermd | The other stuff under http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs may also be useful to you. In particular, PiecesInBrief talks about terminological usage, which differs somewhat among different VCSen. | 01:24 |
| === marienz_ is now known as marienz | ||
| chrissbx | When using "bzr git-apply ../00*", all patches that have multiple lines in the message, when afterwards shown in bzr log, end up missing two newlines between the first (subject) line and the rest (body). | 02:07 |
| chrissbx | I'm on Debian stable, bzr 2.1.2. Has this been fixed, or is my interpretation wrong? | 02:08 |
| chrissbx | Ah well, and it doesn't apply the changes at all. | 02:13 |
| AuroraBorealis | ive never used git-apply o.o | 02:13 |
| chrissbx | So, this alternative actually almost worked: bzr fast-export-from-git foogit/.git exportfile && mkdir foobzr && cd foobzr && bzr init && bzr fast-import ../exportfile | 02:21 |
| AuroraBorealis | what are you trying to do | 02:22 |
| chrissbx | The only thing is it uses the git committer time for patch times, and looses the git author times. | 02:22 |
| chrissbx | I've previously converted a bzr repo to git, worked on it, now trying to bring my work back into bzr. | 02:22 |
| AuroraBorealis | i dont think you are meant to use fast import/export repeatedly :3 | 02:23 |
| chrissbx | well, the bzr history has been kept identical. | 02:23 |
| chrissbx | Only thing that bothers me a bit is that my author times are lost. | 02:24 |
| AuroraBorealis | might be a bug with the git things | 02:24 |
| AuroraBorealis | i dont use git with bazaar so i cant say | 02:24 |
| fullermd | I'm pretty sure bzr doesn't have multiple timestamps... | 02:25 |
| chrissbx | I'd like to have a flag to tell it "use my author times, not committer timestamps as bzr timestamps" | 02:26 |
| chrissbx | Are bzr timestamps changing if you rebase or cherry-pick (well that's git terminology..) patches? | 02:27 |
| AuroraBorealis | i thought bzr really isn't meant for..cherry picking | 02:27 |
| fullermd | They're set when a revision is created, and fixed afterward. | 02:27 |
| fullermd | Whether rebase copies over the timestamps to the new revs, I dunno. For rebase-ish operations, I think I'd guess no... | 02:28 |
| fullermd | But that's implementation detail, not fixed. | 02:28 |
| chrissbx | Can you create a patch file with everything and apply it afterwards? (like git format-patch and git am) | 02:29 |
| chrissbx | with everything in a commit | 02:29 |
| fullermd | That sounds like the territory of merge proposals and bundles. | 02:29 |
| === medberry is now known as med_out | ||
| GungaDin | Is there a way to specify excluded files/paths without specifying -x infront of each of them? | 05:59 |
| === Quintasan_ is now known as Quintasan | ||
| AuroraBorealis | put them in .bzrignore? | 06:00 |
| GungaDin | nah.. can't you just specify them with one -x??? | 06:12 |
| GungaDin | comma separated? | 06:12 |
| GungaDin | something? | 06:12 |
| AuroraBorealis | im not sure | 06:12 |
| AuroraBorealis | never used that before | 06:12 |
| fullermd | And .bzrignore is unrelated to [ci] -x. | 06:14 |
| vila | hi all ! | 06:26 |
| vila | poolie: ping ? | 06:26 |
| poolie | hi vila | 06:26 |
| vila | \o/ | 06:26 |
| vila | I'd like to discuss about library_state | 06:27 |
| vila | the scope is unclear to me at the moment as is the intended use, | 06:28 |
| vila | do we intend to support threads ? Recursive calls ? | 06:29 |
| vila | Which kind of global do we expect to add ? (Apart from the comment saying none should be added) | 06:30 |
| vila | "Accessing the current BzrLibraryState through this variable is not encouraged: it is better to pass it around as part of the context" puzzles me, | 06:32 |
| poolie | oh hi | 06:32 |
| poolie | sure i'd be happy to discuss that | 06:33 |
| vila | passing the state around ? Do we want to add such a parameter everywhere (almost) ? Rely only on a few strategic objects to propagate it (branch, repo, wt) ? | 06:33 |
| poolie | the simple end of it is: there is a bunch of global state | 06:33 |
| poolie | for instance, the ui factory, hooks, etc | 06:34 |
| poolie | this needs to be initialized when a program using bzrlib starts | 06:34 |
| poolie | (and possibly closed off) | 06:34 |
| poolie | also, it is typically reset when running tests | 06:34 |
| poolie | at the moment, this is done ad-hoc for different types of state | 06:34 |
| vila | encodings and i18n also comes to mind | 06:35 |
| vila | right, so you describe indeed a simpler scenario: initialize the state once | 06:36 |
| vila | but nothing about threads or possibly calling bzrlib with a new state while preserving the current one | 06:36 |
| poolie | right | 06:39 |
| poolie | perhaps eventually you'd want to have multiple threads each with separate state | 06:39 |
| poolie | that would be perhaps a clean way to allow multiple completely independent threads more safely | 06:39 |
| poolie | (each running a ui, for instance) | 06:39 |
| poolie | but that's not really on my radar at the moment | 06:39 |
| poolie | yes, i18n and encoding are good examples | 06:39 |
| poolie | similarly i don't see much urgency to do recursion except for the particular case of testing | 06:40 |
| poolie | now as far as propagating it | 06:40 |
| poolie | to start with, having just one global (the state) that points to every other bit of global state is in itself an advance | 06:40 |
| poolie | at least it's easy to switch just that and know you've reset it | 06:40 |
| poolie | obviously that wouldn't scale to threading, but as i said that's not urgent | 06:41 |
| poolie | so | 06:41 |
| poolie | by 'pass it around' | 06:41 |
| poolie | you wouldn't want to pass it to every function | 06:41 |
| poolie | we might manage to put it into eg the bzrdir, then pass that down in to objects opened off there | 06:41 |
| poolie | this tends to run in to trouble when we pass through a non-method function | 06:42 |
| vila | yeah, that's what I meant with "strategic" objects but it's blurry at best | 06:42 |
| vila | yeah | 06:42 |
| poolie | anyhow | 06:44 |
| vila | ok, so, that means the "various bits of global state that are slowly being eliminated" really means the aim is to centralize first and may be, in the long term, eliminate it, but nothing I can nor should worry about right ? | 06:44 |
| poolie | right | 06:44 |
| vila | haaaa | 06:44 |
| poolie | so, your specific thing is reading configs just once ,right? | 06:45 |
| vila | hmm, not a haaa of surprise but of relief :) | 06:45 |
| vila | nope | 06:45 |
| vila | not yet | 06:45 |
| vila | the specific bit is about bug #491196 | 06:45 |
| ubot5 | Launchpad bug 491196 in Bazaar "want a way to set configuration options from the command line" [High,In progress] https://launchpad.net/bugs/491196 | 06:45 |
| vila | and how this should be shared with all stacks | 06:45 |
| vila | so not the config files yet but kind of the same issue | 06:45 |
| vila | there is only one instance of some dict holding the overridden options and it should be used by all stacks | 06:46 |
| vila | short path: a new global | 06:46 |
| vila | preferred (?) path: use library_state, but AFAICS it's not even supported by the test suite today | 06:47 |
| vila | chicken-and-egg | 06:48 |
| poolie | oh ok | 06:50 |
| poolie | i'd so much love to see that added | 06:50 |
| vila | should we start by filing a bug asking for library_state to be used by the test suite ? (Note that we can now debug code where stdin/stdout are redirected which should help a lot !) | 06:50 |
| poolie | so i do think that belongs in the library state | 06:51 |
| poolie | perhaps not exactly a specific concept of 'command line options' (though that would be ok) | 06:51 |
| vila | overrides ! not options | 06:51 |
| poolie | but rather 'low priority config stacks' and 'overriding config stacks' or something | 06:51 |
| vila | yup | 06:51 |
| poolie | so | 06:53 |
| vila | but you realize that using a specific state for tests is a recursive use case (simpler than a general case but recursive nevertheless) | 06:53 |
| poolie | yes i do | 06:53 |
| vila | good | 06:53 |
| poolie | <poolie> similarly i don't see much urgency to do recursion except for the particular case of testing | 06:53 |
| poolie | :) | 06:53 |
| vila | oh, sorry :D | 06:53 |
| poolie | np :) | 06:53 |
| poolie | so, i think it would not be much harder to put it in the library state than in a global | 06:54 |
| * vila nods | 06:54 | |
| poolie | even-if the test integration doesn't promise to save and restore the whole state, and it only does the specific config stuff | 06:54 |
| poolie | but, perhaps it will turn out that just an overrideAttr on the library state is enough to make it work | 06:54 |
| vila | hehe, right I always miss those shortcuts :) | 06:55 |
| vila | hmm, I'd feel better with a bug about library_state so we can focus on some minimal stuff there without mixing that with other aspects, I'll do that unless you object | 06:57 |
| poolie | what would that bug say? | 06:59 |
| vila | library_state cannot be used | 06:59 |
| poolie | :/ | 07:00 |
| poolie | yes it can :) | 07:00 |
| poolie | actually | 07:00 |
| vila | by the test suite mainly, but even by code as the recommended usages are unclear | 07:00 |
| poolie | i think we can get there one step at a time by adding new stuff to it, or migrating | 07:00 |
| poolie | and since we're adding something new | 07:00 |
| poolie | i think it will be no harder than adding a global, and it may make stuff easier | 07:01 |
| poolie | so i'd like you to try it | 07:01 |
| poolie | if it turns out to cause byzantine failures, let me know | 07:01 |
| * vila scratches head | 07:01 | |
| vila | oh, you mean I should overrideAttr for tests... but only for the part I care about ? | 07:02 |
| poolie | well, i think that would still be incrementally better | 07:02 |
| poolie | than just having a global | 07:02 |
| vila | ok, I think I see :) | 07:02 |
| vila | thanks for the teddy bear'ing | 07:04 |
| * vila switches to make tea, lp rollout planned at 0830 UTC | 07:04 | |
| * fullermd wonders what vila is adding to the tea to cope with that :p | 07:05 | |
| vila | caffeine | 07:05 |
| vila | and other substances I'm not allowed to speak about publicly | 07:06 |
| vila | no, I didn't even write that | 07:06 |
| poolie | stinky cheese :) | 07:07 |
| poolie | bit early for that though | 07:07 |
| vila | my daughter was doing that when she was young ;) | 07:07 |
| vila | Roquefort was her favorite... | 07:08 |
| poolie | vila, i'm going to go out in a bit | 07:14 |
| poolie | hi jam | 07:15 |
| vila | poolie: it's ok, I have enough feedback | 07:15 |
| poolie | oh, did you understand my terse comment about lazr.restful? | 07:15 |
| poolie | i fixed a bug in it to do with indexerror | 07:15 |
| poolie | we would need to either release and deploy it, or run from a checkout | 07:15 |
| poolie | i could look into it next week | 07:15 |
| vila | oh yes, I knew about that, what I don't know is how and when it will be deployed though | 07:15 |
| poolie | it will probably help the existing backoff stuff work quite a lot better | 07:15 |
| poolie | me either :) | 07:16 |
| * vila nods | 07:16 | |
| poolie | but those are the main choices | 07:16 |
| poolie | 1- run from a checkout | 07:16 |
| poolie | 2- make a release, build it, backport it, cat-rebuild it, get that installed | 07:16 |
| vila | I commented about that: 'make tea' is a catch-all, it doesn't mean we shouldn't fix every case where we can | 07:16 |
| jam | morning poolie | 07:16 |
| vila | poolie: I prefer 2 despite 1 giving better control | 07:17 |
| jam | hi vila | 07:17 |
| vila | jam: _o/ | 07:17 |
| vila | poolie: the aim should still be to be able to control the imports without ssh access, so the less specific bits we maintain ourselves, the better | 07:18 |
| vila | poolie: and I deal with my own contradictions on the topic ;) | 07:19 |
| poolie | vila, ok so then the next step is for someone to make a tarball release | 07:20 |
| poolie | either you or i, or we moan at someone from #launchpad to do it | 07:20 |
| poolie | since this is only the first step of a bunch of changes perhaps it's easier to just do it | 07:20 |
| poolie | that package has so much weird stuff for its size i don't anticipate the release being trivial but perhaps it will be | 07:21 |
| vila | poolie: please do :) | 07:22 |
| vila | http://egbg.home.xs4all.nl/counterscript.html ftw ! Just got a telemarketer hang up *during* the 2nd question ! | 07:36 |
| vila | make tea experiment failed (due a minor bug, I have a fix): the circuit_breaker failed to access the db | 08:51 |
| vila | ~100 failures will be retried shortly | 08:53 |
| vila | the first failure was unknown: bzrlib.errors.UnknownErrorFromSmartServer: Server sent an unexpected error: ('error', 'xmlrpclib.Fault', '<Fault -1: \'Unexpected Zope exception: DisconnectionError: could not connect to server: Connection refused\\n\\tIs the server running on host "lp-prod-pgbouncer.canonical.com" and accepting\\n\\tTCP/IP connections on port 5433?\\n\'>') | 08:54 |
| vila | I've added it to the known transient ones | 08:54 |
| vila | two more imports failed with the same error | 08:55 |
| vila | the following ones were lazr.restfulclient.errors.HTTPError: HTTP Error 500: Internal Server Error so covered by the next lazr deployment (poolie you confirm?) | 08:55 |
| vila | ha, poolie is gone, nm | 09:05 |
| vila | I'll monitor again during next rollout currently planned next Tuesday 0830 UTC | 09:11 |
| vila | all transient failures has now been re-processed, so we recovered in one hour only, with some manual prodding, still better than the several hours previously needed (less failures though) | 09:28 |
| vila | testing my fix right now (found a way to trigger the faulty code path without shutting down launchpad ;) | 09:33 |
| vila | test successful, ready for next rollout | 09:41 |
| briandealwis | is there any way to tell if a plugin is being run from the smart server rather than the bzr client? | 10:34 |
| jelmer | briandealwis: how do you mean? | 11:09 |
| jam | jelmer, briandealwis: I think he means something like bzr-email. Is there a way to tell that the server-side hook is running and causing the email to be sent, rather than the client. | 11:30 |
| jam | I don't know of any sort of generic way. | 11:31 |
| jam | You could always disable the client plugin with "BZR_DISABLE_PLUGINS=pluginname" | 11:31 |
| briandealwis | jam: I actually have a plugin (just polishing and will then announce) and wanted to alter the plugin's behaviour if it's running within the server | 11:37 |
| jam | briandealwis: so you mean can you tell from-within-the-server | 11:38 |
| jam | you could tell based on the URL you are working on | 11:38 |
| jam | whether it is a local or remote one. | 11:38 |
| briandealwis | though it would be local if bzr client was working on local branch too, right? | 11:38 |
| jam | briandealwis: yes | 11:38 |
| jam | though I wouldn't be surprised if you wanted that | 11:39 |
| jam | depending on what you are doing, you could just check hostname | 11:39 |
| jam | "socket.gethostname()" | 11:39 |
| jam | I don't know how specific this is to your system. | 11:39 |
| briandealwis | jam: I'm polishing up a "reflog" plugin for bzr. I want to record the action that changed the tip though (e.g., pull, commit, uncommit), but that info isn't available from the post_change_branch_tip hook. So I'm currently hooking the other branch hooks, but those aren't sent on the smart server. | 11:46 |
| briandealwis | Maybe I should just change the bzr source to provide a reason the ChangeBranchTipParams | 11:47 |
| jam | briandealwis: That would make more sense, though the layering might make it a bit tricky. As noted, though, it does sound like you want that to run for clients as well as on the server. | 11:47 |
| jam | Since probably 90% of the time the server side is "pushed" :) | 11:47 |
| briandealwis | exactly | 11:48 |
| briandealwis | a separate question: how do I specify an encoding when requesting or writing a file through a transport? | 11:49 |
| briandealwis | nm, I didn't realize I needed to encode and decode lines explicitly | 12:05 |
| jam | briandealwis: yeah, content is binary | 12:14 |
| jam | get_bytes/put_bytes | 12:14 |
| briandealwis | thanks | 12:14 |
| === med_out is now known as medberry | ||
| jelmer | jam: hi | 13:35 |
| jam | hey | 13:35 |
| jelmer | jam: thanks for that review. In general, I was going for minimal impact with that foreign-branch-tests-pt-6 branch. | 13:36 |
| jelmer | jam: You're probably right that we should do some refactoring | 13:37 |
| jelmer | jam: I think a .is_initializable() would make sense; do you know if there's any particular reason assertInitializeEx doesn't just raise TestNotApplicable itself? | 13:37 |
| jam | jelmer: assertInitialize ? | 13:38 |
| jam | jelmer: found it | 13:39 |
| jam | I think it should just raise TestNotApplicable | 13:39 |
| jam | it would clean up a lot of other code, too | 13:39 |
| jam | I'm guessing it was before we had NotApplicable | 13:39 |
| jam | where there was a debate between SKIP being used for a test that is missing a dependency | 13:39 |
| jam | (a test you could make pass somehow) | 13:39 |
| jam | and NotApplicable meaning never-will-happen | 13:39 |
| jelmer | jam: ah, fair enough | 13:40 |
| jam | vs just passing the test because it wasn't something you could fix | 13:40 |
| jam | ever | 13:40 |
| jam | jelmer: if you look at the code, all the code paths have "if control is None: return" | 13:40 |
| jam | and you can get rid of all that boilerplate by raising the exception. | 13:40 |
| jelmer | jam: Well, that's what I thought. But I also figured whoever wrote it probably was doing that for a good reason :) | 13:41 |
| jelmer | I think I forgot there was a time when we didn't have TestNotApplicable | 13:41 |
| jam | jelmer: yeah, that was quite a while ago :) | 13:44 |
| jelmer | jam: Thanks, I'll have a look at raising TestNotApplicable and introducing .is_initializable() | 13:45 |
| jam | jelmer: of course, all of those lines were recently copied by you, so it is a bit hard to see how old they are :) | 13:45 |
| LeoNerd | I'm honestly surprised nobody's registered bzrhub.com yet | 15:27 |
| * vila runs | 15:42 | |
| * jelmer counts further down.. 28 failures left :) | 15:47 | |
| vila | jelmer: \o/ | 16:04 |
| === beuno is now known as beuno-lunch | ||
| === beuno-lunch is now known as beuno | ||
| exarkun | yo what's up, http://codepad.org/bU40nmSJ | 19:39 |
| jelmer | hi exarkun | 19:40 |
| jelmer | exarkun: you need a newer version of bzr-fastimport that matches your bzr | 19:40 |
| exarkun | How do I know what version of bzr goes with what version of bzr-fastimport? | 19:41 |
| jelmer | exarkun: generally speaking, newer versions of bzr-fastimport will work with bzr >= 2.0 | 19:42 |
| jelmer | r313 of lp:bzr-fastimport fixes this particular issue | 19:44 |
| exarkun | Thanks, I think that worked | 19:46 |
| exarkun | I think I did my fast-import-filter wrong though | 19:48 |
| exarkun | How do I remove one directory from history? | 19:48 |
| exarkun | I have /master/ and /support-master/ and I want to get rid of /support-master/ | 19:49 |
| exarkun | I tried -i master/ but that dumps all of master/ into / | 19:49 |
| jelmer | exarkun: perhaps -x ? | 19:50 |
| jelmer | though I should note I don't have much experience using fast-import-filter | 19:50 |
| exarkun | oh right, I should have re-read the docs after upgrading. | 19:51 |
| exarkun | yea, -x works just right. thanks. | 19:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
