#bzr 2008-07-01 <igc> morning <jml> with loom up-thread conflicts, do the *.THIS files refer to the lower of the two threads? <lifeless> jml: IIRC, yes. Its switched because we use symmetry to make the operation faster <jml> lifeless: ahh ok. how hard would it be to make them .UPPER and .LOWER, for example? <lifeless> jml: patches appreciated <lifeless> jml: (I don't know) <jml> or .<thread-name>, I guess. * igc breakfast <lifeless> poolie: ping <lifeless> http://bundlebuggy.aaronbentley.com/request/<1214359843.1536.41.camel@lifeless-64> <- I'm blocked on that; igc has commented but neither as tweak or resubmit <thumper> I use a shared repo with no trees <thumper> and use cbranch most of the time <thumper> however now I need to make a new checkout of someone else's branch <thumper> and I want to use --hardlink <thumper> what's the magic? <lifeless> EPARSE <thumper> checkout --lightweight --hardlink ??? <branch location> <thumper> lifeless: did the last bit help? <lifeless> thumper: is branch location on your local disk ? <thumper> yes <lifeless> uhm. I don't know that co --lightweight knows about hardlink <thumper> but the branch has no working tree <thumper> hm, ok <lifeless> then there is no point <thumper> I'll just use the lightweight <lifeless> can't hardlink to files that don't exist <lifeless> thumper: hardlink is only relevant for working trees, it doesn't hardlink history <thumper> I was hoping that there would be some magic where it could link to trunk if it knew the file was unchanged <lifeless> thumper: uhm <thumper> I have a working tree of trunk <lifeless> thumper: cp -al trunk foo; cd foo; bzr switch otherbranchname <thumper> bzr col it is (another alias :-) <thumper> ETOOMANYCMDS <igc> lifeless: I'm just wrapping up that review now. <lifeless> igc: thanks <igc> lifeless: there were some questions buried in my comments. Can you reply to those please? <lifeless> sure <poolie> lifeless: pong <lifeless> igc: done <lifeless> poolie: nvm, igc is here today :) <nandersson> What is the easiest way to see if plugin bzr-xmloutput is installed or not? Can I try something from the command line? bzr + ??? <Odd_Bloke> nandersson: bzr plugins <nandersson> Odd_Bloke, Thanks! I see bzr_xmloutput in the list! <Odd_Bloke> nandersson: No worries. <poolie> lifeless: he'll be away in the afternoon but i'm trying to do reviews today <nandersson> Am I able to checkout a bzr branch in Eclipse into my project? It seems that feature is not implemented <nandersson> I'm using BzrEclipse that is <lifeless> nandersson: you can, but its a bit weird, because of eclipse's project concept <lifeless> beuno: do you know the trick? <nandersson> lifeless, No, what's the trick? <poolie> just what is the limit on transferring revisions between rich root and other repositories? <nandersson> lifeless, I do it from the command line from within the project folder? <poolie> (referring to Marius's mail) <poolie> does it depend on the revision or is it blocked altogether? <lifeless> poolie: subtrees -> rich root is blocked on subtrees being used I think; rich root->plain is full blocked <lifeless> poolie: because we can't tell 'made here' from 'converted' <nandersson> In Eclipse I select "New Project" - "Bazaar" - "Branch as a new Project". In the next dialog I choose "Use existing branch location" but then the "next" button is greyed out and I can't go further. Is it a bug? Using Eclipse 3.4 and most recent BzrEclipse. <nandersson> Hrmm.... seems it work if I use "New branch"... *investigating* <igc> lifeless: That review is complete now - I've voted tweak fyi. The email should come through soon. <lifeless> igc: thanks very much <jelmer> spiv, Thanks for that memory analysis <spiv> jelmer: not a problem. I just wish I had a clear idea of what we can do about it... <jelmer> spiv: not just because of the bzr push analysis but also because it explains Python memory usage analysis a bit * spiv nods <spiv> Yeah, I learned a bit while doing it. <spiv> I'd like to be able to introspect CPython's memory management a bit more <spiv> It shouldn't be hard conceptually for CPython to tell me about all the arenas its allocated and what their stats are. <mwhudson> heh, the coloured diffs plugin for tbird does extremely strange things to that mail <spiv> mwhudson: heh. <mwhudson> spiv: have you trying compiling python --without-pymalloc ? <spiv> mwhudson: I haven't, and I don't want to :) <spiv> I think that is where I'm headed, though. <mwhudson> why not, it shouldn't be hard <spiv> (But not today, I have other things to do as well...) <spiv> Admittedly the last time I compiled Python was around 1.5.2. It's probably a little less icky than it was then. <spiv> But I don't really fancy tracking down random C extensions and things. <Peng> It's easy to compile it. The only problem is if you don't have all of its build deps installed, it'll lack readline, or bz2, etc. <mwhudson> spiv: it _really_ isn't hard <spiv> I'll probably be compiling it myself soon anyway, because I want to play with 2.6 <spiv> Anyway, why do you suggest --without-pymalloc? To see if the fragementation is better/worse? <mwhudson> yes <lifeless> spiv- apt-get source <lifeless> spiv: apt-get build-dep <spiv> lifeless: yep <spiv> mwhudson: Hmm, I'm not sure how that would help me, really <lifeless> spiv: it would let us file bugs <lifeless> :P <mwhudson> spiv: it would be data <spiv> I see. <spiv> Well, I have data. :P <mwhudson> spiv: i don't know that it would help with finding a solution necessarily * spiv nods * lifeless speeds up on the b+tree index <meuserj> Is there any way to have a remote repository which you CAN update the working files by pushing (or similar) to it? I have a project I need to work on which I don't have shell access and would like to be able to push to it to update it. <meuserj> well, repository is the wrong term.. branch I guess <Verterok> meuserj: maybe the bzr-upload plugin might be useful <meuserj> Verterok: ah, that looks perfect, thanks. <meuserj> quit <Verterok> bye meuserj <lifeless> poolie: ping <lifeless> (Pdb) print original_size <lifeless> 5308576 <lifeless> (Pdb) print len(contents) <lifeless> 2564096 <poolie> pong <beuno> mwhudson, poking at your dont-hold-branches branch now, while I pack <mwhudson> beuno: cool, i'm still working on it a bit <beuno> mwhudson, haven't looked into bzr.lru_cache, but does that cache automagically? <mwhudson> beuno: it's like a dict <mwhudson> that throws items out when it reaches a certain size <beuno> well, code looks good, and from the looks of it, this should reduce RAM consumption a bit. Let's give it a spin... <beuno> not a good start: <beuno> File "/home/beuno/bzr_devel/loggerhead.dont_hold_branches/loggerhead/apps/filesystem.py", line 48, in __call__ <beuno> cached = self.root.cache.get(path) <beuno> AttributeError: 'BranchesFromFileSystemRoot' object has no attribute 'cache'[A[A[A[A[AA[A[A[A[A <beuno> right, serve-branches hasn't been tweaked yet <mwhudson> beuno: try pulling maybe <mwhudson> ? <beuno> mwhudson, I'm on revno 191 * spiv -> lunch <mwhudson> hm <beuno> start-loggerhead works though <beuno> browsing the project has a small glitch: Exception: 'BranchWSGIApp' object has no attribute 'history' <lifeless> spiv: when you return, I'd like to chat memory with you <beuno> mwhudson, other than those two things, code looks sensible to me, and it *feels* faster, although I don't have any facts to back that up <mwhudson> i'm working on the browse view now <beuno> may be my head is working slower <thumper> AfC: ping <AfC> thumper: hello <mwhudson> oh argh i hate the browse view <mwhudson> beuno: try rev 194, just pushed <beuno> mwhudson, fixed both issues, can't find more :) <mwhudson> beuno: ok, now see if the code makes sense :) <mwhudson> (i guarantee config.py won't) <beuno> I'm curious on to how this affects memory usage. Where is Peng when you need him... <mwhudson> it should be a bit better i guess <mwhudson> not massively <Peng> He's watching TV. :) <beuno> ah, view_data_by_name is interesting... <mwhudson> beuno: that's one word for it <lifeless> oh <beuno> it's not bad, maybe with some docstring slapped on it explaining a bit of the logic would work <lifeless> that reminds me <lifeless> bzr-search_integration? <beuno> Peng, tv is bad for you :p <Peng> beuno: Yeah, I'm gonna die young. * Peng eats some potato chips. <beuno> lifeless, well, that's in a mergeable-ish state. I'm not sure mwhudson is in a reviable-ish state though :) <beuno> Peng, you dare devil.... <mwhudson> maybe <beuno> "reviewable-ish" state is probably what I meant, but since I'm already making up words... <beuno> mwhudson, if this fixes the problem with too many branches open, some explanation in config.py should be good enough, IMHO <mwhudson> beuno: ok, thanks * mwhudson writes some docstrings <beuno> maybe even try to get the guy with the 100% CPU bug to give it a spin <beuno> you know, make him break his server before you break LP :p <beuno> damn, still haven't started packing <lifeless> igc: the pb thing is tricky <lifeless> igc: passing it to the child - and each child will do 0..total <lifeless> for total == what the child has <igc> lifeless: yes, it's ugly <igc> not passing it the child means the pb only shows the progress of local revisions <igc> it's almost like you need to pass through an offset and total so the one pb can just keep stepping <lifeless> igc: also, get_sha1s - <lifeless> igc: its part of the overall 'VersionedFile is dead, long live VersionedFiles' <lifeless> igc: agreed on the pb thing - thats the sort of tweak that would work <igc> wrt no NEWS you mean? <lifeless> igc: yes <igc> ok <lifeless> igc: we can list every single method if wanted, but its essentially everything that broke in that space; highlighting get_sha1s isn't very useful IMO <igc> agreed <lifeless> cool <igc> my concern is always plugin authors <lifeless> happy for me to land this? <igc> yes <lifeless> wooo <igc> looking forward to it :-) <igc> lifeless: well done on this, being able to stack across formats will be pretty magic when it all comes together <lifeless> igc: it is :) <lifeless> igc: I've been playing with it <lifeless> igc: I'm pushing the latest shallow-branches loom too <igc> cool <lifeless> ok, with that done, I'm going to go write a parser/reader for BTreeIndex's <igc> lifeless: I'm heading off to the doctors soon for most the afternoon so I probably won't get much more reviewing done today sorry <lifeless> igc: thats cool; I'll sweet talk poolie <igc> lifeless: yep, I'm hoping poolie can keep you unblocked <lifeless> it is his job :) <lifeless> now, where is that plumbers friend <Peng> Eek, LH's memory usage is still going up a bit. <thumper> Peng: where are you looking? <beuno> Peng, even with mwhudson's new branch? :) <Peng> beuno: No, I haven't tried that. Want me to? <Peng> beuno: Should it be reasonably stable? And does serve-branches.py work? <beuno> Peng, https://code.edge.launchpad.net/~mwhudson/loggerhead/dont-hold-branches-open <beuno> Peng, "yes" and yes :) <mwhudson> Peng: yes, just pushed revision 195 <Peng> Those are some ominous quotation marks. :P <mwhudson> will probably merge to trunk soon <Peng> How soon? <mwhudson> in a few minutes <Peng> Oh. I'll wait then. <Peng> My Loggerhead setup uses a custom branch in ~/loggerhead, so I'm not sure how I'd try a different branch than trunk. <mwhudson> man, 1221 lines of diff <Peng> (And yes, it is a stupid reason not to try another branch, but I'm lazy. :D ) <lifeless> Peng: serve-branches ../differnet <lifeless> spiv: pingish (refreshing scrollback) <mwhudson> Peng: trunk revno 180 <mwhudson> it's landed <Peng> Okay. <mwhudson> Peng: when you said that the memory usage was going up, how much memory was it using? <Peng> mwhudson: It had gone from 101 to 102 MB. <mwhudson> Peng: oh <mwhudson> that's not especially exciting :) <Peng> I was surprised it hadn't stopped growing. <mwhudson> (given that it routinely uses upwards of a gig on launchpad, though that's old old code now) <Peng> Well, I'm on a 360 MB VPS, so it is concerning. :P <mwhudson> ok <Peng> Anyway, I'm using the latest trunk now. <mwhudson> do you know what revno you were on before? <Peng> The last one. <Peng> So, 179, I guess. <mwhudson> ok, so you had the streaming output <Peng> Yeah. <Peng> Streaming can't be used with compression, right? <Peng> Because that would really reduce bandwidth use.. <mwhudson> um, don't really see why not <lifeless> get apache to do it ? :) <lifeless> (because compression is a great way to break buggy browsers, and the apache modules have the workarounds well noted) <Peng> lifeless: I use lighttpd. 1.4 doesn't support compressing dynamic stuff, though 1.5 does. <lifeless> Peng: there you go then :) <lifeless> Peng: though, if they followed the spec, and didn't read mod_gzip etc from apache, expect problems :) <mwhudson> hm, it looks like paste.gzipper will stop the streaming from streaming indeed <Peng> lifeless: The only breakiness I know of is IE and CSS and JS? <Peng> Woah. <Peng> I'm still connected, right? <lifeless> Peng: ye <lifeless> s <Peng> I thought I wasn't. I was about to reconnect everything when it started working again... <spiv> lifeless: pong <lifeless> spiv: memory usage; would a new index with an LRU cache help much do you think? (can we talk voice?) <spiv> lifeless: perhaps (and yes) <lifeless> is that you? <spiv> it is <lifeless> handset out of juice <spiv> Ah. <spiv> skype? <lifeless> its a silly bug in the battery <lifeless> yes skye <igc> bbl <lifeless> poolie: chatted with spiv; the memory from reading existing indices was a significant thing. <lifeless> poolie: also - for my copy of python-in-bzr-packs: <lifeless> Original aggregate index size: 39016345 <lifeless> B+Tree aggregate index size: 7585936 <lifeless> Difference: 31430409 <lifeless> spiv: ^ <spiv> That's a huge improvement! <spiv> I hope the improvement in memory consumption is as good :) <lifeless> it will be different <lifeless> I'll need some pointers on string interning etc <mwhudson> wow <spiv> Interning strings is easy, at least. Just "intern(s)", it's a builtin. <spiv> Oh, rather "s = intern(s)" <lifeless> spiv: whats the overhead? (why isn't it the default) <spiv> It's the default for string literals that look like python identifiers. <mwhudson> the overhead is looking in and storing references in a big-ass global dictionary <spiv> But Python doesn't automatically check every str you read from disk to see if it is already intern'd. I assume the cost is roughly similar to checking a big dict. <lifeless> I'm a little concerned about the cost of running millions of keys through that <spiv> I am too, although from what I saw from my testing it wasn't a big cost. <spiv> It's definitely worth benchmarking it more carefully though. <spiv> The upside speed-wise is that string comparisons get slightly faster (s1 == s2 is quick if s1 and s2 are the same str, it's just a pointer comparison). <spiv> It wouldn't shock me at all if it was less of a win with B+Tree indices... <lifeless> spiv: an open question to think about is making index creation use less memory <spiv> Hmm, yeah. <beuno> mwhudson, I'm off to bed, have to catch a plain in a few hours. I'll probably be fairly unresponsive the next few days, especially on IRC, I may do better with email. Hopefully, long hours on the plane will get me to finish setup and directory-templates <mwhudson> beuno: ok, sounds good, sleep well <mwhudson> i'm stopping for the day too <mwhudson> (no internet at home yet, should get connected tomorrow) <beuno> mwhudson, ah, so we can expect less mwhudson_'ns? <mwhudson> we shall see <beuno> wish you luck with that :) <bob2> AttributeError: 'KnitPackRepository' object has no attribute 'weave_store' <bob2> ah, fixed already <lifeless> bob2: what plugin? <bob2> ah, search <lifeless> :) <bob2> (doesn't happen with 3515) <lifeless> bob2: 3515? <bob2> r of bzr.dev <lifeless> oh, revno of bzr.dev? VersionedFiles hath landed:) <bob2> ah, piffy <bob2> well, spiffy <lifeless> bob2: yes, massive API breaks R us * spiv ducks out for a bit <Peng> So far, I think the dont-cache thing improved Loggerhead's memory usage, but I can't really tell. <Peng> At the least, it sent back a 490 KB page and is using less than 22 MB of memory. <Peng> So the point of that branch was keeping branches open and stuff, but still, that surprised me. <catsclaw> Anyone around for a quick question? <catsclaw> Is anyone around for a quick question? <RAOF> catsclaw: Generally it's a better idea to ask the question. <catsclaw> I've never had much luck doing that. <RAOF> You've obviously been in the wrong chanels :) <catsclaw> At any rate, I'm hosted on Dreamhost and I'm trying to use Bazaar. <Peng> How unfortunate. <RAOF> I'm not familiar with dreamhost, but at worst you've got sftp access, right? <Peng> Yes. <catsclaw> Yes. But then I have to define shell access for every one of my users. <catsclaw> Correct? <Peng> Isn't it possible to restrict a user to sftp with no other ssh access? <bob2> yes <sabdfl> even better, use bzr+ssh, restricted <Peng> sabdfl: That would involve installing bzr on the server, which is more of a pain. <catsclaw> At the moment, all access is generated from a database, which dynamically writes an .htaccess file and the svn access file dynamically <catsclaw> I don't know of any way of doing the same with the ssh users and passwords <catsclaw> And because the ssh usernames have to be unique across the server, I couldn't have easy logins to the site. <catsclaw> Is there any way to share an ssh login, but keep the contributor's logins distinct? <Peng> With bzr, commit authors and ssh users are not related in any way. <catsclaw> Where do commit authors get set, and is that secure? <Peng> ~/.bazaar/bazaar.conf, or by running "bzr whoami" <Peng> And anyone can claim to be anything. <catsclaw> There's no way to include validation? <RAOF> Peng: And presumably the next statement is "but you can GPG sign your commits" :) <Peng> Oh, right. <bob2> are you using svn over ssh? <catsclaw> I'm planning on using sftp <Odd_Bloke> catsclaw: For SVN or for bzr? <catsclaw> bzr <Odd_Bloke> catsclaw: So what protocol are you using for svn? <bob2> must be raw svn:// or you'd have the same spoofing potential as with bzr <catsclaw> It's http <bob2> how usable is the bzr webdav thing? <catsclaw> Not, at the moment. It requires 1.6. <Odd_Bloke> I'm not sure, it's vila's thing (SUBTLE PING). <catsclaw> How do I uninstall a plugin, btw? <lifeless> catsclaw: reverse however you installed it <lifeless> catsclaw: if you used the plugins setup.py, it will have installed to python_lib_prefix/bzrlib/plugins/NAME <lifeless> catsclaw: but if you installed via apt, use apt to uninstall, if you installed by branching into ~/.bazaar/plugins/NAME, just remove NAME from there <catsclaw> I did a bzr branch command from lp <Peng> Where did you branch it to...? <catsclaw> I don't know. I was sitting in the Bazaar plugin directory, but it didn't put it there <vila> bob2: webdav is usable, the 1.6 requirement is a bit artificial, I haven't the resources to test it against 1.5 and nobody will care in a few weeks. I'm just trying to minimize my entropy :) <lifeless> catsclaw: if you ran 'bzr branch lp:FOO' then it made a basename(FOO) directory in the directory you were in <catsclaw> Well, it did it in such a way that it doesn't show up in explorer or a command line <lifeless> catsclaw: interesting :) <Odd_Bloke> catsclaw: 'bzr plugins -v' will tell you where it is, if it's affecting bzr. <drxnele> hi <catsclaw> not installing http[s]+webdav:// support (only supported for bzr 1.6 and above) <catsclaw> Unable to load u'bzr.webdav' in u'C:/Program Files/Bazaar/plugins' as a plugin b <catsclaw> ecause the file path isn't a valid module name; try renaming it to u'webdav'. <drxnele> can somebody help <Peng> drxnele: Not without knowing what you need help with. <drxnele> bzr push lp:~screenlets-extras-team/screenlets/screenlets-extras <drxnele> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Escreenlets-extras-team/screenlets/screenlets-extras/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() <Odd_Bloke> drxnele: 'bzr launchpad-login' <Peng> catsclaw: You should do that then. <catsclaw> C:\Program Files\Bazaar\plugins\webdav <catsclaw> Only the only thing listed there is Launchpad <drxnele> No Launchpad user ID configured. <drxnele> how to do this? <Odd_Bloke> drxnele: Sorry, I meant 'bzr launchpad-login <username>'. <drxnele> meny thanks <drxnele> it worked <catsclaw> I just deleted the plugins directory. I get the same error, and the same results from bzr plugins -v <bob2> vila: awesome <lifeless> catsclaw: run bzr --version <lifeless> catsclaw: it will tell you where the 'log file is' <lifeless> catsclaw: delete the log file, then run the command that is showing an error, then pastebin (e.g. to http://rafb.net/paste) the contents of the log, and the output bzr gave <Peng> You shouldn't have deleted that directory... <catsclaw> I can reinstall it <catsclaw> http://rafb.net/p/7tqMoL85.html <lifeless> catsclaw: so in C:/Program Files/Bazaar/plugins <catsclaw> Yes? <lifeless> catsclaw: you would appear to have a directory called 'bzr.webdav' <lifeless> catsclaw: and bzr is telling you to rename that to 'webdav' <lifeless> catsclaw: please do that, then try again <catsclaw> Which I would do, if I had a directory "C:\Program Files\Bazaar\plugins" <catsclaw> I don't. I deleted it. <Odd_Bloke> catsclaw: Are you on Vista, by any chance? <lifeless> catsclaw: [ 6096] 2008-07-01 01:51:29.979 WARNING: Unable to load u'bzr.webdav' in u'C:/Pr <lifeless> ogram Files/Bazaar/plugins' as a plugin because the file path isn't a valid modu <lifeless> le name; try renaming it to u'webdav'. <lifeless> catsclaw: that says that you do; please check :) <catsclaw> There wasn't a subdirectory except for "launchpad" there before, either <catsclaw> I am on Vista. <Odd_Bloke> Right, it does some screwy stuff in Program Files. <Odd_Bloke> All in the name of saving you from yourself, of course. <catsclaw> There is no subdirectory named "plugins" in the Bazaar directory. <Odd_Bloke> I'm not sure what to suggest, but I think you're right when you say you can't see anything and bzr is right when it says there is something there. <luks> well, try to search for bzr.webdav on your disk <luks> but first look to C:/Users/catsclaw/AppData/Roaming/bazaar/2.0/plugins <catsclaw> Directory of C:\Users\catsclaw\AppData\Local\VirtualStore\Program Files\Bazaar\plugins <catsclaw> 07/01/2008 01:05 AM <DIR> bzr.webdav <luks> so there is a bug in bzr, which reports incorrect directory <catsclaw> More to the point, when I ran the bzr branch command, why did it extract things to the VirtualStore? <catsclaw> And not the directory I was sitting in? And shouldn't bzr know about that, and warn you? <Odd_Bloke> bzr _should_ be told about it. <luks> I'm guessing it's Vista playig tricks on you <Odd_Bloke> Whether it actually is or not is another matter. <luks> bzr was probably not allowed to write to C:\Program Files or something like that <RAOF> It looks like bzr is triggering some of the "don't break permissions-ignorant code" workarounds in Vista <catsclaw> I'm sure that was it. <RAOF> So you need to do whatever the vista equivalent of "sudo bzr branch ..." is. Presumably it has one. <catsclaw> I can launch a cmd window as an administrator <lifeless> yay windows. <lifeless> catsclaw: sorry, I didn't realise just how much Vista gets in users way :) <catsclaw> But no point, since I can't use the webdav stuff without 1.6 <catsclaw> And if people can log in with different commit names under ssh, that works anyway <Odd_Bloke> vila: Is there the chance for subtle bugs if the webdav stuff is used with <1.6, or will any problems be glaringly obvious? <vila> Odd_Bloke: You tell me :-) <vila> seriously, I'm not aware of any potential problem <Odd_Bloke> Presumably it would be API mismatch, which'll ditch before anything could go wrong. <vila> event there, the only API I use that may cause problems with old versions is test related only, the transport API is pretty stable <vila> the last transport API break was requiring writable transport to implement list_dir and stat. This was the only reason I stop working on it for some months <vila> Now, that plugin has of course not been widely used, so file bugs, file bugs, file bugs :) <Odd_Bloke> catsclaw: You could try using the plugin with <1.6 if you want to. Just change the 'minor < 6' on line 31 of __init__.py to something lower. <Odd_Bloke> Of course, the SSH route is safer. :) <catsclaw> bzr: ERROR: Permission denied: "/.bzr": [Errno 13] Permission denied <catsclaw> That's when I try init-repo on the sftp site <catsclaw> Login works, though, and I can manually upload files <Odd_Bloke> catsclaw: Find the relevant part in bzr.log and that should help us out. <lifeless> catsclaw: when I see that its usually a virtual vs absolute path difference <lifeless> catsclaw: if you are doing 'bzr init-repo sftp://HOST/FOO', be aware that that is '/FOO' on the host, not '~/FOO' aka 'FOO' <lifeless> catsclaw: if you want 'the current directory' you need 'sftp://HOST/~/FOO' <catsclaw> Ah. Sure enough. <catsclaw> Final question tonight, I swear <lifeless> the more the merrier <catsclaw> There's nothing out there that allows you to edit bzr files from a web interface, is there? <catsclaw> Edit text files stored in a bzr repository, I mean. <Odd_Bloke> catsclaw: ikiwiki might do it. <Odd_Bloke> Wait, do I mean ikiwiki. *thinks* <Peng> catsclaw: There are lots of programs to edit files from a web interface, but committing them with bzr afterwards is another story... <catsclaw> Got any good ones to recommend? <Peng> Odd_Bloke: I'm not sure if ikiwiki can use bzr as a backend. <Peng> catsclaw: DreamHost has WebFTP set up. <Odd_Bloke> http://jameswestby.net/bzr/ikiwiki.bzr/trunk/ suggests that james_w has looked at it at some point. <lifeless> spiv, I have iter_all_entries workig <lifeless> spiv: is there a simple test to check memory impact? <spiv> lifeless: I included a simple script in my mail <spiv> lifeless: want me to pastebin it for you? <lifeless> you did? I'll grab it <Odd_Bloke> Actually, that just looks like a conversion of ikiwiki's history to bzr. <lifeless> spiv: (by simple I mean, no bzr needed :P) <Peng> Odd_Bloke: I think I heard that bzr doesn't support one of the hooks ikiwiki sues. <spiv> Or, just bzr push bzr.dev into /tmp and watch top ;) <Peng> Odd_Bloke: That may have changed, of course. <lifeless> spiv: I don't have a repo format using this <lifeless> spiv: that needs iter_entries working <lifeless> spiv: and possibly iter_entries_prefix <spiv> Fair enough. So, search my email for iter_all_entries <Odd_Bloke> Peng: http://ikiwiki.info/rcs/bzr/ <aantn> hello <Odd_Bloke> aantn: Hi. <aantn> is it possible to uncommit one specific revision after other revisions have been made <aantn> hey Odd_Bloke <Odd_Bloke> aantn: Do you want to remove it from history, or just undo the changes it made? <aantn> Odd_Bloke: remove it from the histroy <aantn> it has an incorrect commit log :-[ <catsclaw> Ok. I gotta jet. <catsclaw> Thanks for the help. I'll have more later, have no doubt. <Peng> aantn: How incorrect? Most people learn to live with typos.. <aantn> Peng: I forgot to add files, so it picked up on a tiny minor change and missed the big change <aantn> Peng: another developer ended up committing the big change <lifeless> spiv: 117M vss, 58M res <hsn_> anybody knows if bzr is installed on sf.net shell server? <lifeless> spiv: http://rafb.net/p/zCpYDb71.html <lifeless> spiv: thats for my bzr.dev's indices converted <lifeless> spiv: robertc@lifeless-64:~/source/baz/integration$ du -sh --apparent /tmp/fo/ <lifeless> 5.5M /tmp/fo/ <spiv> lifeless: interesting, that's vs. 61M res I get with bzr.dev and my original script. <spiv> Although your vss is much higher. But you have a 64-bit system, I think? So the comparison isn't 100% fair. <lifeless> spiv: I do <lifeless> spiv: lets get a baseline <spiv> That suggests your new stuff is a bit better, though. That's a promising sign. <spiv> Hmm, also your vss is double mine, which seems odd. <lifeless> spiv: 16474 robertc 20 0 72804 11m 2800 S 0 0.6 0:00.20 python <lifeless> spiv: thats before any indices are processed <spiv> Ok, so the oddness is someone else's fault :) <lifeless> 16474 robertc 20 0 117m 58m 2864 S 0 2.9 0:02.56 python <lifeless> and thats after it finishes <lifeless> now, the largest index is 2.5MB <lifeless> and readv() does some interesting data slicing <lifeless> oh, hmm, lets gc() too <lifeless> 16565 robertc 20 0 117m 58m 2864 S 0 2.9 0:02.62 python <lifeless> so, gc isn't freeing anything :) <spiv> Yeah, I'd be a little surprised if you had reference cycles. <spiv> Worth being careful with our measurements, though. <lifeless> spiv: http://rafb.net/p/iDf7SP71.html <spiv> So, what do you get on your system with my script (i.e. the current index format)? <lifeless> spiv: thats what I've ended up with <spiv> That script consumes memory? It looks like it should be freeing everything before the final raw_input <lifeless> spiv: thats right <lifeless> spiv: strange huh <spiv> Very. <lifeless> 16825 robertc 20 0 91764 18m 2980 S 0 0.9 0:00.56 python <lifeless> using bzr.dev <lifeless> your script (well, nearly) <lifeless> I'm buggered if I know where its going <spiv> Try my countrefs hack? (http://twistedmatrix.com/users/spiv/countrefs.py) Getting the counts before and after might tell you something. <lifeless> 16984 robertc 20 0 74368 13m 2860 S 48 0.7 0:03.74 python <lifeless> for item in index.iter_all_entries(): <lifeless> pass <lifeless> that tells me all I need to know :P <spiv> Heh. <lifeless> fragmentation anyone ? <lifeless> seriously, I think I'm better off getting this code out there in a repo format for you to try <spiv> Yeah, I'd like that. <lifeless> I wanted to see if it was potentially useful :) <hsn_> any work in progress on making commited log messages editable by other commits? <berto-> jelmer: hello. <lifeless> spiv: I'd be interested if chewing rather than listing the iterators affects your results <lifeless> spiv: also, going down to the _indices attribute and doing each one might also be useful <lifeless> hmm, 12 second test case. not good <berto-> jelmer: i figured out my compilation issues on OS X. it had to do with having MacPython installed on my system. Once I cleaned that up, running make worked just fine. I also updated the OS X instructions: http://bazaar-vcs.org/BzrForeignBranches/Subversion#mac-os-x <berto-> is bzrsvn a good way to migrate over to bzr? i noticed that bzrsvn uses SvnRepository; how different is that from the standard Bzr repository? <gour> berto-: have you tried tailor? <berto-> gour: no, what's that? <gour> berto-: kind of universal migration tool <Peng> berto-: bzr-svn stores the data in a regular rich-root-pack repository; I'd think SvnRepository is just how it communicates with the svn server. <luks> berto-: bzr-svn uses SvnRepository only if you want a checkout <berto-> thanks, everyone. <Peng> Also, I dislike Tailor. <gour> why? <Peng> I only used it once, to convert from bzr to hg, and the result was a bit messy. <Peng> Also, it might be a "jack of all trades, master of none" thing. <berto-> more general, if i wanted to put a bunch of related codebases in a single bzr repository how would i go about doign that? for example, i'm now converting an svn repo with bzrsvn, can i bzr init-repo and somehow move the contents over? <gour> i found the recent version as the only tool able to migrate from darcs <Peng> berto-: I think you have to "bzr branch" into the new repo. <Peng> berto-: Note that all a shared repository is is a data storage optimization; it has no other meaning. <berto-> Peng: because it keeps one copy of common stuff between branches, right? <gour> berto-: right <berto-> ok, cool. i think i get it. :) <berto-> tailor may help me get stuff out of git. <Peng> berto-: You should check out bzr-fastimport for git (and hg). <berto-> peng: cool, checking it out. <gour> berto-: pick latest tailor if possible, it improved in many ways <Peng> berto-: (I'm not sure how production-ready it is, but in any case, it might work, and it's good stuff.) <LarstiQ> vcs-fast{export,import} seems to be the way of the future <gour> LarstiQ: with darcs, my experience of darcs-fast was darcs-SLOW-and-broken and that's why i used tailor <gour> see https://bugs.launchpad.net/bzr-fastimport/+bug/232177 <ubottu> Launchpad bug 232177 in bzr-fastimport "Better darcs support needed" [Undecided,New] <LarstiQ> gour: future, because things might not be there overall. The tailor author has lots of darcs experience, so I expect that to be rather good indeed. <gour> ymmv, though <LarstiQ> gour: interesting <Peng> Yeah, Tailor seems to be good for Darcs. <berto-> awesome, just got django via bzr. :) <berto-> finally got this working. took me forever to track down problems on my system <berto-> nite, all <lifeless> ok, b+tree querying up and running <lifeless> now for a repository format to use it <lifeless> spiv: ^ pushed too <jelmer> lifeless, ping? <lifeless> hi <lifeless> lp:~lifeless/+junk/bzr-index2 <lifeless> toy^ play ^ enjoy <jelmer> lifeless, I've implemented item_keys_introduced_by() <lifeless> jelmer: cool <jelmer> lifeless, what branch of bzr-index should I try on a svn repo? <lifeless> jelmer: bzr-search; trunk <lifeless> jelmer: look for commits_only = True <lifeless> jelmer: change it to False, and it will try for texts <jelmer> lifeless: Hmm, bzr-index triggers svn to return new and interesting errors <lifeless> jelmer: :) <jelmer> visik7, ping <weigon> how do I convert svn-tags into bzr-tags ? <visik7> yes ? <jelmer> visik7: Any chance you can try the branch from django again with the latest version of bzr-svn? <jelmer> visik7: No hurry, I'm just wondering what is causing the breakage for you <jelmer> visik7: Can't reproduce it here, so it's pretty hard for me to fix those two bugs atm :-/ <visik7> jelmer: I should upgrade bzr too latest bzr-svn doesn't work with 1.5 <jelmer> visik7: ah, yeah <jelmer> weigon: How do you mean? After importing a svn repository using bzr-svn? <weigon> yep <visik7> actually I'm not setuped to keep bzr from bzr :) <weigon> I would like to get rid of the tags/ folder afterwards and use bzr-tags instead <jelmer> lifeless: bzr index completed >-) <weigon> this shall be a one-time operation, the svn tree will be abonded afterwards <jelmer> weigon: I believe somebody wrote a script to do that <jelmer> weigon: Something like this should also do it: <lifeless> jelmer: cool <lifeless> jelmer: I shall remove the hack then tomorrow <jelmer> lifeless: It was slow, but not unbearable <jelmer> (290 seconds for gnome-specimen) <lifeless> jelmer: bling bling <jelmer> visik7, :-) <weigon> jelmer: after branching from svn into bzr, applying the bzr-tags, removing tags/ and branches/ it makes sense to move trunk/ one level done into the basedir of the repo (like bzr move trunk/* .), right ? <jelmer> weigon: Sure, though you wouldn't use "bzr mv" for that (since the root of the repository is not a branch) <jelmer> lifeless: Now we only need tracker integration >-) <lifeless> jelmer: I looked at that <lifeless> jelmer: I'm not sure its a good fit. But openchange could use a search engine :P <lifeless> jelmer: also, new index layer, half-size indices for bzr; will probably make bzr-search much snappier <weigon> jelmer: you lost me: isn't $ bzr branch svn+ssh://.../ creating _one_ repo with 3 folders (tags/, branches/, trunk/) is in SVN ? <weigon> or are they already in shared-repo with 3 different repos ? <jelmer> weigon: You would use bzr branch on the trunk/ URL rather than on the repository <uws> jelmer: heh. it seems gnome-specimen has become a bzr/svn playground for a bunch of people :) <jelmer> weigon: "bzr svn-import" will import a repository (and create separate bzr branches for trunk, branches/*, tags/*) <weigon> *doh* thanks <weigon> that's what I was missing <jelmer> uws: yeah :-) It's a nice fit for testing since it's not too big but contains some regular and some bzr-svn commits <jelmer> weigon: I'll see if I can add a warning <jelmer> lifeless; 9-: <jelmer> s/9/( <jelmer> lifeless: So, now that I have this index, how do I use it? <lifeless> jelmer: 'bzr search' <jelmer> lifeless: I indexed a remote URL <lifeless> jelmer: or fire up loggerhead on this branch and then type in the search field (using a bzr-search integrated loggerhead of course) <lifeless> jelmer: you did something like: <lifeless> svn co foo bar <lifeless> cd bar <lifeless> bzr index <lifeless> right ? <jelmer> no, I did "bzr index svn://svn.gnome.org/svn/gnome-specimen/trunk" <lifeless> jelmer: ok, its probably indexed in ~/.bazaar/bzr-search/svn-lookaside/UUID <lifeless> jelmer: which is cool, I so didn't expect that to work :P <lifeless> jelmer: do a svn co of trunk <lifeless> jelmer: cd to it <lifeless> and do 'bzr search foo' <sabdfl> lifeless: where's the trunk of the search plugin? <jelmer> lifeless: Too late, I already started working on "bzr search -d" :-P <lifeless> sabdfl: lp:bzr-search <lifeless> sabdfl: (where else ? :) <sabdfl> it was the "bzr-search" bit I was looking for <lifeless> sabdfl: ah <sabdfl> we need bzr branch lp:+search/"bzr search plugin" ;-) <lifeless> sabdfl: that would be fun <lifeless> sabdfl: if you want something really shiny, run bzr index on launchpad <lifeless> sabdfl: then run beuno's bzr-search integrated loggerhead locally <lifeless> lp:~beuno/loggerhead/bzr-search_integration <lifeless> it needs python-simpletal, python-paste and python-sqlite installed <sabdfl> lifeless: it blows up on bzr.dec <sabdfl> v <lifeless> the serve-branches.py script is now used to run it - just give it the path to a branch <lifeless> sabdfl: indexing bzr.dev? <sabdfl> yes <lifeless> sabdfl: let me try <lifeless> sabdfl: are you running bzr.dev? or 1.6b2 ? <lifeless> beuno: btw, loggerhead is definitely returning bogus revisions in searches still; we need to track that down <lifeless> sabdfl: if you are running bzr 1.6b2, use lp:~lifeless/bzr-search/pre-1.6 instead <lifeless> its 50% through indexing bzr.dev from scratch for me, no errors <jelmer> lifeless: -d patch sent <lifeless> jelmer: ! nice. (With test?) <jelmer> lifeless: of course (-: <lifeless> sabdfl: yeah, I think you are running bzr 1.6b2, I had no trouble indexing bzr.dev <lifeless> sabdfl: let me know how you go, I'm crashing soon as this test completes; midnight! <sabdfl> lifeless: ./bzr index worked in bzr.dev <lifeless> sabdfl: ok cool <jelmer> lifeless: lp:~jelmer/bzr-search/debian <lifeless> jelmer: mail me I'm halt()ing <lifeless> gnight all <jelmer> lifeless: will do <jelmer> lifeless, goodnight <weigon> jelmer: the svn-import did the trick <liminal> Hi, I'm having problems with svn-push: it gives me a C++ assertion error. Can anyone help me? <liminal> Would the mailing list be a better place to get advice for this issue? <LarstiQ> liminal: did you check the bzr-svn buglisting? <liminal> I hadn't... just did a search for 'svn-push' and it doesn't seem to turn up anything <jelmer> liminal: Please file a bug <liminal> sure. in the meantime is there any other way to get a repo into svn? <jelmer> liminal: Probably easiest to see first if we can fix this bug <jelmer> Once you file the bug, I'll see how hard it would be to fix <liminal> ok, thanks. Should I let you know the bug # or anything? <jelmer> liminal, yeah, please paste it here <liminal> jelmer, the bug # is 244583 -- thanks <jelmer> bug 244583 <ubottu> Launchpad bug 244583 in bzr "Svn-Push Assertion Error" [Undecided,New] https://launchpad.net/bugs/244583 <jelmer> liminal, what version of bzr-svn is this? <liminal> http://d5190871.u44.websitesource.net/bzr-svn/bzr-svn-0.4.10-svn-1.4.6-setup-0.exe <jelmer> liminal: Ah, Windows.. <jelmer> liminal: Do you have a build environment available? If so, you may want to try the latest bzr-svn <jelmer> which no longer uses the patched Python subversion bindings <jelmer> I can't find that assertion that's being triggered in my copy of bzr-svn - it looks like yours has been patched <jelmer> s/bzr-svn/subversion/ <liminal> do you mean the development version of bzr-svn? on the project page it lists 0.4.10 as the latest <jelmer> liminal, yeah, the development version <liminal> I used the precompiled installer because all the instructions for deploying from source seem to assume running from linux <jelmer> yeah, compiling on windows may be a bit of a hassle <jelmer> It'd be happy to help get it to work (also so the instructions for building on windows can be updated) <liminal> ok, thanks for taking a look. It seems that this won't be simple to address. I'll work around this instead (commit latest version to svn and keep the current bzr repo in case I need past history) <liminal> thanks for the offer, but a colleague just came in and we need to focus on other stuff. Thanks again. <jelmer> k <liminal> jelmer, I saw your comment about adding a backtrace to my bug. How would I do that? <mrevell> james_w: Hi are you around> <james_w> hey mrevell <mrevell> james_w: unping, sorry :) <james_w> no problem <awilkins> Verterok: <guilhembi|pause> jam: hello! could you please post a progress note in support issue 2413? <jam> guilhembi|pause: I'm having the guys test some win32 installers right now <jam> Found a weird issue with a system lib getting bundled in the installer <jam> I can post that to tracker if you want <jam> I was waiting for them to give the "all clear" and post then <Verterok> awilkins: hi <awilkins> Verterok: Hi, I was going to discuss this SaveableEditorInput thing with you ; I'm going to see how Subversive does it first though <Verterok> awilkins: Ok that would be great, I looked a bit how subclipse is doing it. <awilkins> Verterok: Good to cover the bases :-) <Verterok> :) <Verterok> awilkins: it's ok if we start with this in a while, I'm not 100% available right now :( , maybe in a hour? <awilkins> Verterok: Sure, no problem <Verterok> awilkins: cool, thanks :D <tolstoy> Anyone have any docs on bzr_access? I can't figure out if it's supposed to be used on the client side, or the server side. <james_w> tolstoy: server side <james_w> it's supposed to go as the command in the authorized_keys file on the server. <tolstoy> james_w: Hm. Okay. I think I get you. I'll try that out. <mkanat> mwhudson: I updated to tip, it's going fine so far. <mwhudson> mkanat: awesome <mkanat> mwhudson: I saw that you fixed webpath, too, and that seems to be working well. <mwhudson> oh yes <mwhudson> mkanat: the 100% cpu thing is still odd, i'd like to understand it <mwhudson> but if it's stopped happening, good enough for me <mwhudson> mkanat: is your loggerhead accessing some of the branches it's viewing over http? <mkanat> mwhudson: Nope. <mkanat> They're all local. <mkanat> mwhudson: Well, I'm not entirely sure it's stopped. :-) <mwhudson> heh, ok <mkanat> mwhudson: I just upgraded recently, we'll see how it goes. <mwhudson> please let me know either way <mwhudson> how's memory usage? <mkanat> Using 300m RES right now. <mkanat> Which seems better for its uptime. <mwhudson> good good <Peng> Hmm, no-op pulls over bzr+http are a definite improvement. It's about a dozen <85 byte requests (not counting headers), vs. a couple hundred KB of index requests. <mwhudson> oh, beuno is travelling isn't he <bartt> Any advise/pointers for using bzr as a local client to CVS? I'd like to use bzr as a 2 way client to a CVS repository. bzr then allows me to branch locally, experiment and merge back when ready to commit to CVS. * mwhudson points at launchpad's code browsing, now running trunk loggerhead <mwhudson> bartt: i'm not aware of anything like that <Peng> It's running both trunk bzr and Loggerhead? Spiffy. <mwhudson> Peng: well, it's not quite trunk bzr, it's r3508 <Peng> mwhudson: That's the trunk, just not the very latest. <mwhudson> Peng: i guess so yes <lifeless> moin <berto-> hello. i'm trying to build bzr-svn on a debian etch box using python2.4; i'm getting this error: http://paste.pocoo.org/show/78310/ any thoughts? <lifeless> which branch of bzr-svn are you trying to build ? <lifeless> berto-: I would unset your CFLAGS <jelmer> berto-: looks like 2.4 doesn't have Py_ssize_t <jelmer> I've added a typedef for it <jelmer> berto-, should work if you pull current 0.4 <berto-> jelmer: that did it, thanks! <berto-> jelmer: not sure if you saw my message to you last night; i got things working on os x and updated the bzrsvn wiki to reflect the new stuff. <jelmer> berto-: Ah, nice - thanks! <awilkins> jelmer : You appear to have traded spaces for tabs on your indents <jelmer> awilkins: yeah, in the c files <berto-> jelmer: in commit.py, line 716; is that py2.5 syntax ? <jelmer> probably * jelmer fixes <berto-> jelmer: i can do that one ... <berto-> jelmer: how do i send you a patch? <jelmer> berto-: bzr send <0.4-url> <awilkins> jelmer: Bah, you haven't changed that C99 syntax <jelmer> awilkins: no, sorry - havent had time for that yet <awilkins> jelmer: Is there a simple way of changing it that a C-idiot can grasp? <jelmer> awilkins: Yeah, I think so <jelmer> awilkins: emily84@example.com in the python development files <jelmer> PyTypeObject is defined there <jelmer> With C99 it's possible to assign a struct member using ".tp_<name> = foo," <jelmer> without C99, the members have to be specified in the right order <jelmer> (preferably one on each line, with a comment at the end of the line with the name, to keep things maintainable) <jelmer> I can convert an example one, if that helps <awilkins> jelmer: So this is the struct ending on line 345 of object.h? <jelmer> awilkins, yep <awilkins> jelmer: Do you need all the members or just the ones you are using? <berto-> jelmer: sorry, i'm *very* new to bzr. i get this: bzr: ERROR: No mail-to address specified <berto-> bzr send <berto-> Using saved location: http://people.samba.org/bzr/jelmer/bzr-svn/stable/ <awilkins> berto-: bzr send [target] --mail-to <jelmer> berto-: Please try again <jelmer> berto-: I forgot I removed the child_submit_to setting <jelmer> schierbeck, ! <schierbeck> jelmer! <schierbeck> hi :) <jelmer> awilkins: All members up to the last one we need to set explicitly <jelmer> awilkins: The members in between need to be set to 0 or NULL (depending on their type) <berto-> jelmer: ok, that worked. so you changed something on the server side, eh? where is child_submit_to set? <awilkins> pointers NULL, ints 0 <awilkins> Righto (blech). <jelmer> awilkins: yep, exactly <jelmer> schierbeck, hi (-: <jelmer> berto-: child_submit_to is set in .bzr/branch/branch.conf on the server side <berto-> ok, cool. <awilkins> jelmer: Some of these members sound like they need poitners but they are not declared with * <schierbeck> jelmer: i see you've been busy working on bzr-gtk -- nice! <lifeless> garh, needing too many keys for this test :( <schierbeck> i've been way too busy at work recently <awilkins> eg descrgetfunc tp_descr_get : 0 or NULL ? <jelmer> awilkins: yeah, the various things ending in func would be NULL <jelmer> the compiler will probably warn you as well if you try to assign 0 to a pointer or NULL to an integer <awilkins> Righto, off we go. <jelmer> schierbeck: yeah, among other things your signature work is enabled again now <schierbeck> jelmer: nice :) <schierbeck> although it doesn't seem to detect seahorse at all right now <schierbeck> perhaps an issue with dbus activation? <jelmer> schierbeck: yeah, I have to comment out the "if BUS_NAME not in bus_names:" bit <jelmer> otherwise it doesn't get activated <jelmer> that line only seems to work if seahorse already was triggered by some process <schierbeck> jelmer: i'm not sure what the canonical (hehe) way to do it is <vadi2> How does one break a lock when bzr break-lock fails? we messed up our branch a bit and now can't access it: http://pastebin.com/m2480833e <schierbeck> jelmer: we've been through quite a bit of different approaches... <jelmer> schierbeck: yeah... <berto-> found another py2.4 incompatibility; just used bzr send again. <mcrael> vadi2: I am having trouble breaking a lock also. I hope someone here can point us in a good direction. <jelmer> berto-: did you send an email earlier? I haven't received anything yet <jelmer> schierbeck: sanest approach would probably be to just try to use seahorse and catch the possible exceptions that indicate it wasn't found <berto-> jelmer: thought so: just ran "bzr send" and figured that had some magic. <berto-> is there a file i need attach to an email somewhere? <schierbeck> jelmer: yup, think that's best <jelmer> berto-: bzr send should take care of sending the email for you <jelmer> and launch an email client, etc <berto-> hmm, might be the mail server on the machine i'm using ... 1 sec. <berto-> is there a way to have bzr send just give me a file i can attach? <jelmer> yeah, "bzr send -o <filename>" <berto-> boo, relaying denied. <berto-> ok, 1 sec. <vadi2> ï»¿mcrael: I think I'll just delete branch and make it again in my case, since it's a relatively new one <mcrael> vadi2: I may have to do the same. <berto-> jelmer: sent. <jelmer> mcrael/vadi2: try "bzr break-lock lp:~gufw-developers/gui-ufw/0.0.6" <jelmer> berto-, thanks <berto-> np. let me know if there is some naming convention you usually use. <vadi2> ï»¿jelmer, already remade the branch, but thanks for the reply <jelmer> berto-, Still nothing received.. <schierbeck> jelmer: i'm off to bed, g'night <jelmer> schierbeck: ok, see you later <berto-> jelmer: that's odd; jelmer-at-samba.org ? <jelmer> yep <jelmer> never mind <jelmer> looks like it was just slow <jelmer> berto-, thanks, merged! <berto-> how do i get the bzrsvn manual? just tried bzr help svn but that doesn't give me much. <lifeless> jelmer: ^ :P <jelmer> berto-: see the FAQ <lifeless> berto-: I believe much/all of it is on the wiki <lifeless> jelmer: do you see my point about people trying the inline help system <jelmer> lifeless: yes, I do get your point <jelmer> I just don't want to add a verbatim copy of the current files in the py files <lifeless> jelmer: sure, I got that <berto-> so getting my changes into the svn repo is just a matter of using "bzr push"? <jelmer> berto-: if you're pushing a new branch that isn't in svn yet, "bzr svn-push" <berto-> no just changes to trunk, so that should work, i suppose. <jelmer> yep <berto-> jelmer:
{'channel': 'bzr', 'month': 7}