[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] _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] _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] _kbulgrien: you're obviously not on Ubuntu, or this would Just Work™ [02:14] _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] _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] _kbulgrien: thats what AfC was referring to above. [02:19] _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] _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] 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 === bigjools-afk is now known as bigjools [02:25] <_kbulgrien> this would be so much simpler with partial checkout... just sayin... [02:25] how would you do partial checkout with no .bzr directories in every folder [02:26] which makes me loathe svn [02:26] 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] 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] we used to use svn with partial checkouts, but it was different projects inside a root folder managed by svn [02:28] 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] haha [02:29] my teacher told the students to use cvs [02:29] 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] 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] and yes bzr is nice cause you don't have to be forced into one way of doing things [02:32] which i dont like about git [02:32] <_kbulgrien> I tried git first. [02:32] git is nice with a pretty UI, which on osx there are plenty of [02:32] on windows, nopenopenopenopenope [02:33] 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] like [02:36] <_kbulgrien> https://bugs.launchpad.net/bzr/+bug/1012907 [02:36] Ubuntu bug 1012907 in QBzr "Access denied in uncontrolled folder prevents add in controlled folder" [Undecided,Incomplete] [02:37] <_kbulgrien> and similar file system permissions issues with command-line [02:38] ah yes. [02:38] i should take a look at that, that shouldn't be very hard to fix..... [02:39] 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] 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] hmm yes [02:41] C:\Documents and Settings\kbulgrien\Favorites\yadayada.url [02:41] <_kbulgrien> exactly [02:41] it went down a directory then went into all users [02:41] weird [02:41] 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] git was written by linus, so it pretty much depends on the gnutils or whatever its called [02:43] _kbulgrien: where is the bzr repo on your disk? [02:44] <_kbulgrien> C:/ for that scenario in that bug [02:44] ahh [02:44] oh, right, that's because it works finefine [02:44] but then you go onto windows, you need cygwin [02:44] which sucks sometimes [02:44] <_kbulgrien> oh... repo... no... the repo is somewhere else [02:44] msys doesn't suck as slowly, I think [02:45] <_kbulgrien> like bzr+ssh://linushost.... [02:45] well the local copy of the repo [02:45] <_kbulgrien> I use msys [02:45] 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] As I recall, gitk on Windows actually looks a lot nicer than on OS X ... [02:46] 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] something to do with the font metrics... [02:46] 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] unlike svn where you don't have the history ever, its all on the server [02:47] ah [02:47] but its in C:/ [02:47] so thats slightly better, i thought bzr was going up a directory [02:47] mgrandi: that's what bzr-svn is for ;-) [02:47] and thats kind of bad [02:47] but like i said, its probably doing some sort of os.walk() without any error handling [02:47] 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] well, it makes sense when you think about it... [02:48] 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] you can probably do bzr status --versioned [02:49] <_kbulgrien> hm... [02:50] 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] but you are only versioning certain parts [02:50] usually everything (like in a code project) in the folder wants to be versioned unless you specifically ignore it [02:50] 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] but no recurse wouldn't make sense, cause where would it not recurse? =P [02:51] well bzr/git/whatever works fine for this, but yeah have to do some things a little different [02:51] 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] 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] but no recurse makes me think that it just only goes into public_html [02:53] 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] 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] 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] should and link it, again shouldn't be that hard [02:55] 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] might as well start with the status one =P [02:59] <_kbulgrien> otoh bzr status not having it _is_ the most annoying. [02:59] 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] 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] 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] yes [03:02] people have discussed that bzr and any vcs is hard cause of complex data structures that really can't fail ever =P [03:02] 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] Ubuntu bug 964338 in Bazaar "bzr status abort on encountering an unreadable file." [Low,Confirmed] [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] yeah, it seems that bzr should not be failing on these [03:38] <_kbulgrien> ok, its been did [03:40] link? [03:41] <_kbulgrien> https://bugs.launchpad.net/bzr/+bug/1053778 [03:41] Ubuntu bug 1053778 in Bazaar "bzr status needs --no-recurse" [Undecided,New] [03:41] ok [03:41] i;ll take a look at it [03:41] 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... === AfC1 is now known as AfC [07:28] morning [07:28] moin moin === bigjools-afk is now known as bigjools [09:58] Hi! I'm quite new to bzr and I have come across a situation I don't know how to deal with: [09:58] 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] Why do you want to? [10:10] 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] Just merge trunk and move on. [10:24] Right, but then the rev numbering doesn't match the main branch. It doesn't matter? Doesn't look clean to me. [10:24] Doesn't matter. [10:25] Fine then. Thanks for the help [10:25] 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] Ok [14:07] hello :) [14:08] what means that: [14:08] You have not informed bzr of your Launchpad ID, and you must do this to [14:08] write to Launchpad or access private data. See "bzr help launchpad-login". [14:27] kiretoo: exacyl [14:27] kiretoo: exactly that. you have not told bzr what your username on launchpad is yet [14:38] jelmer, i've already has a username [14:40] kiretooo: does bzr know about it? have you run bzr lp-login? [14:42] i have to add some ssh keys ? [15:24] 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 === yofel_ is now known as yofel [16:54] hmm. Bzr 2.3's lsprof cachegrind/callgrind output needs work :-( [17:14] SamB_MacG5: have you tried getting a more recent python on your G5 ? [17:16] I suppose I could, though also getting the extra batteries might be a bit of a pain... [17:16] SamB_MacG5: easy_install ? [17:17] SamB_MacG5: that was just a thought, no idea how complex it can turn out [17:18] 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] would it be reasonably easy to build an installer for that, is another worry [17:19] (a bzr installer, I mean) [17:19] oh, and another complication would be that 10.5's xcode only comes with SVN 1.4 [17:23] oh, I was thinking of trying to build from Apple's python sources... [18:00] SamB_MacG5: I was thinkinh more about http://python.org/ftp/python/2.7.3/python-2.7.3-macosx10.3.dmg [18:01] jelmer: is bzr-svn trunk compatible with svn-1.4 ? [18:02] SamB_MacG5: well, you could start with a reduced number of plugins (all is defined in config.py right?) ? [18:04] SamB_MacG5: http://python.org/download/ says the above is for 10.3 through 10.6 [18:46] vila: I suppose bzr *probably* doesn't have much use for apple's extra pack-ins ... [22:28] 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] I mean Python extensions/libraries that Apple has bundled into Python, though upstream (and in most distros) they're packaged separately [22:30] er. I should have said "into the Python framework" [22:32] basically, the stuff in /System/Library/Frameworks/Python.framework/Versions/2.5/Extras [23:21] SamB_MacG5: right, I'm pretty sure bzr uses nothing from there (well, I'm sure for the core, pretty sure for the plugins)