| mwhudson | hello | 00:01 |
|---|---|---|
| beuno | get_revision_graph was deprecated in 1.4, what would be best the way to do it now? I'm using get_graph(), but it seems slower | 00:43 |
| mwhudson | beuno: how much slower? | 00:45 |
| mwhudson | beuno: i'm assuming this is for the history object creation time in loggerhead? | 00:45 |
| beuno | 2.8sec vs 2.1sec | 00:45 |
| beuno | yes, in History.from_branch | 00:46 |
| mwh | mm, that's fairly bad | 00:46 |
| mwh | is that on bzr.dev ? | 00:47 |
| beuno | 1.5 actually | 00:48 |
| beuno | I should probably switch to bzr.dev, but it should be faster in 1.5 too | 00:48 |
| mwh | i woudn't expect much difference | 00:51 |
| beuno | I may going about it wrong | 00:52 |
| beuno | I doing log._get_mainline_revs, and then graph.iter_ancestry | 00:53 |
| beuno | mwhudson, why would loggerhead want each revisions parents to generate it's current history? | 00:57 |
| beuno | ah, probably to show "merged from" | 00:58 |
| mwhudson | beuno: right | 00:58 |
| mwhudson | beuno: "revisions that are in the ancestry of this revid but not this other one" | 00:59 |
| beuno | what it doesn't seem to do is limit to what i actually will show on screen | 00:59 |
| beuno | and just ask for the whole history | 00:59 |
| mwhudson | beuno: mind you, there are much better graph apis for this now, thanks to jam | 00:59 |
| mwhudson | beuno: loggerhead caches a whole heap of whole-history information when history objects are created | 01:00 |
| mwhudson | beuno: it would certainly be interesting to take an 'outside in' approach | 01:01 |
| mwhudson | where you consider what information each view needs and what facilities now exist to get this without whole history operations | 01:01 |
| mwhudson | i think computing revnos from revids would still be a sticking point | 01:02 |
| beuno | maybe the revisions that are going to be viewed can be retrieved and cache, if they aren't already | 01:02 |
| mwhudson | it's not the revisions per se that are interesting | 01:03 |
| mwhudson | it's the relationships between them | 01:03 |
| beuno | hrm, yes | 01:04 |
| beuno | alright, thanks for the brainstorming, I'll start looking for a better alternative to the deprecated method, and try to leave the caching intact for now | 01:05 |
| beuno | mwhudson, https://lists.ubuntu.com/archives/bazaar/2008q2/042306.html seems like a probable improvement | 01:13 |
| beuno | but, using some of these will make loggerhead depend on bzr 1.5 > | 01:14 |
| mwhudson | beuno: well, maybe, it's a trade-off between making the history creation a bit slow and having blazing fast revid->revno mappings | 01:16 |
| mwhudson | beuno: and having slower page loads | 01:17 |
| mwhudson | beuno: a more incremental approach would be nice, and probably possible | 01:17 |
| mwhudson | probably need to be careful about memory usage &c though | 01:17 |
| beuno | would you rather I look into memory issues first? This was deprecated in 1.4, so it should be there for a few more months. I can do a few tests with Genshi | 01:20 |
| beuno | (annotate does have deprecated methods too, btw) | 01:21 |
| poolie | beuno: hello | 01:21 |
| beuno | hey poolie :) | 01:21 |
| mwhudson | beuno: eh, looks like get_revision_graph is gone in bzr.dev already | 01:26 |
| mwhudson | beuno: fixing this stuff seems like a good thing to do :) | 01:27 |
| mwhudson | beuno: in particular fixing annotate has been on my todo list forever | 01:27 |
| mwhudson | beuno: well, for at least 6 months :/ | 01:27 |
| * mwhudson goes for lunch | 01:28 | |
| beuno | mwhudson, alright, I'll stick with the deprecated methods first | 01:28 |
| beuno | bonne appetit | 01:28 |
| Vigh | Hey - anyone here available to help me with a quick problem? | 01:44 |
| bob2 | best to just ask | 01:45 |
| Vigh | yeah, I just wanted to make sure I wasn't the only one that isn't AFK before I did =P | 01:46 |
| Vigh | anyway, I'm pushing a versioned project to a dumb FTP server ("dumb" because it's not running Bazaar) | 01:46 |
| Vigh | and I wanted to know if there's a way to remotely update the FTP server's working tree | 01:46 |
| Vigh | pushing updates the .bzr directory but not the actual files, and the way that the documentation suggests I do it is by running "bzr update" on the host of the branch, but I can't since the FTP server isn't running Bazaar | 01:47 |
| bob2 | well, if you can ssh in, you can bzr co | 01:47 |
| beuno | Vigh, do you want to keep the history on the other end, or just want the working tree? | 01:47 |
| Vigh | meh, that's the thing - there's no way I can get Bazaar running on the FTP server | 01:48 |
| bob2 | but otherwise, no, unless you upload the checked out files via ftp too | 01:48 |
| Vigh | beuno: Well, here's what I'm working on. I'm working on a web application with 3 other people, and the web app is being hosted on a webhost which provides FTP access but no SSH access | 01:49 |
| Vigh | I'm using Bazaar because we need versioning and revision control on the project | 01:49 |
| beuno | Vigh, if you just need the working tree, there is an experimental plugin that does that | 01:49 |
| beuno | you can use a random place to centralize the repo | 01:49 |
| beuno | and upload to the production server with the plugin | 01:49 |
| beuno | (it's main target actually is for web development) | 01:50 |
| beuno | http://launchpad.net/bzr-upload | 01:50 |
| beuno | it's still in it's initial stages, but it works well enough, we use it at work pretty frequently | 01:50 |
| Vigh | Hmmm....this looks perfect | 01:50 |
| beuno | :) | 01:50 |
| Vigh | Thanks beuno! | 01:50 |
| beuno | bugs and patches very welcome, btw | 01:51 |
| * beuno curses graph.iter_ancestry | 01:52 | |
| Vigh | So I basically just run Bazaar with this plugin on one of my servers and store the repo there, then anytime one of the four of us pushes a revision to it, it will upload the modified files to the specified FTP server? | 01:52 |
| beuno | Vigh, you don't need to run it on the server, just the client | 01:54 |
| beuno | bzr upload location | 01:54 |
| beuno | and it uploads, be default, all files changed from the last revision uploaded | 01:54 |
| Vigh | Oh, wow, even simpler than I though | 01:54 |
| Vigh | *thought | 01:55 |
| beuno | yes, that's what we where aiming at :) | 01:55 |
| beuno | make sure merge eachothers changes before uploading, it will check on the remote server, the last revid uploaded, so you should have that in your repo | 01:55 |
| Vigh | Can I centralize the project on the FTP server and have it upload the modified files in the working tree on the same FTP host? 'Cause we're each running Bazaar and we have the centralized branch already on the FTP server and it works great, the only problem was that any new revisions only updated the .bzr directory on the FTP server, not the actual files (i.e. the working tree) | 01:57 |
| beuno | mwhudson, changed a few things around, got the new API with the same performance as the deprecated one. I'll cleanup a bit, upload, and start working on annotate. Dinner first though :) | 01:57 |
| Vigh | In other words, can we each just install this plugin and start using bzr upload without changing any configs? | 01:57 |
| mwhudson | beuno: excellent | 01:58 |
| mwhudson | i would subscribe to the branch but there's not much point when the scanner | 01:58 |
| mwhudson | 's fubarred | 01:58 |
| beuno | Vigh, you can, but it should be to different locations. You don't need anything special to use this plugin, as it basically uploads via ftp/sftp all files changes since the last revid uploaded | 01:59 |
| beuno | mwhudson, fubarred? | 01:59 |
| mwhudson | beuno: not working | 02:00 |
| Vigh | beuno: I ask because we already have the main project centralized on the FTP site and it works fine, it's just that we had to upload the modified files manually because pushing only modified the remote .bzr directory, not the remote working tree | 02:00 |
| beuno | Vigh, yes. I usually upload the branch to a folder outside of apache's reach, so that only devs can see it, and upload files to a a public directory | 02:02 |
| beuno | so I keep the repo and files seperate | 02:02 |
| Vigh | beuno: I'd do that, but out webhost gives us very limited access to the server...no SSH access, and we can only read/write to apache's htdocs directory | 02:03 |
| bob2 | put the branch somewhere protected by htaccess | 02:03 |
| Vigh | at the moment, we have a /bzr directory on the host that is hidden from public view via .htaccess | 02:03 |
| beuno | Vigh, that works too, yes | 02:04 |
| Vigh | Ok, thanks again for the help | 02:04 |
| beuno | np | 02:04 |
| Vigh | I'll tell ya' if I have any troubles with the plugin =P | 02:04 |
| beuno | Vigh, please do :) | 02:04 |
| * beuno goes grab some dinner | 02:06 | |
| poolie | i'm going to do a patch for russel's nfs bug, should be trivial | 02:12 |
| * igc lunch | 03:02 | |
| beuno | mwhudson, pushed the branch with some cleaning done. It now performs as well as the deprecated method does, I'll move on to annotate, and once I clean all deprecated methods, go back and start working on performance | 04:21 |
| beuno | I don't see a cleaner way to get the graph, although it's an improvement to my previous approach. I'll catch jam tomorrow and see if he knows a cleaner/faster way of getting it | 04:22 |
| mwhudson | beuno: i'll take a look | 04:23 |
| mwhudson | beuno: i think you typoed the branch name (logger*g*ead) :) | 04:26 |
| beuno | argh | 04:28 |
| mwhudson | beuno: and left a mystery "OB" | 04:28 |
| beuno | I forget to --remember :p | 04:28 |
| mwhudson | but otherwise it looks good :) | 04:28 |
| beuno | mwhudson, re-pushed and cleaned | 04:29 |
| beuno | hrm, bzr isn't remembering the location :/ | 04:30 |
| beuno | btw, why is branch scanning disabled? | 04:31 |
| mwh | it's wedged on a large branch :/ | 04:32 |
| beuno | ah, so it's just delayed | 04:33 |
| mwh | yeah, it'll get unstuck at some point | 04:33 |
| poolie | igc, hm i'm trying to work out how to reply to http://bazaar-vcs.org/AlexanderBelchenko | 04:41 |
| bob2 | does pqm run the tests on windows? | 04:45 |
| === samurai is now known as samiam | ||
| mwh | beuno: i can confirm that your branch has basically identical performance to what's in trunk now | 04:56 |
| beuno | mwh, cool. One less, 2 to go | 04:57 |
| mwh | which are ... ? | 04:57 |
| beuno | performance-wise, the main problems I saw, not having gone too deep, was annotate and diff | 04:57 |
| beuno | mwh, annotate_iter is what I'm working on now | 04:58 |
| mwh | ok, yes | 04:58 |
| beuno | and there is one more which I don't have handy, but it may be the same | 04:58 |
| beuno | (used somewhere else) | 04:58 |
| beuno | I've been thinking we may want to try caching the diff's as static HTML, even if we get a good enough improvement with a different templating engine | 04:59 |
| beuno | it will make diff views *very* cheap once they're generated | 05:00 |
| mwh | there used to be something a bit similar done | 05:01 |
| beuno | aha, and it was removed because...? | 05:01 |
| mwh | but they weren't cached as html, so you still had to pay the rendering cost | 05:01 |
| mwh | beuno: used heaps of diskspace and didn't benefit much | 05:02 |
| beuno | well, the disk space will probably still stand, but we should render it once, and never again | 05:03 |
| beuno | CPU and RAM will be very happy | 05:03 |
| beuno | so make 2 people happy and one sad, 50% win! | 05:03 |
| beuno | mwh, maybe we can try just storing the diff bit of the HTML, and generate the rest. That way we may save some space, and leave the rest as-is | 05:10 |
| mwh | beuno: it makes some sense | 05:11 |
| lifeless | I have three thoughts | 05:14 |
| lifeless | one, I'm wasted, having travelled etc. | 05:14 |
| mwhudson | hi lifeless | 05:14 |
| lifeless | two, why would loggerhead benefit from such a diff cache and not bzr core | 05:15 |
| lifeless | three, why not analyse logs that we have today to gather data on whether repeated diffs happen/sizeof cache needed etc | 05:16 |
| beuno | lifeless, hi | 05:16 |
| lifeless | in bzr we have found that caches need to be examined with great care to avoid $various issues | 05:17 |
| lifeless | hi :) | 05:17 |
| beuno | lifeless, I may be wrong, but the diff between two specific revisions will never change, so, if we handle that carefully enough, we should be able have a plain text (html) cache of it | 05:18 |
| beuno | so if I have something like revid1_revid2_diff.cache | 05:19 |
| beuno | I can look for those first, and fall back to generating it if it's not there | 05:19 |
| beuno | of course, it may not be the case for many other parts of bzr, but diff and annotate I think should be possible, and extremely cheap to serve once generated | 05:20 |
| beuno | analysing logs on where the current memory hog is, of course, would be of great help, but out of my hands | 05:21 |
| lifeless | sure; I can see that. Of course it raises the cost of generating it on MISS, and adds a requirement to manage that cache | 05:22 |
| lifeless | you could also just whack a http proxy in front of loggerhead to cache specific urls | 05:23 |
| lifeless | anyhow, not saying its a bad idea, saying analyse! | 05:23 |
| lifeless | also, I didn't say analyse logs for memory, I was saying analyse logs to see what benefit a diff cache would have | 05:23 |
| lifeless | if any diff gets hit only once, what benefit a cache? | 05:24 |
| beuno | right, if the current problem is diffs in different repos, than it won't help very much | 05:24 |
| beuno | the http proxy may work well-ish for LP, but doesn't seem like a good implementation for Loggerhead itself, as it would force an extra setup step for people | 05:25 |
| beuno | so, I agree. mwhudson, will you be able to spare some time to take a look at that? Or is there any way I can help? | 05:26 |
| lifeless | [lemma - standard rule in performance tuning is be sure you have identified the problem] | 05:28 |
| mwhudson | i'm working, slowly, with the sysadmins to get some decent log analysis | 05:28 |
| lifeless | a cache is a good answer for 'we repeat [making diffs] a lot and its the effort of repeating ourselve makes us slow] | 05:29 |
| lifeless | s/]$/'$ | 05:29 |
| mwhudson | my limited intuition is that slapping squid in front would have a good bang/buck ratio when it comes to dealing with the problems launchpad had last week | 05:30 |
| lifeless | if the problem is 'making diffs is slow' adding a cache only helps to the proportion of diffs avoided | 05:30 |
| beuno | yes, since I don't have any performance information, yet, I went down the cache path, as it helps scale, and, worse case scenario, it's as expensive as it currently is | 05:30 |
| beuno | mwhudson, squid will help, until we change the URLs to revnos :) | 05:32 |
| lifeless | there is a fallacy there; the worst case of a cache is not the same | 05:32 |
| lifeless | if you are IO bound | 05:32 |
| lifeless | loading dentries is not free | 05:32 |
| lifeless | anyhow, I'm not against a cache per se; I just want you guys to be sure. | 05:33 |
| beuno | yes, sane advice, thanks | 05:34 |
| beuno | we also need to think on other use cases, outside LP | 05:34 |
| beuno | where I do think it's more probable to hit the same diff several times | 05:34 |
| beuno | but some performance analysis should absolutely be done, on how expensive adding a cache is | 05:35 |
| lifeless | a cache costs you code; it costs you a cache dir to maintain (and filesystems can have surprisingly pathological behaviour) | 05:36 |
| lifeless | it adds background tasks | 05:36 |
| lifeless | there is also the question of where the cost is | 05:37 |
| lifeless | getting two texts and diffing in bzr should be very cheap | 05:37 |
| lifeless | is it rendering, or blaming | 05:37 |
| lifeless | could we render on the client | 05:37 |
| lifeless | or not blame by default | 05:37 |
| lifeless | if its bzr diff performance that is the issue should the cache be in bzr | 05:39 |
| lifeless | another concern on caches is that they can mask actual problems | 05:40 |
| lifeless | by making 'op' seem cheap when its not, and this can lead to suprising results when later performance tuning. See for instance 'kndx' files. | 05:40 |
| lifeless | we're still dealing with the fallout of making all operations access all history - much code started to depend on that, even when we were usually careful | 05:41 |
| * igc pick up kids | 05:41 | |
| lifeless | do you juggle? | 05:42 |
| mwhudson_ | well, loggerhead also suffers from the 'needs to access all history' problem | 05:43 |
| lifeless | I'm going to halt() for a bit; utterly stuffed and not really coherent | 05:45 |
| beuno | lifeless, your input is very much appreciated :) | 05:46 |
| beuno | how was UDS, btw? | 05:46 |
| lifeless | most excellent | 05:47 |
| beuno | chech beer? | 05:47 |
| jamesh | "czech" | 05:47 |
| === c1|freaky_ is now known as c1|freaky | ||
| DanielEads | This is probably a stupid question, but I googled around for 20 minutes and couldn't find it.... How do you install someone's branch onto your system with bzr? | 05:49 |
| lifeless | tchau for now | 05:50 |
| beuno | DanielEads, you can get a copy of it with: bzr branch remote_location | 05:50 |
| DanielEads | beuno: Thank you :) | 06:01 |
| beuno | mwhudson_, do you know of any way of forcing the annotate cache to re-generate, apart from cleaning the sqlite DB manually? | 06:19 |
| beuno | I replaced the deprecated method, but I want to do some performance comparisons before pushing | 06:19 |
| mwhudson_ | beuno: er | 06:20 |
| mwhudson_ | beuno: the annotate cache is/was a bzr thing | 06:20 |
| mwhudson_ | beuno: to do timings without loggerhead's revision cache, you can comment out the cache_path in the config file | 06:21 |
| beuno | mwhudson_, that's what I was looking for, thanks | 06:21 |
| === ^Gonzo^ is now known as [PUPPETS]Gonzo | ||
| beuno | yay! new method is 4x faster | 06:23 |
| mwhudson__ | beuno: :) | 06:32 |
| beuno | mwhudson__, it seems applying the template to big files like NEWS is almost as expensive as generating the annotation itself... changing the templating engine makes more and more sense | 06:42 |
| mwhudson__ | beuno: you noticed :) | 06:43 |
| mwhudson__ | though to be fair, it's not all the rendering engine's fault | 06:43 |
| mwhudson__ | there's a lot of time spent inside the loop that's the core of annotate.kid | 06:45 |
| beuno | mwhudson__, pushed the code for annotate. That's the last of deprecated methods I could find | 06:47 |
| beuno | it gets better performance in some cases, and the same in other (larger, more complex files) | 06:48 |
| beuno | won't make a difference, but it won't get deprecated either :) | 06:48 |
| beuno | almost 3am here, so I'm about to call it a day. If you can't think of anything more important, my next step would be experimenting with different templating engines | 06:50 |
| beuno | and possibly evaluating how some of the caches are used, it seems there's room for improvement in some cases | 06:50 |
| mwhudson__ | beuno: it's the end of my work day too, so thanks and i'll get back to you tomorrow | 06:52 |
| beuno | mwhudson__, thanks, cya tomorrow | 06:53 |
| beuno | I'm off, have a good day everyone :) | 07:01 |
| === AnMaster_ is now known as AnMaster | ||
| * igc dinner | 09:13 | |
| === [CroX] is now known as CroX | ||
| === Ng_ is now known as Ng | ||
| === yacc__ is now known as yacc | ||
| tca | Have anyone here managed to use http://cia.vc and bzr together? I'm trying the cia client http://cia.vc/clients/bzr/cia_bzr.py, but see no message or warning, and nothing happens at cia.vc and the irc robot is silent. | 12:37 |
| jamesh | tca: that plugin looks like it is using the old hook registration method so if you haven't updated your ~/.bazaar/locations.conf file, as the comment at the top says, it won't do anything | 12:40 |
| jamesh | tca: https://launchpad.net/bzr-cia/ is probably more promising | 12:41 |
| tca | I did modiy locations.conf. I'll try the client on launchpad now. | 12:43 |
| tca | This works. Thank you. I will notify them about this client. | 12:52 |
| Pieter | If I uncommit a large number of revisions, how can I get the space occupied by those revisions back? | 13:24 |
| jelmer | tca: It's actually the same client, just that the CIA folks haven't responded my requests to update the one on their site | 13:26 |
| === mw|out is now known as mw | ||
| === kiko_ is now known as kiko | ||
| jelmer | Pieter: a copy of the branch will not contain those revisions | 14:44 |
| beuno | what does bzr commit --fixes actually do? | 15:27 |
| gour | adds some metadata for the bug-tracker? | 15:28 |
| Jemsquash | Can someone help me getting bzr visualise to work on windows Vista? I've tried various installs and can't seem to get bzr to recognise that its installed. I've tried the pygtk windows installer and a cygwin installation but no luck. | 15:44 |
| Jemsquash | According to the instructions I need to install olive using python olive-gtk. It gives an error that pygtk2 is not installed. | 15:46 |
| Jemsquash | I can see the following apps installed in the Control Panel: Python 2.5 pycairo-1.2.6, Python 2.5 pygobject-2.12.3, Python 2.5 pygtk-2.10.1, Python 2.5.2 | 15:48 |
| Jemsquash | Otherwise is there some other way to get a graphical representation of branches in a bzr repository? | 15:52 |
| jelmer | it may be easier to get qbzr to work on windows | 15:53 |
| Jemsquash | yeah I've got it working but it does not show a nice graph of the branches AFAIK. | 15:54 |
| Jemsquash | qbzr is quite helpfull but I'd prefer to use a pretty picture to show me what's merged where. I'm a bit of a simpleton at times :) | 15:57 |
| beuno | jam, could you pass a merge request I just sent, through the filter? It's 1.7mb :) | 15:59 |
| beuno | (and if you have time at some point, I have a question on what the best way to get a repos's graph is) | 16:00 |
| Jemsquash | em, I lost you there. Through the filter? | 16:01 |
| beuno | Jemsquash, that would be for jam :) | 16:01 |
| Peng | 1.7 MB?! What'd you do, rewrite bzr in Ruby? | 16:10 |
| beuno | Peng, LOL | 16:11 |
| beuno | it may be that or it may be the images for the spanish docs. Nobody will know until it goes through the filter :) | 16:12 |
| Peng | That's way less interesting. :P | 16:16 |
| beuno | well, it could still be the ruby thing | 16:17 |
| fullermd | Well, maybe it's a rewrite in perl, that just LOOKS like the images for the spanish docs. | 16:17 |
| beuno | and with tests! :) | 16:18 |
| fullermd | Everybody's all about the code being the documentation, after all... | 16:18 |
| beuno | that should confuse the reviewers enough | 16:18 |
| jam | beuno: for this one, could you push a branch to LP and just submit a plain diff? I'd rather not push 2MB to everyone on bazaar@ | 16:41 |
| jam | I can if it is hard for you | 16:41 |
| Peng | It's possible to do a merge directive without a diff or bundle, right? | 16:41 |
| jam | beuno: btw, how do you get 2MB from editing source files? | 16:41 |
| jam | Peng: 'bzr send --no-bundle' | 16:41 |
| jam | that sort of thing | 16:41 |
| jam | but you need a proper public location | 16:41 |
| jam | beuno: well, editing documentation, but that's still a lot of changes | 16:42 |
| Peng | jam: Not if it's images. | 16:42 |
| beuno | jam, I can, but it will take a while, as I have to upload a new bzr branch to LP | 16:42 |
| jam | Peng: if it was bitmaps | 16:42 |
| jam | Which is something we wouldn't really want to merge | 16:43 |
| Vigh | Hola - beuno, you here? | 16:43 |
| Peng | The en quick-start-summary.* is 1 MB. | 16:43 |
| Peng | Maybe compressing and base64ing it blew it up. | 16:43 |
| jam | could be | 16:44 |
| Peng | 1.1 MB. base64 could do that. | 16:44 |
| beuno | Vigh, yeap yeap | 16:44 |
| jam | I'll let it through, I guess | 16:44 |
| Peng | Really? | 16:44 |
| beuno | it's the workflow png/svg's | 16:44 |
| beuno | jam, I *can* upload the branch, I don't want to annoy everyone :) | 16:45 |
| jam | beuno: though technically, it is my day off :) | 16:45 |
| jam | already sent, and I'm afk | 16:45 |
| beuno | jam, aaaah, I did not know that, have a good holiday | 16:45 |
| Vigh | beuno: I just installed bzr-upload and it's _almost_ working...the initial full upload fine | 16:45 |
| beuno | and thanks | 16:45 |
| beuno | Vigh, almost working is pretty good for a pre-alpha :p | 16:45 |
| Vigh | but after making a new commit and trying to upload, I'm getting this error: | 16:45 |
| Vigh | File "C:\Python25\Lib\site-packages\bzrlib\plugins\upload\__init__.py", line 98, in run | 16:46 |
| Vigh | display_url = urlutils.unescape_for_display(stored_loc, | 16:46 |
| Vigh | NameError: global name 'urlutils' is not defined | 16:46 |
| beuno | Vigh, htm, let me check | 16:46 |
| beuno | you have the latest version? | 16:46 |
| Vigh | Yup, just pulled this morning | 16:46 |
| Vigh | That's the only place in the script that urlutils is actually used, so I'm tempted just to leave out the unescaping | 16:48 |
| beuno | hrm, all tests pass | 16:48 |
| Vigh | the test_upload.py runs fine for me, too >.< | 16:49 |
| beuno | Vigh, uploading a fix now, try pulling and re-uploading | 16:50 |
| Vigh | I just fixed it myself too =P | 16:50 |
| Vigh | I realized that urlutils was never actually being imported | 16:51 |
| beuno | yes, that would be it :) | 16:51 |
| Vigh | Anyway, it's working wonderfully now | 16:51 |
| beuno | can you see if trunk fixed it properly too? just so I can be sure | 16:51 |
| Vigh | sure, hold on | 16:51 |
| Vigh | Yup, works with the newest version | 16:52 |
| Vigh | Thanks =) | 16:52 |
| beuno | Vigh, thank you :) | 16:52 |
| * beuno adds comment to add a test for those lines | 16:53 | |
| beuno | vila, ^^ :) | 16:53 |
| jam | Vigh: just add a "from bzrlib import urlutils at the top | 17:06 |
| Vigh | jam: yeah, I know =) | 17:10 |
| === kiko is now known as kiko-fud | ||
| Pieter | if I have a shared bzr rpo, can I just delete one of the working dirs and then get it back later? | 17:48 |
| pasky | Hi, what are the most popular tools for history visualization in bzr? The dot-based tool in BzrTools, or something else? | 17:50 |
| radix | Pieter: technically, all of the revisions are stored in the repository, so all the data is still. however, I don't know of any easy way to get it back out | 17:50 |
| radix | Pieter: however, if the branch you have deleted has already been merged into another branch, then it's possible and easy to reproduce the merged/deleted branch | 17:50 |
| jelmer | Pieter: it should be possible to delete the working tree files but leave the pointer to the revision in | 17:50 |
| Pieter | I just think the one repo / dir thing is totally whack | 17:50 |
| Pieter | coming from git / hg :) | 17:50 |
| radix | Pieter: oh, I assume you mean one of the branches, not just the working tree files | 17:51 |
| jelmer | Pieter: the "bzr remove-tree" command will do that - you can later create it again using "bzr checkout" | 17:51 |
| Pieter | it'll just leave an empty dir? | 17:51 |
| radix | Pieter: when you say "delete one of the working dirs" what exactly do you mean, please? | 17:51 |
| Pieter | I want to get rid of the files, but keep the branch in the repo | 17:51 |
| jelmer | Pieter: yes, an empty dir with just a .bzr directory with a couple of files in it | 17:51 |
| Pieter | that also works in a shared repo? | 17:52 |
| jelmer | Pieter: Pieter yes | 17:52 |
| jelmer | whoops, one tab too much :-) | 17:52 |
| Pieter | ok :) and if I want to delete the whole branch, and then remove any data added by that branch, in order to decrease repo size? | 17:52 |
| gour | Pieter: what did you bring from git/hg ? | 17:53 |
| Peng | Pieter: There's no easy way to do that. | 17:53 |
| jelmer | Pieter: repository's are append-only | 17:53 |
| Pieter | gour: you mean, which projects? | 17:53 |
| Peng | jelmer: So are hg's, but mq has a "strip" command. | 17:54 |
| pasky | By the way, is there any nice paper describing bzr's on-disk data structures etc? | 17:54 |
| gour | what will rm branch-dir-folder do? | 17:54 |
| pasky | or do I have to defer to the source code? | 17:54 |
| jelmer | Peng: what does that do, simply create the repository again but only with the data it actually needs? | 17:54 |
| Peng | pasky: Perhaps doc/developers/packrepo.txt? | 17:54 |
| gour | Pieter: i was/am thinking you are migrating from other VCSs to bzr | 17:54 |
| Peng | jelmer: I dunno. I've always figured it edits the revlogs in some hacky and unreliable way. :P | 17:55 |
| Pieter | gour: I have my own projects that mostly I am working on (in git). Someone else wants to help me out, but he prefers bzr, so I was looking if it would be good to convert it :) | 17:55 |
| Peng | pasky: Oh, that file doesn't have very many details. | 17:55 |
| gour | Pieter: ahh, cool | 17:56 |
| Pieter | gour: I just prefer git's inline branches somewhat | 17:57 |
| Pieter | if I have multiple git branches, do I have to supply multiple branch url's for someone to get all of them? | 17:57 |
| Pieter | when I convert them to bzr, that is | 17:57 |
| * gour also wonders about bzr's best-practices when rm-ing e.g. 'feature' or 'fix' branches which are very cheap in darcs | 17:57 | |
| pasky | Peng: *nod* :( I'm looking for something like the Mercurial OLS paper or Linus-njs dialog about git packs | 17:58 |
| pasky | on the other hand, there's more in there than I thought at first glance... I'll read it carefully | 17:59 |
| pasky | Possibly my question was lost in the other conversation, so I'll try again ;-) - what are the most popular tools for history visualization in bzr, please? The dot-based tool in BzrTools, or something else? | 18:10 |
| Pieter | you're looking for something like gitk? | 18:11 |
| dato | pasky: I think `bzr viz`, from bzr-gtk, is commonly used too | 18:11 |
| Pieter | How can I remove a single revision from my history (not the last revision) | 18:12 |
| gour | heh, cherrypicking | 18:13 |
| gour | uncommit -r rev | 18:14 |
| luks | simple answer: you can't. otherwise you can make a new branch that ends on the revision you want to remove, and use bzr replay for the rest of the branch | 18:14 |
| Pieter | is replay a plugin? | 18:15 |
| luks | it's in the rebase plugin | 18:15 |
| luks | but naturally it won't be the same branch anymore | 18:15 |
| luks | so merge, pull etc. from the original branch will be broken | 18:15 |
| Pieter | yeah, I know the risks :) | 18:15 |
| pasky | dato: thanks - is that http://samba.org/~jelmer/bzr/bzrk.png or smt lelsE? | 18:32 |
| dato | pasky: precisely that | 18:34 |
| === dpm_ is now known as dpm | ||
| pasky | dato: thanks! | 18:53 |
| === kiko-fud is now known as kiko | ||
| === mw is now known as mw|food | ||
| Rhamphoryncus | Weee.. recovering a hosed repository definitely puts me in a better mood | 19:52 |
| Pieter | how did your repo get hosed? | 19:53 |
| Rhamphoryncus | https://bugs.launchpad.net/bzr/+bug/150438 | 19:53 |
| ubottu | Launchpad bug 150438 in bzr "AssertionError: Could not find target parent in wt in wt4 _process_entry" [High,Confirmed] | 19:53 |
| Rhamphoryncus | https://bugs.launchpad.net/bzr/+bug/150438/comments/9 | 19:53 |
| * Rhamphoryncus wonders if bzr will grow a "Directory not found: Fake it?" prompt ;) | 19:55 | |
| === kiko is now known as kiko-afk | ||
| tca | /join #commits | 20:39 |
| === mw|food is now known as mw | ||
| libwilliam | A couple questions I hope someone can help me with. 1) Is there a function that returns the list of files applicable to be removed? 2) I am looking at messing with 'list_files' but by its description it makes me believe it will just list the files to stdout as opposed to 'unknown' and 'versioned' which returns the list of files. | 21:07 |
| libwilliam | Ideally I would like a list of just the versioned files. | 21:08 |
| Odd_Bloke | libwilliam: Could you reiterate (1)? I don't quite understand what you're looking for. | 21:08 |
| libwilliam | ok, let me rephrase | 21:08 |
| libwilliam | I have a GUI that will have a tree view with the list of files under version control | 21:08 |
| libwilliam | the user will select which files they would like to remove | 21:09 |
| libwilliam | so I just need a list of files that are currently versioned | 21:09 |
| libwilliam | not sure if that help clears things up any | 21:09 |
| fullermd | Well, `bzr ls --versioned` can do it, so you could see what that's calling behind the curtain. | 21:10 |
| pfharlock | bzr status? | 21:10 |
| libwilliam | bzr status lists lots of different categories. I was looking for just versioned, I will check out the source for ls --versioned and see if I can figure out what is going on | 21:11 |
| pfharlock | ahh, I see | 21:12 |
| pfharlock | hey, I have a silly question, if there are any vim users in here, I've not had much luck with bzr diff --using="vim -d" foo.file. It works fine with gvim, but I don't always have the option of using Xwindows. Does anyone else use vim as their diffing tool and has a solution to this problem? | 21:14 |
| pfharlock | also it tends to completely foobar whatever terminal I'm using at the time to the point where it just has to be closed, which seems odd. | 21:16 |
| tca | Have anyone seen this problem before: https://bugs.launchpad.net/bzr/+bug/235055 ? It looks like there is a problem with the very first revision created by baz_import (I think that was the script used to import to bzr) | 21:18 |
| ubottu | tca: Error: Could not parse data returned by Launchpad: The read operation timed out | 21:18 |
| tca | ubottu: just retry the link. launchpad is a little slow now, but it is not down... | 21:22 |
| ubottu | tca: Error: I am only a bot, please don't think I'm intelligent :) | 21:22 |
| Odd_Bloke | Hmm, ubottu probably shouldn't direct the timeout comment to the user that pasted the bug number. | 21:24 |
| Odd_Bloke | james_w: o/ | 21:24 |
| james_w | hi Odd_Bloke | 21:25 |
| === mario_ is now known as pygi | ||
| === mwhudson is now known as mwh | ||
| === mwhudson_ is now known as mwhudson | ||
| awilkins | Is the Windows/Python installer not supported anymore? | 21:52 |
| Odd_Bloke | awilkins: I think it is. | 21:54 |
| Odd_Bloke | Why do you ask? | 21:54 |
| awilkins | Just not made an appearance in 1.5 flavour yet :-) | 21:54 |
| Odd_Bloke | It's always lagged somewhat, and bialix is taking a break from Bazaar development ATM. | 21:55 |
| Odd_Bloke | So he's still doing the installers, but looking for someone to take over. | 21:55 |
| awilkins | It can't be a hard build, can it? | 22:01 |
| awilkins | Are the sources for the packages available? | 22:01 |
| * awilkins finds the Win32ReleaseChecklist page | 22:03 | |
| awilkins | Erm, what if the 1.5 sources won't build (the docs, in this case) ? | 22:18 |
| awilkins | Heh, ignore me, turns out the HEAD version of docutils has a bug up it's ass | 22:20 |
| awilkins | I don't suppose anyone would be inclined to trust me to proffer an upload of 1.5 installers for Win32 py2.5 and py2.4 ? | 22:34 |
| awilkins | Hmm. | 22:37 |
| awilkins | Do the team have a policy of zero fails in the test suite or are a certain percentage of fails expected? | 22:44 |
| lifeless | awilkins: drive by comment - alexander had terrible trouble keeping win32 failures at zero; I know this frustrated him, so my guess is that 0 failures on win32 is not currently realistic. | 22:59 |
| * lifeless waves and heads off | 22:59 | |
| awilkins | Ah well... not strictly relevent since I'm just running the testsuite on my shiny new 1.5 build | 23:00 |
| awilkins | I can't fix it, it's "released" code | 23:00 |
| antoranz | Hi guys! | 23:26 |
| antoranz | remember me? new lines on windows? :-D | 23:26 |
| antoranz | I thought of a "cleaner" way to knwo what files to process, instead of having them in a file | 23:26 |
| antoranz | How about using bzr's api to know which files have been aded/modified? | 23:27 |
| james_w | it's not about knowing what was added/modified, but what rules to apply to those files | 23:32 |
| james_w | got to go, sorry. | 23:34 |
| antoranz | show_tree_status? | 23:43 |
| antoranz | Hell! I'm importing bzrlib.workingtree | 23:57 |
| antoranz | but python says WorkingTree is not defined | 23:57 |
| antoranz | but it's right there | 23:57 |
| antoranz | in /usr/lib/pycnetral/blahblah/bzrlib/workingtree.py | 23:58 |
| spiv | antoranz: can you pastebin the exact error? | 23:58 |
| antoranz | sure | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
