| abentley | elmo: It does use the authserver. In fact, it uses it multiple times per session. | 00:17 |
|---|---|---|
| abentley | jam: option a) is significant scope creep. | 01:10 |
| abentley | Why do I have to rewrite your code the way you wish you'd written it? | 01:12 |
| plexq | Is there any way to get bazaar to actually check the files in the directory to see if they are new rather than just assuming they are becuase their timestamp changed? | 03:31 |
| plexq | or will bazaar only actually check in changes that are real? | 03:32 |
| abentley | plexq: Bazaar doesn't use the timestamp to determine whether a file is changed. | 03:33 |
| abentley | It uses a cached SHA1 sum. | 03:34 |
| plexq | ah-ha | 03:38 |
| plexq | I think it's the permissions | 03:38 |
| plexq | windows is funky | 03:38 |
| plexq | ok - a bzr diff says 'properties changed' how can I tell what properties so I can unchange them? | 03:41 |
| fullermd | That would probably be the executable bit... | 03:42 |
| === weigon__ is now known as weigon | ||
| === Toksyuryel` is now known as Toksyuryel | ||
| awilkins | james_w: Ping? | 10:45 |
| james_w | hi awilkins | 10:46 |
| awilkins | james_w: I wrote that "spit the arguments in the stack trace" code we talked about on Wednesday, it wasn't too horrible | 10:56 |
| james_w | awilkins: ah cool, can I see it? | 10:56 |
| awilkins | Let me paste it somewhere.... | 10:56 |
| awilkins | http://pastebin.ca/996915 | 10:58 |
| james_w | thanks | 10:58 |
| awilkins | I put this in trace.py, just above report_bug, and replace the std traceback.print_tb routine with it | 10:59 |
| james_w | awilkins: cool, and that works for positional and keyword arguments? | 10:59 |
| awilkins | Didn't test it ; I just trusted the API docs | 10:59 |
| james_w | any way it could print locals as well, or is that info not available? | 10:59 |
| james_w | heh :-) | 10:59 |
| awilkins | james_w: Yes, it works by reading the locals dict, which contains the args first | 11:00 |
| james_w | awilkins: ah yes, I see, do you think printing all locals would be useful, or too much? | 11:00 |
| awilkins | So you would just change the [:co._co_argcount] to [:] | 11:00 |
| awilkins | Some of those routines have a lot of locals | 11:00 |
| james_w | often the thing you are interested in would be a argument somewhere in the stack, but in certain cases seeing everything might be useful. | 11:01 |
| james_w | true, I think arguments would be a great first step. | 11:01 |
| awilkins | Even just using the sample "assert" test spews a lot if you use all locals | 11:01 |
| james_w | I'd love it if we could have this in the core, controlled by a -D flag probably | 11:01 |
| awilkins | You might not want to make it default ; I was thinking about the D flag | 11:02 |
| awilkins | Because I reckon it could be very nasty with large string values (but I don't know how many bzr chucks around internally) | 11:02 |
| james_w | yeah, default would be too much I think, when a user gets a backtrace there scary enough as it is. | 11:02 |
| awilkins | I suppose if bzr is well designed it doesn't throw around large strings | 11:02 |
| james_w | I don't think it does. | 11:02 |
| james_w | the other alternative would be an environment variable, but I think I prefer the -D option | 11:03 |
| awilkins | Likewise | 11:03 |
| james_w | cool | 11:03 |
| awilkins | You might even want (say) an option for a regex/glob path to match the routines you wanted "arged" | 11:03 |
| james_w | yep, or perhaps a number of frames from the bottom, often the lowest one or two are all you care about. | 11:04 |
| thumper | is there a simple way to just run a subset of the tests? | 11:26 |
| thumper | Odd_Bloke: ping | 11:27 |
| james_w | hi thumper | 11:27 |
| thumper | hi james_w | 11:27 |
| james_w | bzr selftest <regex> | 11:27 |
| thumper | james_w: thanks | 11:27 |
| james_w | it matches on the test names, including the module names. | 11:27 |
| * thumper nods | 11:28 | |
| thumper | I don't have to register new test classes anywhere do I? | 11:29 |
| james_w | classes, no. modules, yes. | 11:29 |
| james_w | tests/test_foo.py has to be listed as test_foo in tests/__init__.py | 11:30 |
| thumper | hmm, I've added a class to tests/test_config.py | 11:30 |
| thumper | however I can't seem to get it running the test | 11:30 |
| james_w | using a regex? | 11:31 |
| thumper | I tried with the class name first, and that didn't work | 11:32 |
| thumper | and I assumed that adding a .* to both ends might help, but it didn't | 11:32 |
| james_w | odd | 11:32 |
| james_w | you're running with the right bzrlib? | 11:33 |
| * thumper smacks forehead | 11:33 | |
| * thumper needed ./bzr rather than bzr | 11:33 | |
| james_w | heh | 11:34 |
| TFKyle | hmm, bundlebuggy b0rked? | 11:53 |
| === mrevell is now known as mrevell-lunch | ||
| Odd_Bloke | thumper: Pong! | 12:44 |
| awilkins | The BB for bzr-gtk doesn't seem to be eating list mails, at least | 12:45 |
| * awilkins is answering a question from a half-hour ago, RAin Man style.... | 12:46 | |
| Odd_Bloke | The bzr BB seems to be b0rked as well. | 12:48 |
| Odd_Bloke | abentley: ^ | 12:48 |
| thumper | Odd_Bloke: I was going to talk with you about PQM | 12:48 |
| thumper | Odd_Bloke: but it's getting late here, and my laptop is about to lose battery power | 12:48 |
| thumper | Odd_Bloke: perhaps we could talk next week some time | 12:48 |
| thumper | oh, and I finally got around to writing tests from by alias command for bzr | 12:49 |
| Odd_Bloke | thumper: Yeah, that'd be good. | 12:49 |
| thumper | Odd_Bloke: when would be good? | 12:49 |
| thumper | Odd_Bloke: can you talk in the evening? | 12:50 |
| Odd_Bloke | thumper: Yeah, normally. Bear in mind that I'm on UTC+1, so evening is somewhat subjective. :p | 12:50 |
| thumper | Odd_Bloke: what time do you head to bed? | 12:51 |
| Odd_Bloke | thumper: Around 11pm local time on average, though it often depends. | 12:51 |
| thumper | Odd_Bloke: how about 9:30, or 10pm Sunday night your time? | 12:52 |
| Odd_Bloke | thumper: Sunday nights don't work well for me, unfortunately. Both Monday and Tuesday evenings work. | 12:53 |
| thumper | ok, how about Monday night? | 12:53 |
| Odd_Bloke | thumper: Sure. | 12:54 |
| thumper | Odd_Bloke: ok, I'll ping before calling (to get your number among other things) | 12:54 |
| * thumper heads to bed now | 12:54 | |
| thumper | nightall | 12:55 |
| abentley | thumper: night | 12:55 |
| Odd_Bloke | thumper: Night! | 12:55 |
| === bigdo3 is now known as bigdog | ||
| abentley | Odd_Bloke: Up now. | 13:18 |
| Odd_Bloke | abentley: Cool, thanks. | 13:20 |
| * Peng suggests a kill-and-restart monitor daemon for BB. | 13:36 | |
| TFKyle | abentley: assuming you were talking about the bzr bb it still seems to be b0rked here: OperationalError: (OperationalError) database is locked u'INSERT INTO visit [...] | 13:52 |
| abentley | Peng: I already implemented one. | 13:53 |
| Peng | :) | 13:53 |
| abentley | TFKyle: Should be working again. | 14:03 |
| === bigdo3 is now known as bigdog | ||
| ubotu | New bug: #221890 in bzr-loom "export-loom should be able to ignore bottom thread (at least)" [Undecided,New] https://launchpad.net/bugs/221890 | 14:49 |
| === mw|out is now known as mw | ||
| mw | The link for the latest RC on http://bazaar-vcs.org/Download is incorrect | 15:02 |
| mw | it says bzr-1.4rc2.1.tar.gz but the actual tarball is named bzr-1.4rc2.tar.gz | 15:03 |
| === cpro1 is now known as cprov | ||
| jam | morning all | 15:27 |
| === pmezard__ is now known as pmezard | ||
| dennda | How do I reverse my whole branch to revision 16? | 16:06 |
| LeoNerd | bzr revert -r 16 | 16:06 |
| dennda | (And, after that has been done: If I commit again, will revisions 17, etc. be overwritten?) | 16:06 |
| radix | dennda: no | 16:07 |
| dennda | how does that work? | 16:07 |
| radix | dennda: revert just modifies your working tree to look like a previous revision. | 16:07 |
| radix | dennda: so if you commit, you'll just be adding a revision that looks like the old content | 16:07 |
| radix | dennda: if you don't want those revisions at all, you can "bzr branch -r 16 oldbranch newbranch" | 16:08 |
| dennda | ok no the standard behaviour is fine | 16:09 |
| vila | hi all | 16:40 |
| vila | beuno: ping | 16:40 |
| abentley | awilkins, james_w: One of the ways Bazaar represents file contents is as large strings. | 16:58 |
| james_w | ah, ok. | 16:58 |
| awilkins | james_w: Could probably do with something that represents large strings as "This is a big {....}." then | 17:28 |
| james_w | awilkins: yep, sounds like it | 17:28 |
| awilkins | I use this thing called HuntErr31 for VB6 (blech) stack tracing | 17:29 |
| james_w | you could str() everything, and then len() it. | 17:29 |
| james_w | then truncate if it's more than some number of characters. | 17:29 |
| awilkins | Much nicer in Python, you don't have to handwrite a stack trace into every routine :-) | 17:29 |
| james_w | heh | 17:29 |
| awilkins | A set of formatting classes might be nice | 17:29 |
| awilkins | (but getting ahead of things) | 17:29 |
| james_w | if you do this it wouldn't want to be hooked in to log_exception_quietly, or whatever it is called, as then you are going to be putting a performance penalty on things. | 17:30 |
| james_w | if the info is wanted you can just ask for -Derror -Dwhatever, that should work. | 17:30 |
| === mrevell is now known as mrevell-afk | ||
| mtaylor | post_push hook: "and the rest should be self explanatory" | 18:52 |
| mtaylor | where "the rest" == "old_revno, old_revid, new_revno, new_revid" | 18:52 |
| mtaylor | if I've got 7 revisions to push, rev x1-x7, (before I push) and after I push they are revs y1-y7 - does old_revno == x1 or x7 ? | 18:54 |
| mtaylor | ok. it seems those match up with 'last-revision' | 19:05 |
| mtaylor | so the question is - if I want to send a post-push message that contains the diff representation of what I just pushed - what's the best way to find the revision from which the push started? | 19:06 |
| mtaylor | I've got a broken recursive function walking back up the tree at this point | 19:06 |
| === threeve__ is now known as threeve | ||
| === mw is now known as mw|food | ||
| emgent | heya | 20:06 |
| james_w | hi emgent | 20:25 |
| kevins | hello all...I have a merge/replay question | 20:39 |
| kevins | I think I know the answer, but want to confirm. I have been following bzr development for years, but only now finally have a chance to use it on a serious project | 20:40 |
| kevins | If I do development on a feature branch, and then merge into the mainline, the default behavior is for all my changes to get combined into one changeset (with details available in log --long) | 20:41 |
| kevins | But if I really want all my individual commits to be reflected in the mainline, there is no simple way to do so | 20:41 |
| kevins | I would have to rebase, replay, and then push...is that right? | 20:42 |
| james_w | not sure what you mean by replay, but yes. | 20:44 |
| james_w | push or pull as the last step works. | 20:44 |
| jelmer | beuno: ping | 20:44 |
| beuno | jelmer, ping (vila too) | 20:44 |
| jelmer | beuno: any chance you can review http://bundlebuggy.vernstok.nl/bzr-gtk//request/%3C1207373163.31805.6.camel@ganieda.vernstok.nl%3E ? | 20:45 |
| beuno | jelmer, sure, let me just hide from marianom for a minute :p | 20:45 |
| jelmer | marianom? | 20:45 |
| beuno | jelmer, he's here working with me on something, but ignore that comment :) | 20:46 |
| james_w | hi jelmer, beuno | 20:47 |
| james_w | beuno: you have a party tonight? | 20:47 |
| beuno | hey james_w! | 20:47 |
| beuno | james_w, we already had one last night | 20:47 |
| beuno | should we have another one today? | 20:47 |
| beuno | maybe we should... | 20:47 |
| james_w | every night! | 20:47 |
| james_w | how was it? | 20:47 |
| beuno | jelmer, can I log into BB directly? It still doesn't let me vote through email | 20:47 |
| jelmer | beuno: yes, you should be able to login directly | 20:48 |
| kevins | james_w: I think the rebase plugin has a replay command | 20:48 |
| jelmer | beuno: I think I sent you the password by email during the sprint | 20:48 |
| james_w | kevins: ah, I didn't know that. | 20:48 |
| beuno | jelmer, let me try and find it | 20:49 |
| kevins | if not that, then how else would I be able to do a push if someone else had made changes? | 20:49 |
| beuno | james_w, did you folks have a party at Canonical? | 20:49 |
| james_w | kevins: ah, that's what rebase is, it does the replay I thought. | 20:49 |
| Daviey | beuno: There was one - and it was lots of fun! | 20:49 |
| james_w | beuno: there was one, with some of ubuntu-uk as well, but I wasn't in London so I missed it. There were reports of people getting home at 9am this morning though. | 20:50 |
| beuno | jelmer, found it, approved. It redirects me to localhost for some reason though... | 20:51 |
| james_w | hi Daviey. Are you going to Swindon tomorrow by any chance? | 20:51 |
| jelmer | beuno: yeah, I think I need to update | 20:51 |
| beuno | james_w, 9am?? oh god... | 20:51 |
| jelmer | beuno: It should be fixed | 20:51 |
| jelmer | beuno: (update BB that is) | 20:51 |
| Daviey | james_w: hmm - haven't requested a weekend leave pass from MrsDaviey - i should try :) | 20:51 |
| james_w | Daviey: you can tell her you're staying over at mine, as long as she doesn't phone we'll be ok. | 20:52 |
| Daviey | :) | 20:52 |
| Daviey | i would love to! I'll work on it | 20:53 |
| jelmer | beuno: thanks, btw :-) | 20:53 |
| beuno | jelmer, anytime :) | 20:55 |
| * beuno goes back to work | 20:55 | |
| kevins | I'm not sure how to suggest it, but my question is not covered in any docs/wiki/mailing list archive that I could find. It was a big surprise to me, so it would be great if it could be documented | 20:59 |
| jelmer | kevins: what was your question exactly? | 21:00 |
| kevins | jelmer: I was confirming that moving full history from a feature branch to a mainline is difficult, not automatic | 21:04 |
| kevins | jelmer: the way I do code reviews on our project, that's going to be somewhat painful for me | 21:08 |
| jelmer | kevins: What do you mean by "moving history" exactly? "bzr merge" will reconcile the histories of a feature branch and mainline | 21:09 |
| kevins | jelmer: by "full history", I mean that I could look at mainline, and see each individual commit that was made on the feature branch, not just a single "merge" changeset | 21:09 |
| kevins | jelmer: and not just commit logs, but the actual diffs, so I could do code reviews from the mainline itself | 21:10 |
| jelmer | kevins: You can do that if you use merge | 21:11 |
| jelmer | "bzr log" will show the merged revisions indented | 21:11 |
| jelmer | and you can use "bzr diff -c" on the revision numbers listed there | 21:11 |
| kevins | jelmer: ah, that isn't documented (that I could find)...so you are saying that each commit gets merged, and can be individually explored...I couldn't figure out what -c was for | 21:15 |
| kevins | jelmer: Just tried it, and with bzr visualize, it looks like it does exactly what I want. Thanks! Would be great if the merge documentation were clearer about that. | 21:24 |
| jelmer | kevins: please file a bug report or talk to igc when he is around (he does most of the work on the docs) | 21:25 |
| vila | beuno: pong | 21:36 |
| === mw|food is now known as mw | ||
| korpios | pung. pang. peng. | 21:39 |
| beuno | vila, hey! | 21:39 |
| vila | beuno: tests passing again in bzr-upload, man, at least run the test suite before committing :) | 21:40 |
| vila | Were you able to install medusa ? | 21:40 |
| beuno | vila, I was able _after_ I committed. Sorry about that :( | 21:41 |
| vila | beuno: Argh, re-reading log, it looks like I reverted your ""Moved reporting of what has been done to a default instead of verbose mode" | 21:41 |
| beuno | I'll be good now :) | 21:41 |
| beuno | vila, no worries, I'll add that on later | 21:42 |
| beuno | glad you're back | 21:42 |
| vila | But since we have a verbose option I really think we should use it, you can define an alias to put it on | 21:42 |
| vila | Thanks for your additions anyway, good to see changes and conflicts checked ! | 21:43 |
| beuno | vila, I initially had it as verbose, but, on the other hand, who *doesn't* want to know what was uploaded? | 21:43 |
| beuno | seems to me like 95% of the time, you will want to know | 21:43 |
| beuno | so I moved it to a default behavour | 21:43 |
| vila | cron jobs, people trusting the plugin, **tests** -) | 21:44 |
| vila | But since the outf modification broke nearly all the tests I need to re-think the way they are structured so I can run them with verbose=False and put verbose=True as default | 21:45 |
| beuno | vila, then it seems like it's the inverse, you need a --quite :) | 21:45 |
| beuno | s/you/we | 21:45 |
| vila | sure | 21:45 |
| beuno | vila, yes, I realized my outf broke the tests. But now I can run the tests, so it should be easier not to piss you off :) | 21:46 |
| james_w | is this the plugin you were talking about in London for people who want to have websites in bzr and upload the working tree as well? | 21:46 |
| vila | beuno: time to bzr update then, that was fixed a couple of hours ago :) | 21:46 |
| beuno | james_w, yeap, it's pseudo-working :) | 21:47 |
| vila | and wether or not verbose is True, all outf statements should be under its control :) | 21:47 |
| vila | james_w: yup | 21:47 |
| beuno | vila, cool. I'll pull and look at the diff/logs | 21:47 |
| james_w | awesome, thanks guys | 21:47 |
| beuno | james_w, http://launchpad.net/bzr-upload :) | 21:48 |
| ubotu | New bug: #222161 in bzr "Documentation is unclear about merge history preservation" [Undecided,New] https://launchpad.net/bugs/222161 | 21:56 |
| vila | beuno: how far have you gone in your bzr-upload use ? | 22:05 |
| beuno | vila, not far, I'm stuck on uploading individual files to integrate it into my system | 22:14 |
| beuno | I have, however, used it for several personal sites | 22:15 |
| beuno | and it's working fine | 22:15 |
| vila | hmmm, you want to upload unversioned individual files ? | 22:15 |
| beuno | vila, upload arbitrary versioned files :) | 22:22 |
| vila | I can't parse that... Either you use bzr-upload to keep your wt and your remote synchronized or you don't, as soon as you modify your remote... well you broke the sync | 22:23 |
| vila | Or do you mean you want a --uncommited option ? | 22:24 |
| beuno | vila, that's not it. I mean, use bzr-upload to re-upload an arbitrary versioned file. For any reason possible. Or, if not possible, *exlude* some files from being uploaded | 22:24 |
| vila | That will break the sync, what's the use case ? | 22:25 |
| beuno | vila, well, here, since multiple people push stuff, many times, someone doesn't want to upload the other guy's changes, so he just uploads his changed files | 22:27 |
| vila | 8-) verbose=False to the rescue !!! | 22:28 |
| vila | seriously, the remote could really messy with no hope to ever be able to upload incrementally, you're got really high risks of having an incoherent remote site | 22:29 |
| vila | s/could really/could really get/ | 22:29 |
| vila | s/you're/you've/ | 22:29 |
| * vila is back with his typos | 22:30 | |
| * vila 's hands suffer to rebuild the kitchen, be gentle ;-) | 22:31 | |
| beuno | vila, right, I agree from a purist point of view. I'm just explaining what my reality is: I can't fully use it if I force people to upload every file | 22:31 |
| beuno | and I imagine I'm not alone :) | 22:31 |
| vila | That's not purity at all, that's just that it will not work :) | 22:32 |
| vila | We use bzr to know what needs to be uploaded so bzr should be informed about what is uploaded or she can't tell us | 22:33 |
| vila | and if bzr can't tell us, either we download the remote and compare it with local or we blindly upload the full wt | 22:33 |
| vila | which you will find equally unacceptable | 22:34 |
| vila | AIUI, *you* force them to merge which implies you force them to upload other guys changes | 22:35 |
| vila | if you really want that do that, but if you don't, don't force them to merge and leave them handle the consequences: a remote mess :) | 22:35 |
| vila | What we are trying to achieve is minimizing uploads, we use bzr for that, you can't find upload less and still be able to do it incrementally | 22:37 |
| vila | s/find// | 22:38 |
| beuno | vila, not even if we warn the user enough? | 22:40 |
| vila | warning the user will not give us a way to avoid a full upload | 22:41 |
| vila | why don't they want to upload the other's guy changes ? Time ? Cost ? | 22:41 |
| vila | Not wanting to assume the other guy bugs ? | 22:41 |
| vila | Honestly, I'm trying to solve the problem, if it means tons of code I'll tell you come back next century, but I will not say no | 22:43 |
| james_w | heh :-) | 22:48 |
| beuno | vila, assuming the other guys bugs :) | 22:49 |
| vila | There you go, do bzr-upload in a pre-commit hook :) | 22:50 |
| vila | or don't force htem to merge before uploading | 22:51 |
| beuno | vila, right, well, they _have_ to merge to be able to push to the main repo | 22:51 |
| beuno | and, I probably don't want them to upload from their own repo, but from the main one | 22:52 |
| beuno | but I suppose I can change parts of that, or work around it when they want to upload it partially | 22:52 |
| vila | but you leave them push without uploading ? | 22:52 |
| beuno | vila, yeap, many times | 22:52 |
| beuno | I don't want every change to go online | 22:52 |
| beuno | 3 people might work on a feature (or different ones) for a few weeks before uploading | 22:53 |
| beuno | and, suddenly, one of them want to upload the feature they've been working on | 22:53 |
| beuno | but not the others | 22:53 |
| beuno | so, currently, they just upload the files they've been working on | 22:53 |
| vila | fair enough, use feature branches | 22:53 |
| beuno | yes, I've been avoiding adding a layer of complexity for the non-techie guys | 22:54 |
| beuno | with this less-than-perfect option of uploading specific files | 22:54 |
| vila | but how do they know what specific files they need to upload ? | 22:55 |
| vila | they do that without bzr ? | 22:55 |
| vila | me is scared for them | 22:55 |
| vila | :) | 22:55 |
| * vila is scared for them | 22:55 | |
| vila | scared damn it (put down that hammer will you) | 22:56 |
| vila | bzr-upload is a mix of bzr export and bzr push | 22:56 |
| vila | it's not really a push because we can't patch the remote files, we need to upload them completely | 22:57 |
| beuno | vila, yes, it's scary :) | 22:57 |
| vila | but at least we know which files have been modified because we use the revid to identify the whole remote tree | 22:57 |
| vila | if you upload one or severa; files behind our back, there is no more revid to represent the whole remote tree, we're doomed | 22:58 |
| vila | but we can upload any revid, so I think the solution is to give them the right branches to work with | 22:59 |
| beuno | vila, right. I guess a more advanced interface than they currently have might work around this | 22:59 |
| beuno | (let them choose which one of *their* revids they want to upload( | 23:00 |
| beuno | so, you can ignore that bug, and I'll add more work to my list :) | 23:00 |
| vila | I don't really think it's a workaround, you want to know the history of your remote site | 23:00 |
| beuno | vila, yeap, gotcha | 23:02 |
| vila | My advice would be to clearly define the overall workflow including the constraint that you want to track the work done *and* the remote history, I'm under the impression that you need to define some intermediate branches from where you push to the main repo and then you upload | 23:04 |
| vila | That way code can be shared before upload without forcing any part on anyone too early | 23:04 |
| beuno | vila, yeap, I'll look into changing bits of my workflow | 23:07 |
| vila | Ok, keep me informed, I'll try to make full upload more robust anyway and then have a look at the chmod bits | 23:08 |
| beuno | vila, will do. I'll need some basic logging out of the plugin to catch errors, and then I can implement on a wider scale | 23:10 |
| beuno | (I'm thinking error-side errors mostly) | 23:10 |
| vila | server-side ? | 23:10 |
| beuno | vila, random web servers going down in the middle of an upload | 23:11 |
| beuno | I currently report back to the user what was succesfully uploaded, and what wasn't (currently comparing md5, but I'm only using SSH) | 23:12 |
| beuno | so the user knows they have to re-upload i | 23:12 |
| beuno | *it | 23:12 |
| beuno | which is another use case for the bug I filed | 23:12 |
| beuno | 100 files to upload on revid X | 23:12 |
| beuno | 99 get uploaded, and 1 fails for random reason | 23:12 |
| beuno | you just re-upload 1 file | 23:12 |
| beuno | not 100 | 23:13 |
| jelmer | beuno: thanks again for looking after those reviews | 23:13 |
| beuno | jelmer, np, I should of done it a while back anyway :) | 23:14 |
| vila | Hmm, yes, ftp transport should handle more gracefully transient errors, that would help a lot | 23:15 |
| beuno | vila, maybe resume b0rked upload may be an option to implement for the case I just proposed | 23:17 |
| beuno | of course, that means a lot of more work | 23:18 |
| beuno | because you have to keep the state of the upload somewhere, until it's succesfull | 23:18 |
| vila | handling transient errors will address most of the failures, is needed anyway and yes, is easier | 23:19 |
| vila | So let's do that first and see :) | 23:19 |
| beuno | vila, alrighty | 23:20 |
| vila | gee midnight already gone ! night all :) | 23:35 |
| beuno | vila, sleep well! | 23:35 |
| * beuno waves at mwh_ | 23:41 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!