[01:32] <_kbulgrien> I have a web host that has an old python so only bzr 2.3.4 is usable.  Is there an easy way to know what versions of a plugin are compatible.  I'm interested in fast-export/import etc. as I made my repo too big and want to break it into smaller pieces.
[01:34] <AfC> _kbulgrien: do the work on your local system, then send the results back up to the server. Distributed.
[01:35] <_kbulgrien> Hmm.  Heh.  Yeah, new to the whole distributed thing.  Thanks for that thought.
[02:00] <_kbulgrien> hrm.  not having luck installing the plugin.
[02:01] <_kbulgrien> bzr plugins lists it, but when I try to use it I get bzr: ERROR: Unable to import library "fastimport": bzr-fastimport requires the fastimport python module
[02:03] <_kbulgrien> I guess that means my python installation needs something called fastimport.
[02:04] <_kbulgrien> fun. nothing in the distribution that looks like that.
[02:11] <AfC> _kbulgrien: it's the bzr-fastimport plugin on Debian/Ubuntu
[02:12] <_kbulgrien> I got that, but I think I need https://launchpad.net/python-fastimport too
[02:13] <AfC> _kbulgrien: you're obviously not on Ubuntu, or this would Just Work™
[02:14] <lifeless> _kbulgrien: how are you installing the plugin ?
[02:14] <_kbulgrien> i untarred the tarball and put it in ~/.bazaar/plugins/fastimport then ran python setup.py build_ext -i there.
[02:15] <_kbulgrien> bzr plugins shows it installed
[02:16] <_kbulgrien> Now I just found python-fastimport and have run python setup.py install for it... (working through it bit  by bit as I'm not a python guy)
[02:17] <_kbulgrien> I think I might have to set up PYTHONPATH now
[02:19] <lifeless> _kbulgrien: ok, so the usual way if you are using ubuntu etc is to do 'apt-get install bzr-fastimport' which will take care of all the dependencies for you.
[02:19] <lifeless> _kbulgrien: thats what AfC was referring to above.
[02:19] <lifeless> _kbulgrien: you might find docs in README or something in the source tree for bzr-fastimport documenting its dependencies.
[02:19] <_kbulgrien> Yeah, but I am not an ubuntu user
[02:20] <lifeless> _kbulgrien: ok
[02:20] <_kbulgrien> and apparently this distro does not have python-fastimport packaged or I do not have the right source set up for it.
[02:21] <lifeless> you might find 'pip install fastimport' works
[02:22]  * _kbulgrien isn't aware of pip
[02:23] <_kbulgrien> ok, got it.
[02:24] <_kbulgrien> did python setup.py install --user for python-fastimport
[02:24] <_kbulgrien> now bzr fast-export worked
[02:25] <_kbulgrien> this would be so much simpler with partial checkout... just sayin...
[02:25] <mgrandi> how would you do partial checkout with no .bzr directories in every folder
[02:26] <mgrandi> which makes me loathe svn
[02:26] <mgrandi> so much
[02:26] <_kbulgrien> well, I don't know the techie details... sorry... but I am so used to partial checkout I haven't figured how to emulate it in bzr yet.
[02:27] <_kbulgrien> I don't like svn either
[02:27] <mgrandi> i dont see the need for partial checkouts when you have branches
[02:27] <_kbulgrien> I probably would get abused if I said I was a cvs user
[02:27] <_kbulgrien> of course not, you're not me
[02:28] <_kbulgrien> everyone sees things from the way they learned to work.
[02:28] <mgrandi> we used to use svn with partial checkouts, but it was different projects inside a root folder managed by svn
[02:28] <mgrandi> which could of easily been split up into branches, but i dunno
[02:29] <_kbulgrien> I happen to find partial checkouts in cvs really powerful.  I have to learn a new way now, but since I only used cvs and svn enough to know I didn't want to migrate to it... well, I have to figure it out.
[02:29] <mgrandi> haha
[02:29] <mgrandi> my teacher told the students to use cvs
[02:29] <mgrandi> for the final, at the end he asked how many people lost data / had problems, nearly everyone raised their hands
[02:31] <_kbulgrien> I must be old and musty because I think cvs works fine as I use it all the time at work and find it easy compared to picking up distributed vcs, though bzr comes the closest to fitting the idea I think a vcs should work.
[02:31] <mgrandi> instead of partial checkouts, put the things you would partially checkout into separate branches/repos
[02:31] <_kbulgrien> we never loose data in cvs.  the reason we are on cvs is because we lost data on everything else.
[02:32] <_kbulgrien> but then that was maybe 15 years ago when cvs came to the shop.
[02:32] <mgrandi> and yes bzr is nice cause you don't have to be forced into one way of doing things
[02:32] <mgrandi> which i dont like about git
[02:32] <_kbulgrien> I tried git first.
[02:32] <mgrandi> git is nice with a pretty UI, which on osx there are plenty of
[02:32] <mgrandi> on windows, nopenopenopenopenope
[02:33] <mgrandi> the only thing ive seen is the github app for windows, which is using a c# library that produces/consumes git stuff, rather then actually using the git program itself
[02:33] <_kbulgrien> After two weeks of struggling, I ran into  wall.  In <1hr I had converted the git repo to bzr and was working without even looking in a manual.
[02:35] <_kbulgrien> only I find now that doing stuff like this is more complicated.  I also find bzr has some annoying bugs that seem like they will not get fixed.
[02:35] <mgrandi> like
[02:36] <_kbulgrien> https://bugs.launchpad.net/bzr/+bug/1012907
[02:37] <_kbulgrien> and similar file system permissions issues with command-line
[02:38] <mgrandi> ah yes.
[02:38] <mgrandi> i should take a look at that, that shouldn't be very hard to fix.....
[02:39] <mgrandi> its probably doing a 'os.walk()' without catching exceptions
[02:39] <_kbulgrien> well what is odd is that it goes digging around where it shouldn't go in the first place.
[02:39] <_kbulgrien> then if you have anything fail, the whole operation fails
[02:39] <_kbulgrien> cvs would baulk but would keep going
[02:39] <mgrandi> so what folder are you trying to actually monitor?
[02:39] <_kbulgrien> bzr upchucks and bails without doing anything
[02:41] <_kbulgrien> well in this use-case, I am controlling user directory type stuff so I can share my setups between machines... keep a reference setup to push/pull in and out off.
[02:41] <mgrandi> hmm yes
[02:41] <mgrandi> C:\Documents and Settings\kbulgrien\Favorites\yadayada.url
[02:41] <_kbulgrien> exactly
[02:41] <mgrandi> it went down a directory then went into all users
[02:41] <mgrandi> weird
[02:41] <mgrandi> i'll take a look at it, ive been meaning to actually write some code for bzr
[02:41] <_kbulgrien> In that case, I could go command-line and make it work.
[02:42] <_kbulgrien> But the problem is that I also deliberately control areas of the filesystem that have stuff I can't read too, and command-line is just hosed there.
[02:43]  * SamB_MacG5 doesn't remember noticing a lack of gitk on Windows ... wonders why?
[02:43] <mgrandi> git was written by linus, so it pretty much depends on the gnutils or whatever its called
[02:43] <mgrandi> _kbulgrien: where is the bzr repo on your disk?
[02:44] <_kbulgrien> C:/ for that scenario in that bug
[02:44] <mgrandi> ahh
[02:44] <SamB_MacG5> oh, right, that's because it works finefine
[02:44] <mgrandi> but then you go onto windows, you need cygwin
[02:44] <mgrandi> which sucks sometimes
[02:44] <_kbulgrien> oh... repo... no... the repo is somewhere else
[02:44] <SamB_MacG5> msys doesn't suck as slowly, I think
[02:45] <_kbulgrien> like bzr+ssh://linushost....
[02:45] <mgrandi> well the local copy of the repo
[02:45] <_kbulgrien> I use msys
[02:45] <mgrandi> cause a repo monitors things inside of it, so its in C:/ ?
[02:46] <_kbulgrien> no... repo is completely somewhere else... .bzr is in C:\
[02:46] <_kbulgrien> I answered wrong the first time
[02:46] <SamB_MacG5> As I recall, gitk on Windows actually looks a lot nicer than on OS X ...
[02:46] <mgrandi> well the thing is with bzr and other DVCS, if you have a 'branch ' of something, then you technically have the complete copy of the history
[02:46] <SamB_MacG5> something to do with the font metrics...
[02:46] <mgrandi> so you technically have the repo on C: and on your server
[02:46] <_kbulgrien> except in this case I used --lightweight or whatever
[02:46] <mgrandi> unlike svn where you don't have the history ever, its all on the server
[02:47] <mgrandi> ah
[02:47] <mgrandi> but its in C:/
[02:47] <mgrandi> so thats slightly better, i thought bzr was going up a directory
[02:47] <SamB_MacG5> mgrandi: that's what bzr-svn is for ;-)
[02:47] <mgrandi> and thats kind of bad
[02:47] <mgrandi> but like i said, its probably doing some sort of os.walk() without any error handling
[02:47] <mgrandi> i'll take a look at it, this seems like a nice place to start~
[02:48] <_kbulgrien> I also don't like that bzr status doesn't allow --no-recurse
[02:48] <mgrandi> well, it makes sense when you think about it...
[02:48] <mgrandi> the whole point is that stuff under the repo folder is monitored
[02:49] <_kbulgrien> well when, say I am working on a webserver, I lots of times don't give a rip about status anywhere except where I am, and all the boatload of status is annoying
[02:49] <mgrandi> you can probably do bzr status --versioned
[02:49] <_kbulgrien> hm...
[02:50] <mgrandi> you have a weird case where your repo is your entire hard drive
[02:50] <_kbulgrien> ok... will have to try to remember that
[02:50] <mgrandi> but you are only versioning certain parts
[02:50] <mgrandi> usually everything (like in a code project) in the folder wants to be versioned unless you specifically ignore it
[02:50] <mgrandi> but yeah, use --versioned, will only show files that are actually versioned instead of all those ? ones
[02:51] <_kbulgrien> well  I know my grief is that I want to do version control for things that aren't typical software dev, but I think version control transcends software dev...
[02:51] <mgrandi> but no recurse wouldn't make sense, cause where would it not recurse?  =P
[02:51] <mgrandi> well bzr/git/whatever works fine for this, but yeah have to do some things a little different
[02:51] <mgrandi> the same thing with dropbox, everything in the dropbox folder gets uploaded
[02:52] <_kbulgrien> well, I don't know what you are saying because cd ~/public_html; bzr status --no-recurse makes sense to me.
[02:52] <mgrandi> but if there are files in /public_html/stuff and /public_html/stuff2, it has to enter those folders
[02:53] <_kbulgrien> why does it have to?
[02:53] <mgrandi> but no recurse makes me think that it just only goes into public_html
[02:53] <mgrandi> i kinda get what you are saying,
[02:53] <_kbulgrien> All I care about most of the time is the folder where I am, and I don't really need to know status for the whole sub-tree all the time
[02:53] <mgrandi> kind of like ls
[02:54] <_kbulgrien> Sure, at some point I care, but not while I'm working locally in that folder only.
[02:54] <_kbulgrien> I use bzr status . all the time to not get history outside a sub-tree.  It's the same principle.
[02:54] <mgrandi> have you filed a bug report on this yet? (just so people remember)
[02:54] <_kbulgrien> Not yet.
[02:55] <_kbulgrien> I'm still getting used to things and the annoyance pressure hasn't built up to file a bug level yet.
[02:55] <mgrandi> should and link it, again shouldn't be that hard
[02:55] <mgrandi> to add --no-recurse
[02:58] <_kbulgrien> well  I guess I'm not sure if bzr status is the only thing that doesn't have --no-recurse that I wish had it... so part of the delay is to see if there are other commands that get annoying because of no --no-recurse.
[02:58] <mgrandi> might as well start with the status one =P
[02:59] <_kbulgrien> otoh bzr status not having it _is_ the most annoying.
[02:59] <mgrandi> i'll look into it and see if its easy
[02:59] <_kbulgrien> I guess I'm skeptical that anyone cares these days.
[03:00] <mgrandi> open source software for you =P
[03:00] <_kbulgrien> And I feel since I don't know python that people think I'm just whining... you know... submit a patch then doofus...
[03:00] <mgrandi> hehe
[03:00] <_kbulgrien> but learning python to patch a vcs is not something done lightly
[03:01] <_kbulgrien> well, really, its not the learning python part... its learning the bzr source part.
[03:02] <mgrandi> yes
[03:02] <mgrandi> people have discussed that bzr and any vcs is hard cause of complex data structures that really can't fail ever =P
[03:02] <mgrandi> but if its just command stuff like this, i feel i can take a stab at it
[03:02] <_kbulgrien> I code in so many languages and scripting languages that its really not about learning python.
[03:04] <_kbulgrien> This is the other bug that kills me https://bugs.launchpad.net/bzr/+bug/964338
[03:04] <_kbulgrien> heh, I see bug listed for bzr revert needs --no-recurse
[03:04] <_kbulgrien> Ok, so maybe I add one
[03:05] <mgrandi> yeah, it seems that bzr should not be failing on these
[03:38] <_kbulgrien> ok, its been did
[03:40] <mgrandi> link?
[03:41] <_kbulgrien> https://bugs.launchpad.net/bzr/+bug/1053778
[03:41] <mgrandi> ok
[03:41] <mgrandi> i;ll take a look at it
[03:41] <mgrandi> but now need to go, later!
[05:08] <_kbulgrien> Hmm. well, I guess that went ok.  Looks like I broke apart the repository the way I intended out, though I went about removing the top-level directory in a harder way than was necessary... it turns out fast-import-filter public_html/ with the trailing slash is the right way to prune top-level folder levels out of the fast-export.
[05:09] <_kbulgrien> I guess the grammar on that was bad... I meant ...specifying extra path levels is the way to prune...
[07:28] <mgz> morning
[07:28] <emeric_> moin moin
[09:58] <Ovocean> Hi! I'm quite new to bzr and I have come across a situation I don't know how to deal with:
[09:58] <Ovocean> I have uploaded a branch for Lutris on Launchpad, it's been merged with the main branch. But I had done a couple commits to my local branch before the merge, and didn't upload them yet. Now I need to get/merge back the last version of the main branch (rev 163) and have my last commits (rev 176 & 177 on my local branch) put on top of that as rev 164 and 165. How would I do that?
[10:08] <fullermd> Why do you want to?
[10:10] <Ovocean> To be able to continue to work on my branch, and not loose my last commits. What's the normal way to do this?
[10:11] <fullermd> Just merge trunk and move on.
[10:24] <Ovocean> Right, but then the rev numbering doesn't match the main branch. It doesn't matter? Doesn't look clean to me.
[10:24] <fullermd> Doesn't matter.
[10:25] <Ovocean> Fine then. Thanks for the help
[10:25] <fullermd> Only thing that matters in merging and suchlike is what revs are present where.  revnos just relate to the shape of the local history.
[10:26] <Ovocean> Ok
[14:07] <kiretooo> hello :)
[14:08] <kiretooo> what means that:
[14:08] <kiretooo> You have not informed bzr of your Launchpad ID, and you must do this to
[14:08] <kiretooo> write to Launchpad or access private data.  See "bzr help launchpad-login".
[14:27] <jelmer> kiretoo: exacyl
[14:27] <jelmer> kiretoo: exactly that. you have not told bzr what your username on launchpad is yet
[14:38] <kiretooo> jelmer, i've already has a username
[14:40] <jelmer> kiretooo: does bzr know about it? have you run bzr lp-login?
[14:42] <kiretooo> i have to add some ssh keys ?
[15:24] <SamB_MacG5> kiretooo: yeah, you need to set up an ssh key on your system and paste the public key into a box in your launchpad profile/configuration
[16:54] <SamB_MacG5> hmm. Bzr 2.3's lsprof cachegrind/callgrind output needs work :-(
[17:14] <vila> SamB_MacG5: have you tried getting a more recent python on your G5 ?
[17:16] <SamB_MacG5> I suppose I could, though also getting the extra batteries might be a bit of a pain...
[17:16] <vila> SamB_MacG5: easy_install ?
[17:17] <vila> SamB_MacG5: that was just a thought, no idea how complex it can turn out
[17:18] <vila> SamB_MacG5: on the other hand, if you can get up to 2.7, you should be good to go for quite a while
[17:18] <SamB_MacG5> would it be reasonably easy to build an installer for that, is another worry
[17:19] <SamB_MacG5> (a bzr installer, I mean)
[17:19] <SamB_MacG5> oh, and another complication would be that 10.5's xcode only comes with SVN 1.4
[17:23] <SamB_MacG5> oh, I was thinking of trying to build from Apple's python sources...
[18:00] <vila> SamB_MacG5: I was thinkinh more about http://python.org/ftp/python/2.7.3/python-2.7.3-macosx10.3.dmg
[18:01] <vila> jelmer: is bzr-svn trunk compatible with svn-1.4 ?
[18:02] <vila> SamB_MacG5: well, you could start with a reduced number of plugins (all is defined in config.py right?) ?
[18:04] <vila> SamB_MacG5: http://python.org/download/ says the above is for 10.3 through 10.6
[18:46] <SamB_MacG5> vila: I suppose bzr *probably* doesn't have much use for apple's extra pack-ins ...
[22:28] <vila> SamB_MacG5: sry was afk, extra pack-ins as in python modules added by apple ? In this case, I'm pretty sure the answer is yes. The only one I can think that may use apple specific stuff is for the keyring (sry, can't remember the plugin name) and I seem to recall it doesn't use any apple-specific python stuff
[22:30] <SamB_MacG5> I mean Python extensions/libraries that Apple has bundled into Python, though upstream (and in most distros) they're packaged separately
[22:30] <SamB_MacG5> er. I should have said "into the Python framework"
[22:32] <SamB_MacG5> basically, the stuff in /System/Library/Frameworks/Python.framework/Versions/2.5/Extras
[23:21] <vila> SamB_MacG5: right, I'm pretty sure bzr uses nothing from there (well, I'm sure for the core, pretty sure for the plugins)