[12:02] <lifeless> abentley: IIRC it was pournelle and ??? in 'The mote in gods eye'
[12:02] <Lo-lan-do> lapthrick:     AddHandler None .knit .kndx
[12:02] <lifeless> the gripping hand was the big overdeveloped arm, not the fine-tuned hand
[12:02] <lifeless> oh yes, they did a book called that too
[12:02] <lapthrick> Lo-lan-do: .htaccess by default is valid for all subdirs unless overrided, right?
[12:03] <abentley> Yeah, Pournelle/Niven, but I think the "on one hand, on the other hand, on the gripping hand" phrase came from the sequel, "The Gripping Hand"
[12:03] <Lo-lan-do> Right
[12:03] <abentley> Anyhow, I'll look the patch over now.
[12:04] <lifeless> abentley: could be, I don't think I've read the sequel
[12:09] <Lo-lan-do> jelmer: I pushed my gateway branch to http://alioth.debian.org/~lolando/bzr/gforge/upstram-svn/trunk -- it contains the stuff that I'm trying to push to SVN
[12:11] <Lo-lan-do> I'm off to bed for now, but I'll be available in the next few days to provide info if needed.
[12:12] <Lo-lan-do> Thanks already for the time you spend on my bugs :-)
[12:14] <radix> abentley: Do you mean Haruki, Ryu, or Takashi? :)
[12:14] <abentley> Heh, Haruki.
[12:14] <radix> (the first three Murakamis that have written books that I can think of)
[12:15] <radix> ok yeah, figured ;-)
[12:15] <radix> funnily enough, they're all flaming postmodernists
[12:15] <abentley> I also read this blog about SCO by Jones.
[12:19] <radix> that's probably not postmodern :)
[12:22] <abentley> radix: No, but SCO is a significant author of speculative fiction.
[12:22] <radix> haha
[01:03] <lapthrick> is there some more documentation on bugs metadata in bzr?
[01:03] <lapthrick> help bugs isn't very verbose
[01:07] <lifeless> there is a document in the docs
[01:07] <lifeless> doc.bazaar-vcs.org/bzr.dev/en/
[01:08] <lapthrick> thanks
[01:10] <lapthrick> is the immutability inherent in the design, or just something to be implemented?
[01:10] <lifeless> what do you mean
[01:11] <lapthrick> lifeless: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/bug_trackers.html , section Limitations
[01:11] <lapthrick> is that limitation supposed to be removed?
[01:12] <lifeless> not in the short term
[01:12] <lifeless> the reason its immutable is that its part of the commit
[01:12] <lifeless> so changing it would involve changing the commit, which is part of history
[01:13] <lifeless> one can imagine a more complicated system where later commits can 'revert' things, but that hasn't been really designed or discussed at this point
[01:14] <lapthrick> lifeless: I see, I was reading http://bazaar-vcs.org/Specs/RevisionBugMetadata
[01:14] <lapthrick> which indeed does discuss that :)
[01:14] <lifeless> well
[01:15] <lifeless> in terms of concrete goals
[01:15] <lifeless> there are no patchs, nor folk hacking on, the more complicated sorts of things
[01:15] <lifeless> so far no one has needed them
[01:17] <lapthrick> aha
[01:41] <lifeless> igc: call ?
[01:41] <igc> yep - 10 mins
[01:57] <igc> lifeless: you at home?
[02:30] <abentley> lifeless: I don't think _apply_delta is unused.  I think the reason nothing else needed to be changed is that static methods can be invoked on instances as well as on classes.
[02:33] <lifeless> abentley: true enough, still leaves it as a no-op change though
[02:33] <lifeless> robertc@lifeless-64:~/source/baz/test-repos/mozilla$ time ~/source/baz/repository/bzr commit -m 'commit' --unchanged -q
[02:33] <lifeless> 
[02:33] <lifeless> real    0m58.889s
[02:33] <lifeless> user    0m50.591s
[02:33] <lifeless> sys     0m3.640s
[02:33] <lifeless> robertc@lifeless-64:~/source/baz/test-repos/mozilla$ time ~/source/baz/repository/bzr commit -m 'commit' --unchanged -q a
[02:34] <lifeless> 
[02:34] <lifeless> real    0m27.626s
[02:34] <lifeless> user    0m25.538s
[02:34] <lifeless> sys     0m1.504s
[02:34] <lifeless> 25 seconds to *just* do the overhead of a commit for a single file.
[02:34] <lifeless> I'm going to target this for a bit
[02:34] <abentley> It does remove the artificial requirement for a knit instance.
[02:34] <igc> lifeless: adding staticmethod is a good change iff semantically it has nothing to do with the current object
[02:35] <igc> that's certainly the case in terms of the implementation fwiw
[02:35] <lifeless> abentley: this is true, but it also makes it unvariable when you have a knit. I think moving it closer to the users would make sense.
[02:35] <lifeless> rather than just bit-twiddling
[02:36] <lifeless> I mean, applying a delta would seem to be be related to the delta representation
[02:36] <lifeless> and/or the content representation
[02:37] <abentley> How do you mean unvariable?
[02:37] <lifeless> well object methods are mainly to allow code to vary based on the content of the object
[02:38] <lifeless> if this method has no dependencies *in principle* on the content of the object, then its probably on the wrong object
[02:38] <abentley> I'm with you there.
[02:39] <igc> so the params are lines and delta ...
[02:39] <igc> it operates on lines and returns lines
[02:39] <lifeless> igc: if delta is returned by another method on the VersionedFile, then delta is linked to the VersionedFile
[02:39] <lifeless> igc: so its not clear from this level of discussion that there is no connection
[02:40] <lifeless> anyhow, I've said my bit
[02:41] <abentley> lifeless: But it's trivial to imagine an implementation of iter_file_versions directly on top of packs, using knit deltas.  And that would clearly have no need for a versionedfile of any kind.
[02:41] <lifeless> abentley: I agree. However it could sensibly use a KnitData instance
[02:42] <lifeless> there is delta assembly too
[02:42] <lifeless> so being able to use a single KnitSomeThing instance to manage that implementation would be good
[02:42] <lifeless> something that takes (fileid, revisionid) keys and uses the index directly without the mapping thunk layer
[02:43] <abentley> Yep, we're agreed there.
[02:44] <thumper> lifeless: know where poolie is?
[02:44] <lifeless> thumper: yes
[02:44] <abentley> I think the reason we don't have something like that already is that knit deltas are not objects.
[02:44] <lifeless> abentley: well there is KnitData/KnitContent.
[02:45] <lifeless> abentley: I'm not sure that individual delta objects are the problem
[02:45] <lifeless> its more that the delta application stuff was conflated with storage.
[02:45] <lifeless> KnitData vs KnitAccess has fixed that
[02:45] <thumper> lifeless: sometimes you remind me of a friend in the UK (never answered the implied question)
[02:46] <lifeless> thumper: I'm proud to remind you of a friend :)
[02:46] <lifeless> thumper: oh, and merf says hello
[02:46] <thumper> merf who?
[02:46] <lifeless> michael murphy
[02:46] <lifeless> from uni
[02:47] <abentley> KnitData looks more akin to ContainerReader.  KnitContent looks plausible.
[02:47] <thumper> lifeless: ah, where is he now?
[02:47] <lifeless> Sydney
[02:47] <thumper> doing?
[02:47] <lifeless> we had Jason's bucks night last weekend
[02:47] <thumper> cool
[02:48] <thumper> it go well?
[02:48] <lifeless> oh, hes running something in the money market space for commbank
[02:48] <lifeless> yah
[02:48] <igc> abentley: so is moving _apply_delta into knit.py (and out of versionedfile.py) agreed as an improvement?
[02:48] <spiv> lifeless: I think that qeebo revision of yours is definitely strange.
[02:48] <lifeless> don't have a sound-bite label for it unfortunately, but he's happy and it sounds fun and interesting
[02:48] <spiv> lifeless: In that the second parent does seem to be in the ancestry of the first parent.
[02:49] <lifeless> spiv: yah. Want to be a cherrypick merge will do that
[02:49] <abentley> igc: If we are talking about the optimal place, that looks like it.  I'm also happy with a staticmethod, or the status quo.
[02:49] <lifeless> *bet*
[02:50] <lifeless> spiv: try this on for size:
[02:51] <lifeless> bzr branch -r 2634 bzr.dev foo; bzr merge -r 2591..2592 ; bzr st
[02:52] <lifeless> spiv: its merging in a revision that was already merged previously, but had had its text discarded
[02:53] <lifeless> spiv: but even so, the heads() calculation for me gives the right single parent case
[02:53] <spiv> lifeless: right, but we don't record cherrypicks yet?
[02:53] <lifeless> its not a cherrypick :)
[02:53] <lifeless> because the base revision is in the ancesty
[02:53] <fullermd> Sounds more like a cherryununpick.
[02:54] <poolie> good morning
[02:54] <lifeless> hi
[02:55] <spiv> lifeless: ah, that does indeed create it.  Weird.
[02:55] <igc> morning poolie
[02:55] <lifeless> spiv: normal IMO
[02:55] <lifeless> spiv: its unusual but still a valid DAG
[02:55] <spiv> (incidentally bzr viz just ignores the second parent for the purposes of drawing lines)
[02:55] <lifeless> spiv: yes, I wrote that code :)
[02:56] <lifeless> its the same logic as bzr log uses for indenting
[02:56] <spiv> lifeless: well, "weird" in the sense that I had thought that "bzr merge -r X..Y" wouldn't record a pending merge, but it turns out the world is more complicated.
[02:56] <spiv> lifeless: thanks for satisfying my curiosity about that.
[02:56] <lifeless> :)
[02:56] <lifeless> np
[02:57] <abentley> Could this be related to igc's restoration of my patch that jam reverted?
[02:57] <lifeless> yes
[02:57] <lifeless> jams patch apparently reverted many things
[02:57] <lifeless> mine was restored months ago
[02:58] <lifeless> but I don't think igc could have caused the parent confusion
[02:58] <igc> revno 2614 was the merge
[02:58] <igc> fwiw, I used patch -p0 to apply abentley's changes to bzr.dev
[02:58] <spiv> lifeless: so, what information in the corrupt bzr.dev repo can be used to deduce that file revision has the wrong parents?
[02:59] <lifeless> spiv: left_parent = r.get_inventory(p1)[fileid] .revision
[02:59] <spiv> lifeless: did you say InventoryEntry.find_previous_heads figures it out?
[02:59] <abentley> spiv: My reconcile algorithm ought to determine the correct parents already.
[02:59] <lifeless> right_parent = r.get_inventory(p2)[fileid] .revision
[03:00] <spiv> abentley: *nod*.  I want to figure out why it isn't.
[03:00] <lifeless> correct_parents = r.get_graph().heads([left_parent, right_parent] )
[03:00] <abentley> spiv: the algorithm is applied only when there are unreferenced parents.
[03:00] <lifeless> for me, that returns just one
[03:00] <abentley> This parent is clearly referenced.
[03:00] <spiv> abentley: ah, I see.
[03:01] <lifeless> so disabling the condition to only check when its not referenced should be enough
[03:01] <lifeless> d
[03:06] <lifeless> hmm
[03:06] <lifeless> perhaps we should catch UnicodeDecodeErrors and log them, then show a nice user error IFF their locale is C
[03:06] <lifeless> otherwise raise them as normal
[03:06] <lifeless> (in run_bzr_)
[03:09] <abentley> spiv: I have paged the algorithm back into memory.  Ping me if you want a description, but I gather you've already been looking at that code.
[03:09] <spiv> abentley: thanks, I think I'll be ok, but I'll let you know.
[03:25] <igc> lifeless: that patch submitted to pqm now
[03:35] <spiv> Ok, I have a version of Aaron's reconcile that does correct that problem.
[03:36] <spiv> Now to polish it and test it properly...
[03:36] <spiv> lifeless, abentley: it's safe to say I understand this stuff much better than I did a week ago...
[03:36] <abentley> cool
[03:40] <lifeless> igc: thanks
[03:40] <lifeless> spiv: cool
[03:42] <spiv> Boy I wish reconcile gave some progress indication.
[03:43] <fullermd> Maybe it figures it would just be too depressing.
[03:43] <spiv> fullermd: I want to know how depressed to be! :)
[03:44] <spiv> It's the depression with no visible end that gets me down... ;)
[04:01] <spiv> Good grief reconcile is slow though.
[04:01] <spiv> I guess NEWS has a particularly large history, but even so...
[04:07] <lifeless> it spins
[04:08] <lifeless> just give it some progress figures
[04:13] <spiv> 20 minutes just to check the NEWS knit.
[04:43] <spiv> lifeless: FWIW, the reconcile branch http://people.ubuntu.com/~andrew/bzr/reconcile-check-heads
[04:44] <lifeless> its cooked ?
[04:44] <spiv> lifeless: it just has the manually tested fix, it's not fully cooked at all.
[04:44] <lifeless> k
[04:44] <spiv> lifeless: how urgent is it for you that I cook it now?
[04:44] <lifeless> if you don't, I'll have to
[04:44] <lifeless> I can't work with bzr.dev till we apply it there, and uncooked code == buggy
[04:45] <spiv> Ok, I'll keep at it.
[04:45] <ubotu> New bug: #130574 in bzr "Interrupting bzr log causes "bzr crashed with IOError in <module>()"" [Low,Confirmed]  https://launchpad.net/bugs/130574
[04:52] <fullermd> So, what's the upshot of all of this fribbery with that ancestry lately?
[04:52] <fullermd> Should I be avoiding updating my bzr.dev, or switching back to the release for my daily work?  Or is it ignorable for us non-devs?
[04:53] <lifeless> ignore it
[04:53] <lifeless> we'll fix it and issue a bzr that will correct it all
[04:53] <fullermd> Sweet.  My favorite problems are those I can ignore   :)
[04:59] <lifeless> poolie_: my fix to not propogate changes has hit bzr.dev.
[04:59] <lifeless> poolie_: I propose to move pqm to that version asap
[05:00] <lifeless> not propogate randomish index changes I mean
[05:19] <lifeless> OMG
[05:19] <lifeless> regular bzr is /so slow/ now :(
[05:21] <jdong> are you teasing us? :)
[05:22] <lifeless> not at all
[05:22] <lifeless> I'm testing a specific optimisation for bzr.dev
[05:22] <lifeless> and its making me cry
[05:25] <jdong> ah, I see
[05:25] <jdong> I read it as "haha, look at me with my faster bzr!" :D
[05:25] <lifeless> initial commit of a moz tree with my hacked up bzr that I'm peeling off patches is 1m32
[05:27] <lifeless> with bzr.dev and the patch I'm currently testing it is ... 8m
[05:28] <jdong> wow, that's a substantial difference
[05:29] <lifeless> yes
[05:29] <lifeless> We've been working on performance
[05:30] <jdong> glad to hear
[05:34] <fullermd> Is 0.91 due this week, or is it blocked on resolving that ancestry burp?
[05:35] <lifeless> its due
[05:36] <fullermd> Cool.
[05:55] <lifeless> anyhow, thats a clean 4% in that patch
[05:56] <lifeless> igc: ^
[05:59] <igc> cool
[06:05] <lifeless> add_inventory is 20%
[06:05] <lifeless> update_builder is 37%
[06:11] <poolie_> fullermd: i'll probably do 0.91 when i get home
[06:11] <poolie_> just spending some quality time w spiv now
[06:14] <fullermd> Oh, I was just making sure I was up-to-date with plans.  Not trying to rush you.
[06:32] <lifeless> ok, of that 25 seconds, I've just nuked 7
[06:33] <igc> neat
[06:33] <lifeless> it won't apply to non-selected-file commits unfortunately, but it will make it easier to see hot spots in the code that does apply
[06:34] <lifeless> care to review that other patch ?
[06:34] <igc> sure
[06:47] <lifeless> garh benching on bzr.dev is breaking my balls
[06:47] <lifeless> ..so.. ..slow..
[06:47] <lifeless> while this runs I'm going for a wlak to think
[07:11] <lifeless> woot
[07:11] <lifeless> 50% saving
[07:12] <lifeless> real    0m29.516s
[07:12] <lifeless> user    0m27.594s
[07:12] <lifeless> sys     0m1.236s
[07:12] <lifeless> to
[07:12] <lifeless> real    0m19.251s
[07:12] <lifeless> user    0m17.897s
[07:12] <lifeless> sys     0m0.768s
[07:12] <lifeless> in bzr.dev
[07:12] <AfC> You're a rock star
[07:12] <lifeless> well, not *quite* 50%
[07:12] <lifeless> now to see if it passes tests, and if so send it in
[07:13] <lifeless> AfC: I know :)
[07:13] <lifeless> AfC: I have initial commit with packs faster than hg, on my laptop
[07:14] <lifeless> darn this fails tests, I'll have to tweak it for corner cases.
[07:14] <AfC> lifeless: Initial commit... I know that's what you've been working on; that's for importing projects into Bazaar, right? [ie, unrelated to initial checkout?] 
[07:15] <lifeless> AfC: yes, the first experience for folk considering migrating an existing project to bzr
[07:15] <AfC> Sure
[07:15] <lifeless> AfC: much of initial commit is present in incremental commit too
[07:15] <lifeless> so wins there show up in incremental
[07:15] <AfC> Understood
[07:21] <lifeless> bbiab
[07:47] <AfC> lifeless: you _really_ need to take half an afternoon and put something a bit more flattering up as a home page.
[07:47] <fullermd> Eh, people have been telling me that for years.
[07:47] <AfC> lifeless: right now it doesn't even _mention_ Bazaar
[07:48] <AfC> fullermd: yeah, but if I link to Rob in a blog post, it's like embarrassing for him.
[07:48] <fullermd> They usually phrase it as "Aiee, my eyes are bleeding!", but it means about the same thing...
[08:02] <Peng> What's lifeless's homepage.
[08:02] <Peng> ?
[08:02] <lifeless> to say its bare bones would be to talk it up
[08:02] <lifeless> AfC: I loath web design; someone who's eyes bleed enough will eventually offer me a new site
[08:02] <Peng> Mine is completely empty.
[08:02] <Peng> I just realized what I need to do: 1997!
[08:03] <Peng> But with valid HTML and CSS.
[08:03] <Peng> So it's ironic?
[08:06] <Peng> Anyone got a freely-licensed animated GIF of the U.S. flag?
[08:07] <igc> lifeless: review sent to the list now
[08:07] <lifeless> igc: + or - ?
[08:08] <igc> few changes would be good I think
[08:10] <lifeless> ok, I'll llook tomorrow
[08:10] <lifeless> for now I want to get this 40% win polished
[08:16] <nocturn> Hi all
[08:16] <nocturn> I'm relatively new to Bazaar and I think I made a mistake
[08:16] <nocturn> I wanted to branch an existing project to which I only had a source tarball
[08:17] <nocturn> So I unpacked it in project.vanilla and made that a Bazaar repo
[08:17] <nocturn> I then created project.mybranch and imported the tarball again
[08:17] <nocturn> I made my changes on mybranch.  Now I would like to use diff and later merge as the vanilla version gets updates
[08:17] <nocturn> but mybranch  and vanilla have no common ancestor....
[08:18] <nocturn> Is there any way to fix this?
[08:18] <poolie_> nocturn: if you've just done the one change, it may be easiest to do diff -r 1 on mybranch, then apply that through patch to a branch coming from the real import
[08:19] <poolie_> uh
[08:19] <poolie_> actually, why not just throw away project.vanilla, and replace it with
[08:19] <poolie_> bzr branch -r 1 mybranch vanilla
[08:19] <poolie_> ?
[08:19] <nocturn> I did multiple changes (3 actual releases of my branch)
[08:19] <nocturn> poolie_: What would that do exactly?
[08:20] <poolie_> that would give you a new 'vanilla' branch, containing the import you committed as the first on mybranch
[08:20] <poolie_> but it would be known to have history in common
[08:20] <nocturn> OK, and would that still be OK when I use diff and merge since Vanilla is actually the real mainline
[08:20] <poolie_> right
[08:20] <nocturn> Ok, trying...
[08:21] <poolie_> have you done anything else with your original vanilla branch?
[08:22] <nocturn> no, I didn't touch it.  It belongs to someone else (I'm branching their projec)
[08:22] <lifeless> then the best thing to do is to use the branch command :)
[08:23] <nocturn> lifeless: Yeah :-)
[08:23] <nocturn> Ok, did the branch
[08:24] <poolie_> lifeless: hi, just reading this 4% branch
[08:24] <poolie_> trying to understand
[08:24] <poolie_>          # If length == 1, then we only have the root entry. Which means
[08:24] <poolie_>          # that there is no real difference (only the root could be different)
[08:24] <poolie_> -        if (len(self.builder.new_inventory) != 1 and self._any_real_changes()):
[08:24] <poolie_> +        if len(self.builder.new_inventory) != 1 and (self.entries_changed or
[08:24] <poolie_> +            self.entries_deleted):
[08:25] <nocturn> poolie_: Do I need to do anything special to remove the branch again?
[08:25] <poolie_> nocturn: you can just either delete it, or i usually prefer to move it into a directory called 'Abandoned'
[08:25] <poolie_> just in case i want it back
[08:25] <poolie_> like a trash can
[08:26] <nocturn> Is it wise to follow something like trunk,tags,branches in bzr too
[08:26] <poolie_> no, better to just have the trunk and branches in one directory
[08:26] <poolie_> as separate branches obviously
[08:27] <poolie_> lifeless: the len(...inv) tests in there look a bit strange strange
[08:27] <nocturn> poolie_: silly question, but how to I do that 'have the trunk and branches in one directory'?
[08:27] <poolie_> the usual setup is
[08:28] <poolie_> bzr init-repo myproject
[08:28] <poolie_> bzr init myproject/trunk
[08:28] <AfC> lifeless: don't need anything fancy. Just a one paragraph bio, some bullet points about what you're _currently_ working on, and a photo. Don't need any of the rest of the bling.
[08:28] <poolie_> (do stuff)
[08:28] <poolie_> bzr branch myproject/trunk myproject/somefeature
[08:28] <AfC> lifeless: bring a photo jpg along this weekend and we'll hack someething up quickly.
[08:28] <lifeless> AfC: photo. Eek.
[08:28] <AfC> lifeless: hackergotch at least :)
[08:28] <lifeless> quick, look for a cookie monster jpg
[08:28] <poolie_> i have some good photos of lifeless
[08:28] <poolie_> i think
[08:29] <poolie_> he can be the judge
[08:29] <AfC> poolie_: did I hear you say Bazaar 0.91 would be "today"?
[08:29] <lifeless> poolie_: I think you're probably better placed to asses
[08:29] <poolie_> AfC: yes i expect so
[08:29] <lifeless> poolie_: they are strange but correct; its an artifact of 'the null tree has no root'
[08:30] <lifeless> which I don't like but is entrenched now
[08:34] <lifeless> bleh test output ordering failures.
[08:35] <lifeless> ok fixed version I think, real    0m18.834s
[08:35] <lifeless> user    0m17.645s
[08:35] <lifeless> sys     0m0.580s
[08:35] <ubotu> New bug: #141157 in launchpad-bazaar "Locks acquired via the smart protocol have poor lock info." [Undecided,New]  https://launchpad.net/bugs/141157
[08:40] <lifeless> ok, all commit tests pass, next round
[08:42] <lifeless> looking good
[08:42] <lifeless> 2K ok so far
[08:45] <lifeless> time?
[08:46] <AfC> It was 19.2 seconds. You just said 18.8
[08:46] <AfC> (or was that for something else?)
[08:46] <AfC> down from 29.5s
[08:48] <lifeless> oh right
[08:48] <lifeless> so if you want the test scenario
[08:48] <lifeless> this is a mozilla tree
[08:48] <lifeless> doing 'bzr commit -m message FILENAME'
[08:48] <lifeless> I'm aiming for that to be about 2seconds eventually, or less
[08:48] <lifeless> long way to go to get there
[08:49] <lifeless> this is just the low hanging fruity biscuits
[08:49] <AfC> lifeless: forgive me for being stupid, but isn't that incremental commit, not initial commit?
[08:49] <lifeless> I'm talking about incremental today
[08:49] <lifeless> *initial commit* figures:
[08:49] <lifeless> bzr.dev
[08:50] <lifeless> real    6m21.980s
[08:50] <lifeless> user    3m16.668s
[08:50] <lifeless> sys     0m18.469s
[08:50] <lifeless> my experimental pack work, not all of which is stable enough to publish in any form (but I can supply patches for the *really* brave)
[08:50] <lifeless> real    1m34.322s
[08:50] <lifeless> user    1m20.829s
[08:50] <lifeless> sys     0m4.668s
[08:50] <AfC> (Your comment was just the seed for me writing a blog post, but it's part of my contribution to the ongoing war in GNOME land about DVCS)
[08:51] <nocturn> Ok, I'm reading TrackingUpstream here:
[08:51] <nocturn> http://dev.marva.antwerpencentraal.be/
[08:51] <nocturn> Sorry, wrong url
[08:52] <nocturn> http://bazaar-vcs.org/TrackingUpstream
[08:52] <nocturn> How can I use SVN from upstream instead of CVS
[08:53] <lifeless> bzr-svn
[09:02] <lifeless> nocturn: bzr-svn is wicked cool
[09:04] <lifeless> at this point, calling status, then a selected commit with the ids from status is still faster, have to hammer some more.
[09:05] <nocturn> OK, thanks lifeless
[09:09] <lifeless> igc: review requested
[09:10] <igc> lifeless: sure
[09:16] <lifeless> it should be obvious which one :)
[09:17] <igc> lifeless: yes, and you're right re the nested tree stuff I think
[09:23] <nocturn> Ok, got the structure set up
[09:23] <nocturn> I created a repo with bzr init-repo project
[09:23] <nocturn> and upstream and mybranch in that
[09:24] <nocturn> Now, how can I check out the repo?
[09:25] <lifeless> bzr checkout project/mybranch
[09:25] <lifeless> or have I misunderstood what you mean?
[09:26] <nocturn> lifeless: That checks out only my branch, can I checkout the entire repo?
[09:27] <nocturn> Like an SVN checkout without specifying trunk
[09:27] <lifeless> no
[09:27] <lifeless> in bzr branches are *semantic*, they define structure
[09:28] <lifeless> in svn there are no branches, which is a huge problem for programmatic use of svn
[09:29] <nocturn> Ok, when I try to get the upstream branch, it says: bzr: ERROR: Not a branch
[09:30] <nocturn> For mybranch too.
[09:30] <lifeless> how did you make the branches ?
[09:30] <nocturn> I created myproject with repo-init
[09:30] <nocturn> then upstream with bzr init
[09:31] <nocturn> then mybranch with branch upstream mybranch
[09:31] <nocturn> I'm now trying a checkout over sftp
[09:31] <nocturn> As I usually do
[09:31] <lifeless> what sftp url are you using ?
[09:32] <nocturn> sftp://hostname:/path-to-repo/upstream
[09:32] <lifeless> (don't paste a password or anything, but the rest would be useful. feel free to mangle hostnames etc, but keep the path basically intact if possible)
[09:32] <lifeless>         ^
[09:32] <lifeless> erm
[09:32] <lifeless>              ^
[09:32] <lifeless> thats better
[09:32] <nocturn> bzr co sftp:/bzrhost.domain:/home/bzr/marva/upstream
[09:32] <lifeless> the second : is incorrect in SFTP urls, you would need a port number there
[09:32] <lifeless> and you are missing a /
[09:33] <lifeless> bzr co sftp://bzrhost.domain/home/bzr/marva/upstream
[09:33] <lifeless> that will work better
[09:33] <nocturn> Sorry, I need more coffee ;-)
[09:34] <nocturn> It worked now.  Sorry for the mistake, I'm missing some sleep...
[09:35] <lifeless> no worries
[09:35] <lifeless> perhaps you should sleep though :)
[09:35] <lifeless> igc: there is a bug, I don't know if I introduced it though (with nested pointless)
[09:36] <lifeless> I've added a test
[09:39] <igc> ok - let me think about your mail re nested trees some more
[09:39] <lifeless> hmm, I've fixed the bug and am doing the other comments right now
[09:39] <lifeless> that mail is orthogonal
[09:39] <lifeless> well, I *am fixing* dammit.
[09:39] <lifeless> its still there
[09:45] <lifeless> hah!
[09:45] <lifeless> self._unchanged is fuxored for nested treees
[09:46] <igc> fuxored?
[09:46] <lifeless> say it out loud
[09:46] <poolie_> he has children :)
[09:47] <lifeless> :)
[09:47] <lifeless> they will learn
[09:47] <igc> they're absent right now so it's ok :-)
[09:53] <thekorn> hi, one short question: i pushed a branch to launchpad with bzr 0.15 (feisty), is it possible to get this branch with bzr 0.8 (available in dapper)?
[09:54] <lifeless> igc: ok, I think I've squashed that bug - insufficient coverage
[09:54] <lifeless> thekorn: yes
[09:55] <lifeless> thekorn: we will be issuing a new format in the near future which will break compatibility with dapper, but we also have debs of newer bzr's for dapper
[09:57] <thekorn> lifeless: ah ok, thanks
[09:59] <nocturn> Another question... There where changes to upstream trunk (which I do not want yet)
[10:00] <nocturn> How can I get them in mybranch?
[10:00] <nocturn> merge probably, but I would like to be able to give my changes back too...
[10:03] <lifeless> to get someone elses work use merge
[10:03] <lifeless> to send your work, if they use bzr either publish a branch or use bzr send
[10:04] <lifeless> if they don't use bzr, use 'bzr send --no-bundle'
[10:05] <nocturn> I don't have bzr send...
[10:05] <lifeless> oh, must be an old bzr
[10:05] <nocturn> Bazaar (bzr) 0.17.0
[10:06] <nocturn> On Ubuntu Dapper (server)
[10:06] <lifeless> if they don't use bzr you can get a good diff for emailing them with 'bzr diff -r ancestor:PATHTOUPSTREAM'
[10:06] <lifeless> this will do the right thing even if you haven't merged everything from upstream yet
[10:06] <nocturn> Ok, thanks
[10:06] <lifeless> if they use bzr either publish a branch, or use 'bzr bundle'
[10:06] <poolie_> :!sort % |uniq -c|sort -nr > dupes.tmp
[10:06] <poolie_> easy guide to refactoring :)
[10:07] <poolie_> well, slightly interesting
[10:07] <lifeless> poolie_: the big commercial code analysis engines are basically that, but more generic
[10:08] <nocturn> The's no newer version of bazaar for dapper, I'm using the bazaar repository
[10:08] <lifeless> igc: ok, both patches are back in your court
[10:08] <Lo-lan-do> G'day
[10:08] <lifeless> nocturn: yes, thats right, there will be soon
[10:08] <igc> thanks
[10:08] <lifeless> theres a 44% win, and you're sitting on it!
[10:08] <lifeless> (kidding)
[10:09] <igc> great news! Makes me happy! (not kidding)
[10:09] <nocturn> Ok, good that it's still getting updates :-)
[10:09] <nocturn> I'm waiting for the next LTS to upgrade the server
[10:15] <ubotu> New bug: #141172 in bzr "Interrupting bzr Ctrl-C does not kill openssh subprocess" [Undecided,New]  https://launchpad.net/bugs/141172
[10:16] <LeoNerd> Isn't that a rather old duplicate?
[10:16] <spiv> LeoNerd: perhaps, but I didn't find the dup when filing.
[10:24] <igc> lifeless: should the parameter to find_ids_across_trees in commit.py be self.specific_files or specific_files or doesn't it matter?
[10:25] <lifeless> it does not matter
[10:25] <lifeless> the results are the same if its deduped or not
[10:25] <lifeless> but the later checks win by processing minimal entries
[10:26] <igc> ok
[10:28] <lifeless> night all
[10:28] <lifeless> igc: if you are happy or want trivial changes, please feel free to do them and submit it
[10:29] <lifeless> as I still can't resolve conflicts bzr.dev
[10:29] <lifeless> and I'm sure there are some on these
[10:29] <igc> lifeless: one more Q ...
[10:29] <lifeless> so I'd be asking you to submit it anyhow :)
[10:29] <igc> line 687 - you've dropped ie.revision = None ...
[10:30] <lifeless> right
[10:30] <igc> was that deliberate?
[10:30] <lifeless> yes
[10:30] <lifeless> its bogus
[10:30] <lifeless> we're carrying over an unaltered inventory entrie
[10:30] <lifeless> *entry*
[10:30] <lifeless> why would we mark it as possibly-changed ?
[10:30] <igc> fair enough
[10:31] <igc> night and thanks
[10:31] <lifeless> gnight
[10:32] <Kinnison> hey lifeless, how's pack coming along?
[10:49] <nocturn> Anyone here using the Bugs Everywhere system?
[10:50] <nocturn> I found it on the bazaar homepage, link http://panoramicfeedback.com/opensource/
[10:54] <lifeless> Kinnison: faster than hg on my laptop for the first commit
[10:55] <lifeless> Kinnison: thats the highlight, reality is more complex, of course
[10:55] <Kinnison> lifeless: :-)
[10:55] <Kinnison> lifeless: I'm more interested in whether or not it'll improve push/pull at all
[10:55] <Kinnison> Since my first commit is usually of no more than five or six files :-)
[10:56] <lifeless> push/pull with it is about 120% of rsync
[10:56] <lifeless> later
[10:56] <Kinnison> And is that with a pure protocol like sftp, or with something smart?
[10:57] <ubotu> New bug: #141105 in bzr "Crash with authenticated https checkout" [Undecided,New]  https://launchpad.net/bugs/141105
[10:58] <matkor> python apps do not crash ... they only raise exceptions ...
[11:01] <nocturn> Ok, I have made an experimental branch using the branch command
[11:01] <nocturn> But the source branch had minor changes
[11:01] <nocturn> How Can I pull them in?
[11:01] <Kinnison> matkor: right up until the C extensions crash :-)
[11:02] <matkor> Kinnison: Then it is C crash ;)
[11:02] <Kinnison> even if it's the python interpreter which is crashing?
[11:02] <fullermd> C crash run!
[11:03] <matkor> Kinnison: yeahh...  blame C and Canada ;)
[11:04] <spiv> Kinnison: that's with sftp
[11:04] <matkor> nocturn: commit on source branch and pull merge on experimental ?
[11:04] <Kinnison> What if it's a pypy interpreter and the code running in that causes the pypy interpreter to raise an exception, rather than to raise an exception within itself?
[11:04] <spiv> Kinnison: AIUI
[11:04] <Kinnison> spiv: that's pretty cool
[11:05] <spiv> Kinnison: a big win is that there's very few roundtrips with packs, because there's relatively few files.
[11:07] <gabe__> hello ppl
[11:08] <gabe__> hoping someone might be able to give me some pointers with using bzr_launchpad
[11:08] <gabe__> bzr+launchpad
[11:42] <lifeless> gabe__: I'm just passing through, but perhaps #launchpad may have some folk able to help too; also you should really ask your question, vague things like 'need help' don't give helpers enough info to know what to say to you
[11:44] <gabe__> hehe yeah cheers
[11:45] <gabe__> well I have a central repo (no-trees) with many branches in it, do you know if it's possible to link the whole thing up with launchpad, rather than individual projects?
[11:46] <fullermd> I'm pretty sure not.  You can only push/pull branches, so you'd have to iterate over them one way or another.
[11:46] <fullermd> And I don't think launchpad gives you any repo control, so they'd each be independant on the other end too.
[11:46] <gabe__> oh
[11:47] <gabe__> well then can i use launchpad as a ticketing system, without linking it with my branches?
[11:47] <thumper> What's the chance of dapper backports for bzr > 0.17?
[11:48] <fullermd> I imagine so.  I mean, it doesn't force you to upload any branches at all, so...
[11:48] <spiv> gabe__: sure, you can use any part of launchpad independently of the others.
[11:48] <Lo-lan-do> thumper: It was mentioned earlier that there will be some soon.
[11:48] <spiv> gabe__: obviously the intent is that the various parts will integrate nicely and work well together, but you don't have to upload branches to use the bug tracker, or vice versa.
[11:49] <gabe__> aha sounds cool, basically in my company we have lots of websites that we maintain. We want a ticketing system to track required changes etc. Each website is its own branch. But we don't want to have a seperate ticketing system for each website. What would be the bet way to go about this?
[11:50] <thumper> poolie: re the testing that I was going to do tomorrow,
[11:50] <poolie> (phone)
[11:50] <thumper> poolie: there is not currently a bzr > 0.17 for dapper
[11:51] <lifeless> thumper: run from source?
[11:51] <lifeless> there will be soon
[11:51] <thumper> lifeless: ok, could do
[12:27] <zomba> hi
[12:27] <zomba> i have a problem
[12:28] <zomba> bzr: ERROR: File exists: '/bzrrep/myrep/.bzr/repository/lock/1v8fqh0fv9.tmp': Failure: unable to mkdir
[12:28] <zomba> any ideas?
[12:28] <fullermd> Permissions?
[12:28] <zomba> no...I can't do a bzr commit
[12:31] <zomba> i've the solution
[12:32] <zomba> disk space on the server repository
[12:32] <zomba> thanks anyway
[01:12] <AfC> Did you decide to cut 0.91 today, or is it still in progress?
[05:03] <resiak> as far as i can tell, it's not possible to persuade `bzr log` to include diffs.  is there a straightforward way to fake this, short of parsing `bzr log` and feeding each rev to `bzr diff -r $rev-1..$rev` ?
[05:13] <fullermd> No, there's not.  Though you probably want -rparent:$rev..$rev.
[05:13] <resiak> aha, thanks
[05:13] <fullermd> Or even '-c$rev' (new on 0.91, I think)
[05:14] <fullermd> If you were more ambitious, you could probably write a custom log formatter that did the job...
[05:14] <fullermd> (would certainly be faster than spawning a kadnillion python processes...)
[06:13] <grantgm> Is there any way to merge (add) a bzr branch into an existing svn repo? I've started work on some code for a prof, and now that I'm about 100 revisions into tracking it with bzr, he's told me he'd like me to start using the department's centralized svn server. The svn server has a ton of different directories in TRUNK (one for each researcher/project - about 8 gigs total). He would like me to create another directory there for my project.
[06:13] <grantgm> Ideally, what I'd like to do is import my bzr branch into the svn repo (while maintaining my revision history), and maintain the ability to work with bzr on my end, using that single svn directory as a remote (possibly bound) branch. If possible, I'd like to avoid having to keep the rest of the svn trunk on my local system, since 99% of it is completely irrelevant to me.
[06:13] <grantgm> It seems that using the svn repo through bzr can be done with the svn/bzr foreign branches plugin (is that correct?) but I can't seem to find any way of actually getting the data that I already have into svn.
[06:13] <grantgm> Any help would be greatly appreciated!
[06:15] <dato> jelmer would know if pushing just to a subdirectory is possible.
[06:15] <jelmer> grantgm: you should be able to use svn-push from the latest bzr-svn
[06:16] <jelmer> to push to /trunk or something (to the root of the repository won't work)
[06:21] <grantgm> so i should create the dir in svn trunk, then just using svn-push svn://host/trunk/mydir will get my revision history into svn?
[06:21] <Peng> grantgm: Try convincing them to use Bazaar instead of svn. :D
[06:22] <grantgm> i already did :) ... but he didn't seem impressed :(
[06:23] <jelmer> grantgm: Yep, that should work, as long as mydir isn't the top-level directory of the repository
[06:24] <grantgm> of the svn repository?
[06:24] <jelmer> yep
[06:25] <grantgm> nope, it isn't, so I'll give it a go. Here's hoping I don't wipe out the whole Comp Sci & Engineering repo in the process :)
[06:28] <grantgm> when it says on http://bazaar-vcs.org/BzrForeignBranches/Subversion that renames aren't supported (under Future Enhancements) does that just mean that if I want to move a file I should do it with svn rather than bzr, and then everything will be fine, or will doing any renaming break it?
[06:37] <jelmer> grantgm: bzr can push renames just fine
[06:37] <jelmer> and will still see them as renames
[06:38] <jelmer> but if somebody does a "svn mv" bzr won't consider that a rename
[06:38] <jelmer> I'll clarify the statement on the wiki
[06:38] <LeoNerd> The core problem is that svn doesn't really have a file move operation
[06:38] <LeoNerd> It sees a new file whose history continues from some other file, then a deletion
[06:39] <jelmer> right, you have to use heuristics to determine that when somebody does a delete+copy they actually meant a move
[06:40] <jelmer> bzr-svn stores rename information in a bzr-specific property in svn
[06:42] <grantgm> let me make sure i have this correctly: if i do a bzr rename, will it won't be pushed to svn as such - bzr will understand it, but in svn it will appear as a delete-then-create. is that right?
[06:45] <jelmer> grantgm: yes
[06:46] <LeoNerd> Er...
[06:46] <LeoNerd> It's more that svn doesn't _have_ a move operation, so that's the best thing that it can do, a delete-then-create
[06:46] <LeoNerd> It's almost the same as CVS, only SVN can reference other files for history further back than the first revision, so the newly-created file takes the history of the one that's deleted
[06:47] <grantgm> so that is what 'svn move' actually does?
[06:47] <LeoNerd> Since it doesn't have one, a bzr->svn push can emulate a rename using a delete-then-create
[06:47] <LeoNerd> Yes.
[06:48] <LeoNerd> svn has lots of "magic" that isn't really magic at all, that's simply hacked on using the cheap-reference-copy thing
[06:48] <LeoNerd> There's no such thing as a branch, or a tag, in svn
[06:48] <LeoNerd> The only things that exist are cheap copies
[06:48] <LeoNerd> A branch is a cheap copy of its parent, that then has new divergent history
[06:48] <LeoNerd> A tag is a cheap copy of its referrant, that you promise not to change
[06:48] <fullermd> But that's the best way to do it.  Obviously.  I mean, it took them 6 years of hard work to perfect it.
[06:48] <LeoNerd> A rename is a cheap copy of the old name of the file, the old file is then deleted
[06:50] <LeoNerd> All these operations do exist natively within bzr
[06:50] <LeoNerd> This difference in world view, is what makes bidirectional bzr<->svn gatewaying very difficult in the general case
[06:50] <grantgm> yea...that seems a lot more sane
[06:51] <LeoNerd> You can only guarantee proper gateway in restricted cases where both sides can agree a proper representation for the operations. Namely, a single branch of commits that just add, change, or remove files.
[06:54] <jelmer> LeoNerd: bzr-svn can handle all sorts of funky revisions
[06:55] <LeoNerd> But surely just by heuristic analysis?
[06:55] <grantgm> right, but it seems that svn can't. so long as bzr tracks what is _really_ happening, i'm happy
[06:55] <jelmer> LeoNerd: No, 1-to-1 mapping
[06:56] <jelmer> LeoNerd: or do you mean what directories to consider branches and the like?
[06:56] <LeoNerd> Er.. Not sure I quite get the question any more...
[06:57] <jelmer> LeoNerd: can you give an example of the sort of heuristic analysis you mean?
[06:57] <LeoNerd> Detecting a merge
[06:59] <jelmer> it can't detect svn merges and won't try to, but it stores information about bzr merges
[06:59] <jelmer> and can read that
[07:00] <LeoNerd> Yes, that's the sort of thing I meant
[07:00] <jelmer> it will also be able to use the merge info svn 1.5 writes out (when it's finally released)
[07:02] <jelmer> sorry, I misunderstood you then
[10:08] <grantgm> hey, jelmer, are you here?
[10:08] <jelmer> grantgm, yep
[10:10] <grantgm> I've just tried what we were talking about earlier, but it doesn't seem to like it: I created the directory in the svn repo, (svn mkdir mydir), and I'm now trying to push my local branch to it, but its telling me that the branches have diverged
[10:10] <jelmer> grantgm: It will create the directory for you, otherwise you'll indeed get that error
[10:10] <DShepherd> how can I update to a specific revision?
[10:11] <grantgm> ok. so at this point, should i --overwrite it?
[10:11] <jelmer> grantgm: easiest would be to just remove it and then do the push
[10:12] <grantgm> ok. I tried merging, as well, but that seemed to hang. I killed it after ~20 minutes of no activity
[10:12] <jelmer> grantgm: what exactly did you try to merge?
[10:14] <grantgm> from within my local branch i did 'bzr merge svn://remoteserver/repo/trunk/mydir'
[10:15] <grantgm> the same thing I'd do if my local branch had diverged from a remote one using just bzr
[10:15] <jelmer> grantgm: These branches don't have any history in common
[10:15] <jelmer> although I agree it shouldn't hang
[10:16] <grantgm> yea...I figured I'd give it a try. Grasping at straws, I guess.
[10:25] <grantgm> ok, so I've removed the directory from the svn repo, and ran the push again. Its throwing an list index out of range exception. Check http://paste.ubuntu-nl.org/38028/
[10:25] <lifeless> moin
[10:26] <grantgm> ... throwing *a* list index ...
[10:27] <jelmer> hey lifeless
[10:27] <lifeless> power failures
[10:27] <lifeless> hate em
[10:28] <jelmer> grantgm: what version of bzr-svn are you running?
[10:28] <grantgm> 0.90.0, package from Ubuntu Gutsy
[10:29] <jelmer> grantgm: that command should be 'svn-push' rather than 'push'
[10:30] <grantgm> oh, sorry, that's the bzr package...one second
[10:30] <jelmer> the two will be integrated eventually but that hasn't been done yet
[10:31] <jelmer> lifeless: you haven't missed much here
[10:33] <grantgm> Ok, it seems to be going now. 'bzr help svn-push' makes it sound like they are already pretty much integrated: "this command is the same as that of 'bzr push', except that it also creates new branches." Gimme
[10:33] <grantgm> ... a sec and I'll let you know if it goes through
[10:41] <lifeless> I need a favour from someone familiar with bzr
[10:41] <jelmer> lifeless: what sort of favor ? :-)
[10:41] <lifeless> jelmer: I need someone to generate a bundle of bzr.dev against my repository branch
[10:41] <lifeless> because I can't push-pull :)
[10:42] <lifeless> then I can apply that bundle to my local copy of bzr.dev, which will make my [merge]  mails be slightly less out of date
[10:43] <jelmer> lifeless: what's the location of your branch?
[10:43] <lifeless> people.u.c/~me/baz2.0/repository
[10:45] <jelmer> lifeless, not quite sure I follow - what command do you need me to run?
[10:45] <lifeless> oh
[10:45] <jelmer> 'bzr.packs bundle http://people.ubuntu.com/~robertc/baz2.0/repository/' from my local bzr.dev copy?
[10:46] <lifeless> yes I think
[10:46] <lifeless> or s/bundle/send/ and ad --mail-to robert...
[10:51] <jelmer> on its way
[11:01] <lifeless> danke
[11:02] <thumper> lifeless: which branch should I grab to do my load testing on dapper?
[11:02] <thumper> lifeless: I guess bzr.0.90
[11:03] <lifeless> load testing on dapper?
[11:03] <lifeless> ok, I'm confuzzled
[11:03] <lifeless> 0.90 is fine though yes
[11:04] <thumper> lifeless: it'll all become clear soonish :)
[11:04] <thumper> I hope
[11:18] <ike> Hello.
[11:18] <ike> Anyone know something about crypto repository format?
[11:19] <ike> Will it work? afaik it was GSoC project but i couldn't find anything on mailing lists.
[11:28] <lifeless> ike: it didn't get finished
[11:29] <ike> pitty. but was it completly dropped or just the progress is slow?
[11:31] <ike> lifeless: do you know maybe?
[11:31] <ubotu> New bug: #141368 in bzr "merge command should have --change option" [Undecided,New]  https://launchpad.net/bugs/141368
[11:32] <lifeless> ike: I was the mentor
[11:32] <lifeless> ike: and I don't know :(
[11:36] <ike> lifeless: oh. pitty. was it your idea? 'cause i'm looking for crypto repository oslt.
[11:36] <ike> i need repository for sensitive data (passwords etc)
[11:36] <lifeless> it was bogdano's idea
[11:36] <lifeless> and a really nice one.
[11:36] <lifeless> but he disappeared basically in the second half
[11:37] <lifeless> there is code on launchpad but it doesn't encrypt, only obscures the data - proof of concept progress only
[11:37] <ike> mhm. not much useful in my case.
[11:37] <ike> so another question maybe.
[11:38] <ike> i thought about some repository inside crypto partition/file.
[11:38] <ike> secured by a password... and question: is it possible to tell bzr or i don't know what to interactve pass password to ... mount oslt?i
[11:39] <lifeless> what is "oslt?i" ?
[11:40] <ike> i want to simply `bzr pull` and if the repository isn't available (the partition isn't mounted) to mount particular partition first.
[11:40] <ike> oslt - or something like that. the last "i" was a typo.
[11:41] <lifeless> ok
[11:41] <ike> i know that the whole partition whould be clearly readable while sending the data but... it's better than nothing i think.
[11:41] <lifeless> uhm no, bzr doesn't have that, but you could use luks separately
[11:41] <igc> morning
[11:41] <lifeless> and just have a loopback crypto partition
[11:41] <lifeless> cryptsetup is your friend for that
[11:41] <lifeless> hi igc
[11:41] <igc> hi lifeless
[11:42] <lifeless> jelmer: I haven't seen it
[11:43] <lifeless> jelmer: oh I found it sorry :)
[11:43] <ike> Ok. I get that. But is scenario like that possible: clients executes `bzr up`, bzr connects to the repository, asks client for a password, mounts partition with provided password, receives data from a repo, unmounts the partition?
[11:43] <lifeless> ike: yes, you could do that in a plugin as a transport I think
[11:44] <ike> o! hooray. thanks. i'll look at this.
[11:44] <lifeless> just replace the normal local transport with one that knows about your path; however I'd just do it as a shell script wrapper IMO
[11:44] <lifeless> proably simpler, and easier to be sure its unmounted afterwards
[11:45] <ike> Hm. So you suggest a script which mounts needed partition, executes `bzr something` and unmounts it.
[11:46] <ike> crap. how i didn't figure this out by myself?
[11:47] <lifeless> :)