[12:02] <Rotund> This is particularly important for things like tests that should be reviewed long before the last one is written.
[12:02] <luks> well, that is a different problem
[12:03] <Rotund> I suppose you could do a "reviewed" branch and limit commit rights
[12:04] <luks> I think that's the most common solution the branch/merge development model
[12:05] <Rotund> I've got a lot of concerns I have to alleviate if they consider it.
[12:06] <Rotund> Mostly it'll need a new process definition.
[12:08] <abentley> Distributed version control usually works on the basis that it's easier to get forgiveness than permission.
[12:08] <Rotund> Or you throw a fancy gatekeeper or plugin in to do it.
[12:09] <Rotund> We're in the kind of business where people die if we mess up, so people want tight control.
[12:09] <abentley> Well, even so, anyone can work on any file at any time.  It's hoped that the changes won't conflict, but running the risk of conflicts is considered worthwhile for the benefits it gives.
[12:10] <abentley> Gatekeepers don't necessarily have to be fancy.  If you have reviewers, they can be the gatekeepers.
[12:10] <Rotund> I think it's a great model for full development, but I'm wondering how to make it work w/ 100 independent tests.
[12:11] <Rotund> true, true.  Just gotta make sure THEY know the rules.
[12:11] <Rotund> that's much easier.
[12:12] <Rotund> can BZR do automated header generation?
[12:13] <abentley> Rotund, no, but it has hooks for running scripts on commit.
[12:13] <Rotund> Hmmm.  That should work.
[12:13] <Rotund> I definitely like the idea of a PQM.
[12:13] <Rotund> That to me would be great.
[12:14] <Rotund> keeps people from doing that stupid commit on Friday night that breaks everything.
[12:15] <Rotund> Or worse... before going on vacation.
[12:16] <Rotund> I'll definitely have to look into how to do plugins.
[12:16] <Rotund> Any support for things outside straight text?
[12:17] <Rotund> A way to diff docs would be great, but rtf files should be doable, right?  That's text I think.
[12:17] <Rotund> (can't wait for docx/odf)
[12:18] <abentley> The tool will not damage binary data, but does not have inbuilt support for diffing other types.  There is a plugin that lets you use an arbitrary diff
[12:24] <Rotund> okay.
[12:25] <Rotund> Hmmm.  Can you write a plugin that can add attributes to files?
[12:26] <Rotund> Like, can I have one that would add an attribute "reviewed" that's a boolean?
[12:41] <schierbeck> hi guys
[12:42] <Rotund> hi
[12:57] <schierbeck> phanatic: bundle-buggy kicks ass
[12:58] <phanatic> schierbeck: indeed :) huge thanks to jelmer for setting it up!
[12:58] <schierbeck> jelmer rules :)
[04:00] <spiv> lifeless: sent
[04:05] <poolie> lifeless, did you build debs?
[04:19] <lifeless> poolie: build failure
[04:20] <lifeless> its a background task, cycling on it all day
[04:55] <poolie> np
[04:55] <poolie> lifeless, for johnf's patch i'm just going to add a test in RemoteTransportRegistration to make sure we can get the transport
[04:55] <poolie> ok with you?
[05:51] <lifeless> poolie: sounds good
[06:56] <lifeless> abentley: beautiful name
[07:25] <poolie> yep
[07:25] <poolie> continuing the buggy theme
[07:28] <lifeless> as well as being trac inverted
[07:29] <poolie> i think it's bogus for attempt_lock to explicitly check transport.is_readonly
[07:29] <poolie> rather than just letting the lock attempt fail
[07:32] <lifeless> I agree
[07:32] <lifeless> it may have been a premature optimisation
[07:32] <poolie> i'd like an  attempt to commit to a readonly transport to say:
[07:32] <poolie> bzr: error: cannot commit to http.........: transport is readonly
[07:33] <lifeless> well
[07:33] <poolie> it might be a bit clearer to say "location is readonly"
[07:33] <lifeless> it could be that its readonly
[07:33] <lifeless> $location cannot be locked (it is readonly)
[07:33] <poolie> actually, right
[07:33] <poolie> raising it from the lockdir layer is good
[07:33] <lifeless> $location cannot be locked (IO error creating lockdir)
[07:33] <lifeless> etc
[07:33] <poolie> it's probably reasonably clear to say 'cannot be locked'
[07:34] <poolie> and follow it with the underlying message
[07:34] <poolie> do you think people will understand why?
[07:34] <lifeless> I think it is an improvement
[07:34] <lifeless> I don't know if its enough
[07:36] <james_w> I don't think it is enough.
[07:37] <james_w> poolie: just for reference, some commands that require a write raise LockError (well, a subclass), others I think raise TransportNotPossible, and there are probably some that raise something else.
[07:37] <james_w> the transportNotPossible one is at least partially intelligible, if only because it is not an internal error.
[07:38] <poolie> james_w, yes, i can see there is some unneeded diversity
[07:38] <poolie> what do you think would be a good message?
[07:39] <james_w> If you can't be more specific to pick out the protocols where this is likely a user misunderstanding, then at least put readonly in there, even at the risk of being wrong sometimes.
[07:40] <poolie> james_w, i looked for your previous patch btw but couldn't find it
[07:40] <poolie> what we want to communicate seems to be
[07:40] <poolie> - you were trying to write to $url and couldn't
[07:40] <poolie> - this is the expected behaviour, not a bug
[07:41] <james_w> You don't have to assert that it is readonly, just that it is a possibility, and perhaps hint that the user should check the transport they are using. (Maybe using urlspec as a pointer).
[07:41] <poolie> - because you can't write over $protocol
[07:41] <poolie> it might be good to hint you could use another protocol
[07:42] <james_w> You were trying to write to $url and couldn't. This is usually because $transport is readonly. You may be able to use another transport to complete the operation see 'bzr help urlspec' for details on the avaiable transports.
[07:43] <poolie> if we fix this for readonly protocols people will still hit similar situations when eg they don't have permission for that directory
[07:43] <james_w> or perhaps 'bzr help transports' which would explain the issue in more depth, and then point to urlspec. Perhaps it could suggest the common ways to change the transport.
[07:44] <james_w> poolie: yes indeed. Perhaps that could be another sentence. However transport issues seem to be far more prevalent.
[07:52] <lifeless> I don't think transport and urlspec should be separated
[07:52] <lifeless> urlspec is afterall simply the address of a transport
[07:53] <lifeless> poolie: can't write over transport OR can normally but some [transient?]  limitation has occured
[07:53] <poolie> yes, i know
[07:53] <lifeless> righto
[07:54] <poolie> i think this will be sufficiently improved by
[07:54] <poolie> just:
[07:54] <poolie> failed to lock $url: $reason
[07:54] <poolie> as a noninternal error
[07:54] <poolie> also, i wish there was a more systematic way to handle remote errors in hpss
[08:01] <spiv> Yeah.
[08:01] <spiv> Me too...
[08:18] <lifeless> wow
[08:18] <lifeless> I can't wait for packs to be in mainline
[08:19] <lifeless> pushing to knits is painful :(
[08:19] <lifeless> (its annotating every changed file)
[08:28] <lifeless> poolie: on error codes
[08:28] <lifeless> things like pull use exceptions to signal 'can't pull'
[08:29] <lifeless> but '3' as the return value seems a little weird to me
[08:29] <lifeless> yo i386
[08:29] <i386> hey lifeless
[08:29] <i386> I thought id come and idle here :)
[08:29] <lifeless> great idea
[08:30] <poolie> lifeless, i think pull should return 1
[08:30] <i386> Id like to think so :)
[08:30] <poolie> you understand that i didn't change that behavior with my recent patch?
[08:30] <lifeless> poolie: I know, it just got me thinking
[08:30] <i386> lifeless: perhaps I can offer some of my time at some point
[08:30] <lifeless> poolie: that perhaps exceptions that are not internal should have a .errno attribute
[08:31] <poolie> maybe errors should have an attribute to say their
[08:31] <poolie> jinx
[08:31] <lifeless> i386: even better idea :)
[08:31] <i386> Im writing that allocator, btw
[08:32] <lifeless> excellent
[08:36] <i386> lifeless: have you heard of Hoard ?
[08:36] <lifeless> yes
[08:36] <i386> Its a really advanced memory allocator
[08:36] <i386> ahh
[08:37] <i386> Im thinking of writing a obmalloc.c that uses it
[08:37] <i386> and doing some more profiling if my current reasoning is correct
[08:37] <lifeless> did you establish that allocation time was the root cause?
[08:37] <i386> not yet
[08:37] <lifeless> or is it still speculative?
[08:37] <i386> yes, speculative - but ill have that answer in the next few days
[08:37] <lifeless> cool
[08:38] <i386> Im reading a lot of material at the moment to counter my lack of a Computer Science degree
[08:38] <i386> for this particular problem
[08:38] <lifeless> hmm, I wouldn't expect a CS degree to necessarily help
[08:38] <lifeless> this domain is a little specialised
[08:39] <lifeless> as well as being NPC IIRC
[08:39] <i386>  NPC?
[08:39] <lifeless> non polynomial complete
[08:40] <lifeless> IIRC memory allocation has been shown to be equivalent to the knapsack problem
[08:41] <lifeless> time to test commit again
[08:41] <lifeless> now I've just done mass merges
[08:41] <i386> lifeless: can I get the url for your experimental branch ?
[08:41] <lifeless> of course
[08:41] <i386> thanks
[08:41] <lifeless> it, and details for how to dogfood, are all on the list
[08:42] <lifeless> if you goolge for robertc packs repository dogfood
[08:42] <lifeless> you'll get the first post
[08:43] <lifeless> uhm, look for [PACKS]  in the message listing, last one was late last week
[08:44] <lifeless> poolie: I'm gagging for reviews now
[08:46] <lifeless> hmmm, 1m28
[08:46] <lifeless> not too bad
[08:46] <lifeless> twice the speed of knits :)
[08:47] <lifeless> initial commit:
[08:47] <lifeless> real    3m49.358s
[08:47] <lifeless> user    1m28.650s
[08:47] <lifeless> sys     0m5.840s
[08:48] <lifeless> incremental:
[08:48] <lifeless> real    0m25.878s
[08:48] <lifeless> user    0m23.797s
[08:48] <lifeless> sys     0m1.372s
[08:48] <lifeless> partial incremental:
[08:48] <lifeless> real    0m26.801s
[08:48] <lifeless> user    0m19.969s
[08:48] <lifeless> sys     0m0.768s
[08:49] <spiv> i386: a lot of effort has gone into the design and implementation of the CPython memory allocator.
[08:49] <lifeless> spiv: I mentioned this :)
[08:50] <spiv> i386: so I will be pleasantly surprised if you can do better :)
[08:57] <i386> spiv: im probably completely wrong but leave learning something out of the ordeal
[09:12] <lifeless> night all
[10:11] <ubotu> New bug: #148443 in bzr "progress bar for loading tests" [Wishlist,Confirmed]  https://launchpad.net/bugs/148443
[10:44] <lifeless> poolie: latest packs pushing now
[10:44] <lifeless> i386: ^
[10:44] <lifeless> revno 2788
[10:45] <i386_> hey lifeless
[10:56] <ubotu> New bug: #148463 in bzr "structured way to remote exceptions" [Medium,Confirmed]  https://launchpad.net/bugs/148463
[11:44] <i386_> lifeless: what software do you use for bazaar-vcs.org ?
[12:38] <AnMaster> i386_, hm I wonder that too
[12:39] <AnMaster> very nice wiki they have there
[12:39] <elmo> it's moin
[12:39] <AnMaster> hm looking at http://bazaar-vcs.org/RecentChanges it seems to be moin
[12:40] <AnMaster> ah elmo beat me to it
[12:41] <AnMaster> or mediawiki, for larger projects
[12:44] <i386_> AnMaster: 's/mediawiki/Atlassian Confluence/'
[12:45] <fullermd> Mediawhati?  Trunk?  Are those new versions of vi?   :p
[01:00] <AnMaster> i386_, link?
 Mediawhati?  Trunk?  Are those new versions of vi?   :p <-- why? I use emacs myself :P
[01:01] <hsn_> i think Eclipse is new version of gViM
[01:01] <i386_> AnMaster: http://www.atlassian.com/software/confluence
[01:01] <i386_> AnMaster: we give free licenses of our products to open source projects
[01:01] <i386_> because we love you guys
[01:01] <AnMaster> not open source though
[01:02] <fullermd> AnMaster: Well, I only have a gig and a quarter of RAM, so I can't use emacs...
[01:02] <i386_> no but liberally licensed though
[01:02] <AnMaster> if not OSI approved license, forget it ;P
[01:02] <i386_> you buy a license and you get the source :)
[01:02] <AnMaster> i386_, only non free software on my computer would be bios and nvidia drivers
[01:03] <AnMaster> (anyway this seems to be getting off topic)
[01:03] <Keybuk> I have a random question
[01:03] <AnMaster> well ask it then?
[01:03] <fullermd> I have a random answer   :)
[01:03] <Keybuk> why is it that when I bzr branch with an sftp:// URL, I get a .bzr/branch/parent
[01:03] <jelmer> hey Scott
[01:04] <Keybuk> but when I bzr branch with an http:// URL, I get a .bzr/branch/branch.conf ?
[01:04] <AnMaster> interesting
[01:04] <jelmer> Keybuk: same branch?
[01:04] <fullermd> Because the branch you're branching over sftp is a branch5, and the branch over http is a branch6.
[01:04] <jelmer> Keybuk: it may be different between formats, but it should not be different per transport
[01:05] <AnMaster> um? what is branch5/6? is this related to formats lke
[01:05] <AnMaster> like* dirstate?
[01:05] <fullermd> 'dirstate' (and 'knit') use branch5.  dirstate-tags uses branch6.
[01:05] <AnMaster> ah
[01:05] <AnMaster> so then I use branch6
[01:05] <AnMaster> good to know
[01:05] <Keybuk> ahh
[01:05] <AnMaster> fullermd, btw, is there any way to see tags in trac-bzr?
[01:05] <Keybuk> interesting
[01:06] <AnMaster> haven't found a way
[01:06] <Keybuk> it makes a difference, because it means that branch6 branches remember where you push them to
[01:06] <fullermd> No idea.  I've never used trac, bzr or otherwise.
[01:06] <Keybuk> whereas branch5 branches don't
[01:06] <fullermd> No, branch5 branches remember.
[01:06] <fullermd> They just pollute locations.conf with it, instead of storing it in-branch.
[01:06] <Keybuk> (instead ~/.bazaar/locations.conf remembers for you, so if you move the directory, it forgets)
[01:06] <AnMaster> fullermd, how does this work with shared repos, like if you run bzr upgrade --dirstate-tags in one branch in a shared repo
[01:06] <AnMaster> what will happen then?
[01:07] <fullermd> AnMaster: Shared repos only share the repo format.  The branch and WT formats can differ inside it all you want.
[01:07] <AnMaster> ah
[01:07] <AnMaster> WT?
[01:07] <i386_> fucking LOL
[01:07] <fullermd> Working Tree.
[01:07] <AnMaster> ah
[01:07] <i386_> This guy just posted anon his penis on /b/ except his name was in the exif data - so I tracked him down on face book
[01:07] <i386_> and now /b/ is a whole lot less boring
[01:08] <AnMaster> i386_, *slightly* off topic here I feel
[01:08] <i386_> http://img.4chan.org/b/res/41472375.html
[01:08] <i386_> oops
[01:08] <i386_> wrong chan
[01:09] <i386_> ahhh
[01:09] <AnMaster> well, I have posted in wrong channels before (asking bzr questions in #trac by mistake for example) but nothing like that, (I'm not on channels like that)
[01:10] <i386_> huh?
[01:10] <i386_> 4chan is a message board for anime
[01:10] <gabe_> nah don't worry not the wrong channel
[01:10] <i386_> and japanese culture
[01:10] <gabe_> i need some distraction from work
[01:10] <fullermd> Right.  The rest of us have standards instead   ;>
[01:10] <i386_> Anonymous are going to lynch this guy
[01:10] <gabe_> although looking at 4inchers wasn't what i had in mind
[01:11] <gabe_> infact i feel a bit queasy now :(
[01:11] <i386_> :(
[01:12] <i386_> err sorry everyone
[01:15] <gabe_> np, you got any intellectually stimulating websites to redeem yourself with? :P something like benchmarks of UFS2 vs XFS or Ext4
[01:15] <i386_> ahh
[01:16] <i386_> found this neat website on garbage collection and memory management
[01:16] <i386_> http://www.memorymanagement.org/
[01:17] <gabe_> ok that's a good start :)
[01:17] <gabe_> although not so much use for me as Ruby does all that for me
[01:28] <jelmer> phanatic: btw, did you see my message about vizchanges?
[01:31] <GaryvdM> Hi jelmer
[01:31] <GaryvdM> I just busy replying to it :-)
[01:31] <jelmer> hi Gary
[01:32] <jelmer> GaryvdM: thanks!
[01:45] <sakke> When I try to connect to a server i get the following error: Exception: Error reading SSH protocol banner(10054, 'Connection reset by peer')
[01:45] <sakke> Traceback (most recent call last):
[01:45] <sakke>   File "paramiko\transport.pyc", line 1448, in run
[01:45] <sakke>   File "paramiko\transport.pyc", line 1564, in _check_banner
[01:45] <sakke> SSHException: Error reading SSH protocol banner(10054, 'Connection reset by peer
[01:45] <sakke> ')
[01:45] <sakke> What's the problem?
[02:02] <AnMaster> sakke, can you ssh in normally?
[02:02] <AnMaster> also try sftping some file by hand
[02:03] <AnMaster> if both of those work check the path you used to the server, right port and so on
[02:03] <AnMaster> in case of typos
[02:07] <AnMaster> sakke, any luck?
[02:44] <JackPhil> it complains the pyrex not installed
[02:44] <JackPhil> is it ok?
[02:46] <luks> JackPhil, yes, it will still work fine, but a bit slower
[03:09] <fullermd> It won't be slower if you're running from a release tarball; only from a dev branch.
[03:34] <AfC> Is that local-area-ad-hoc-network branch-sharing thing that lifeless was working on published and usable?
[06:48] <LeoNerd> Hmm.... I have a branch that's up to date, with respect to revisions, but is missing a tag compared to the server...
[06:48] <LeoNerd> Is there some way I can force a resync of the tags?
[06:50] <luks> bzr pull?
[07:01] <LeoNerd> Hrm... That seems to have fixed it... Wonder why it didn't before...
[09:56] <piedoggie> I think my bze repository lost touch with the launch pad repository.  this latest check in flagged in more files than it should have
[09:56] <piedoggie> how can I reconnect the two?
[10:25] <thumper> piedoggie: I don't quite understand your problem, would you care to explain a bit more?
[10:28] <piedoggie> it is weird.  I buit a repository in launchpad
[10:28] <piedoggie> and thought I uploaded files to it
[10:28] <piedoggie> but is is empty
[10:29] <piedoggie> so it make sense that my local copy only stored updates local
[10:30] <piedoggie> I'll deal with it later.. I have a fire here that comes first
[11:01] <james_w> put_bytes_non_atomic says "This function is not strictly safe to use. See Transport.put_bytes_non_atomic for more information."
[11:02] <james_w> This is Transport.put_bytes_non_atomic. Can anyone tell me why it is not safe?
[11:25] <ubotu> New bug: #148728 in bzr "Bzr gives ugly error error message on bzr+ssh:// timeout" [Undecided,New]  https://launchpad.net/bugs/148728
[11:26] <BasicOSX> Does bzr do the right thing with spaces in the directory name when over-riding the things in your ~/.bazaar/locations.conf? I tried both spaces and %20 (for the spaces) and I cannot get the overrides to work.
[11:26] <james_w> BasicOSX: I'm not sure I'm afraid.
[11:27] <BasicOSX> [/Applications/World of Warcraft/Interface/AddOns/]  vs [/Applications/World%20of%20Warcraft/Interface/AddOns/] 
[11:27] <james_w> bzr uses ConfigObj to that parsing, so you could check that.
[11:28] <wingo-pb> good day!
[11:28] <wingo-pb> can bzr do in-place branching?
[11:29] <james_w> BasicOSX: it looks like configobj should pick it up ok.
[11:29] <james_w> wingo-pb: what do you mean?
[11:29] <BasicOSX> with space or encoded?
[11:30] <wingo-pb> james_w: like i see with git and `git branch'; it seems useful rather than having repo parent dir and lots of branch checkouts
[11:31] <james_w> wingo-pb: no it can't.
[11:31] <ubotu> New bug: #148731 in bzr "Bzr gives ugly error error message when server requires non-existant ssh keys " [Undecided,New]  https://launchpad.net/bugs/148731
[11:31] <ubotu> New bug: #148737 in bzr "Bzr needs a more decriptive error message when product does not exist on launchpad" [Undecided,New]  https://launchpad.net/bugs/148737
[11:31] <james_w> however using bzrtools' switch command you can approximate it.
[11:31] <james_w> or maybe cbranch. Or both, I can't remember.
[11:32] <james_w> BasicOSX: are you on Windows?
[11:32] <BasicOSX> no, OSX
[11:33] <BasicOSX> recently moved to osx, so I'm struggling :-)
[11:34] <james_w> BasicOSX: should have guessed from the name :)
[11:34] <james_w> it looks like spaces should be used.
[11:35] <wingo-pb> james_w: thanks for the info tho
[11:35] <wingo-pb> is there a place that bzr devs look at for feature requests? ;-)
[11:35] <james_w> wingo-pb: launchpad, or the mailing list for discussions.
[11:36] <james_w> wingo-pb: though proposing git style branching won't get very far.
[11:39] <wingo-pb> james_w: ah, there has been previous discussion in this regard? i occaisionally read the mailing list but must have missed that. anyway sorry to bother you :)
[11:42] <salty-horse> hi. when running "bzr log|less" and quitting less before the command is done, I get a "IOError: [Errno 32]  Broken pipe" error on flush(). this is quite common in application, but it's especially annoying when ubuntu wants to report the crash. A fix was committed to win32, but I'm on Linux. see http://bundlebuggy.aaronbentley.com/request/%3Ces4ihj%24dcf%241%40sea.gmane.org%3E
[11:55] <poolie> hello