[00:18] <spiv> jelmer: wow, that's an impressively slow reconcile :)
[00:19] <spiv> jelmer: possibly the gcc inventories are so large the default lru cache sizes are ineffective?
[00:20] <lifeless> thumper: it does
[00:20] <thumper> lifeless: yay
[07:14] <mgz> morning all!
[07:20] <vila> morning mgz
[07:25] <mgz> how are you today vila?
[07:25] <vila> hot :)
[07:25] <mgz> heh, reverse here, is overcast today
[07:25] <vila> 33C as yesterday, yummy
[07:26] <fullermd> Shoot, that's all?
[07:28] <mgz> I'm not going to feel sympathy for the heat you have to endure fullermd
[07:31] <fullermd> Nobody ever has sympathy for me  :(
[07:32] <mgz> it's because everyone's too busy admiring you? :)
[07:34] <fullermd> I s'pose it IS time consuming, all that time people spend thinking of nice things to do for me.
[08:16] <vila> well, my favorite Stone's song is Sympathy For ... wossname
[08:20] <fullermd> What, more than Gimme Shelter?
[08:31] <vila> yup
[13:23] <BY0LOG1C> hello folks, mind if a cvs n00bie ask for support in here?
[13:27] <BY0LOG1C> ill make it short. im an indie developer for a small studio and i had the *poor?* idea to put our whole 50gb project under version control. commiting the whole folder would cause OOM so i broke it down into smaller commit.
[13:27] <BY0LOG1C> large binary files would still crash so i had them ignored. all fine, except the 10 commit triggers a repack - which crash, no matter what i do
[13:28] <BY0LOG1C> i tried the bzr repack -nosmart+[url] found on the forum but that also crash around file 50k/80k on a win7 machine. is there anything i can do to help my cause?
[13:29] <mgz> why version the large binary files?
[13:30] <mgz> this is something people (eg games developers) have asked for, but none of the dvcs systems are really designed to handle that sensibly
[13:30] <BY0LOG1C> i am fine with that issue, i had the large binary ignored. the problem is now that bzr will OOM on any commit/repack
[13:30] <mgz> if it's not human-editable text, there's not much point putting it in version control as opposed to using some other archive+update method
[13:31] <mgz> BY0LOG1C: probably you committed at some point, then removed it? instead, you want to not add it it the first place
[13:31] <fullermd> I have an archive+update mechanism; it's called "version control"  ;p
[13:32] <mgz> for videos and photos from your camera fullermd?
[13:32] <mgz> most people use something better suited.
[13:32] <BY0LOG1C> thanks for the help mgz. yes ive had added the whole directory and tried commiting that - which failed on the ~1gb video files. so ive went to the bazaar explorer and had the file removed
[13:32] <mgz> games development is interesting, because they generally have two different groups that still want to combined form to be synced in some manner
[13:32] <fullermd> Heavens no.  I don't want any paper trail for my videos and photos...   safer that way.
[13:33] <fullermd> I mean...   what videos and photos?  I don't know of any videos and photos.
[13:34] <mgz> all those risqué self-portraits fullermd...
[13:35] <fullermd> Oh, you're supposed to do them yourSELF?
[13:35] <fullermd> Well, shucks.  I could have saved all those subpoenas...
[13:35] <mgz> BY0LOG1C: I'd go from the start again, clearly you had at least one commit that included big things
[13:37] <BY0LOG1C> so, i should delete my .bzr folder and start over and be more careful what i commit? ok ill try that, but it does seems kinda fragile, isnt it?
[13:38] <mgz> there's a thing in 2.5 that warns you when adding a file larger than 10MB or somehing
[13:38] <BY0LOG1C> i'd like to keep my whole(as mush as possible) my full game project under version control - is that impossible, am i required to manually browse each folder and add relevant files myself?
[13:39] <BY0LOG1C> im using 2.5.1(?) and i havent seen warning or anything
[13:39] <mgz> I'd have an assets folder for all art/music etc that is stored and updated elsewhere but the sourcecode build process knows how to fetch and update
[13:39] <mgz> if you've currently got stuff scattered around all over the place that's a little harder to manage
[13:40] <BY0LOG1C> yeah i understand that starting a project with cvs in mind would've helped us greatly
[13:41] <mgz> so then you just ignore ./assets, and make creates and populates it from a well known location
[13:42] <BY0LOG1C> right, that should work
[13:43] <mgz> and ftp server that gets backed up regularly or something, and you give upload rights to your artists
[13:43] <BY0LOG1C> so i really should version my assets myself - in a totally separate manner than code files
[13:44] <mgz> probably don't need to version, just keep a few checkpoints to prevent one person accidentially screwing stuff up too much
[13:45] <BY0LOG1C> ok, so an example pipeline could be to commit changes, zip up an asset folder and mark it with the revision id, i guess that could keep things clean and simple
[13:48] <BY0LOG1C> well, thanks for the help. i guess this project's kind of ruined but the next ones should hopefully work great
[13:50] <mgz> well, you can filter out the bad bits of history with fast-export/fast-import but that's probably not gaining you much over just versioning from now minus the big files
[13:52] <BY0LOG1C> yeah, well, after hearing your advices. i guess my idea of versioning the 'project' and all its pre-compiled stuff was wrong. my idea was that one could switch between versions with only a few clicks within the bazaar contextmenu
[13:53] <BY0LOG1C> i really should version only the source code directory and then have the engine recompile that when required
[13:53] <mgz> that's something that games dev do want, it's just not well supported by anything at the moment, given the rather different content storage requirements
[13:53] <BY0LOG1C> im amazed at the quantity of commands and possibilities that cvs offers, versioning really is an art
[13:54] <mgz> btw, it's vcs, or dvcs (for bzr, hg git), cvs is a specific vcs without the d
[13:54] <fullermd> Well, CVS is...  _like_ art...
[13:54] <BY0LOG1C> oh ok,ty
[13:54] <fullermd> In the "fingerpainting with your own intestines" sense, anyway.
[13:54] <BY0LOG1C> lol
[14:58] <BY0LOG1C> how can i un-version a project? will just deleting the .bzr folder do the trick?
[14:59] <BY0LOG1C> it looks like some connection remains
[15:00] <BY0LOG1C> nvm, looks like that dit it, my bad -_-
[15:04] <james_w> vila, hi
[15:04] <james_w> vila, you think there should be lock_for_script(name) that does the locking, and prints a useful error message, and that is used by all scripts?
[15:04] <vila> james_w: yes
[15:05] <james_w> sounds good
[15:05] <james_w> vila, I'm not sure I understand your point about the makedirs() though?
[15:05] <vila> I think we're close to that already and I really realized it when seeing your proposal
[15:05] <vila> so,
[15:06] <vila> ensure_dir makes sure the dirs are created so, only doing it in the tests means it will fail on a new install (at the worst possible time ;)
[15:06] <vila> that is: we don't have (yet) a script to ensure all the needed dirs are created
[15:07] <vila> your patch is fine as is for running the tests, for jubany and probably for your other udd instance but if I create a local one for tests purposes, I'll have to create the lock dirs manually
[15:07] <james_w> yes, it will fail on install
[15:07] <james_w> but it will also fail if e.g. the config options aren't being expanded and it's trying to lock ${pi.locks_dir}/whatever, which is obviously not what is wanted
[15:08] <james_w> it's a case of failing noisily so the admin can be sure it is doing what they want
 Ha right
[15:08] <vila> hmm, but that expansion issue has been solved right ?
[15:08] <james_w> I think that's the right way to go, so I'd like to look for ways to go that way and mitigate the fallout
[15:08] <james_w> yeah, we had to upgrade bzr
[15:09] <james_w> the version check didn't match exactly when the API changed
[15:09] <vila> well, ideally the way to go is to have a postinstall script
[15:09] <vila> yeah, my bad, I was hoping for people using trunk to upgrade often
[15:09] <vila> the bug was there for only a couple of revisions
[15:10] <vila> well, a mormon couple :)
[15:16] <james_w> vila, so are you happy if I land with the lock_for_script() change?
[15:16] <james_w> and we can add a script to create dirs for new installs or something?
[15:19] <vila> hehe, if the script appears soon enough *then* I'll be happy :) On the other hand, if you start with just creating the obvious dirs, it shouldn't be hard to write
[15:19] <vila> hmm,
[15:19] <vila> in fact, the script is what you started to add in the test setup
[15:19] <vila> no more no less
[15:19] <james_w> yeah
[15:19] <james_w> have a function that creates needed dirs
[15:19] <james_w> run it in test setup
[15:19] <james_w> have a script that calls it too
[15:19] <vila> perfect
[15:19] <james_w> then it can't get out of sync
[15:20] <vila> and is tested by design :)
[15:20] <james_w> vila, I'll make those changes, thanks
[15:20] <vila> thanks to you
[15:22] <vila> oh, since you're there, I had to struggle a bit to run the tests for this branch (install postgres, find postgresfixtures (damn, not packaged ?), install python-fixtures as recommended in 'requirements.txt'), but succeeded then
[15:22] <james_w> should I add a Makefile?
[15:22] <vila> I was wondering if we should add them as dependencies for udd if only to be able to run the tests after installation
[15:23] <vila> hmm, not sure I would have thought of the Makefile (I did find requirements.txt quickly)
[15:23] <james_w> on other projects we have "make bootstrap" create a virtualenv with everything you need to run tests
[15:23] <vila> I mention that because I mentioned to jml  that running the test suite would have caught the expansion bug
[15:24] <vila> never used virtualenv :)
[15:24] <vila> I do chroot, lxc, kvm, vbox and so on but no venv yet :)
[15:25] <jml> james_w: oh right I forgot to chase that up ... did we actually end up upgrading bzr? no one got back to me from ops
[15:25] <james_w> jml, oh, I was assuming it was done
[15:25] <jml> james_w: yeah. me too :\
[15:27] <vila> james_w: so, summary, no Makefile needed, for now it's up to the dev to setup his env properly, I think I'll add them as dependencies to bzr-package-importer as some point
[15:27] <vila> s/as some/at some/
[15:27] <james_w> ok
[15:28] <vila> and if you add the postinstall script, it will also find its place there ;)
[15:29] <vila> james_w: oh, and jokes aside, I *did* at various points in the past installed a local udd in vbox then kvm then lxc then chroot ;)
[15:29] <james_w> vila, you ran a chroot in an lxc in a kvm in virtualbox?!
[15:29] <vila> lol
[15:29] <vila> on my BeBox !
[15:29] <james_w> heh
[18:10] <BY0LOG1C> ive got some more beginners questions if you guys dont mind.
[18:11] <BY0LOG1C> what exactly is the purpose of repacking? is it only to save space or is there a speed benefit?
[18:12] <fullermd> I imagine there's a moderate theoretically speed benefit.  Larger practical one.
[18:12] <BY0LOG1C> also, is there a way to ask bazaar to not repack automatically?
[18:12] <BY0LOG1C> oh ok, thanks. so repacking is primarily to save space?
[18:13] <fullermd> Not really.  You could probably monkey around via a plugin and shortcut the autopacks away.
[18:13] <fullermd> No, and yes.  x-ref "larger practical".
[18:15] <BY0LOG1C> hmm, i guess i can handle the auto-repack
[18:15] <BY0LOG1C> thanks. i had been committing a 50gb project into smaller pieces and the 10th commit triggered auto-repack, which took forever when i was one commit away from completion
[18:16] <fullermd> There are basically 2 times that the auto-repack will hurt you a lot.
[18:16] <BY0LOG1C> not a real issue, but it got me wondering
[18:16] <fullermd> (1) you're doing a lot of dumb server work, in which case DDTT applies
[18:16] <fullermd> (2) you have ginormous mounds of data, in which case you're probably going to be in trouble from other things anyway.
[18:17] <BY0LOG1C> yeah i was working locally but was actually commiting the full game project. i talked a little in here today(you were there) and i learned that wasnt a good idea in any case
[18:17] <BY0LOG1C> still, im trying to figure the whole versioning idea
[19:04] <BY0LOG1C> is there a platform similar to launchpad that allows non-public shared project for free?
[19:05] <ccxCZ> I believe bitbucket allows a few of private repos for free
[19:05] <ccxCZ> hg or git only though
[19:07] <ccxCZ> also, launchpad is opensource, you can run it on your machine :]
[19:07] <BY0LOG1C> you mean i'd host my own repo?
[19:08] <ccxCZ> single repo is trivial, via ssh or something
[19:09] <ccxCZ> but you can run the whole suite with project management, teams, bug tracking etc..
[19:09] <BY0LOG1C> hm, ill have to check it out, could be interesting
[19:10] <ccxCZ> or you could just slap on bzr plugin on trac or redmine
[19:10] <BY0LOG1C> though i guess it'll be complicated enough that i'll mess up something. i hoped for an external solution heh
[19:11] <BY0LOG1C> im sorry if those are dumb questions. is bazaar somehow based on svn or are they completelty different projet?
[19:12] <ccxCZ> private hosting solutions are out there, you just need to pay for them :]
[19:12] <ccxCZ> completely unrelated
[19:12] <ccxCZ> similar goal, different approach, completely different implementation
[19:13] <BY0LOG1C> right. im kind of just checking out vcs. im just an indy game developer with a little codebase i can easily handle
[19:14] <BY0LOG1C> but i share code with a few team, i thought it could be fun to see how the big guys do stuff. i guess i can just drop it on launchpad and nobody will bother with it
[19:15] <BY0LOG1C> thanks a lot for the suggestions though.im just not too sure im able to apply them :)
[19:35] <ccxCZ> you don't need to use launchpad for just one project
[19:36] <ccxCZ> VPSes are pretty cheap if you need to share some space with others and you don't already have always-on accessible computer
[19:44] <BY0LOG1C> is that something i could setup on my hosted domain?
[20:10] <lamont> bzr st
[20:10] <lamont> bzr: ERROR: exceptions.AssertionError: get_next() called when there are no chars left
[20:10] <lamont> do we know about that one?
[20:10] <lamont> 2.3.4-0ubuntu1
[20:11] <lifeless> lamont: there should be more in ~/.bzr.log, but my WAG is you have a corrupt status file.
[20:46] <ccxCZ> BY0LOG1C: depends on what hosted domain actually means. for smart-server to run (which is quite beneficial) you basically need to be able to run custom apps, which is usually known as "shell account"
[20:47] <ccxCZ> VPS is more than that, you get control over whole (virtual) server, with user accounts etc.
[20:48] <ccxCZ> bzr can run with just file access, as most webhosts provide, but it would be suboptimal
[20:48] <BY0LOG1C> oh i see. well i believe ive got a shell account - im the cpanel admin anyway. ive setup a small test where i just uploaded a versioned folder and i could easily pull from it with bazaar
[20:49] <BY0LOG1C> i didnt try pushing but at this point i guess it works too. so that should be simple and efficient enough for me. im a happy camper
[20:49] <BY0LOG1C> but wait, so im goint the suboptimal way, arent i?
[20:50] <ccxCZ> if you can install bzr on the server, you will be able to use bzr+ssh:// style uris too (aka smart-server)
[20:50] <ccxCZ> if the server has python installed already it should not be hard
[20:52] <ccxCZ> easy_install --user bzr  might just do the trick
[20:54] <BY0LOG1C> i notice a ssh/shell section where i can setup key. but i cant find where i'd install it. i guess i should search around a little and see what i find. i dont want to bother you all day
[20:56] <ccxCZ> assuming you come from windows: http://www.howtoforge.com/ssh_key_based_logins_putty
[20:58] <BY0LOG1C> great info, thanks again!