[00:01] <thumper> jam: thanks
[00:15] <mindstorms> hi everybody! a friend told me that there should be a .dmg for the bzr 1.0 distro
[00:16] <mindstorms> I have found it here http://phanatic.hu/bzr/mac/, but it looks like it is only for Leopard
[00:16] <mindstorms> do you know if there is any packaged distro for Tiger?
[00:16] <mindstorms> tia
[00:28] <mneptok> mindstorms: use MacPorts
[00:29] <mindstorms> mneptok: thanks. I am aware of this option, but I currently don't have XCode installed
[00:30] <mindstorms> so it would require me to pass through quite a few hops just to get bzr working on my sys :(
[00:31] <mindstorms> that's the reason I would have preferred a packaged distro (and considering there is one for Leopard I don't think it will be so difficult to get one)
[00:31] <mneptok> mindstorms: you're not using bzr for source code management?
[00:32] <mindstorms> that's my intention indeed
[00:32] <mneptok> because if that's your planned use case, it seems odd not to have XCode installed.
[00:32] <mindstorms> I
[00:32] <mneptok> *shrug*
[00:33] <mindstorms> I am mostly developing on java
[00:33] <mindstorms> plus some perl/python/ruby
[00:33] <mindstorms> none requires xcode
[00:33] <mneptok> ah.
[00:34] <mindstorms> so... I'll probably wait to 1/ either a packaged bzr will become available for Tiger
[00:34] <mindstorms> 2/ more things will require me to install XCode
[00:34] <mneptok> i think 2 is a certainty
[00:35] <mindstorms> so far I've managed not to install it... so I'm pretty tough here
[00:35] <mindstorms> so frankly speaking i hope 1/ is the option ;-)
[00:36] <poolie> mindstorms, Tiger is the new one, right?
[00:36] <mneptok> poolie: Leopard is
[00:36] <mindstorms> Tiger=10.4, Leopard=10.5
[00:37] <mneptok> poolie: Tiger is OSX.4, and prolly has a fairly old version of Python by default
[00:37] <mindstorms> I think it comes by default with 2.3
[00:37] <mneptok> mindstorms: and that will cause you to need XCode/MacPorts
[00:37] <mindstorms> but I'm currently using 2.5.1
[00:37] <mneptok> mindstorms: supplied by Apple in a sysyem update?
[00:37] <mindstorms> mneptok: I don't see any relationship between python version and xcode?
[00:37] <mneptok> *system
[00:38] <mindstorms> nope... why would that be needed?
[00:38] <mathrick> hiya, a question that arose on #gnome-hackers, can you do cvsimport without shutting down the repo?
[00:38] <poolie> the cvs repo
[00:38] <poolie> yes, i think so
[00:38] <mneptok> mindstorms: if bzr requires a newer Python than Apple currently ships as part of the OS, XCode/MacPorts becomes necessary to get the newer Python
[00:38] <mathrick> as in, while still being to commit while it's importing
[00:38] <poolie> mindstorms, how about just installing from the tarball?
[00:39] <mathrick> and sync it afterwards
[00:39] <mindstorms> mneptok: I don't think you are correct about it
[00:39] <poolie> not every importer can do incremental syncs
[00:39] <poolie> mindstorms, i think what he's getting at is that
[00:39] <spiv> mathrick: I believe cscvs can do that.  Not sure about other importers (like Tailer).
[00:39] <poolie> a dmg may be built assuming you're using the system python
[00:40] <spiv> Er, "Tailor"
[00:40] <mindstorms> if my environment is correctly setup, bzr should firstly find the configured python
[00:40] <poolie> mindstorms, how about just installing from the tarball?
[00:40] <poolie> i don't think that would need anything beyond a recent python?
[00:40] <mindstorms> poolie: there are quite a few dependencies
[00:40] <mathrick> spiv: can you use it to migrate to bzr?
[00:40] <mindstorms> including the c library
[00:41] <mindstorms> that means that I would need to build it locally => I need to install XCode
[00:41] <mindstorms> which is what I was trying to avoid :)
[00:41] <mneptok> mindstorms: and you trust "some guy who can make a .dmg" more than MacPorts to account for and solve such dependencies? ;)
[00:41] <spiv> mathrick: yes
[00:41] <mindstorms> why wouldn't I?
[00:41] <mneptok> mindstorms: uh ...
[00:41] <poolie> mneptok, you're not totally helping here
[00:42] <spiv> mathrick: if it's a public CVS repository you could get Launchpad to try mirror it to bzr for you.
[00:42] <mindstorms> should I trust somebody and use bzr or just pay for whatever other thing I can pay for
[00:42] <mneptok> poolie: i'm trying to understand the reticence in installing Apple's developer tools in order to use a developer tool. :)
[00:42] <mindstorms> so I don't thin it is a matter of trust that should be involved here
[00:42] <mindstorms> mneptok: it is simple 1GB + time
[00:43] <poolie> mindstorms, afaik the compiled extensions are optional
[00:43] <poolie> i agree it would be nice to have a dmg built for older systems
[00:43] <mathrick> spiv: it's not
[00:43] <mathrick> it's about a company repo
[00:43] <mindstorms> poolie: I think you might be right... because for those it is said: recommended
[00:43] <poolie> but i'm just trying to work out if there's anything else problematic about using the tarball?
[00:44] <poolie> they will make it faster
[00:44] <mathrick> and launchpad or not, it doesn't really matter, if launchpad can do it, so can anyone else
[00:44] <mathrick> I'm interested in the method, really
[00:44] <mindstorms> poolie: which is quite important, but I think I can live with it till somebody will create the dmg
[00:44] <mneptok> mindstorms: why not try the tarball, and rm it if it misbehaves or does not play nicely under Tigert?
[00:44] <mneptok> -t
[00:45] <mindstorms> mneptok: cause initially it was my understanding that there are some external dependencies
[00:45] <poolie> mindstorms, there was a recent thread about this
[00:45] <spiv> mathrick: launchpad uses cscvs under the hood for cvs->bzr
[00:46] <poolie> "improved installation experience" etc
[00:46] <mneptok> mindstorms: right. but if they cause problems, only then remove. it may be that your use cases are addressed without relying on the functionality of compiled extensions.
[00:46] <mindstorms> poolie: it is not clear that those are optional in fact
[00:46] <mindstorms> I've rechecked the page here: http://bazaar-vcs.org/InstallationFaq
[00:46] <mathrick> spiv: aha, cool
[00:46] <poolie> mindstorms, what page/file are you looking at?
[00:46] <poolie> ok
[00:46] <mathrick> I thought cvscs was for Arch only
[00:47] <mindstorms> and those are listed as dependencies
[00:47] <poolie> mindstorms, so, in that thread
[00:47] <poolie> it looks like people concluded "if we make a Tiger dmg, it'd need to include python2.5"
[00:48] <poolie> i think the general expectation is that dmgs should be totally self contained
[00:48] <mindstorms> darn i'm tired
[00:48] <poolie> but you think we should do one which requires/assumes you already installed python?
[00:48] <poolie> that could make sense
[00:48] <mindstorms> cElementTree: it's been made part of the standard library in python 2.5
[00:48] <mindstorms> stupid me.... and playing at 3am
[00:49] <poolie> np
[00:49] <igc> poolie: I think out Tiger dmg should assume python 2.5 is already installed
[00:49] <mindstorms> poolie: I think the installer should just look for python in the path
[00:49] <igc> s/out/our/
[00:49] <mindstorms> and check the version
[00:49] <spiv> mathrick: https://launchpad.net/launchpad-cscvs/
[00:50] <mindstorms> it looks I should probably be able to run it right from the distro
[00:50] <mathrick> spiv: ah, nifty
[00:50] <mindstorms> as I'm only missing the python dependencies which i guess can be easily installed
[00:51] <mneptok> poolie: IIRC, Apple installers can be made to require dependencies. so an installer could check for >py2.5.x
[00:51] <mindstorms> however, I do think that a packaged distro would make the user experience a hell lot nicer ;-)
[00:52]  * mneptok hasn't done any Apple .pkg stuffs in a loooong time
[00:52] <poolie> if you have python2.5 you should not need anything else.
[00:52] <poolie> i'm going to follow up to that thread
[00:52] <mindstorms> I think I've mentioned that I have the 2.5.1 installed
[00:52] <poolie> pm me your email address if you want me to cc you
[00:54] <mindstorms> thanks guys
[00:57] <mneptok> bah. i guess dep-checking isn't handled by packagemaker - http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/packagemaker.1.html
[00:57] <mneptok> we curses it.
[01:01]  * spiv -> lunch
[01:40] <orospakr> Hey, when is bzr 1.0 likely to show up in gutsy backports?
[01:40] <orospakr> I should I just load the debs from hardy?
[01:48] <orospakr> nope, hardy debs are no good on gutsy.
[01:48] <orospakr> libc6 version dep not met.
[01:48] <orospakr> oh well, building from source.
[01:55]  * igc lunch
[01:56] <orospakr> oh, can I get coloured output from bazaar, too?
[01:56] <orospakr> ie, bzr status, bzr log, etc.
[01:56] <orospakr> makes things much more readable.
[02:00] <bob2> you can install bzrtools and get cdiff
[02:01] <orospakr> well, that's good, but that's only for diffs
[02:03] <abentley> bob2: long time, no see.
[05:45] <ubotu> New bug: #177080 in bzr "code coverage unclean" [Undecided,New] https://launchpad.net/bugs/177080
[07:03]  * igc dinner
[07:37] <lifeless> poolie: right, one itch scratched. (See my just-sent merge)
[07:55] <lifeless> poolie: the error you got was because you used a lower version than ubuntu has.
[07:56] <poolie> and the "Signer has no rights?"
[07:56] <poolie> is that just a knock-on effect?
[08:01] <lifeless> dunno
[12:26] <zerok> hi :-) am I blind or doesn'T there yet exist a bzr 1.0 package (newer than rc1 ) in the gutsy apt source?
[12:30] <spiv> zerok: there's a 1.0 package in https://launchpad.net/~bzr/+archive now, but the bazaar-vcs.org archive hasn't been updated yet.
[12:30] <zerok> spiv, ah ok :) tnx :)
[12:34] <lifeless> no guarantee the ppa will be updated regularly or anything though, AIUI poolie is just fiddling
[12:34] <lifeless> YMMV
[12:34] <lifeless> night
[12:35] <spiv> lifeless: g'night
[12:58] <zerok> strange ... now i've clearly modified a file but for some reason it doesn't show up with `bzr status` :-/
[13:02] <zerok> O_o `diff` died ...
[13:04] <zerok> arghhhhh where is my code O_o
[13:09] <AfC> Are you ignoring it? Try `bzr ignored`
[13:10] <AfC> And regardless of what Bazaar thinks, your file and your modifications are your business. It won't touch the file on disk unless you a) `revert` or b) `merge`, but the former case leaves backups, and the latter reports conflicts, if present.
[13:10] <fullermd> It's not dead, it's resting.
[13:10] <zerok> AfC, i'm currently not even sure anymore, where my files are ;)
[13:10] <zerok> had probably nothing to do with bzr :-)
[13:10] <AfC> fullermd: Indeed :)
[13:11] <zerok> somethign really weird was going on here ;)
[14:08] <alienzx> I am fleshing out a plan to move from Subversion to bzr and was wondering if anyone had thoughts on how to handle a svn:externals situation
[14:10] <alienzx> The project is a Rails website with a front and backend that share a common set of models, so inside /frontend/app/models is set to svn:external /backend/app/models, would I be able to make app/models into a 3rd bzr project and yet somehow still check it out into the proper place on the frontend and backend?
[14:13] <mtaylor> bzr: ERROR: bzrlib.errors.NoSuchRevision: Branch <bzrlib.plugins.svn.revids.RevidMap object at 0x1412610> has no revision monty@inaugust.com-20071218140922-2p0p7z3s1i61eo7a
[14:13] <mtaylor> so, this may not be something I can do...
[14:13] <mtaylor> but I've got a bzr repository that's a collection of branches of an upstream svn repos
[14:13] <mtaylor> I created a branch in my bzr repos, which works fine
[14:14] <mtaylor> but I wanted to push the branch, thereby creating a branch upstream.
[14:14] <mtaylor> but that didn't so much seem to work - giving the above error
[14:14] <mtaylor> am I just trying too much?
[14:14] <mtaylor> jelmer: ^^
[14:16] <jelmer> alienzx: there is experimental support in Bazaar for a feature called by-reference nested-trees, which are similar to svn:externals
[14:16] <jelmer> mtaylor, Try svn-push
[14:16] <jelmer> rather than push
[14:16] <mtaylor> jelmer: ok
[14:17] <mtaylor> jelmer: btw, doing a normal push to an already existing svn repos has been working _beautifully_!
[14:17] <jelmer> good to hear :-)
[14:19] <alienzx> jelmer : thanks, I'd screw something up by checking out a bzr project within a subdirectory of another bzr project I take it?
[14:19] <alienzx> without using nested-trees
[14:19] <jelmer> alienzx, no, that should work
[14:20] <alienzx> cool, guess I'll find out soon enough :)
[14:22] <mtaylor> jelmer: bzr svn-push worked. thanks!
[14:29] <spiv> jelmer: where do you push your bzr-svn commits to?  I want to play with your memory leak improvements :)
[14:37] <jelmer> spiv: http://people.samba.org/bzr/jelmer/bzr-svn/0.4/
[14:52] <Zindar> jelmer: have you tried building bzr-svn on mac?
[14:53] <Zindar> I'm trying while waiting for other things
[14:53] <mwhudson> i have
[14:53] <mwhudson> it was horrific
[14:53] <Zindar> that's my impression as well
[14:53] <Zindar> :(
[14:53] <mwhudson> Zindar: are you on ppc or intel?
[14:53] <Zindar> intel
[14:54] <mwhudson> Zindar: i presume you mean "building a sufficiently patched copy of the subversion python bindings"
[14:54] <Zindar> correct
[14:54] <mwhudson> i managed to get it to work on powerpc after a lot of swearing
[14:54] <mwhudson> how far along are you?
[14:55] <mwhudson> you need a very precise version of swig
[14:55] <Zindar> make swig-py :)
[14:55] <Zindar> I have 1.3.27
[14:55] <Zindar> that should work
[14:55] <mwhudson> and iirc to replace the version of libtool in the subversion tarball
[14:55] <Zindar> OH
[14:55] <Zindar> really?
[14:55] <Zindar> why's that?
[14:55] <mwhudson> Zindar: one lazy option is to install ubuntu in parallels....
[14:55] <mwhudson> Zindar: i don't remember
[14:56] <mwhudson> Zindar: what errors are you getting at the moment?
[14:56] <Zindar> I get this strange thing in configure of svn...
[14:56] <Zindar> checking for apr_int64_t Python/C API format string... rm: conftest.dSYM: is a directory
[14:56] <Zindar> L
[14:56] <mwhudson> whisky tango foxtrot
[14:56] <Zindar> hmm.. none really.. I get through the building of svn.. and install.... and swig-py-install as well
[14:57] <alienzx> ugh, yeah won't be going down that path
[14:57] <alienzx> :)
[14:58] <mwhudson> Zindar: and then what?
[14:59] <Zindar> but I install in a specific build_root... then I set PYTHONPATH and LD_LIBRARY_PATH...
[14:59] <Zindar> and then bzr-svn dies with "wrong version of bindings" or something
[14:59] <jelmer> zindar: and this is subversion 1.5 or 1.4 patched?
[15:00] <Zindar> 1.4 patched
[15:01] <Zindar> it builds quite happily.. except the strange thing above.. but seems to build...
[15:01] <Zindar> perhaps I'm not setting some path right
[15:01] <Zindar> >>> import svn.delta
[15:01] <Zindar> >>> hasattr(svn.delta, 'svn_delta_invoke_txdelta_window_handler')
[15:01] <Zindar> False
[15:02] <mwhudson> right
[15:02] <mwhudson> svn.delta.__file__ ?
[15:03] <Zindar> ??
[15:03] <mwhudson> what is that?
[15:03] <Zindar> that's what bzr-svn runs to verify correct svn bindings
[15:03] <mwhudson> are you sure you're importing the version of the bindings you think you are?
[15:03] <Zindar> not 100% sure no....
[15:04] <Zindar> I'm a perl and ruby guy.. not python...
[15:04] <mwhudson> so run
[15:04] <mwhudson> import svn.delta
[15:04] <mwhudson> print svn.delta.__file__
[15:04] <mwhudson> in a python prompt
[15:04] <Zindar> ahh
[15:04] <Zindar> great
[15:04] <Zindar> no.. wrong one
[15:04] <Zindar> hmm
[15:05] <Zindar> ok...
[15:05] <Zindar> got the right one
[15:05] <Zindar> still False
[15:06] <mwhudson> :(
[15:06] <mwhudson> something that can happen here
[15:06] <Zindar> it might be using the wrong compiled binary libraries I guess?
[15:07] <mwhudson> is that iirc the processing of the swig files can fail, but you can still build the bindings from the c files that are included in the tarball
[15:07] <Zindar> ok
[15:07] <mwhudson> so maybe delete the built extensions in your build dir
[15:07] <mwhudson> and the c that's generated from the swig
[15:07] <mwhudson> and try again?
[15:07] <mwhudson> it's a long time ago that i fought with this :/
[15:08] <Zindar> :)
[15:12] <Zindar> hmm.. I would expect to see "invoke_txdelta" somewhere in delta.py
[15:12] <Zindar> wouldn't I?
[15:13] <Zindar> it's in svn_delta.i... but not the svn/delta.py
[16:02] <MattCampbell> In response to the bug report I filed yesterday in launchpad-bazaar, someone suggested that I downgrade to bzr 0.92.  I'm currently running bzr 1.0rc3 and created a branch in the default format for that version.  So do I need to do anything special with that branch when downgrading to 0.92?
[16:04] <beuno> MattCampbell, no, 0.92 supports the new pack format
[16:04] <beuno> (it's calles pack-0.92 after all  :p)
[16:05] <Peng> Ooh, auto-pack of bzr.dev's repo just added an 800 KB pack, a 15 KB one, 200, and 240.
[16:11] <MattCampbell> How likely is it that bzr 1.0 on the client side would be incompatible with a smart server running bzr 0.92?
[16:15] <beuno> MattCampbell, seems unlikely to me, but I can't say for sure, haven't played with smart server in a while
[16:25] <MattCampbell> The error that I got when trying to commit to a branch on LP yesterday, for which I filed a bug in launchpad-bazaar, has led me to question the maturity of bzr.
[16:26] <MattCampbell> which is why I'm asking so many questions now.
[16:27] <beuno> MattCampbell, as away  :D
[16:27] <beuno> we've all been using it in all kinds of enviroments for a long time now
[16:28] <MattCampbell> I presume you meant "ask away"
[16:28] <beuno> MattCampbell, would you have the bug numer around?
[16:28] <beuno> MattCampbell, ah, yes I did  :D
[16:28] <beuno> we
[16:28] <beuno> "bug number"
[16:29] <beuno> keyboard hates me today
[16:29] <MattCampbell> bug 176978
[16:29] <jam> bug #176978
[16:30] <jam> ubotu: bug #176978
[16:30] <ubotu> Launchpad bug 176978 in launchpad-bazaar "Error when trying to commit to a central branch via smart server" [Undecided,New] https://launchpad.net/bugs/176978
[16:30] <jam> slow today
[16:30] <MattCampbell> I was trying to trigger a response from ubotu but didn't know the format.  I'm really new here.
[16:31] <jam> MattCampbell: I would have thought it would trigger from what you did
[16:31] <jam> MattCampbell: that is a known bug in the 0.92 smart server
[16:31] <jam> fixed in 1.0
[16:31] <MattCampbell> It should; that would only involve a slight regex tweak.
[16:31] <MattCampbell> OK, then I guess I'll switch to sftp.
[16:32] <jam> bug 161131
[16:32] <ubotu> Launchpad bug 161131 in bzr "dirstate file gets damaged by commit() in a merge when there are 2 deletes in a directory." [Critical,Fix released] https://launchpad.net/bugs/161131
[16:32] <jam> bug 176978
[16:32] <ubotu> Launchpad bug 176978 in launchpad-bazaar "Error when trying to commit to a central branch via smart server" [Undecided,New] https://launchpad.net/bugs/176978
[16:32] <jam> MattCampbell: maybe it just doesn't like you :)
[16:32] <jam> I'm guessing it was actually just being slow
[16:33] <MattCampbell> jam: Thanks for your help.  Someone should close my bug as a duplicate.
[16:33] <jam> I'm searching for it now
[16:34] <jam> (I was just testing the bug tracker with the bug I mentioned first :)
[16:34] <jam> MattCampbell: I'm not in launchpad-bazaar group, but I gave the link in the bug report
[16:40] <jam> I guess I can set it to duplicated :)
[16:46] <ubotu> New bug: #176978 in launchpad-bazaar "Error when trying to commit to a central branch via smart server (dup-of: 156546)" [Undecided,New] https://launchpad.net/bugs/176978
[16:48] <MattCampbell> huh?
[16:48] <MattCampbell> Why did that one just get reported as a new bug?
[16:49] <jam> MattCampbell: because 'bzr' bugs are reported here while 'launchpad-bazaar' ones are not
[16:49] <jam> This is newly marked as a duplicate of a 'bzr' bug
[16:49] <jam> It shouldn't really claim 'New bug:' though
[17:36] <mgedmin> so, would it be an incredibly stupid idea to run 'bzr init .' inside a directory mounted with davfs2 from a webdav server?
[17:38] <MattCampbell> If you did that, then you'd have a working copy on the WebDAV server.  Do you really want a shared working copy?
[17:42] <mgedmin> what I want is a versioned Zope 2 TTW website
[17:43] <mgedmin> (TTW is Zope-jargon for Though The Web, implying that you can edit it with a web browser)
[17:44] <MattCampbell> bzr would be no good for that, because the TTW edits wouldn't be committed to the bzr branch.
[17:44] <mtaylor> mgedmin: you'd need to write a zope zodb hook to commit to the branch
[17:45] <mtaylor> mgedmin: but writing a bzr product for zope would probably be pretty cool
[17:45] <MattCampbell> And doesn't Zope 2 have its own versioning?
[17:45] <mtaylor> it does
[17:45] <mgedmin> that's like saying vi is no good because it doesn't know how to commit
[17:45]  * mtaylor thinks vi is no good because it doesn't know how to commit :)
[17:45] <mgedmin> zope 2 built-in versioning is a silly toy
[17:46] <Peng> Doesn't emacs know how to commit?
[17:46] <mtaylor> Peng: yup
[17:46] <MattCampbell> with bzr?
[17:46] <mgedmin> TTW edits would be just like vi/emacs edits in a working dir: changes you have to commit yourself
[17:46] <mtaylor> mgedmin: it is not VC, but it does mean that the hooks are already there in the Zope 2PC to commit on object save
[17:46] <mtaylor> mgedmin: well that would certainly be easier
[17:46] <mtaylor> MattCampbell: yes
[17:46] <mgedmin> how much power from the filesystem does bzr want?
[17:47] <mtaylor> MattCampbell: although it doesn't know how to do more complex things yet
[17:47] <mgedmin> e.g. does it work on stupid FAT fs'es?
[17:47] <mgedmin> bzr is cross-platform, so I assume it won't need hardlinks (or symlinks)
[17:47] <mgedmin> what about atomic renames?
[17:57] <mwhudson> mgedmin: bzr runs on stupid FAT fses i think
[17:57] <mwhudson> case insensitivity can throw some curve balls
[18:08] <jam> mwhudson: correct
[18:13] <jelmer> what's the idea for post-1.0 versioning?
[18:13] <jelmer> Stable and unstable branch or just one development branch?
[18:13] <jelmer> if the latter, what are the version numbers going to be, 1.X or 1.0.X ?
[18:14] <mwhudson> i think 1.1, 1.2, 1.3.  not sure though
[18:22] <jam> jelmer: in Martin's post he said "1.1 in January"
[18:22] <jam> so I think the plan is to just keep doing 1.X releases
[18:22] <jam> every month
[18:58] <jelmer> ah, ok
[19:12] <Treeform> hey, i have a text file i guess i would like to treat as binary his this option been already added to bzr?
[19:13] <Peng> Treat as binary? Why?
[19:14] <Treeform> well it takes 1.5 GB of my ram to commit now and its only 40mb file
[19:14] <Peng> Ooh.
[19:14] <Treeform> its a files of a 3d model
[19:14] <jelmer> Treeform: sorry, there's nothing binary-specific yet
[19:14] <Treeform> most models where not this bad
[19:14] <Peng> Why would treating it as binary help?
[19:14] <Treeform> Peng, well png and jpg commit just fine
[19:14] <jelmer> Treeform: there was talk about support for streaming though
[19:14] <Treeform> and they are big too
[19:14] <Treeform> yes that is what i found by googleing
[19:14] <jelmer> Treeform: so it wouldn't be necessary to keep various versions of the full file in memory
[19:15] <Treeform> well i realy dont need to keep it versioned per line
[19:15] <Treeform> 3d program generates it
[19:17] <Treeform> i just need to over write it every time just like it does images
[19:33] <jam> Treeform: any chance you could help us figure out why we are taking 1.5GB to commit?
[19:34] <jam> like, is there a way you could make that file public for us?
[19:34] <jam> espec if you could have us see the .knit file (in case it is because of history as well as just the file itself)
[19:34] <jam> 40MB => 1.5GB seems like we have a rather serious bug
[19:34] <Treeform> ok its more like 1gb
[19:35] <Treeform> it ate up my ram and moved into the swap
[19:35] <Treeform> which made it super slow
[19:35] <Treeform> jam ok i will upload the file
[19:45] <Treeform> jam, its 79mb and its here if you wan http://affuniverse.com/artdepot/Treeform/fleetbox-full2.egg.zip
[19:45] <Treeform> the file does that on add
[19:45] <Treeform> i have no clue what it will do on merge
[19:47] <jam> Treeform: and what version of bzr?
[19:47] <jam> hmm... it is only 7.9MB :)
[19:47] <jam> is this just 1 copy of the file?
[19:47] <jam> not the history of it?
[19:48] <Treeform> there is no history
[19:48] <Treeform> i just bzr add and bzr commit
[19:48] <jam> you have 1 copy and it took 1GB to commit it?
[19:48] <Treeform> yep
[19:48] <Treeform> its zip unzip the file
[19:48] <jam> will do
[19:49] <Treeform> it unzips to 78 mb
[19:49] <jam> that seems really strange
[19:49] <Treeform> maybe i am wrong my system almost lucked up during the commit
[19:49] <jam> yah, I see 80M here
[19:49] <Treeform> i could not tell what exacty it was but i guess its this file
[19:49] <jam> I won't say you are wrong, but something really odd is going on if that is happening.
[19:49] <jam> Also, what repository format are you using?
[19:49] <jam> and bzr version
[19:50] <Treeform> how would you look that up?
[19:50] <jam> it is ~2.6M lines long
[19:50] <jam> bzr --version
[19:50] <jam> bzr info
[19:50] <jam> info gives the format string
[19:50] <jam> --version tells me about bzr
[19:51] <Treeform> jam, http://dpaste.com/28430/
[19:51] <Treeform> i think i use the one in the ubutnu apt-get
[19:53] <jam> Treeform: and what Ubuntu version? You can add the Bazaar repositories here:
[19:53] <jam> http://bazaar-vcs.org/releases/debs/
[19:53] <jam> something like: deb http://bazaar-vcs.org/releases/debs/gutsy ./
[19:53] <jam> It would just be good to test with bazaar 1.0
[19:53] <jam> and also possibly test with --pack-0.92
[19:53] <jam> to see if that changes things
[19:54] <Treeform> but i dont want to version files this big any ways
[19:54] <Treeform> i want for it to just think of it as a binary file
[19:54] <jam> well, we treat binary files in almost the same fashion
[19:55] <jam> there are a couple places that are different
[19:55] <Treeform> oh so you version parts of them?
[19:55] <jam> but I'm hoping that by 1.0 we fixed some of what you are running into
[19:55] <jam> Treeform: all files are "binary" that just happen to have some '\n' in them
[19:55] <jam> at least at the lowest layer
[19:56] <Treeform> hmm
[19:56] <jam> 'bzr diff' knows not to display files that have NULL in them
[19:56] <Treeform> hmm that sounds as a hack
[19:56] <Treeform> did you try the file did it work for you?
[19:57] <jam> and 'merge' knows to just overwrite the file, etc.
[19:57] <jam> I just finished downloading, I'll let you know in a second (I'm running some timing tests, and don't want to interfere with it)
[19:59] <Treeform> ok and i have upgraded
[19:59] <Treeform> 1.0
[20:00] <Treeform> jam, so it will treat is as binary if a tack a null at the end?
[20:00] <jam> only in the beginning 1024 bytes, iirc
[20:01] <jam> I'm guessing, though that it has more to do with the 2.6M lines
[20:02] <Treeform> it used only 350mb on the new one to commit the 80mb file
[20:02] <jam> with bzr.dev and knits, it took 650MB before I killed it because my machine was very unhappy
[20:02] <Treeform> jam, yes its a big text file you can take a look at the date if you want
[20:02] <jam> I'll try again with packs
[20:04] <jam> Treeform: is it okay if I make this file public for testing purposes?
[20:05] <Treeform> grr i would rather you woulnt
[20:05] <jam> no problem
[20:05] <jam> I'll keep it private per your request
[20:05] <Treeform> you can probably generate a file based on it that would cousel the same problem
[20:05] <jam> probably
[20:06] <jam> I just hit 700MB real
[20:06] <jam> so it seems to still be a problem
[20:06] <Treeform> ok
[20:06] <Treeform> probably if bzr had real binary support that would not be a problem
[20:07] <jam> not really, it is just somewhere internal where we are splitting into lines and being innefficient about it
[20:07] <Treeform> also i was thinking to use bzr for sql databases dumps... wouldn't they have similar stricture to this file?
[20:07] <jam> I can't say for sure
[20:07] <jam> anyway, thanks for letting me see a test example
[20:09] <Treeform> jam, no problem i like bzr its good to be of help
[20:09] <jam> Treeform: now *my* machine is sluggish as it pulls everything back out from swap
[20:09] <Treeform> yep
[20:09] <Treeform> mine almost crashed the first time
[20:10] <Treeform> i had most the gig in use when bzr hit it with another one
[20:14] <jam> Treeform: bug #109114 is where this is discussed if you want to follow it a bit
[20:14] <ubotu> Launchpad bug 109114 in bzr "commit holds whole files in memory" [Medium,Confirmed] https://launchpad.net/bugs/109114
[20:22] <Treeform> jam, you probably could replace all the chars and numbers with random chars while keeping the white space and brackets the same then make it public
[20:23] <jam> well, I was going to start with creating just a trivial file with a lot of lines
[20:23] <jam> and see if that reproduces it
[20:23] <Treeform> i dont think bzr reads the brackets
[20:24] <Treeform> but it might read stuff like >>> [20:24] <jam> yeah, I *think* it is just because it has 2.6M "\n" in it
[20:24] <jam> well, that and it is 40MB to start with
[20:24] <Treeform> 80mb
[20:24] <jam> oh, right
[20:24] <Treeform> i have another 40mb files thats v1 of this file
[20:24] <Treeform> but they have different name
[20:24] <Treeform> artists ...
[20:25] <jam> well 'bzr rename' would help :)
[20:25] <luks> hm, that's weird. the RAM usage goes high even when only removing such files
[20:25] <luks> it's actually higher than when I was adding it
[20:25] <jam> luks: committing the removal of the file?
[20:25] <jam> that does seem odd
[20:25] <luks> yes
[20:25] <Treeform> jam, is there a way to permanently delete a file form bzr including all previous versions?
[20:26] <Treeform> an irreversible operation
[20:26] <jam> no
[20:26] <jam> not without something like 'rebase'
[20:27] <luks> uh oh
[20:27] <jam> ?
[20:27] <luks> I see difflib.py in lsprof-file output when removing the file
[20:27] <Treeform> i had to restart this repos because aritsts just commit crap and move it without proper move
[20:27] <luks> __chain_b is taking the most time
[20:27] <luks> it shoudn't use difflib.py at all, no?
[20:28] <jam> Arguably it could notice that the new text is empty
[20:28] <jam> I would have to track through the code, though
[20:28] <luks> hm, _patiencediff_py is calling it
[20:28] <jam> it shouldn't need to hit difflib for the add or the remove
[20:28] <jam> luks: well, then you at least need to "make" to use _patiencediff_c :)
[20:28] <luks> :)
[20:29] <jam> The big thing is that we shouldn't really *need* to use the SequenceMatcher
[20:29] <jam> It doesn't matter which implementation we are getting
[20:29] <jam> That actually might explain memory bloat a little bit
[20:29] <luks> yes, but it does right that difflib is the most expensive operation, when it doesn't even use it for sequence matching
[20:29] <jam> as the sequence matchers use a dictionary, etc.
[20:30] <luks> er, it is not right
[20:32] <luks> umm, even weirder is that patiencediff is called from _merge_annotations, which isn't even used in packs
[21:41] <elmo> [21:41] <elmo> bzr: ERROR: No such file: u'/etc/lala'
[21:41] <elmo> with bzr 1.0rcsomething diff - known bug?
[21:46] <elmo> srsly, still no gutsy debs on bazaar-vcs.org?
[22:09] <poolie> elmo, they'll be there soon
[22:09] <elmo> poolie: ok
[22:09] <elmo> well I filed a bug in the meantime, hopefully it's not something that's fixed in release.  or maybe hopefully it is.  who knows
[22:11] <ubotu> New bug: #177282 in bzr "[1.0 regression] bzr diff bombs out on removed symlink" [Undecided,New] https://launchpad.net/bugs/177282
[22:13] <poolie> elmo, i'm not sure off hand
[22:19] <jam> elmo: are you using the final release of 1.0, or 1.0rc1?
[22:22] <jam> ISTR bzr 1.0rc1 having that bug, but it was fixed by 1.0rc2 or 3
[22:22] <jam> the NEWS entry shows the fix in rc1, but I'm guessing it is just put in the wrong place
[22:28] <vila> hi all, just passing to ping about http://bundlebuggy.aaronbentley.com/request/%3C1197963539.13798.1.camel@lifeless-64%3E
[22:28] <vila> if nobody objects, I'd like to merge it (see my comment)
[22:28] <jam> vila: I wouldn't say that I object :)
[22:29] <vila> typo ? :-)
[22:29] <jam> I'm fine with the concept, I haven't thoroughly reviewed the code
[22:30] <poolie> i'd kind of like to read it
[22:31] <vila> poolie: ok, I'll go sleeping now, so feel free to comment, my ping was just a way to say: 'I want that since I need it and I'm willing to help merging it soon'
[22:31] <vila> including tweaking it if needed
[22:31] <poolie> is "randomize" a more standard spelling?
[22:32] <jam> randomize randomise
[22:32] <jam> Well, my spellchecker doesn't like the latter
[22:33] <vila> gnome-dictionary-applet says the latter is a synonym for the former
[22:33] <vila> night all
[22:34] <radix> randomize is the american spelling
[22:34] <jam> poolie: I believe one is UK and one is US
[22:34] <poolie> yeah
[22:34] <jam> as with most 'ise' versus 'ize'
[22:34] <poolie> and i think software should normally be US
[22:34] <jam> poolie: I would tend to agree, but I know robert likes to use UK
[22:35] <dato> what does one use in AU?
[22:35] <jam> And then you have "bzr viz" which is the shortcut for "bzr visualise"
[22:35] <poolie> UK, but most software is done in US
[22:35] <poolie> obviously people can read both, but having a mix is annoying
[22:36] <poolie> i'd like to merge your on-demand loader john
[22:36] <poolie> i think being able to load fewer modules is the deciding factor
[22:42] <lifeless> its not that I prefer UK spelling
[22:43] <lifeless> I'm a new zealander
[22:43] <lifeless> I generally write New Zealand english.
[22:44] <jdahlin> congrats for the 1.0 release everybody
[22:44] <poolie> thanks johan!
[22:44] <poolie> hi lifeless
[22:45] <poolie> sorry to bug you with work, but could you please chmod some more things on escudero?
[22:45] <lifeless> isn't elmo right here ? ;)
[22:45] <poolie> not answering
[22:45] <poolie> uh
[22:45] <lifeless> ah
[22:45] <lifeless> ok sure msg me the commands to run
[22:46] <poolie> the sensible next step is to ask for sudo access to your account
[22:46] <lifeless> on that machine, makes sense to me
[22:46] <poolie> 0.5 ;-)
[22:46] <lifeless> until that service account is made :)
[22:48] <poolie> find /srv/bazaar.canonical.com/www -user robertc \! -perm -020 -exec chmod g+w {} \;
[22:51] <lifeless>  ssh escudero 'find /srv/bazaar.canonical.com/www -user robertc \! -perm -020 -exec chmod g+w {} \;'
[22:51] <lifeless> done
[22:51] <lifeless> well running
[22:51] <lifeless> done
[22:52] <igc> morning
[22:52] <lifeless> can you do whatever changes you want to that tweaked merge and send it in ?
[22:53] <poolie> vila's going to
[22:53] <poolie> thanks btw
[22:53] <poolie> or did you want it sooner?
[22:54] <lifeless> nah just that someone will :)
[23:06] <MicahElliott> Hi.  I've been toying with bzr and hg.  I found hg has a -A (addremove) option for 'commit'.  It's very convenient when you have a new file to save the 'add myfile' step, and just say 'hg ci -Am msg'.  Any plans to add such an option?  Any philosophical reasons not to?
[23:23] <poolie> MicahElliott, yes, we plan to add that
[23:23] <poolie> i agree it'd be nice
[23:28] <MicahElliott> poolie: thanks.  pretty minor, but thought it was worth asking about.
[23:35] <bialix> igc:hi
[23:36] <bialix> about http://bazaar-vcs.org/BzrVsHg#head-a1fbb925120017d8d4b05a2da1eba9469ab48160
[23:37] <bialix> IMO text about hg and its dependency on external tool could be emphaside more strongly: it's real pain in the ass especially on windows
[23:38] <bialix> probably their ignorance of built-in merge is the main reason that prevent me to try hg more than for 15 minutes.,