[02:28] <meteoroid> with bzr-svn, can i give a specific revision #? i want to clone a repo with thousands of revisions and want to pull 1k revisions per night.
[02:28] <jelmer> meteoroid, yes, see -r
[02:29] <meteoroid> jelmer - with svn-import ?
[02:30] <meteoroid> or is it easier if i branch each of the root-level 'project' areas with branch, into a shared repo?
[02:30] <jelmer> ahh, there's no option for svn-import for that
[02:30] <meteoroid> yeah see
[02:30] <meteoroid> i need to svn-import something with over 50k revisions
[02:30] <meteoroid> and i'd rather not crash their server ;)
[02:30] <meteoroid> as svn is known to leak and take apache town altogether
[02:31] <AfC> meteoroid: doing `bzr pull -r $x` where $x is incrementing by a few hundred (or whatever) each loop will probably do fine.
[02:33] <meteoroid> AfC: but, how should i start it all off? i'd be best off, as i understand, with an svn-import, and i'm concerned if the branching will be properly recognized otherwise, which may increaase the amount needing to be transferred, and the storage used, exponentially..
[02:33] <meteoroid> i mean this is a huge repo
[02:43] <AfC> meteoroid: just start it off with a branch at -r 10 or something.
[02:43] <meteoroid> hm.
[02:43] <meteoroid> maybe just -r 1
[02:43] <AfC> meteoroid: (actually a `bzr init --rich-root-packs` or whatever == empty branch works too)
[02:43] <meteoroid> hm
[02:43] <AfC> and then a URL on the first pull
[02:43] <meteoroid> explain more about the last statement..
[02:43] <meteoroid> i'd love to write a general purpose utility for branching large svn repos as a shell script or something based on your advise
[02:43] <meteoroid> advice
[02:44] <AfC> meteoroid: For what it's worth, I wrote about in making an initial Bazaar conversion of a monster branch (GTK, as it happens)  which you might find interesting. http://research.operationaldynamics.com/blogs/andrew/#bzr-branch-of-gtk
[02:44] <meteoroid> thanks!
[02:44] <meteoroid> GTK is quite possibly a good bit larger than mine
[02:44] <meteoroid> how many revs when you started?
[02:44] <meteoroid> hm 15k revisions
[02:45] <meteoroid> except for memory limitations on my 1GB Ubuntu slice, I was able to branch over 5k revisions of a 10,5 revision repo
[02:45] <meteoroid> but i figure if i come up with a gentle strategy for the 52k+ rev repo, it will work for others
[02:45] <meteoroid> 15k revisions i could probably branch easily on a bigger box in one overnight run
[02:46] <AfC> meteoroid: the key point is that once *someone* has done the conversion once, no one else has to. They can all just `bzr branch` from you, and then later update their branch via `bzr pull svn+ssh://...`
[02:46] <meteoroid> no i totoally understand
[02:47] <meteoroid> i'm just concerned that i can't be busying up the server for more than a handful of hours
[02:47] <meteoroid> 5k revisions took long enough
[02:47] <meteoroid> i want to spend a month or so pulling around 100k revisions across a few repo
[02:59] <AfC> meteoroid: do you have access to this server? The other way to do this is to get an svn dump, transfer that in toto, and then operate on that elsewhere
[03:00] <AfC> meteoroid: that's how Jc2k built the bzr-mirror.gnome.org set
[03:39] <meteoroid> AfC : the server admins may be hostile, but i can work on it..
[03:40] <meteoroid> i know that'd be the best way.  an svndump i could load and then pull the latest from
[03:40] <meteoroid> i know once i have a copy that updates will be very light
[03:40] <meteoroid> and that's a big reason i've chosen this approach
[03:40] <meteoroid> to provide greater branching freedom in our community
[03:40] <meteoroid> but i'm not sure all people will be welcoming at first
[03:40] <meteoroid> until we can contribute back..
[03:41] <meteoroid> so it's a chicken egg problem and i'd like to just spend a few weeks pulling a couple k rev at a time to not overload upstream server.
[03:41] <meteoroid> but if we need to surf the social issues, we will
[04:50] <pickscrape> lifeless: are you around?
[04:51] <pickscrape> Quick question. In the color discussion Jonathan Lange suggested taking the terminal coloring code from twisted.trial: it supports handling things like Win32 already
[04:51] <pickscrape> What's the bzr policy for taking code from other projects like that?
[05:00] <meteoroid> twisted license is MIT, ya?
[05:08] <lifeless> pickscrape: depends on how it will be taken; if its being copyied it needs to be a) licence compatible and b) not large enough to trigger the need for assignment
[05:11] <pickscrape> Basically it is two classes from here: http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.1.0/twisted/trial/reporter.py
[05:16] <pickscrape> If it's not feasible I can work on my own implementation instead. I wasn't going to use them verbatim anyway.
[05:24]  * meteoroid has had some convo recently with RMS regarding GNU licenses and python "dynamic linking" or loading of .py files, which is fuzzy license territory apparently, despite my previous beliefs..
[05:29] <pickscrape> I think I'll just write my own. Less hassle. :)
[07:32] <markh> lifeless: ?
[07:54] <xshelf> I am having problems in building bzr plugins on windows using MinGW (dir_walk plugin), is it a known issue
[07:55] <xshelf> Since I have been benchmarking it for emacs repository, any performance gain would help
[07:55] <xshelf> I believe that dir_walk on windows does speed up things, am I right in my assumption?
[08:02] <xshelf> anyone online now?
[08:09] <markh> xshelf: if you can get bzr 1.6 building it should already have optimized dir walking for win32.
[08:10] <xshelf> i am using bzr from the bzr.dev
[08:10] <markh> right - and can't get the extension building?
[08:10] <xshelf> i must say it is much better than I (dhruvakm) did a earlier benchmark for emacs
[08:10] <xshelf> yes, I get an error in building the extension
[08:11] <xshelf> python setup.py build -c mingw32
[08:11] <xshelf> something to do with Py_ssize type
[08:12] <markh> hrm - python 2.4?
[08:12] <xshelf> it used to build just fine with vc 2003 and my installed python was built using the same compiler
[08:12] <xshelf> python 2.5.2
[08:13] <markh> strange - it has Py_ssize_t - what is the error?
[08:13] <xshelf> i had to update to vc 8, python does not have vc8 distro
[08:13] <xshelf> I am therefore forced to use mingw
[08:13] <xshelf> error: bzr.dev\bzrlib/_walkdirs_win32.pyx:65:15: Syntax error in C variable declaration
[08:16] <markh> I'm afraid I really can't help I'm afraid :(  I think the author of that code does use mingw, so its possible opening a bug report will get results.
[08:16] <markh> you could always build your own python with vc 8 ;)
[08:17] <xshelf> it needs a whole lot of stuff like sql-lite, bdb...
[08:17] <markh> yeah - but so would building from vc7 - but I agree its a PITA :(
[08:17] <xshelf> i tried hoping it would be quick, just gave up after sometime
[08:18] <xshelf> i really like the PERL bundling
[08:18] <markh> oh - right - if you could use vc7 you wouldn't have to build python itself!
[08:18] <xshelf> I have built PERL using cygwin, mingw and msvc with no sweat
[08:18] <xshelf> true
[08:19] <xshelf> and you cannot build python with mingw
[08:19] <xshelf> i wonder if we have some python devs here listening, get python to build with mingw. I build emacs regularly with mingw and it works fine
[08:20] <markh> some people have managed and contributed makefiles, but they are rarely kept up to date.  It all relies on volunteers, and on Windows at least, builds using a non-standard compiler are less interesting as you can't get any pre-built binaries for it.
[08:20] <xshelf> you have CMake
[08:20] <xshelf> at work, we just moved to cmake
[08:20] <xshelf> it generates platform/compiler specific build files from a common set of cmake files
[08:21] <xshelf> I am really impressed by cmake. BOOST is moving towards cmake (giving up their home grown bjam tool)
[08:22] <xshelf> i never realized you are the same Mark of Python win32 ext
[08:22] <markh> heh - yeah
[08:23] <xshelf> great, you really have brought Python to the windows world, thank you for that
[08:23] <markh> working on bzr 1.6 binaries as we speak - but msvc7 built ones ;)
[08:23] <markh> my pleasure :)
[08:23] <markh> thanks!
[08:23] <xshelf> welcome
[08:23] <xshelf> yes, building with msvc 7 was easy
[08:24] <xshelf> i made a blunder of uninstalling it when i had to install vc8
[08:24] <xshelf> i thought i would save some disk space :-(
[08:24] <markh> can't you reinstall it?
[08:24] <xshelf> i have to run to IT, they will ask questions and get license approvals and all the corporate noise...
[08:24] <markh> heh - bugger
[08:25] <xshelf> i will try that anyway on monday
[08:25] <markh> so - bzr 1.6 should be much faster than 1.5 even without that extension
[08:25] <xshelf> it sure is
[08:25] <xshelf> i was part of the emacs mail chain opposing adoption of bzr
[08:26] <markh> although that extension makes a big different for big trees.  Quoting John, its author: " With this patch, doing 'bzr status' in a mysql tree on Win32 changes  from: 4.2s => 0.64s, or about 6.5x faster. It is quite noticeable when your command prompt hangs for 4s versus returning in < 1s."
[08:26] <xshelf> the turning point was when RMS posted that we have to adopt another GNU project and help make it better
[08:26] <xshelf> Yes, I keep running such commands too often in my development
[08:27] <xshelf> i thought of writting something like using inotify for windows
[08:27] <xshelf> so that, my changes are tracked without walking directories
[08:27] <markh> The binaries I've got a looking pretty good.  If you ping me on Monday I can make sure one is up for you to play with if you like
[08:27] <xshelf> i need time to do that, something that sysinternals filemon (procmon) does
[08:28] <xshelf> i will do that, thanks.
[08:28] <xshelf> I will try getting vc 7 so that I can build and play myself
[08:28] <markh> yeah, tortoise will grow a file-watcher
[08:29] <markh> but bzr status is *very* fast - we are already much much faster than tsvn on most trees I've tried
[08:29] <xshelf> another question: can bzr seamlessly with perforce?
[08:29] <xshelf> I am looking for something like git-p4
[08:29] <markh> not afaik, but its an opportunity waiting to be taken, along the lines of bzr-svn ;)
[08:30] <xshelf> i am forced to use p4 at work, would love to use just bzr for emacs and work
[08:30] <markh> but google may well prove me wrong - I'm not that much in the loop that I'd know about it
[08:31] <xshelf> i have just started looking at vcp from perforce. The svk folks had used vcp to support seamless operability with p4 but dropped it in their new releases
[08:31] <xshelf> let me do some ground work and keep this channel posted
[08:32] <xshelf> well, my family is back, will catch you on monday
[08:33] <xshelf> have a nice weekend. I have to tear myself away from this computer...
[08:33] <markh> cheers!
[08:45] <gour> morning
[08:46] <gour> i just built bzr from the repo and it bears the label:bzr1.7dev. when is 1.6 going to be released?
[08:47] <spiv> gour: the 13th is the plan (see the release announcement for 1.6rc1)
[08:55] <gour> spiv: ta. i'm looking at release notes, but there is nothing
[08:56] <gour> anyway, will bzr come back to regular (aka monthly) releases?
[09:45] <Bronger> Feature request proposal: I'd like to have diffs with diff's "-c" option.  It should be possible to set this in the conf file, so that not only "bzr diff" but also "bzr commit --show-diff" benefit from it.
[10:00] <jonnydee> hello -- I'v got a question: what is the best way to incorporate the contents of repository B into A? At the moment I'm only aware of doing a merge... Is it the right way, or is there another approach?
[10:00] <jonnydee> sorry, I'm confusing repository with branch
[10:01] <jonnydee> but on the other side doing it with shared repositories would also be interesting
[10:02] <jonnydee> btw, with "contents" I mean the complete history, too
[10:05] <Bronger> jonnydee, I think you could also append the changes of one branch to another branch with re-basing.  Haven't done this yet, though.
[10:05] <jonnydee> rebasing...ok. It sounds like this might be a solution...
[10:05] <Bronger> Are the contents of both branches disjunct?
[10:06] <jonnydee> Yes, they generally are. The reason why I'm asking is: I would like to write a plugin that is able to
[10:07] <jonnydee> convert a branch/repository in such a way that the root of the repository/branch is moved one level up in the directory tree
[10:07] <jonnydee> (while preserving the directory tree)
[10:09] <jonnydee> for example, if I have a branch in: /tmp/repo/jonnydee/
[10:09] <jonnydee> then I would like to be able to move /tmp/repo/jonnydee/.bzr to /tmp/repo
[10:10] <jonnydee> which means the directory jonnydee is now versioned, too
[10:10] <Bronger> But repo is not a branch, but a ... well ... repo.
[10:11] <Bronger> I think that this would create some administrative collisions, although I must admit that I don't knot the Bazaar interna.
[10:11] <jonnydee> yes, I know. But I need to handle any combinations....
[10:11] <Bronger> What's the eventual purpose you're thinking of?
[10:12] <jonnydee> Well the idea came from a discussion here
[10:13] <jonnydee> someone had exactly this problem: he versione controlled a specific subdirectory and decided to extend version control over to the parent directory
[10:13] <jonnydee> in his case the solution was simple:
[10:15] <Bronger> I can imagine his solution already.  You may proceed with explaining a case that is not so simple.  ;-)
[10:16] <jonnydee> well, sorry, I'm a bit confused at the moment -- I think it's too early in the morning.
[10:16] <jonnydee> But you got the idea
[10:16] <Bronger> Not really, because your example can be easily solved without new features.
[10:17] <jonnydee> the more complicated cases are where one extends version control to a parent directory that has subdirectories containing other branches/repositories....
[10:17] <jonnydee> ...and now ;)
[10:17] <jonnydee> ???
[10:22] <jonnydee> with other words, the general case is: you strat from an arbitrarily deep subdirectory in the file system, which contains the repository/branch you want to extend one level upwards. when you go one level upwards you might encounter a shared repository, or nit
[10:22] <jonnydee> not
[10:22] <Bronger> Even then it's simple: Go to the root of your branch (not repo!) and type "bzr mkdir branchname".  Move all other top-level files/directories into that dir with "bzr mv".  Then move the desired files/dirs from .. into the branch root dir, and add them with "bzr add".  Commit everything, voilPONG :niven.freenode.net
[10:24] <jonnydee> but I do not only want the contents but also their history (if any)
[10:25] <jonnydee> so lets assume my parent directory is a shared repository. now this means all the branches contained in the shared repository need to be combined into a single branch
[10:26] <jonnydee> if it is not, then your solution comes into place -- with one exception
[10:27] <jonnydee> if some subdirectory of the parent directory contains a branch itself (which may be located in an arbitrarily deep subdirectory) then there is no simple way like adding the files
[10:27] <jonnydee> because we also want the history
[10:29] <jonnydee> well, while I'm explaining this I am starting to doubt whether such a plugin is woth the work....
[10:29] <Bronger> Do the branches have a common ancestor?
[10:30] <jonnydee> maybe they have, maaybe not
[10:30] <jonnydee> In a general case, you might have or are likely to have common ancestors
[10:32] <jonnydee> such a plugin would be a nice-to-have for me, but the question is: how often is it needed to extend the root to one (ore more) levels up....
[10:33] <jonnydee> anyway, I think you see it is not that easy when considering the general case
[10:33] <jonnydee> ok bye Bronger - cu ;)
[10:35] <Bronger> In any case, you have to move all dirs to their final positions in their respective branch, so that there are no collisions anymore when you unite them.  If they have a common ancestor, I'd do a merge, if they have not, you have to do a rebase I think.  You can rebase in both cases though.  Given that this is a rare use case (in case of no common ancestry even *very* rare), and given that it is feasible to do it manually, I don't think that it's worth a plugin
[10:38] <jonnydee> Bronger, I thin you are right.... You know, I'm trying to get into Bazaar development and I thought writing a "simple" plugin would be a good starting point....but this turns out to not be the simplest plugin....
[10:38] <jonnydee> especially in comparison with the benefit one would gain.... :(
[10:39] <jonnydee> ok, so thank you very much for your help and feedback!!! :)
[10:40] <jonnydee> and sorry that I've been wasting your time...
[10:42] <LarstiQ> jonnydee: bzr merge -r 0..-1 path/to/otherbranch
[10:42] <Bronger> Not at all. It help me to understand those DVCS more and more.
[10:44] <jonnydee> thinking positive is always a good idea ;)
[10:44] <LarstiQ> jonnydee: the key thing there is revision 0, being a virtual revision every revision dag inherits from
[10:45] <LarstiQ> jonnydee: so even if the two branches don't have anything in common otherwise, you can force them to merge that way
[10:45] <jonnydee> LarstiQ: When using this command, do I get the complete history from the other branch, too?
[10:45] <LarstiQ> jonnydee: as came up (I didn't read all backlog), you might want to move directories beforehand to keep things from clashing.
[10:45] <LarstiQ> jonnydee: yes.
[10:46] <jonnydee> that sounds like magic :)
[10:46] <LarstiQ> well, it's just normal operation really :)
[10:46]  * LarstiQ runs off for the day
[10:46] <LarstiQ> jonnydee: have fun :)
[10:46] <jonnydee> thanks larstiq
[10:46] <jonnydee>  :)
[10:48] <jonnydee> well, I'm going to play a bit. maybe, I'll implement simple cases, just for fun....and if I still have fun, then maybe I consider more complex cases...
[10:49] <jonnydee> Thanks a lot to Bronger an to LarstiQ :)
[10:52] <Peng_> jelmer: I have a couple bzr-svn questions. With that root revision patch, what exactly was broken, and did data get corrupted or anything, or would bzr just traceback?
[10:54] <Peng_> jelmer: Also, with changing the file ID map version, what exactly does that mean?
[10:54] <jelmer> Peng_: The root revision patch is more just paranoia at this point
[10:55] <spiv> gour: yes, back to monthly releases is the plan
[10:58] <Peng_> jelmer: Okay.
[11:00] <jelmer> Peng_: the file id map version was changed because older versions of bzr-svn may write invalid data to it in some corner cases
[11:01] <jelmer> rare, but still
[11:03] <spiv> jelmer: I liked the suggestion for bumping the version to 1.0, btw.
[11:05] <Peng_> I dunno about 1.0, but I would vote for 0.5.
[11:11] <jelmer> spiv, I'd rather wait with any sort of major version change until the mappings change again
[11:12] <spiv> jelmer: fair enough.  But 1.0 soon is justified I think, it is a pretty mature tool now.
[13:11] <lifeless> markh: ?
[14:55] <rocky> jelmer: remember the other day i said i was working on a bzr-svn blog post and would like you to review it before i published it? i have it ready... don't suppose you have an email i could send it to?
[14:55] <jelmer> rocky, Yeah, sure - my email is jelmer@samba.org
[14:58] <rocky> sent
[15:00] <jelmer> brb
[15:10] <jelmer> rocky, just curious - what sort of blog software do you use?
[15:10] <rocky> TextPress
[15:10] <rocky> i'm a python fanatic
[15:10] <rocky> www.serverzen.net
[15:11] <rocky> i just blogged on settnig up TextPress ;)
[15:14] <jelmer> rocky, I don't see any errors
[15:14] <rocky> any obvious misuse of bzr? i mean, am i using bzr in an acceptable fashion? :)
[15:15] <jelmer> rocky: heh, no that all looks alright
[15:15] <dato> jelmer: I think Wilmer van der Gaast sits a few places from me at work. ;-)
[15:16] <jelmer> dato: Ah, cool
[15:16] <jelmer> dato, he's a good friend of mine
[15:16] <jelmer> dato, I was over there at Google a couple of weeks ago
[15:16] <dato> O'RLY?
[15:16] <rocky> jelmer: alrighty then
[15:16] <dato> we missed the chance to meet, then :(
[15:16] <rocky> now the question is do i wait a bit since i blogged just a few days ago, or post immediately :)
[15:16] <jelmer> dato, You're working for google these days?
[15:17] <dato> jelmer: I'm doing an internship this summer, at least for now.
[15:17] <jelmer> dato, ah, nice
[15:26]  * pickscrape gets bzr diff --color working for the first time :)
[15:28] <jelmer> rocky, thanks for the link to textpress, I'll check it out
[15:28] <jelmer> dato, ask him about french-irish girls in boots :-)
[15:28] <rocky> jelmer: np, my blog post should get you started fast
[15:58] <nexus10> hi -- is there any way I can use 'bzr branch' to read a .bzr repo which is served by a webserver at https://server/site/.bzr  -- when this is passwd protected?
[15:59] <nexus10> I can access the dir using a browser by entering credentials into the basic-auth dialog
[16:00] <beuno> nexus10, sure, bzr branch https://user@server/site
[16:01] <beuno> it should just ask you for the password
[16:01] <nexus10> beuno: :-)
[16:01] <nexus10> beuno: now I feel *really* smart...
[16:02] <beuno> nexus10, I went through the same thing before I learned that, so, welcome to the club  :)
[16:03] <nexus10> :-)
[17:22] <nexus10> beuno: that bzr branch https://user@server/site worked splendidly, thanks a lot.
[18:41] <rindolf> Hi all.
[18:41] <rindolf> How do I use bzr-svn ?
[18:46] <rocky> rindolf: http://www.serverzen.net/2008/08/09/starting-with-bazaar-bzr-svn
[18:48] <rindolf> rocky: thanks.
[18:53] <Peng_> beuno: Loggerhead question: If a commit message is "foo\n\nbar", the /changes page will show "foo" in the summary. Then if you click the expand button, it changes to "foo bar". Is that intended?
[18:54] <rindolf> rocky: python: subversion/libsvn_ra/ra_loader.c:944: svn_ra_get_log2: Assertion `*path != '/'' failed.
[18:54] <beuno> Peng_, it's expected rather then intended
[18:55] <beuno> we strip out all HTML to show in that context
[18:55] <beuno> including \n
[18:55] <beuno> so we can show a plain commit message
[18:56] <beuno> there may be smarter ways of doing that though
[18:56] <beuno> pickscrape, ping
[18:56] <Peng_> Ah..
[18:57] <Peng_> Well, I'm gonna go. Have a nice day. :)
[18:57] <beuno> Peng_, you too
[19:03] <rindolf> https://bugs.launchpad.net/bzr-svn/+bug/234010 - hmmm...
[19:03] <rindolf> What should I do?
[19:08] <rindolf> Anyone?
[19:15] <beuno> rindolf, jelmer is the right person to talk to, but probably not on a weekend
[19:16] <beuno> he'll see the bug eventually, and help you out
[19:16] <rindolf> beuno: thanks.
[19:17] <beuno> :)
[20:01] <asabil> is it normal that the bzr PPA for hardy doesn't actually contain bzr ?
[20:03] <Peng_> Heh.
[20:04] <Peng_> Oh, I'm using the beta PPA. I forgot.
[20:04] <Peng_> asabil: Yes, it is. Someone published 1.6b3 for Hardy, and you can't revert it back to 1.5.
[20:04] <beuno> asabil, it will contain only releases from now on
[20:04] <beuno> so beta PPA for betas/rc's, and bzr PPA for releases
[20:05] <beuno> asabil, https://edge.launchpad.net/~bzr-beta-ppa/+archive
[20:05] <asabil> beuno: hmm ? but it doesn't even contain bzr 1.5
[20:05] <beuno> asabil, right, as Peng_ pointed out, something went wrong, and it had to be removed. 1.6 *will* be on there
[20:05] <asabil> beuno: I don't really want bzr 1.6
[20:05] <beuno> and everything should be fine from now on
[20:05] <asabil> oh oki
[20:22] <NewsMan08> Hello All
[20:42] <pickscrape> beuno: pong
[20:42] <beuno> pickscrape, hi  :)
[20:42] <pickscrape> Afternoon :)
[20:42] <beuno> I've been looking at your patch/branch
[20:43] <beuno> I can't figure out *what* it does
[20:43] <pickscrape> It converts the path string at the top of the file and directory browser pages into breadcrumb links
[20:44] <pickscrape> So you can click on the parts of the path to browse to that directory
[20:44]  * beuno tests again
[20:46] <beuno> pickscrape, cool. Can you make the file browsing do that too?
[20:47] <pickscrape> I thought I'd got them all... Which view are you looking at?
[20:47] <beuno> pickscrape, when you end up in the actual branch
[20:48] <pickscrape> It should already work
[20:48] <beuno> in /files
[20:48] <beuno> it doesn't for me  :/
[20:50] <pickscrape> I just browsed into loggethead/loggerhead/static/css locally. At the top I see "viewing /loggerhead/static/css for revision 206"
[20:50] <pickscrape> loggerhead, static and css are all links for me
[20:51] <beuno> pickscrape, aaaaaaah
[20:51] <beuno> I was expecting the path to continue
[20:51] <beuno> so when I jumped into the file view
[20:51] <beuno> I expected to be able to go back
[20:52] <pickscrape> Ah, you mean the branch name part to the left of the 'viewing'
[20:52] <beuno> right
[20:52] <beuno> it deserved some thought
[20:52] <pickscrape> Yes, I didn't want to play with that because my aim here was to add the links without changing the presentation at all
[20:53] <pickscrape> But I suppose I could add the path to the branch to the left of the branch name.
[20:53] <pickscrape> The branch name itself should probably be a link too.
[20:54] <beuno> yeah, this is a big improvement
[20:55] <pickscrape> The problem is once you add paths, you start to expect seeing the branch's directory name, and not nick.
[20:56] <pickscrape> So it might be better doing it with pure directory names and displaying the nick somewhere else.
[20:56] <pickscrape> I have to pop out for 5 minutes... brb
[20:57] <beuno> pickscrape, ok, cool. Just one comment on the branch, and it's mergeable. You have no link to the root
[21:08] <beuno> pickscrape, I gotto run, but if you can add a link to the root, that'll be great. If not, I'll merge anyway when I come back, as this is very practical  :)
[21:19] <lifeless> beuno: see my export patch ?
[21:25] <pickscrape> beuno: not sure if you mean a link to the branch root or to the root directory that loggerhead is serving.
[22:47] <tacone> hello, wondering if I can nest branches one into another. i.e. in my project folder I could have a subfolder which contains libxxx. I'd like libxxx to be referring to an external branch. is that possible ?
[23:26] <tacone> trying again: hello, wondering if I can nest branches one into another. i.e. in my project folder I could have a subfolder which contains libxxx. I'd like libxxx to be referring to an external branch. is that possible ?
[23:27] <Peng_> tacone: Well, you can put a branch inside of another one. The outer one will completely ignore the inner one.
[23:27] <[cliff]> hi all, I'm trying to push my project onto a new launchpad branch and I'm getting this error: Transport operation not possible: http does not support mkdir(). any thoughts?
[23:28] <Peng_> [cliff]: Run "bzr launchpad-login your_username"
[23:28] <[cliff]> aha! :)
[23:28] <meteoroid> hm, why is an svn-import pulling only one portion of a repo?  i branched earlier, deleted that branch - maybe the svn cache is fudged?
[23:28] <meteoroid> jelmer?
[23:29] <tacone> Peng_: is it possibile to get the outer branch to "include" the code of the inner one ?
[23:30] <[cliff]> Peng_, good stuff, everything works. thanks!
[23:32] <meteoroid> only getting 82 rev of a repo with 577
[23:34] <meteoroid> even with --all