[00:00] krisives, no, bzr only stores it on the top level [00:00] andresj, I don't know what you want to do :) [00:00] my instinct is that you could use bzr-upload [00:00] Or a symlink? [00:00] to deploy your cahnges without a .bzr dir [00:01] bzr-upload? that sounds like it would do its job tremendously well [00:01] i have a production server, which has the constraints i talked about [00:01] andresj, yes, bzr-upload pushed the changes that have been made since the last revision [00:01] To ignore a directory do I do `bzr ignore dir/` or `bzr ignore dir/*` ? [00:01] then i have a development server, which is hosted in my own machine, so it doesn't have sch constraints [00:01] uses sftp or ssh [00:01] does bzr-upload need a .bzr dir? [00:01] (on the "to" side) [00:02] not remotely [00:02] it just stores the last revid uploaded in a hidden file on the remote end [00:02] ##awesome! :D sounds like a good candidate [00:02] hum... does that file need to be in the "root" of the remote end's repo? [00:02] Will `bzr ignore` remove it from version control, or do I also have to `bzr remove --keep dir/` ? [00:02] andresj, https://edge.launchpad.net/bzr-upload [00:02] ok, i'll check it out :D [00:03] andresj, it places it on the root of wherever you tell it to upload [00:03] hum... [00:03] but that's much easier to change [00:03] oooh [00:03] I can tweak that for you, I'm one of the authors ;) [00:03] soudns like a good candidate for a one-word deploy command!! :D [00:03] andresj, that's exactly what motivated it :) [00:04] beuno: lol it would be amazing if you could do that :D [00:04] andresj, do what? specify where you want to store that file? [00:04] beuno: yes. [00:04] it's just a text file with the revid, has no information [00:05] but I can easily add a switch that changes it's location (I think) [00:05] let me play with it for a bit [00:05] well i can play around with it; wouldnt want to spend too much of your time :D [00:05] andresj, if it's a one-off you can just edit the plugin [00:06] you can even make it upload automatically every time you commit if you want to [00:06] line 106 of __init__.py specifies where it stores the revid [00:06] that would actually be awesome. [00:07] decision: trunk or ubuntu .dev [00:07] * .deb [00:07] I'd go with trunk [00:07] same thoughts here :P [00:07] http://bazaar.launchpad.net/~bzr-upload-devs/bzr-upload/trunk/annotate/head%3A/README [00:08] that should give you a nice overview [00:09] wow, thank you so much! :-) launchpad should have manual "add karma points" option ;P [00:10] I have IRC karma I add on to manually ;) [00:10] lol well that i completely missed—am i not informed enough about these concepts? :P [00:16] I bought beer for a hacker once. That should also get me Lauchpad karma points. [00:22] lol [00:28] i think it should have a 'thanks' button [00:28] it's nice there is one in answers, but it should be everywhere [00:28] That was shot down. [00:28] maybe it could have a beer bottle icon, but that may give offence to some people [00:28] Just recently. [00:28] wgrant: really? :/ [00:28] Yes. [00:28] * wgrant finds the bug. [00:29] Bug 394076 [00:29] Launchpad bug 394076 in launchpad-registry "[feature] Add facility to say Thanks to launchpad users" [Undecided,Invalid] https://launchpad.net/bugs/394076 [00:46] i think we should reopen it [00:46] i don't know if it will get done soon though [01:04] self.upload_full_tree(): NotImplementedError [01:05] aaaah [01:05] no support for symlinks, right? [01:07] is that the bzr-upload plugin? [01:08] yes [01:09] I replaced raise NotImplementedError with continue; maybe i'll implement symlink support later :P [02:01] are there bzr binaries available anywhere? [02:01] (for linux) [02:02] mobodo, you mean ubuntu *wink* [02:02] actually, let me check, I'm not sure [02:02] The Pyrex bits are just for speed, aren't they? [02:03] mobodo, i assume you have looked at this page: http://bazaar-vcs.org/Download [02:03] wgrant, mostly confident that's correct. [02:03] wgrant: today, the C extensions are all optional, but *strongly recommended* [02:03] ah, right, I can extract from a ppa [02:04] wgrant: behaviour isn't identical without them, in particular data compression is reduced without the extensions [02:04] lifeless: Oh. [02:04] I see. [02:05] wgrant: for the record, not all the extensions are pyrex either [02:05] I feel dumb, I can't even find the linux flavour of my web server :P [02:05] uname -a should do it, right? [02:08] CentOS... oh my... [02:09] fedora RPM's may be the go for you [02:10] I'll try that... I need to install locally, so rpm will be easier [02:14] hmm ... what's a repository format that isn't going to be deprecated for a long time? [02:15] but isn't bzr-svn's default format either now or soon? [02:15] 2a [02:15] you see, I'm trying to write a blackbox test like jelmer asks for here: https://code.launchpad.net/~naesten/bzr-svn/408560-format-flags/+merge/9606 [02:16] SamB: we deprecate rarely. whats bzr-svn's current default? [02:16] I'm adding support for specifying the format for an "svn-import" [02:16] hmm ... [02:17] rich-root-pack [02:17] it seems [02:18] I think it actually uses default-rich-root, so whatever that points to at a given point in time... [02:18] morning all [02:19] fullermd: ah [02:19] well, I want a format that will be around for a while but definately isn't that in the future ;-) [02:21] SamB: 1.9-rich-root then [02:22] hi igc [02:22] thanks [02:22] hi lifeless [02:22] igc: better? [02:22] hi samb [02:22] you were sick, I believe? [02:23] SamB: still recovering but orders of magnitude better [02:24] SamB: I had some surgery last Monday (stoma reversal) that was meant to be a few nights in hospital but ... [02:24] SamB: things didn't go so well [02:24] ah [02:25] SamB: nothing a few days in intensive care, several bags of blood and a second operation couldn't fix though [02:26] SamB: so I'm tired & ticked off with the world but I'll get over it [02:51] igc: hi, so faster commit is this || close [02:51] lifeless: that's exciting - well done [02:51] igc: if you grab bzr+ssh://bazaar.launchpad.net/~lifeless/bzr/iter-changes-partial-parents and merge bzr+ssh://bazaar.launchpad.net/~lifeless/bzr/commit-specific-files [02:51] lifeless: I'll take a look when I get a moment [02:52] the two combined make specific and full commits the same speed for launchpad [hot cache] [02:59] lifeless: that's too bad [02:59] because there is no || in python [03:02] hold up your thumb and index finger close together [03:02] * SamB ;-P [03:02] anyway ... [03:03] it seems that 1.9 and 1.14 aren't distinguishable by "bzr info"? [03:04] 1.14 is only a new working tree format [03:04] ah. [03:05] so no-working-tree => indistinguishable :-) [03:35] * igc food === cprov is now known as cprov-zzz [03:52] 'bzr branch lp:mup' gets the "Absent factory" error (bzr bug #408251) for me. Wonder if it's my lp plugin? [03:52] Launchpad bug 408251 in bzr "ErrorFromSmartServer: Error received from smart server: ('error', "Absent factory for ('**')")" [Undecided,New] https://launchpad.net/bugs/408251 [03:54] * spiv -> lunch [03:57] kfogel: I see that error too, it's not a bug in your client [03:58] spiv: dang [03:58] kfogel: at a glance it looks like the remote branch is faulty. [03:58] spiv: I really want to get lp:mup, too. Thing is, my branch is not the same as the original one in the bug. CAn that many branches on lp be buggy? [03:59] kfogel: probably with the "classic" bug, not a new problem [04:00] kfogel: yes, please read the description of https://bugs.edge.launchpad.net/bzr/+bug/354036 [04:00] Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed] [04:00] kfogel: certainly the workaround (bzr branch nosmart+lp:mup) will work for you. [04:00] spiv: thx [04:00] spiv: huh ... why does that look so much like the "bzr send is broken with chk" bug? [04:00] spiv: do we think those two are dups? [04:01] bug #40825 and bug #354036 [04:01] Launchpad bug 40825 in linux-source-2.6.15 "Xubuntu Live CD doesn't boot right on laptop" [Medium,Invalid] https://launchpad.net/bugs/40825 [04:01] kfogel: maybe, I don't know. [04:01] Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed] https://launchpad.net/bugs/354036 [04:01] heh [04:01] I meant bug #408251 [04:01] Launchpad bug 408251 in bzr "ErrorFromSmartServer: Error received from smart server: ('error', "Absent factory for ('**')")" [Undecided,New] https://launchpad.net/bugs/408251 [04:01] spiv: ok [04:01] The difficulty is that that error is not a very precise symptom. [04:01] And the cause tends to be somewhat distant. [04:02] how does that relate to bug 393349 ? [04:02] i.e. a client with a bug does a push that appears to work, some time later someone else does a pull or branch and gets that error. [04:02] Launchpad bug 393349 in bzr "Bundle (bzr send) broken with --2a format" [Critical,Triaged] https://launchpad.net/bugs/393349 [04:02] Basically that error just means "a record that bzr expected to be there wasn't there" [04:03] And that might be because bzr is looking for the wrong thing, or because it should be there but wasn't pushed, etc. [04:03] maybe somebody should change AbsentContentFactory to give better AttributeErrors? [04:03] SamB: it's a related class of problem [04:04] SamB: (not sending enough data) [04:04] I'm saying that it should say something about *what* content was absent [04:04] Hmm, that's better phrased as "it's related because it's the same class of problem" [04:04] not just look like someone forgot to implement a method ;-) [04:04] Well, it does, mostly, it gives the key. [04:04] (in current bzr) [04:04] See kfogel's bug comment, for instance. [04:05] spiv: ah, that's basically what I meant ;-) [04:05] but maybe it should also give a clearer indication that AbsentContentFactories aren't expected to have ... whatever attribute? [04:06] kfogel: so, the fixer script from 354036 does find some missing inventories on lp:mup [04:07] kfogel: so your problem is almost certainly that bug. Unfortunately due to the way codehosting works it's not enough to have an owner of the branch run the fix script :( [04:08] spiv: (sorry, in another conversation, will check backscroll and catch up soon) [04:10] kfogel: summary: it's a dupe, and I've marked the bug as such. [04:11] * spiv -> really lunch. [04:12] spiv: ah great, thanks [04:49] * kfogel is away: sleep [05:15] igc, not urgent, but would be curious about your comments on https://code.edge.launchpad.net/~mbp/bzr/408193-hardlink/+merge/9567 [05:16] poolie1: sure. I certainly won't get it today though sorry [05:36] * poolie1 reading https://code.edge.launchpad.net/~jameinel/bzr/1.18-bundle-and-stack-393349/+merge/9334 [07:13] hi all [07:14] * fullermd waves at vila. [07:46] hi vila [07:47] hey igc, glad to see you here :) [07:47] vila: yeah - it's good to be back in the land of the living :-) [07:47] igc: I'm grumpy too this morning if that's of any help :-D [07:47] vila: :-) [08:12] Grumpiness is healthy. It shows that your mind is working well enough that you're not saddled with optimism or other such disorders. [08:22] fullermd: a set of well-placed optimism helps tho [08:28] Pshaw. Optimists are the people who put water in a glass so they can DROWN you in it. [08:32] fullermd: if i didnt have some optimism i wouldn't brother with the opensource work i do [08:32] fullermd: also i figured how to drown you with a drop of water [08:33] lifeless: around? [08:34] Oh, that doesn't require optimism. Just the conviction that everybody else is incompetent, and if you want something done right, you'll have to do it yourself 8-} [08:34] fullermd: oh, lol [08:35] fullermd: i get that surprisingly often [08:35] Arrogance is an excellent substitute for optimism, altruism, and various other alternate sources of gumption. [08:35] perhaps someone else may also be able to help. I need to merge a bzr branch which has been imported from git with a bzr branch that was imported from svn. lifeless recommended I use "bzr fast-export" and "bzr fast-import" but I haven't got those commands [08:35] I'm running bzr 1.17 - is there a newer version I need? [08:35] mdke: They're part of the fast-import plugin. [08:36] doh [08:36] fullermd: thanks! [08:36] fullermd: i dont like arrogance tho, it enables higher falure rate [08:37] Only if you're incompetely, like Everybody Else, see. It totally doesn't apply to Me. [08:37] * bialix tired to unpack zipped branches to do some work with them [08:37] hmm, I still don't have the command, having installed bzr-fastimport (0.0.1~bzr112-0ubuntu1) [08:37] how hard would be to implement zip transport or zip+ decorator [08:37] ? [08:37] fullermd: humans tend to fail, and tend to liet to themself about it [08:37] any hints? [08:38] aha, it's bzr-fast-export [08:38] Lying to yourself is ineffective. There are always other people around to remind you that you're doing it. [08:38] That's where mass murder comes into the picture... [08:39] next questions. lifeless said to use the -r parameter for the export, but bzr-fast-export doesn't seem to have such an option [08:39] spiv: around? [08:40] fullermd: when you are better than most people around your current location, they kind of aint in that position [08:40] mdke: I've got it in mine. The release/package may be Really Old. [08:40] hmm [08:40] mdke: Mine says "0.8dev", just pulled as a branch. [08:40] meh, so far i need the internet to get equivalent and/or better peers [08:40] bialix: yeah [08:41] bialix: what can I break^Wdo for you today? :) [08:41] fullermd: ok, I'll look for a newer version, mine seems to be coming from Ubuntu rather than the bzr ppa [08:41] spiv: I feel the need to write plugin to work with zipped branches, any hints? [08:41] bialix: as in a .bzr directory in a zip file? [08:41] spiv: what is better: zip transport (subclass of Local) or zip+ decorator? [08:42] entire branch inside zip, yes [08:42] Hmm, I think a new transport. [08:42] fullermd: there is a newer version in Ubuntu Karmic, I'll try it there. Thanks again for your help [08:43] Otherwise what would get_transport('zip+file://....').clone('foo') mean? [08:43] Does that mean a new zip file, or would it mean a new file inside a zip? [08:43] spiv: I guess I want read-only transport [08:44] I think you need more like "zip:///path/inside/zip" [08:44] * bialix upgrade to ff 3.5.2, sorry if I'll disappear for a bit [08:44] Or possibly create a ZipServer along the lines of ChrootServer [08:45] (So URLs like zip-111111://... that are just in-process names for an already-open zip file) [08:45] * bialix back [08:46] spiv: escaped url? [08:46] 17:44 < spiv> Or possibly create a ZipServer along the lines of ChrootServer [08:46] 17:45 < spiv> (So URLs like zip-111111://... that are just in-process names for an already-open zip file) [08:46] I think that would be a better option. [08:47] I don't understand === Noldorin___ is now known as Noldorin [08:47] in my imagination I'd like to work from command line as: bzr pull zip://path/to/archive.zip/branch/inside/zip [08:47] Well, it depends a bit on exactly how you want it to work... you want to be able to do "bzr branch http://.../somefile.zip foo" [08:48] Hmm. [08:48] I think valid URL for branch inside zip could be zip://path/to/archive.zip/branch/inside/zip [08:48] so path/to/archive.zip is actually zip file [08:48] Ok, that works, but only for local paths obviously. [08:49] If you're fine with that restriction then go for it. [08:49] yep, that's why I've asked about zip+ decorator [08:49] (zipfile://... might be clearer?) [08:49] Or rather, it works with some hackery. [08:49] zipfile? maybe it is, but longer to type [08:50] You can't just look at the URL you propose and know what the path to the zip file is. [08:50] yes, I guess I need to introduce some restrictions [08:50] Which is why I proposed a scheme more like http [08:50] Where you have a netloc (host) and a path. [08:50] or use different URL scheme, as discussed with colocated branches [08:50] what is netloc? [08:51] jargon for the "host" part of "http://host/foo", roughly. [08:51] ok, I understand [08:51] but no, it will complicate of usage [08:51] So, zip://path%2Fto%2Farchive.zip/branch/inside/zip, for an ugly example. [08:52] it's really ugly [08:52] Yep. [08:52] and I can't use tab-completion then [08:52] I can try to find zip file recursively, trying to open path/to/archive.zip/branch/inside/zip, then path/to/archive.zip/branch/inside etc [08:53] I think there's a better way. [08:53] once I found zip file I'll use remainder as relpath inside zip === Noldorin___ is now known as Noldorin [08:53] what about read-only? [08:54] is it declared somehow or I just need not to implement write methods? [08:54] bialix: I think implementing a ZippedBzrDir would actually work better. [08:54] why? [08:55] bialix: then plan paths and URLs would Just Work, no new URL syntax in the UI necessary [08:55] ah, and I can reuse std probing? [08:55] hi Gary! [08:56] Hi [08:56] And you won't have this friction with probing in a transport, which in your proposal you'd either be redoing *lots* or doing a hack to share state between Transports, which are mostly stateless. [08:56] spiv: ZippedBzrDir will be enough? or I need ZippedBzrBranch as well? [08:56] Right. [08:57] Well, if I were to implement this, I'd make a ZippedBzrDir and then a ZipTransport/ZipServer [08:57] perhaps I need to look at bzr-svn/bzr-git to see how they implement foreign formats [08:57] I don't undertsand [08:57] what is ZipTransport/ZipServer? [08:57] The ZippedBzrDir would probe the transport it is given, and if it finds a zip file, [08:58] garyvdm: can you look at failing test? [08:58] then it would create a ZipServer object (which gives you a single place to open/close the zip file, and possibly do some caching), === Noldorin_ is now known as Noldorin [08:59] spiv: is there example of doing so? [08:59] (the ZipServer would be backed on to the real transport) [08:59] spiv: it sounds a lot like black bzr magic [08:59] bialix: The qbzr treemodel test - yes - it will be easy to fix. I'll do it tonight. [08:59] bialix: Sorry - I have been very busy with other things. [09:00] And then construct a ZipTransport from the ZipServer, and then pass *that* back into regular BzrDir.open_from_transport [09:00] garyvdm: we need to release qbzr in sync with bzr [09:00] spiv: oh [09:00] bialix: take a look at ChrootServer (and bzrlib.smart.server's serve_bzr function) [09:01] But the ZipTransport here wouldn't be something that could be directly constructed from a URL from a user (just like you can't just pass a chroot:/... URL on the command line). [09:02] bialix: if you look at ChrootServer it's a very simple class, and I imagine your ZipfileServer would be pretty simple too; basically just an object to hold an opened zipfile. [09:03] * bialix looks at ChrootServer and serve_bzr [09:03] (like how ChrootServer is basically just an object to remember what the backing transport is, regardless of any t.clone('..') etc done on the individual transport objects) [09:03] chroot_server = ChrootServer(transport) [09:03] chroot_server.setUp() [09:04] transport = get_transport(chroot_server.get_url()) [09:05] Right. [09:05] I'm not quite understand how it prevents of clone('..') [09:06] transport there will be an instance of ChrootTransport [09:06] mdke: hai [09:06] * igc dinner [09:06] so, should I subclass Chroot(Server|Transport) for Zipped*? [09:07] Which implements every method of Transport by first checking the path is safe (see ChrootTransport._safe_relpath), and then calling self.server.backing_transport. [09:10] I wouldn't subclass Chroot* for you. [09:10] just reimplement the logic? [09:10] Yeah. [09:10] last question: how can I force read-only? [09:10] I suppose if you subclassed just ChrootTransport you'd be able to reuse all the shim methods... but it's not a very good fit. [09:10] For that I'd just use the readonly+ decorator, I think :) [09:10] oh, I found [09:10] is_readonly method of transport should do [09:11] so, I have two ways for my plugin: do only zip:// transport, or going hard path and implement ZipBzrDir, Server, Transport [09:11] For the implementation of write methods like mkdir just raise TransportNotPossible("readonly transport"), just like ReadonlyTransportDecorator does. [09:12] Personally, I think the latter is actually the easy path :) [09:12] Because otherwise you're going to be fighting the design of bzrlib.transport rather than working with it. [09:12] TransportNotPossible: ok [09:13] (and return False from is_readonly, of course, as you've noticed) [09:14] maybe you're right about easy path, I need to experiment with Server a bit [09:15] spiv: thanks for the hints, I'll try to play with it [09:15] Another example of the Server/Transport pattern is MemoryServer/MemoryTransport. [09:17] ok === Noldorin_ is now known as Noldorin === Noldorin_ is now known as Noldorin [09:52] Hi - Any advice on how I should respond to this: http://paste.ubuntu.com/247031/ ? [09:55] is it worth responding to? [09:56] convincing somebody that version control is useful can be tough [09:56] luks - yes - I have to collaborate with this guy on a website... [09:57] In cases like this, I like to use swearing... [09:57] garyvdm: How does he plan to keep track of change? [09:57] At the moment, I'm commit his changes on his behalf. [09:57] jpds: He doesn't [09:58] garyvdm: I'm windows box person [09:59] does my words as former windows maintainer will help? [09:59] I think the problem here is VCS in generally, not bzr specificially [09:59] *general [09:59] bialix: The windows issue is easy to deal with. [10:00] It the "why vcs?" issue that is hard. [10:00] I don't understand what is windows issue here [10:00] *It's [10:00] bialix: FUD [10:00] call vcs as automatic backup [10:00] that's all [10:01] Ask him how *he* plans to deal with merging changes when you are both doing work simultaneously, and then point out how VCS would make that so much easier? [10:01] maxb: Yes [10:01] make him screw up something, so he needs an older version :P [10:02] Or just keep on overwriting his changes... [10:02] I've used that technique with some success. [10:02] Though usually, the response ends up being an endless stream of commits with no log messages, and/or the log message "This week's work" every Friday at 16:55. [10:02] And ask him how he would deal with discovering that a mysterious subtle bug was introduced some time ago, and explain about bisecting :-) [10:03] fullermd: better than nothing [10:03] one step at a time :) [10:03] maxb: That will just go straight over his head... [10:03] oh dear [10:03] Yeah, the response to that will be "Who cares where it came from? It's there now, so fix it." [10:04] fullermd: you talk about backup or overwriting changes? [10:04] bialix: Overwriting. [10:04] Or, you can keep checking it in for him. And billing him for the time you spend doing so. [10:18] This is what I'm sending him: http://paste.ubuntu.com/247060/ [10:23] there is always enough lights to one who want to see, and enough darkness to one who don't === Noldorin_ is now known as Noldorin [11:06] heh [11:06] http://crossonline.blogspot.com/2009/08/howto-version-control-using-bzr.html - comparing bzr to rcs === Noldorin_ is now known as Noldorin [11:12] anyone have any experience with bzr-keywords? Not sure how to get it working [11:14] Installing the plugin and enabling the filter got it working for me. [11:14] Shortcomings in filtering make it less than useful, though. [11:14] I guess you need to use 2a format to enable filtering? [11:15] 1.14 [11:15] (2a includes the new WT format too of course) [11:15] hmm [11:16] I setup some rules in ~/.bazaar/rules, but that didn't seem to do anything [11:16] and put a keyword in a test file [11:17] How are you checking that it does anything? [11:17] committing various changes to see if it updates the placeholder in the file with the revision info [11:17] That's one of the filter problems rearing its head. Commit will never update them (expand if they're collapsed, or update if they're already expanded) [11:18] If you make a new 'branch' of it, they'll be expanded there. [11:18] ah I see [11:18] With a branch igc has on LP, they'll be updated on 'pull' too. [11:18] Still not commit (or, I think, merge either) [11:18] yep you're right, branching expands the keyword fine [11:18] revert also won't touch 'em. [11:18] that's annoying [11:19] Well, that's why I say "yes it works" and "less than useful" in the same breath :) [11:19] I can see why :) [11:19] (and of course you can't test whether 'checkout' actually expands them either, since the default format doesn't include rules, and checkout still doesn't have a --format so you can tell it which WT format to use) [11:20] bah [11:20] is this a known issue or worth raising a ticket for on LP? [11:21] Well, there's bug 385879 [11:21] Launchpad bug 385879 in bzr "EOL filter only applied to files when first checked out" [High,In progress] https://launchpad.net/bugs/385879 [11:21] ah thanks [11:22] The title on that is slightly misleading, since it's really a filter bug, not an EOL (or keywords, for that matter) bug. [11:22] I'm guessinf the filter stuff is what's causing the expansion/collapsing problem though [11:49] is it correct that `bzr rm` without arguments does not throw error? [11:52] I'm pretty sure that goes through the tree and explicitly sets removed status for missing files. [11:53] ok [12:27] hello vila === Xavura is now known as Xavur[a] === Noldorin_ is now known as Noldorin === Xavur[a] is now known as Xavura [12:42] has anybody ever done a local/user install of bzr? [12:45] oh, nevermind, it's on the faq :) [12:45] hmmmpfr, except that I need gcc to compile and I don't have access to it.. [12:48] You don't *need* the gcc IIRC [12:49] it just makes things go faster if you can compile stuff [13:01] that's true [13:01] it is much better with it though [13:02] poolie1: just back from my lunch break ! [13:04] pqm seems to be jammed, i just asked on #is [13:16] hmm, appearantly renaming things is a quite pleasant operation on a memorytree, not so far for all the other things [13:18] jelmer: you got any example for stuff like recording rename+content_change in subvertpy, the svn api is still like a black box to me [13:18] ronny: Rename is a copy + delete, there is no separate operation for that [13:19] I'll see if I can update the example to do a simple content change [13:21] hmm, and i guess i'll have to invent something that records changes on one of my trees so i can do my own magic on each of the vcs's [13:26] ronny, updated example pushed [13:38] vxnick, fullermd: I really hope to take a look at the content filtering bugs this week or next [13:38]