[00:17] <abentley> elmo: It does use the authserver.  In fact, it uses it multiple times per session.
[01:10] <abentley> jam: option a) is significant scope creep.
[01:12] <abentley> Why do I have to rewrite your code the way you wish you'd written it?
[03:31] <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:32] <plexq> or will bazaar only actually check in changes that are real?
[03:33] <abentley> plexq: Bazaar doesn't use the timestamp to determine whether a file is changed.
[03:34] <abentley> It uses a cached SHA1 sum.
[03:38] <plexq> ah-ha
[03:38] <plexq> I think it's the permissions
[03:38] <plexq> windows is funky
[03:41] <plexq> ok - a bzr diff says 'properties changed' how can I tell what properties so I can unchange them?
[03:42] <fullermd> That would probably be the executable bit...
[10:45] <awilkins> james_w: Ping?
[10:46] <james_w> hi awilkins
[10:56] <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:58] <awilkins> http://pastebin.ca/996915
[10:58] <james_w> thanks
[10:59] <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 :-)
[11:00] <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:01] <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:02] <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:03] <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:04] <james_w> yep, or perhaps a number of frames from the bottom, often the lowest one or two are all you care about.
[11:26] <thumper> is there a simple way to just run a subset of the tests?
[11:27] <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:28]  * thumper nods
[11:29] <thumper> I don't have to register new test classes anywhere do I?
[11:29] <james_w> classes, no. modules, yes.
[11:30] <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:31] <james_w> using a regex?
[11:32] <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:33] <james_w> you're running with the right bzrlib?
[11:33]  * thumper smacks forehead
[11:33]  * thumper needed ./bzr rather than bzr
[11:34] <james_w> heh
[11:53] <TFKyle> hmm, bundlebuggy b0rked?
[12:44] <Odd_Bloke> thumper: Pong!
[12:45] <awilkins> The BB for bzr-gtk doesn't seem to be eating list mails, at least
[12:46]  * awilkins is answering a question from a half-hour ago, RAin Man style....
[12:48] <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:49] <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:50] <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:51] <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:52] <thumper> Odd_Bloke: how about 9:30, or 10pm Sunday night your time?
[12:53] <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:54] <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:55] <thumper> nightall
[12:55] <abentley> thumper: night
[12:55] <Odd_Bloke> thumper: Night!
[13:18] <abentley> Odd_Bloke: Up now.
[13:20] <Odd_Bloke> abentley: Cool, thanks.
[13:36]  * Peng suggests a kill-and-restart monitor daemon for BB.
[13:52] <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:53] <abentley> Peng: I already implemented one.
[13:53] <Peng> :)
[14:03] <abentley> TFKyle: Should be working again.
[14:49] <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
[15:02] <mw> The link for the latest RC on http://bazaar-vcs.org/Download is incorrect
[15:03] <mw> it says bzr-1.4rc2.1.tar.gz but the actual tarball is named bzr-1.4rc2.tar.gz
[15:27] <jam> morning all
[16:06] <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:07] <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:08] <radix> dennda: if you don't want those revisions at all, you can "bzr branch -r 16 oldbranch newbranch"
[16:09] <dennda> ok no the standard behaviour is fine
[16:40] <vila> hi all
[16:40] <vila> beuno: ping
[16:58] <abentley> awilkins, james_w: One of the ways Bazaar represents file contents is as large strings.
[16:58] <james_w> ah, ok.
[17:28] <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:29] <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:30] <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.
[18:52] <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:54] <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 ?
[19:05] <mtaylor> ok. it seems those match up with 'last-revision'
[19:06] <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
[20:06] <emgent> heya
[20:25] <james_w> hi emgent
[20:39] <kevins> hello all...I have a merge/replay question
[20:40] <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:41] <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:42] <kevins> I would have to rebase, replay, and then push...is that right?
[20:44] <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:45] <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:46] <beuno> jelmer, he's here working with me on something, but ignore that comment  :)
[20:47] <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:48] <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:49] <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:50] <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:51] <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:52] <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:53] <Daviey> i would love to!  I'll work on it
[20:53] <jelmer> beuno: thanks, btw :-)
[20:55] <beuno> jelmer, anytime  :)
[20:55]  * beuno goes back to work
[20:59] <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
[21:00] <jelmer> kevins: what was your question exactly?
[21:04] <kevins> jelmer: I was confirming that moving full history from a feature branch to a mainline is difficult, not automatic
[21:08] <kevins> jelmer: the way I do code reviews on our project, that's going to be somewhat painful for me
[21:09] <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:10] <kevins> jelmer: and not just commit logs, but the actual diffs, so I could do code reviews from the mainline itself
[21:11] <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:15] <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:24] <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:25] <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:36] <vila> beuno: pong
[21:39] <korpios> pung.  pang.  peng.
[21:39] <beuno> vila, hey!
[21:40] <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:41] <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:42] <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:43] <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:44] <vila> cron jobs, people trusting the plugin, **tests** -)
[21:45] <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:46] <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:47] <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:48] <beuno> james_w, http://launchpad.net/bzr-upload   :)
[21:56] <ubotu> New bug: #222161 in bzr "Documentation is unclear about merge history preservation" [Undecided,New] https://launchpad.net/bugs/222161
[22:05] <vila> beuno: how far have you gone in your bzr-upload use ?
[22:14] <beuno> vila, not far, I'm stuck on uploading individual files to integrate it into my system
[22:15] <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:22] <beuno> vila, upload arbitrary versioned files  :)
[22:23] <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:24] <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:25] <vila> That will break the sync, what's the use case ?
[22:27] <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:28] <vila> 8-) verbose=False to the rescue !!!
[22:29] <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:30]  * vila is back with his typos
[22:31]  * 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:32] <vila> That's not purity at all, that's just that it will not work :)
[22:33] <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:34] <vila> which you will find equally unacceptable
[22:35] <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:37] <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:38] <vila> s/find//
[22:40] <beuno> vila, not even if we warn the user enough?
[22:41] <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:43] <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:48] <james_w> heh :-)
[22:49] <beuno> vila, assuming the other guys bugs  :)
[22:50] <vila> There you go, do bzr-upload in a pre-commit hook :)
[22:51] <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:52] <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:53] <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:54] <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:55] <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:56] <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:57] <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:58] <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:59] <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
[23:00] <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:02] <beuno> vila, yeap, gotcha
[23:04] <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:07] <beuno> vila, yeap, I'll look into changing bits of my workflow
[23:08] <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:10] <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:11] <beuno> vila, random web servers going down in the middle of an upload
[23:12] <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:13] <beuno> not 100
[23:13] <jelmer> beuno: thanks again for looking after those reviews
[23:14] <beuno> jelmer, np, I should of done it a while back anyway  :)
[23:15] <vila> Hmm, yes, ftp transport should handle more gracefully transient errors, that would help a lot
[23:17] <beuno> vila, maybe resume b0rked upload may be an option to implement for the case I just proposed
[23:18] <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:19] <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:20] <beuno> vila, alrighty
[23:35] <vila> gee midnight already gone ! night all :)
[23:35] <beuno> vila, sleep well!
[23:41]  * beuno waves at mwh_