[01:35] hi === asac_ is now known as asac [01:35] I just used the mac os x installer and it hosed by bazaar installation [01:36] which bzr -> /usr/local/bin/bzr [01:36] ok nevermind [01:36] new shell solved it [01:42] igc: did you think about using btrees for revgraphcache? [01:43] mwhudson: jam has told me I should but I'm yet to do that [01:43] igc: ok, if jam thinks it's a good idea, it probably is :) [01:44] igc: it seems i'm going to be working on loggerhead some more, and i want to use revnocache, so [01:44] igc: need help with anything? [01:44] igc: and i find the names confusing; is revgraphcache the way of the future? [01:46] mwhudson: I would *love* some help with revnocache [01:47] there's a lot that can be done there and a small amount of it may make it into the core in the future [01:49] mwhudson: I'll whip up a TODO file and commit that so you can see the priorities as I see them [01:54] who here has read the groupcompress stuff enough to grok the design [01:57] igc: thanks [01:58] 3.3G corpus makes my laptop cry [02:02] igc: TODO as i see it: incremental caching updating + use btrees [02:02] igc: not sure there's much else tbh [02:03] lifeless: is bzr one of the projects that will be able to use snakebite? [02:03] hmm on windows where does bazaar ssh keep its config files? [02:03] santagada: snakebite ? [02:03] I want to put some ssh keys in there [02:04] hello lifeless [02:04] mwhudson: incremental writes for incremental updates [02:04] lifeless: www.snakebite.org [02:04] I just updated to 1.11 [02:04] hi keithy, cool [02:04] lifeless: to sum it up they have one machine with 48gb of ram [02:04] :) [02:04] lifeless: ah yes, btrees are write once? [02:05] mwhudson: yes [02:05] that's something of a pain [02:05] mwhudson: not really [02:05] could always abuse the heck out of sqlite again... [02:05] lifeless: for this application it is, i think? [02:05] mwhudson: you can build on top of it; I have a plan! [02:05] i mean, it's less important than having to read the whole lot of it, for sure [02:06] lifeless: ah! [02:06] lifeless: tell me more [02:06] mwhudson: and its important that they are write once, because our fs layer does not have updatable files per se [02:06] mwhudson: due to sftp and ftp [02:07] lifeless: well yes, i don't care about bazaar's needs here [02:11] mwhudson: in the long term you do, because we need an answer in bzr itself, and if its different to what you do, its waste [02:17] mwhudson: also write once has nice cache characteristics, and when you look at eq sqlite internals its essentially writing once at the page layer [02:17] mwhudson: anyhow, take a series of btrees [02:17] query new->old [02:17] take first hit for a value [02:17] write a special value for deletes [02:17] and as the length expands and hits on old trees decrease, repack [02:17] i guess you could do pack repo-like reshuffling too [02:18] right [02:18] on windows where does bazaar ssh keep its config files? [02:18] is the logic for this for pack repos extractable, do you think? [02:18] keithy: I'm not sure, I think it depends on your ssh client [02:18] keithy: its something bzr depends on but doesn't provide itself [02:21] hi, I have a shared repository and when I do bzr branch it is taking forever (> 2-3 minutes).. is there any way to figure out what is wrong? [02:21] sohail: you're branching within the repository? [02:22] lifeless, I am doing bzr branch ~/code/bzr/master ~/bzr/code/bugfix [02:22] sohail: so from the repository, to outside? [02:22] or did you mistype one of those urls' ? [02:23] lifeless, well it seems that ~/bzr/code is the repository [02:23] so seems to be within... [02:23] bzr info ~/bzr/code/ [02:23] Shared repository with trees (format: pack-0.92) [02:23] Location: [02:23] shared repository: /home/sohail/bzr [02:23] on one you said code/bzr [02:23] on the other bzr/code [02:23] oops [02:23] yeah that's a typo [02:23] bzr/code in both cases [02:23] jelmer: I dug up more info about the "mergeinfo capable client" message. [02:24] sohail: ok [02:24] sohail: run bzr info on the result branch, pastebin the output please [02:24] jelmer: It doesn't seem like it's just a collabnet thing [02:24] jelmer: http://www.google.com/search?hl=en&q=Commits+require+mergeinfo-capable+client [02:25] jelmer: For example, there is some discussion of it here: http://groups.google.com/group/openbravo-development/browse_thread/thread/b2aa7aefe7cf14d6 [02:26] jelmer: Supposedly "subversive" 0.7.1 supports it. (I haven't heard of subversive.) [02:26] lifeless, http://rafb.net/p/Y29aDO61.html [02:27] http://www.orkut.com.br/Main#CommMsgs.aspx?cmm=18655944&tid=5297825684124574372&na=4&nst=21&nid=18655944-5297825684124574372-5298061795656704676 [02:27] sorry wrong channel [02:28] jelmer: I don't know if their code would be helpful at all. You can download it here: http://www.polarion.org/index.php?page=download&project=subversive [02:28] sohail: ok [02:28] sohail: so its a repository tree which means its creating a working copy [02:29] yeah, can I somehow make it so that there are no working copies in ~/bzr [02:29] sohail: if you want to be able to edit the files at that path, thats normal; sounds like you have a big tree and the --hardlink option will help [02:29] sohail: on the other hand if you don't want to be able to edit there [02:29] just touch ~/bzr/code/.bzr/repository/no-working-trees [02:30] mwhudson: TODO added. see https://code.edge.launchpad.net/~ian-clatworthy/bzr-revnocache/trunk [02:30] beuno may be interested in this as well [02:30] * igc lunch [02:31] ok so I am using plink [02:31] how confusing why they couldnt just call it ssh [02:32] keithy, ...for one, OpenSSH has that name, so overloading it would mean confusion. [02:32] keithy, ...also, plink does more than just SSH unless I'm badly mistaken -- it also has serial, raw socket, telnet, etc. support. [02:33] k so where does it keep its keys [02:33] keithy: I know nothing about plink; is there some specific thing you need to do - just ask, someone here may know [02:34] keithy, I believe it keeps them in the registry, though it should also be able to talk to any running Pageant instance [02:34] keithy, ...so launching Pageant and adding the keys through its GUI is probably the Right Thing. [02:34] * nDuff isn't principally a Windowsy type, btw, so his advice should be taken with a grain of salt. [02:35] lifeless, ok thanks [02:35] I don't want to edit there, you are right [02:35] I cant be bothered with pageant, its not my server [02:36] that did it [02:36] keithy: so, what do you need to do - just get it working for you on that machine? [02:36] keithy, ...hrm, you have plink but not pageant installed? They should both be bundled in the same PuTTY install package. [02:36] but aegpant is a daemon [02:36] keithy: userspace [02:36] keithy, right, but not a system service [02:36] keithy, ...runs as the current user in the tray. [02:37] keithy: its like ssh-agent, its normal to use it for each user [02:37] * sohail uses pageant with bzr+ssh [02:37] sigh something else to setup [02:37] * nDuff wanders homeward [02:37] the current user is the admin of the box I dont have a user [02:38] I am vncing to the box over a openvpn tunnel [02:38] so I aleady have security [02:38] so I am happy to give a passwordless key to ssh [02:38] keithy: do that then [02:38] if I can only work out where to put it [02:38] just run up pagent [02:39] I think you can right click and tell it to import a key or somethin [02:39] which isnt installed as far as I can see [02:39] oh :( [02:40] I'd read plink documentation then [02:42] arrrgh [02:42] I cant download stuff [02:44] hmm "pageant is allready running" [02:49] is it in the status area ? [02:53] aparently so [02:53] but it wants a ppk file [02:53] time for google ;) [02:54] puttygen is supposed to vonvert [02:54] but it only does private keys [02:54] thats what you need isn't it ? [02:56] my private key is mine [02:57] of course [02:57] why don't you describe your use case [02:57] I'm thoroughly confused [02:57] I want to give my public key to ssh on the remote box [02:57] so he can log in [02:57] its almost as if no one has ever done this before [02:57] hang on [02:57] you want to setup a ssh *server* on the windows machine? [02:58] or a ssh *client*? [03:00] ssh client [03:00] if you are setting up an ssh client, it needs a private key [03:00] the ssh server holds the public key [03:01] if its for your colleague to use, he should setup a private key of his own, and give the ssh server operator his public key. [03:03] ok.. [03:03] its late! [03:04] :) [03:17] wahoo it worked [03:30] That's it for me today - see everyone tomorrow [03:31] ciao [03:42] thanks lifeless, time for bed [03:58] spiv: the other odd thing about pdb: [03:58] (Pdb) raise [03:58] *** AttributeError: Pdb instance has no attribute 'do_raise' [03:59] Yeah. [04:00] invoked by [04:00] try: [04:00] foo [04:00] except: [04:00] set_trace [04:00] ... and now you've lost the exception from the program you're tracing [04:00] jamesh: zigactly [04:00] jamesh: because post_mortem is bust [04:01] spiv: have you landed your fix yet? [04:01] No, but I may as well do that now. [04:03] lifeless: I posted an updated version of the python/valgrind patch that doesn't conflict with trunk (Python 2.7). It was mainly NEWS file and autoconf generated files that had bitrotted [04:03] jamesh: awesome [04:49] poolie: is there a bug for the progress ratio being clipped ? [04:49] 37809/45 [04:50] rather than /45834 [05:01] poolie: ping [05:09] what would be nice, would be running a custom build of python with the packaged stdlib [05:09] + site-packages [05:31] spiv: ping [05:32] lifeless: pong [05:32] is my memory faultier than usual [05:33] I thought we (you and I even) fixed check to detect: text A compressed against text B that isn't actual meant to exist [05:33] or isn't in the ancestry [05:33] lifeless: pong [05:33] poolie: doesn't matter now, bombs away [05:33] :) ok [05:33] lifeless: that sounds familiar [05:33] spiv: care to confirm something for me [05:34] grab a repo object for bzr.dev [05:34] lifeless: but I can never remember the precise details of that sort of thing without looking over the code/commit log, it's just a bit too subtle too stick in my head. [05:35] I have a failing fetch of a text [05:35] Grabbed... [05:35] ok [05:35] .texts.get_parent_map([('intset.py-20050717175247-81cd658f9aaa2731', 'john@arbash-meinel.com-20051219174825-3046c2b52fda89dc')]) [05:35] -> [05:36] ...(('intset.py-20050717175247-81cd658f9aaa2731', 'robertc@robertcollins.net-20050919060519-f582f62146b0b458'),)... [05:36] t = r.revision_tree('robertc@robertcollins.net-20050919060519-f582f62146b0b458') [05:36] t['intset.py-20050717175247-81cd658f9aaa2731'].revision [05:36] erm [05:36] t.inventory['intset.py-20050717175247-81cd658f9aaa2731'].revision [05:36] 'robertc@robertcollins.net-20050915133236-141471392006b464' [05:37] 'robertc@robertcollins.net-20050915133236-141471392006b464' != 'robertc@robertcollins.net-20050919060519-f582f62146b0b458' [05:38] lifeless: yes, that's exactly what I see here. [05:39] spiv: grah [05:39] spiv: unless I'm reading that wrong, that means that there is delta of intset.py-20050717175247-81cd658f9aaa2731 to a text version that is probably spuriously introduced by another inventory [05:40] now I need to find out why my clone operation is dropping that text, and why we are not fixing that delta up [05:40] That's my reading too. :( [05:41] but - I started at 8, and this isn't going to be that short an investigation [05:41] so, I'll look tomorrow [05:41] It does sound a lot like the check/reconcile issue I thought we fixed, but maybe that was a subtly different case... [05:41] /wave [05:41] lifeless: see you tomorrow [05:42] lifeless: try not to get flashes of inspiration over dinner, it'd be terrible if you solved this tonight ;) === spm_ is now known as spm [07:34] hi all [08:03] is bzr supposed to work with py2.6 ? [08:09] ionel_mc: Yes. More or less. [08:09] ionel_mc: I don't think it's officially supported yet, but bugs are fixed whenever they're discovered. [08:11] ah, well, i got it to build (without the c-speedups) [08:13] speaking of that - are there any benchmarks in regard of the c-speedups ? === gdmfsob is now known as mishok13 [10:40] hey how can I add a dir but not its contents. [10:40] I am trying to do a bzr mv but I am running into already versioned problems. === kiko-afk is now known as kiko === kiko is now known as kiko-afk [13:28] jelmer: ping [13:31] Whoops, when you accidentally corrupt a bzr repo, don't do they same thing to your other copy of the repo... [13:32] s/they/the/ [13:33] (Anyway, no big deal. Even if it's not recoverable, all it means is I'll waste a few MB of bandwidth pulling things again.) [13:41] Is there a more proper way of testing for the existence of a shared repo than running "bzr info $path" and looking for "Shared repository" in the first line? [13:46] Well, I'm sure you could do it using bzrlib. [13:47] This is going to be called by a (probably) PHP script, so not until bzrlib gets PHP bindings :-) [13:47] Ah. [13:48] You could check for the existence of $path/.bzr/repository/shared-storage, but that's evil, and may not work on older (or newer) repos. [13:49] I wasn't going to suggest a hack like that, but you're already using PHP... ;) [13:49] you could use xmlinfo and check for /info/location/shared_repository elements [13:49] Ah, that sounds good. [13:51] Isn't that overkill? [13:51] why? [13:51] Also, is that in core bzr, or is it a plugin? [13:52] Lo-lan-do: xmloutput plugin [13:52] Lo-lan-do: You could write a small Python script to do it using bzrlib. [13:53] * Tak shrug [13:53] Would it be better than calling bzr info? [13:53] Lo-lan-do: Would what be better than who? [13:53] (I'm *very* lazy, which is a virtue for programmers :-) [13:53] Writing a script with bzrlib, vs. calling bzr info. [13:53] Lo-lan-do: Well, I doubt "bzr info" is intended to be scriptable. Its output format could change in the future. [13:55] for example one change which may happen is localization, replacing all strings with native language ones. There may also be significant restructuring or even renaming of things. [13:56] Okay. I'll start with bzr info, and write a bzrlib script during (of after) the weekend, since I've been volunteered to learn some bzrlib and use it at FOSDEM. [13:58] is there any plan to ever make, say, a C binding to bzrlib? [14:01] Peng_: hi [14:02] jelmer: Good morning. :) [14:03] Peng_: 'afternoon :-) [14:03] * jelmer is finally back in his native timezone [14:05] Or that. :P [14:12] Lo-lan-do: Here's a very simple script, if you want it: http://paste.pocoo.org/show/102739/ [14:13] jelmer: hey, trying to use bzr-git and it's trying to import foreign_vcs_registry from bzr-foreign and it's not in that project, is one of them out of date? [14:19] jelmer: So, um, about my ping. I have copies of lighttpd-1.4.x imported with both bzr-svn 0.4 and 0.5. I tried to pull from the 0.5 copy into the 0.4 copy, but bzr exited with "Newly created pack file ... has delta references to items not in its repository". Now "bzr check" fails with "parent_id ... not in inventory". === kiko-afk is now known as kiko [14:27] Peng: Thanks. [15:01] is there a way to get bzr shell not to lock the branch it's using while it's idle? [15:11] Augh, another bzr repo bites the dust... [15:11] * Peng_ shakes his fist at lighttpd and bzr-svn. [15:11] Different error this time! :) [15:17] This is killing me. If I "bzr branch" copies of A and B into a repo, and check, it's fine. If I then branch C, and check, there's an SHA-1 mismatch. [15:17] If I create a new repo, and just branch C, it's fine. [15:18] The upstream C is fine, but the upstream A and B are in a repo corrupt in a different way. [15:20] james_w, hi [15:20] james_w, do you have bzr.dev ? some bits of bzr-foreign are in bzr.dev these days [15:20] hey jelmer [15:20] jelmer: ah, that will be it [15:22] Peng_: Can you reproduce this using vanilla branches created with bzr-svn 0.5.0 ? === Goosey_ is now known as Goosey [15:37] jelmer: Ehh. The whole point of the exercise is that I want my old 0.4 branches. :P [15:38] I think "bzr check" goes a lot faster with a btree repo. :) [15:38] ...Wait, I'm not using a btree repo here. Huh. [15:39] jelmer: No, I can't reproduce it. [15:42] Sigh. === fawek_ is now known as fawek [16:33] Hello. [16:33] Is there a proper way to simulate network failures in the bzr test suite? [16:53] hey guys - some months ago I moved my project from subversion from svn to bzr - unfortunatly some history was lost (450 revs => ~1/3 of total history) [16:53] anyone an idea how to get this history back into my bzr branch? [16:54] because I liked to play around with subversion and sometimes changed the general dir layout ... which bzr-svn seems not to handle correctly [16:55] depending on the parameters I pass to bzr svnimport I get different parts of the history - but not the complete one [16:55] git-svn seems to handle it quite good (everything there) - but bzr-git does not want as I want ;) ... [16:56] (and the last question is of course: how to merge it into the current branch...) [17:01] s/some months/one year/ ;) [17:02] Necoro: have you tried svn->mercurial->bzr? [17:02] santagada: nope ... but I thought, that the bzr-hg plugin is quite ... outdated [17:02] Necoro: or merging the diferent runs of svnimport? [17:03] santagada: merging won't work, because the history pieces are all disjunct [17:03] uhmm [17:04] Necoro: there are other tools to move svn to bzr isn't it? [17:05] probably ... but in the end it should be possible to put my current branch on top of the old history ... so anything which produces completely differnt rev-ids won't work I assume [17:06] Necoro: maybe then you can cherrypick the revisions after the svnimport into this new branch [17:07] Necoro: but those are just ideas, I don't know svnimport [17:08] jelmer: am I reading correctly? - bzr-svn needs bzr-rebase-0.4.3 ... which is not released yet? [17:08] hmm - nvm ... going to use trunk [17:15] Necoro, yes, that's correct [17:15] Necoro, rebase is not required though [17:16] Necoro, only useful if you need to run bzr svn-upgrade [17:16] abentley, hi [17:16] jelmer: which is what I wanted to use ;) [17:16] jelmer: hi [17:16] abentley, Is it correct that merge looks at more than just the file id for path conflicts? [17:17] abentley, I have a very obscure use case here (same file ids but no shared revision history) [17:18] Necoro, is this repository public btw, and if not, what is the sort of thing that git-svn preserves but bzr-svn doesn't? [17:18] jelmer: I think so. [17:19] jelmer: repo is public (https://svn.origo.ethz.ch/portato/) -- and the difference is quite simple: git preserves all ~650 revs, where as bzr only preserves ~250 [17:19] bzr thinks a branch is locked by a process that no longer exists - what's the best way to force removal of this lock? [17:19] Tak, bzr break-lock [17:19] Tak: Cut and paste the command it gives you? [17:20] jelmer: because at some time I moved the whole directory structure up one level (i.e. removed the top-level dir) -- and bzr either stops or starts here ;) [17:21] break-lock seems to have worked, thanks! [17:22] Lo-lan-do: it was telling me: "Unable to obtain lock file: [...] Held by: [me] (Process #[somedeadprocess])" [17:23] Necoro, have you tried: bzr svn-import --layout trunk0 ? [17:23] jelmer: hmm - not yet [17:28] jelmer: http://dpaste.com/116602/ [17:28] import worked (but seeing revno 148 it seems not to be correct) - but running svn log the error above happened [17:37] Necoro, thanks, that seems to be the same issue as for which you reported a bug [17:37] jelmer: oh - ok [17:38] Necoro, (svn-upgrade is pointless on a freshly cloned branch btw) [17:40] jelmer: it is not freshly cloned -- it is the one cloned about a year ago [17:40] wanted to upgrade the revision-ids so it could merge ;) (given that there is something to merge with ^^) [17:40] ah, ok :-) [17:42] in theory it should be ease ... here I have the revisions i+1..HEAD and there I have 1..i ... now I just need to glue them together ;) [17:43] Necoro, I'm trying to figure out what the issue is [17:47] abentley, it looks like it will just give path conflicts but after I resolved that it seems to handle things just fine \o/ === mark1 is now known as markh [18:15] so ... what would work is to convince rebase, that it should rebase branch B on top of A - even if they do not share a common ancestor [18:16] (because HEAD(A) = BOTTOM(B)-1) ... but can't find a way to do so [18:19] Necoro, why would you need to rebase? [18:19] because I want to join branches A and B [18:19] I still don't understand why a merge would not solve your problem... but I'm new with bzr [18:20] santagada: in a merge, I would have all my history somewhere in a branch ;) - and not in the mainline [18:22] Necoro: I think you have to somehow tell bzr that B is a checkout of A, and all of B revisions should be replayed on A [18:22] santagada: yap [18:22] Necoro: maybe rebase could do this, but I think there is probably a simpler way [18:23] well ... "replay revisions" is exactly what the purpose of rebase is [18:23] ;) [18:23] Necoro: also the checkout and stacked branch are similar [18:24] Necoro, but why rebasing without common history? [18:25] jelmer: the history is common ... branch B starts right after branch A ends [18:25] jelmer: each of those branches are the result of diferent runs of svnimport [18:25] Necoro, and git-svn imports this correctly? [18:25] Necoro, in that case, it really is an issue with bzr-svn [18:26] jelmer: git-svn seems to just have not tried to split the svn-repo up in branch and tags etc, but just see it as ONE branch ;) [18:26] Necoro, ahh [18:26] (or I have just configured it wrongly ^^) [18:27] Necoro, stitching the branches together this way won't work well with rebase though, as the file ids will be different [18:29] Necoro, bzr-svn can import like git-svn does, as a single branch, but you probably wouldn't want that.. [18:33] jelmer: so - I just did a "bzr svnimport --layout=root" and then an "bzr split" ... [18:34] Necoro, right, that's how to do that.. [18:34] Necoro, that will work, but e.g. won't preserve tags as bzr tags and won't share history with other branches in the repo (as there's only one branch created) [18:35] tags can be added later on by hand ;) - and other branches are just ... well not existing/important [18:36] the project is not this big [18:36] jelmer: btw: this time, the KeyError did not occur [18:37] Necoro, no, as bzr-svn would be ignoring all svk data [18:37] since there's no svk:merge properties set on the repository root [18:37] Necoro, is this a one-time import, or are you going to push back to svn? [18:37] one-time [18:37] just want to re-add history [18:41] ok - so I'll wait until this svn-upgrade bug is fixed. then I should be able to upgrade my current trunk and rebase it onto the svn-stuff [18:45] hi [18:46] i've posted a question regarding file ids i need to reconcile, if anybody has any input it would be appreciated: https://answers.launchpad.net/bzr/+question/58337 [18:48] jbalint: those two files were added indepedently in trunk and branches/branch_5_1 ? [18:49] jelmer: no, it was a migration from an svn repo [18:49] jbalint, I mean in the svn repo [18:49] jelmer: i'm guessing it was a standard svn 'copy', i can take a peak. do you know how it would be indicated? [18:50] jbalint: the entry in the "svn log -v" for the second revision (6636) would tell [18:52] Hello, is there a document/mail that describes what are the future plans for bzr? I keep reading about 'brisbane-core' but I can't figure out exactly what this is going to be like. [18:54] alf: lp:~bzr/bzr/brisbane-core [18:54] is where it lives, I think the commit log may be some indication [18:54] I don't think there's a broad roadmap [18:54] at least not aware of one [18:54] jelmer: yeah, looks like some stuff was moved around at that rev [18:55] jelmer: everything moved from /x/ to just / [18:57] jbalint, but what sort of operations ? Just "A" without "(from: /...)" ? [18:58] jelmer: no, it shows "Copied from path" (i'm using tortoise svn) [18:59] jbalint: For those individual files or the branch ? [18:59] jbalint, It needs to be from the branch for bzr-svn to create matching file ids, as bzr doesn't support copies yet [19:00] jelmer: what do you mean "from the branch" this is just a re-organization inside the branch http://www.improvedideas.com/files/svn_mv.PNG [19:01] jbalint, ahh [19:01] hold on a second, rev 6636 is interesting [19:02] jbalint, I mean, only copies of the branch root will preserve the file id of any affected file [19:02] in all other situations the file id will change [19:02] jelmer: does svn have this same concept? [19:02] jbalint: svn doesn't have the concept of file ids that have to be unique [19:02] jbalint, and it supports copies, whereas bzr does not [19:03] jelmer: so here is 6636, http://www.improvedideas.com/files/svn_mv2.PNG it looks like the merge into trunk re-arranged all the files [19:05] jelmer: this was all done with the svnmerge python script at the time. but we're not even using svn anymore, so i need to figure out some way to be able to merge again - with bzr [19:05] jelmer: ok - invoking git-svn in the correct way, it actually produced what I was looking for ;) - though it took waaaay longer than with bzr - and it checked out the whole repo like ... 50 times [19:05] jbalint, there isn't much that can be done about this until bzr gets support for tracking copies [19:05] Necoro, what is it you're looking for exactly? [19:06] jbalint, for the current situation, the only thing you can do really is to fix the conflicts [19:06] jelmer: checking out the svn-repo and deal correctly with the "one-level-up"-move and thus return the complete history [19:07] (the same I got with bzr-svn-import --layout=root + bzr-split) [19:07] jelmer: i'm willing to do that, but afaict i won't work because bzr wont merge files with different file ids [19:07] Necoro, but that's importing the svn repository as a single branch and then just throwing some stuff out? [19:08] jelmer: i get a contents conflict on every file [19:08] jbalint, yeah, that's true. there's no way to associate more than one file id with a file as far as I know, but you may want to ask on the list. [19:08] jelmer: ok. thanks for the info! [19:09] jelmer: true - git does it in a smarter way - there I really only have the trunk-data in the end -- though the complete one [19:09] Necoro, so where does bzr cut off history? [19:09] Necoro, since if there's enough info for git-svn, there should be enough for bzr-svn (which already tries to follow branch history completley) [19:10] I think the problem was that Necoro moved the trunk dir around [19:10] santagada, that's not a problem [19:10] santagada, at least not with bzr-svn >= 0.5.0 [19:10] upto revision X I had everything in /local/trunk - after rev X in /trunk ... and bzr splits at that X (i.e. I either get: 1..X-1 or X..HEAD) [19:11]