[00:36] humm [00:37] i just tried out bzr-search and i think its corrupted my bzr folder, all operations seem to get stuck at Stage:Indexing...:Saving group 3/4 [00:37] is there any way to recover? [00:42] morning [00:43] morning [00:52] help :) i've seemed to have corrupted my .bzr folder? i ran a bzr check, which worked fine, but when i bzr up - it hangs at Indexing...:Saving group 3/4 [00:52] bah [00:53] was the bzr-search module [00:53] plugin eevn [04:06] Im trying to get a file back which was removed in a commit. Im doing bzr revert -r 14 '80-system-jpeg-png-sqlite.diff' and getting bzr: ERROR: Path(s) are not versioned: 80-system-jpeg-png-sqlite.diff. I've tried full patch to the file also. Am i doing something wrong? [04:06] * igc bbiab [04:07] *path [05:01] stefanlsd: that sounds like a bug. Maybe try 'bzr cat -r14 ...'. If that doesn't work, I'd create another branch, and try without the pathname. That should recreate the file and you can copy it from there. Having said that, we really want your use case working so please raise a bug. [05:03] igc: ok thanks. i did a bzr revert -r14 and got the file. then a bzr revert and copied the file back in.. but yeah, sounds bug like [05:06] stefanlsd: cool. The main catch with re-adding the file is that it will get a new internal file-id (which can cause issues with merges crossing the delete/add boundary). I'm pretty sure add has a --with-ids flag (see bzr help add) but it's annoying to have to worry about that. Hence the need for a bug report so we don't forget to fix it! [06:57] you lost buggerror [07:56] I have something that is puzzling me. I have a local shared repository with 3 branches into it. There's a main branch, a branch branched from the main called sub and the last branch, branched from sub called project. [07:57] The idea was to be able to commit changes to each branch and then merge the changes down to sub and then project [07:57] and if needed create other branches from the sub branch to start other 'projects' like the project branch [07:57] all this works well on my local setup [07:59] but I was wondering when I want to push things to share, I can push any branch with no problem, but I couldn't find a way to push a shared repo. [07:59] I guess it's not possible. And I'm possibly thinking this the wrong way... [08:00] Any one could give me her/his thoughts on this? Thanks [08:02] AntoineLafontain: There might be a plugin to make pushing an entire repo easier, but mostly you just push each branch one at a time. [08:03] and if I branch all the branches to say, another computer, will they keep their relational history... main being the parent of sub and so on? [08:13] AntoineLafontain: That's only a little bit of meta data; if it's wrong, you can do "bzr pull --remember" (parent) or "bzr push --remember" (push location) to fix it. [08:15] humm, I think I get most of what you say... Will need toexperiement to "grasp" thing for myself. But thx for confirming that there's a way and nothing wrong with my base setup. [08:16] AntoineLafontain: What were you referring to? The default "push", "pull", "merge", etc. paths/URLs? [08:17] well I did all this on my local machine, and using the default merge to propagate changes "down" my branch, using the hierarchy created by branching. [08:18] but when I considered pushing my setup to my server via sftp... I couldn't figure out how I would keep this relation between my branches... [08:19] AntoineLafontain: Do you have ssh access to the server? Then you could run "bzr pull --remember", like I said. Or you could manually edit .bzr/branch/branch.conf over ssh or sftp. [08:20] the --remember option isn't only for remebering the location of the parent branch? [08:21] sorry, I think my questions are a bit too basic... my experience with bazaar and versioning is quite limited... [08:21] AntoineLafontain: That is what it's for. [08:22] okey, so I get this part... [08:22] humm I guess that my explanation isn't clear... let me try again [08:22] I made a branch from a remote repo and I called that branch main [08:22] it is a local branch [08:23] I've then branched that main branch into a sub branch and made some additions to it... files, folders etc [08:23] then I made a branch of that sub branch called project [08:24] from this setup I can update main or sub and then propagate the changes to project as needed [08:24] using merge [08:24] this works quite well [08:25] but if I would like to move this setup on another machine... or share it with a co-worker... [08:25] OK, so push your branches somewhere. [08:25] I push all the branches to the server, but if I branch from the branch called sub from the server, the "relation" it had with main is broken [08:26] What "relation"? [08:26] eg, if I commit some changes to main [08:26] I can just move to sub and then do a bzr merge to get all the changes to my sub branch from main [08:27] I feel I just get some concepts wrong... not that bazaar can't do what I want actualy... [08:29] You can still merge or whatever you want to. You may have to run "bzr merge --remember /path/to/whatever" to fix up the stored URL once, but that's all. [08:29] If revisions lost their identities whenever you pushed, DVCSes would be kind of useless. [08:29] :P [08:29] Well, they just wouldn't be very "D". [08:29] haha [08:30] okey, I think I get it (somewhat). will just get my hands dirty and try it to make sure I do get it [08:30] thank you for listening to my ramblings ;) [08:31] :) [09:14] * igc dinner [10:05] Is it possible to copy a versioned file from branch A to branch B while retaining the version history? [10:05] I think "copy" is the wrong word [10:05] what are A and B? are they related? [10:06] well, I have A and B, and I'd like to put them in the same branch (currently in seperate branches) [10:07] merge doesn't work because they didn't start from the same branch [10:08] merge can work [10:08] ok... [10:08] I need a flag or something? [10:08] I forget how to use it to merge unrelated branches, sorry [10:09] --weave seems to do it [10:09] oops [10:09] or not [10:10] I think it was -r0.., but I can't seem to find anything on google [10:10] try asking on the list? [10:24] bob2: got it [10:24] bzr merge -r 0..-1 ../other-branch [10:24] then bzr ci --unchanged [10:25] you shouldn't need --unchanged [10:25] I do, for whatever reason... [10:25] otherwise bzr status doesn't work [10:25] eh [10:26] mkdir C [10:26] cd C; bzr init [10:26] bzr merge -r 0..-1 [10:27] +N blah blah blah [10:27] bzr status [10:27] working tree is out of date, run 'bzr update' [10:27] bzr update [10:27] -D blah blah blah [10:27] maybe I'm doing something wrong? === abentley1 is now known as abentley === abentley1 is now known as abentley === abentley1 is now known as abentley === abentley1 is now known as abentley === abentley1 is now known as abentley === abentley1 is now known as abentley [11:26] I have got a severe problem [11:26] bzr: ERROR: Unknown record type: '\x02' on commit [11:26] is that bad :( ? [11:27] LeonBrussels: There should be a full traceback in ~/.bzr.log, putting that in a pastebin will help people diagnose the issue. [11:31] Traceback: http://pastebin.com/f468824e6 [11:31] It's not a terribly large or complicated repo [11:35] oh, and my bzr check doesn't look very positive either... [11:37] Well, I don't know. [11:37] But someone else who does will show up sometime soon. :) [11:47] * LeonBrussels has decided he hates bzr [11:56] LeonBrussels: :( [11:56] LeonBrussels: I'm surprised there's no one else around to be able to help, the channel is normally much busier than this. [11:57] Actually, thinking about it, all the Canonical people are at their annual conference. [11:57] So that's probably not helping. [12:20] hey. how do i download a specific revision of a project [12:22] Ddorda: "bzr branch -r 123 whatever"? [12:23] so i can do "bzr branch -r 91" and it will download revision 91? [12:23] Uh-huh. [12:24] ערקשא [12:24] great* [12:25] many thanks :D [12:26] :) [12:27] Ddorda: You can also use "bzr revert -r 123" to make the working tree look like it's a certain revision. [12:27] okay.. thanks === nevans1 is now known as nevans === Kissaki^0ff is now known as Kissaki [15:41] is there a better way of checking whether a branch is bound than get_bound_location? [16:07] Just encountered this failure, http://rafb.net/p/CEC6g533.html [16:12] hi! [16:13] anyone knows where can I get a bzr-rebase compatible with bzr 1.15rc1? [16:14] servilo: lp:bzr-rebase? [16:15] GaryvdM: hmmm, will try that... [16:15] do you know how stable is it? [16:17] I'm running it - have no problems. [16:17] GaryvdM: great! are you using bzr 1.15rc1 as well? [16:18] no [16:18] 1.14.1 [16:22] hi. I am playing with bzr-svn and dpush. I want to have a central bzr repo from which all my developers can branch off, and from which I can pull and push to a central svn repo (upstream). I configured the upstream svn repo to support pre-revprop-change hook in order to rewrite the author, and use dpush in order not to push metadata properties (as they are not wanted in upstream). The main idea here is to use bzr but try not to interfere with upstrea [16:22] m (because normally we can't) [16:23] now, I am getting this strange behaviour: [16:23] I have repo A (from which I dpush), repo B (branch of A) [16:23] when I dpush from A (to svn), and then (in B) pull (from A) [16:23] I get a message that the branches have diverged [16:24] ricardokirkner: yes, that's the disadvantage of dpush [16:25] ricardokirkner: it doesn't retain all of the metadata, and so the revisions change slightly [16:26] jelmer, is there any way around this? (as the branches aren't really different) [16:26] maybe using rebase? some option? [16:26] or, once I dpush I loose any chance to continue my branches? [16:26] ricardokirkner: bzr pull --overwrite in branch B should fix it, or using regular push [16:27] jelmer, alright , I'll try using pull --overwrite [16:27] ricardokirkner: (--overwrite that'll remove any extra revisions you have in branch B) [16:27] as direct push to svn is not what I want (my client has complained that a lot of properties appeared in the svn tree -- as they are using svn 1.4, its file props) [16:28] ricardokirkner: so, one of the things you can do is not pull from branch A until you've dpushed branch A into svn [16:28] ricardokirkner: as the revisions won't change after they have been dpushed [16:28] jelmer, but thats what I've been doing [16:28] that's what made me wonder [16:29] I pushed from B to A , then dpushed from A to svn, then pulled from A to B [16:29] and got the error [16:29] ricardokirkner: yes, because the revisions you pushed from B into A have been rebased by dpush [16:31] GaryvdM: to install bzr-rebase local to my account is it enough to copy it under $HOME/.bazaar/plugins? no build necessary? [16:35] * servilio answers himself: yes, just copying is enough [16:35] though bzr checkout lp:bzr-rebase $HOME/.bazaar/plugins/rebase is even better [16:36] jelmer! [16:36] jelmer: got 1.15rc1 built and working, thanks again! [16:37] jelmer, and is this not fixable somehow by rebasing B as A was rebased? (without having to overwrite B entirely) [16:40] servilio: np :) [16:40] ricardokirkner: not yet, for that dpush would have to store the information of how things were rebased so rebase could pick it up [16:43] jelmer, and the problem with pull --overwrite is that I can't do anything in branch B until branch A has been dpushed to svn (in order to avoid any diverged message), right? [16:44] so, if developer B pushes to A, and does nothing else on branch B until branch A has been dpushed, and after that pulls with overwrite from branch A , i should not have any issues, right? [16:45] it's a workflow limitation, but it may work [16:45] ricardokirkner: yes [16:46] ricardokirkner: please file a wishlist bug about dpush saving a revid map if that bit seems useful [16:48] is it possible to do a rebase from a subversion source? I am trying but get a "different rich-root support" error [16:48] should I change the local branch format? [16:48] servilio: that sounds unrelated to rebase [16:48] jelmer, if dpush saves a revid map (locally I guess, as I don't want to push any metadata to the svn server), that would allow bzr to rebase branch B accordingly, and prevent the branches to be interpreted as diverged? [16:49] servilio: you get that when you to pull, too, don't you ? [16:49] servilio: you need to upgrade the other branch to a rich root format [16:49] jelmer: the other branch is a subversion repo [16:49] ricardokirkner: yes, you'd just have to specify the revidmap to dpush (so it can store it) and rebase (so it can load it) [16:49] * SamB doesn't get the point of dpush [16:49] servilio: Sorry, I mean your local branch [16:49] SamB: doesn't set any bzr-specific svn data [16:50] jelmer: that seems pretty useless to me! [16:50] SamB: some people get annoyed by the file properties bzr-svn sets if you're running against a svn < 1.5 server [16:50] I guess if the repository doesn't allow revision properties, maybe it's useful ... [16:50] jelmer, alright.. .I will try pull --overwrite to see if it works for my needs, and file a wishlist for dpush (adding the relevant information for this irc log if you agree) [16:50] jelmer: what version should I upgrade it to? I tried bzr upgrade and it says it is already at the newest (I know you can override to an "experimental/devel" format forcibly, but just don't know which one is the right) [16:51] servilio: "bzr upgrade --default-rich-root" [16:51] jelmer: do you know anything about why a repository that does allow revision properties would disallow mergeinfo ? [16:52] SamB: yes, mergeinfo was added later [16:53] jelmer: does it also depend on something about the repository, in addition to the server ? [16:53] jelmer: worked great! thanks! [16:53] SamB: not that I'm aware of [16:53] jelmer: hmm, I wonder how sourceforge does this then [16:55] since right now the dosemu SVN on sourceforge doesn't allow mergeinfo, but they say that a project admin can upgrade it to do so ... [16:56] * SamB looks for the ticket ... [16:58] jelmer: ah, here's the ticket where they told me this: https://apps.sourceforge.net/trac/sourceforge/ticket/317 [16:58] Error: bug 317 not found [16:58] ubottu: uh, it's definately there! [16:58] Error: I am only a bot, please don't think I'm intelligent :) [16:58] * SamB was only teasing [16:59] jelmer: can you make anything of that ? [17:01] SamB: that URL requires me to log in [17:01] jelmer: it does ? [17:02] that's wierd ... [17:02] SamB: ah [17:02] SamB: yeah, there's a format change required too for mergeinfo [17:03] jelmer: are you going to write about that on the ticket ... or should I just reopen it and let the sf.net people do that ? [17:04] SamB: I don't see what there is to comment on [17:04] SamB: I mean, what is your question to me exactly? [17:04] nevermind, I'll just reopen and see if they can answer ... [17:05] SamB: You'll have to dump and restore the repo as they say in order to use mergeinfo [17:06] now, my question for you is: can bzr-svn, after a repository has been upgraded to support mergeinfo, go back and fill that in for bzr merges ? [17:06] is svn:ignore supported "full-duplex" in bzr-svn? I can see in workingtree.py that it import it, but aside of the tests, can't see any other reference to svn:ignore in the code [17:07] SamB: it'll be a new repo, so you'd need a new bzr-svn import i think [17:07] dash: wouldn't it just be a new representation of the same repo? [17:07] servilio: no, it's only supported in working trees [17:07] i don't know what 'representation' and 'same' mean there [17:08] jelmer: thx! [17:08] SamB: that's not possible, you can't change the file properties in historic revisions [17:08] jelmer: ouch :-( [17:09] * SamB thinks bzr-svn ought to ask for confirmation before pushing to a repository that won't allow mergeinfo for the first time ... [17:10] how would that help? [17:10] dash: well, that way you could maybe do something about getting the repository upgraded *first* [17:10] SamB: why? svn doesn't do anything like that either if the repo doesn't support mergeinfo [17:11] SamB: what's wrong with upgrading it later? just rebranch [17:11] SamB: and svn users benefit from bzr-svn setting svn:mergeinfo, bzr-svn users don't benefit from it (since bzr-svn doesn't look at svn:mergeinfo itself) [17:11] jelmer: hmm. [17:12] jelmer: is what dash says about having to re-import true? [17:12] SamB: yes, that's the only way you can get bzr-svn to set those svn:mergeinfo properties [17:13] jelmer: I mean, after you do the dump/restore, does bzr-svn need to re-import the repository ? [17:14] SamB: depends on if the dump/restore retains the repository UUID [17:14] SamB: You can get it to retain the repository UUID [17:15] SamB: but I think you explicitly have to set the old UUID, otherwise it generates a new one [17:15] jelmer: hmm, the help for "load" appears to indicate that if you load into an empty repo, it sets the UUID from the stream ... [17:17] SamB: ah, I might be wrong then === servilio is now known as Guest21385 [17:18] and I just did a test dump, and "svnadmin dump" seems to dump the repository UUID === servilio_ is now known as servilio [17:19] jelmer: and are SVN revisions from repositories with different UUIDs considered distinct by bzr-svn ? [17:20] SamB: yes [17:20] one hopes so [17:20] * SamB wonders why git-svn doesn't use the UUID instead of the URL [17:21] git was written by C programmers [17:21] git-svn is in perl though [17:21] well, perl was written by C programmers too. ;) [17:21] so was Python [17:22] disputable! [17:22] anyway [17:22] isn't pull the command to get a local copy in sync with the remote subversion repository? [17:22] are you saying that Python is written by wannabe C coders ? [17:22] git succeeds because it makes the same optimization tradeoffs as C [17:22] trading correctness for performance :) [17:23] dash: are you talking about "git merge"? [17:23] servilio: right. it creates a bzr branch containing all the revisions of the remote svn branch [17:23] * SamB wants a better "git merge" [17:23] servilio: why do you ask? [17:23] dash: I already have the local branch, but I need to get it in sync with the repo to be able to push the locally committed changes [17:24] it sounds like you just tried it but it didn't work [17:24] oh, you did say pull, sorry. I did not read what you wrote :) [17:24] SamB: I am getting an exception regarding mismatching revisions [17:24] servilio: paste it somewhere? [17:24] here, if it's short ... [17:24] not short, any pastebin at hand? [17:25] I know none [17:25] !paste [17:25] pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) [17:25] SamB: nice :)) [17:26] servilio: I had no idea if that would actually work or not ;-) [17:26] http://paste.ubuntu.com/176517/ [17:27] servilio: that's a known bug in 0.5.4, fixed in 0.6.0 [17:27] jelmer: using 0.6dev [17:27] with bzr 1.15rc1 [17:28] servilio: which 0.6dev revision? [17:28] (I fixed that bug yesterday) [17:29] how do I see the revision? [17:29] 'bzr revno' [17:29] jelmer: 2993 [17:29] jelmer: is http://bazaar.launchpad.net/%7Ejelmer/bzr-svn/0.6/ the proper URL to checkout from? [17:30] servilio: no, http://people.samba.org/bzr/jelmer/bzr-svn/0.6 [17:30] 2993 should include the fix though.. [17:30] * servilio goes to switch to the new URL actually checking out to plugins dir directly... [17:32] jelmer: @2997 now, trying again... [17:32] jelmer: same result [17:32] jelmer: want me to gather some more data beyond the traceback? run it in verbose mode? [17:32] servilio: please file a bug [17:33] servilio: is this a public repo? [17:33] jelmer: no, local to the university I work [17:33] but I have full access to that machine, could get some data on the repo [17:33] maybe it is still in old format or something [17:34] no, that shouldn't be relevant. this very much looks like a bzr-svn bug [17:34] servilio: is it local for a particular reason? [17:35] SamB: for most of the code, just lack of time to move it out [17:36] some other code is quite local to us [17:36] servilio: as in, private ? [17:36] though publishing it wouldn't do any harm [17:36] SamB: as in only accessible from campus network [17:36] ah, so as in, you don't think anyone else would want it ? [17:37] SamB: at the beginning, yes [17:37] so you could probably get permission to give jelmer a copy of the repository, then ? [17:37] SamB: started with branding stuff, then just put there stuff that might have lived outside [17:38] SamB: yes [17:38] I can give it a try [17:38] don't expect any trouble getting the OK from the stakeholders [17:39] servilio: Perhaps wait until that's really necessary [17:39] jelmer: OK [17:39] jelmer: should I file a new bug or put the new data under an existing one? [17:39] jelmer: well, he seems to think it'd be mostly a matter of asking ... [17:39] servilio: new bug please [17:40] SamB: yes, but I was mainly asking so I can have a quick try to see if I can reproduce + fix it [17:40] jelmer: I think I know what is happening [17:40] whatever ;-) [17:41] * servilio goes to do a short test... [17:42] I just thought I'd ask about it, since I know people at universities often keep stuff private merely because they haven't bothered to make it public ... [17:45] hmmm, there is really a mismatch [17:45] servilio: can you tell what it's doing wrong based on "svn log -v" ? [17:46] the files at the svn repo are at revision 362, but somehow bzr-svn got its metadata at 387 [17:46] servilio: is 387 mentioned anywhere in log? [17:46] servilio: is that particular path changed in 387 ? [17:46] jelmer: will see, svn repo is at 427 [17:47] yes, I think I found the cause [17:48] I changed the base URL of the repo [17:48] it happened at revision 387 [17:48] :) [17:48] servilio: can you please mention this in the bug report ? [17:48] yep [17:48] servilio: Possible with the changes as printed by "svn log -v" from that revno [17:48] jelmer: no problem [17:49] jelmer: what about doing a bzr switch on the local bzr branch? [17:49] could it fix this? [17:50] servilio: no, this really is a bzr-svn bug [17:50] ok [17:50] filing new bug... [17:55] jelmer: what about rebase? shouldn't that make the local branch sync with the remote svn? (just curious) === nevans1 is now known as nevans [17:56] servilio: rebase basically replays your local commits on top of the remote ones [17:56] servilio: the extra revisions you have locally I mean [17:57] jelmer: rebase just says: "No revisions to rebase." [17:57] servilio: if you don't have any extra revisions locally, that's correct [18:05] jelmer: what is better: paste the outputs directly or attached as files? [18:07] servilio: paste directly please [18:07] ok [18:12] jelmer: just to confirm: I am including the output from svn log and bzr pull; am I leaving anything out? [18:19] servilio: "svn log -v" ? [18:19] servilio: other than that, that should be sufficient [18:19] ok [18:42] jelmer: is it possible to use markup in the bug information area? [18:43] servilio: don't know [18:46] is there a way to have a bzr smart server with authentication and allow writes, that doesn't expose the full filesystem path? (like bzr+ssh does) [18:47] ricardokirkner: ClueBzr? [18:47] is it stable enough? (I just saw a mention of it recently) have you any experience using it? [18:48] no idea, no. [18:49] ricardokirkner: barring Launchpad, it's the only server implementation I know that does that. [18:49] LarstiQ: alright, I will take a look at it, thanks [19:01] I'm having some permissions issues in bzr on a Linux box [19:02] Anyone with any knowledge of this? [19:02] mib_thk4aclq: not enough information given to know yet. [19:02] Here goes. [19:02] I have a project that several users on the local box use [19:02] I'd like all to have commit privileges from their local branches to the main branch. [19:03] However, every time I run a push to merge my local branch with the main branch, ownership is set to me alone. [19:03] None of the other devs are able to make commits. [19:03] I'd rather not have to change permissions on the main branch location each time. [19:03] Is there a better way to set it up, to avoid this issue? [19:04] mib_thk4aclq: yes, I personally make use of posix acls [19:04] To what end? [19:05] mib_thk4aclq: to set the permissions on /srv/bzr [19:06] I see. That seems reasonable. I'm rather surprised bzr isn't able to handle this on its own. [19:06] I expected this scenario would be fairly common. [19:06] mib_thk4aclq: something like `setfacl -m group:bzr:rwx /srv/bzr/*' [19:07] mib_thk4aclq: bzr is not in the business of handling permissions [19:07] I suppose that keeps everything nice and general, given its portability. [19:07] Many thanks. [19:07] mib_thk4aclq: alternatively, if you're using a smartserver instead of dumb transports, you could handle it there [19:08] Oh? Could you direct me to the proper documentation? I investigated the smartserver but couldn't find relevant info. [19:08] mib_thk4aclq: http://pypi.python.org/pypi/ClueBzrServer/0.2 or with Apache + mod_auth [19:08] LarstiQ: probably you can't use that if all the urls are file:// ones :) [19:09] dash: correct :) [19:09] Well, using a smartserver or dumb transport makes no difference to me [19:09] All users are local [19:10] mib_thk4aclq: if they use file:// urls, it is purely a filesystem permissions situation. [19:10] for which I recommend setfacl for more flexibility than traditional Unix permissions [19:10] Well, I'd prefer to do the configuration with the smartserver then. [19:10] Which I think I shall [19:11] I'm just sick of having the other devs pissed at me for blocking commits [19:11] :/ [19:12] mib_thk4aclq: you can get partway to where you want to be with the setgid bit [19:12] Mhmm [19:13] but that falls short in the area of new directories mainly [19:13] $ setfacl -m group:developer:rwx /bzr [19:13] $ setfacl -m default:group:developer:rwx /bzr [19:13] takes care of all that [19:13] mib_thk4aclq: I've set it up once on the server, and never look back [19:14] Well, there's certainly no harm in trying it out, since the box is locked down tight [20:00] servilio: did you manage to file the bug? [20:00] jelmer: I am trying to reproduce the bug locally, but can't get bzr to make the first commit before removing an element from the path [20:01] I think I'll file the bug and later try to reproduce it [20:02] also because I need to find a way to put my changes into the subversion repository (I mean, the ones from the real work, not the mock situation trying to reproduce the bug) [20:20] jelmer: I am getting a "Not a branch" when checking out a local svn repo: http://paste.ubuntu.com/176633/ [20:21] servilio: yeah, because the branch you're checking out is not a branch according to the layout you're specifying [20:22] servilio: it seems like you'd want to create l1/l2/trunk [20:23] so, what should I do to have just a directory? [20:23] servilio: how do you mean? [20:23] I tried bzr branch like you suggested here: http://www.nabble.com/My-experience-with-bzr-svn-td23606249.html [20:23] but svn+file is not a recognized protocol [20:24] servilio: file:/// should work [20:24] will try that... [20:25] servilio: I think I see what the problem is [20:26] anyway, time for groceries first, back later [20:26] jelmer: got the branch properly created, now doing some local changes... [20:26] see you later [20:27] servilio: if you end up with a script that can reproduce this, that would be very useful (for the regression testsutie in bzr-svn) [20:27] jelmer: yep, I know [21:01] jelmer: got it :) [21:13] servilio: w00t :-) [21:14] found that it only happens with three levels of nesting [21:14] two doesn't show up [21:15] and bzr missing misses the changes in the remote svn repo on the 3 nesting case [21:15] interesting [21:15] I am extending the script to automate the testing for different levels [21:18] I'd like to see what happens at 4 levels [21:33] servilio: can you attach the script to the bug report? [21:33] I'll do it [21:33] I am finishing it, will test it in a minute [21:58] jelmer: ready, attaching it now to ticket... [22:01] done [22:03]