[00:00] <`mousey> Does anyone know where I can obtain the Windows standalone installer for bzr 1.10? [00:00] `mousey: The build machine has been having issues; there isn't one yet. [00:00] <`mousey> ahh rightio [00:01] <`mousey> can I just grab the zip and overwrite my existing bzr folder with it to get 1.10? [00:01] <`mousey> *install folder === stewart_ is now known as stewart [00:13] wb enigma [00:13] enigma, there are only a few bzr svn-* commands [00:14] bzr svn-import / bzr svn-upgrade (not relevant right now) / bzr svn-branching-scheme (only for bzr-svn == 0.4) / bzr svn-set-revprops / bzr svn-layout [00:15] jelmer: Thanks. [00:16] jelmer: Suppose I branch http://remoterepo/trunk/foobar and then I tag rev 33. How do I get that tag back into SVN? (This is with 0.5) [00:17] I should clarify: http://remoterepo/svn/trunk/foobar [00:20] enigma, there is no way to do that at the moment, in the future it will be possible to set a configuration variable with the path in which tags should be created [00:20] you can hardcode that path for now, at layout/standard.py:230 [00:20] What happens to tags right now? [00:21] Is the "custom" layout stuff relevant for 0.5 still? [00:21] enigma, yes, the custom layout stuff is still relevant for 0.5 [00:21] enigma, You'll see what happens if you try the latest revision from the 0.5 branch :-) [00:21] Are there doc on the layout stuff (beyond the help page for layouts)? [00:22] jelmer: OK. Let me try...pulling... [00:23] enigma, no, the svn-layout helppage is all there is [00:23] OK. Thanks. [00:25] enigma: sorry, that should be layout/standard.py:310 [00:25] OK. [00:26] So, if I check out a branch directly, I end up with a "wild card" layout? [00:27] So, I should check out at the "trunk" level? [00:27] enigma: Ah, sorry [00:27] enigma, You will end up with a WildcardLayout() if you have "branches = " configured in the bazaar configuration file [00:27] enigma, you will end up with TrunkLayout() if you branch "/trunk" or "/branches/X" [00:28] you will end up with CustomLayout() if you branch /trunk/foo/bar [00:28] you will end up with RootLayout() if you branch "/" [00:28] So branching "/trunk/foo" will give me CustomLayout? [00:28] only TrunkLayout() supports tags at the moment (as the path to the tags isn't known in all the other cases) [00:28] enigma, correct [00:29] Oh, OK. I see. It's making a lot more sense now. [00:37] Am I the only one who gets a little mislead by the "No new revisions to push" message when pushing tags? [00:37] It seems like bzr should say "Push new metadata, but no new revisions" [00:37] Or something like that. [00:37] enigma: I think there's already a bug report about that [00:37] (not 100% sure) [00:38] It certainly is confusing. [00:52] By mandate of "central IT", we are required to stuff all our code in one subversion repository. Since we have several different project all in one repo, it seems as if the appropriate structure in svn should be: /project/(trunk|tags|branches). Does that sound right? [00:52] Currently we have /trunk/project, so that isn't going to play nice with bzr-svn if we want branching and tagging, right? [00:53] enigma, branching is going to work ok (since you specify the branch URL each time), tagging isn't (since it has to find the tags URL on its own in that case) [00:54] you can set the "tags" and "branches" configuration variables in the config to force it to find your branches and tags [00:54] except that won't allow you to create new tags (yet), since I haven't hooked that up yet [00:54] OK. [00:56] jelmer: If I felt so inclined to add more detail to documentation, what would be a good way to give that back? [00:57] enigma, yeah, definitely [00:57] How do I send the changes back? [00:58] just "bzr send" should sent back your local commits to me :-) [00:58] OK. :-) [01:16] Peng, interesting bug you hit there :-) Seems to be caused by svk replacing a directory by a copy of itself (without changes) [01:47] jelmer: Suppose I have "trunk/foobar" in svn and I want to make a branch "branches/foobar-2.0", should I just use "svn copy" to make the branch? [01:47] Or is there a way to make that branch with bzr-svn? [01:47] enigma, you can just "bzr svn-push" to the new location [01:47] enigma, but "svn cp" will also work [01:48] OK. Let me try the svn-push. [01:48] Peng_, still there? [01:50] lifeless, ping [01:50] jelmer: Wow! bzr-push worked beautifully! [01:50] Can anybody point me to a document explaining bzr's advantages as compared to git, mercurial, perforce, and similar software? [01:50] :-) [01:51] RyanPrior: This chat room is one of the advantages! ;-) [01:51] RyanPrior, there are various BzrVsX pages on the wiki [01:51] RyanPrior, http://bazaar-vcs.org/BzrVsGit / http://bazaar-vcs.org/BzrVsHg / ... [01:51] RyanPrior: Try to get a hold of the authors of Perforce on irc. ;-) [02:11] Thanks for those links, they are informative. [02:26] Hm. Maybe someone in Canonical's marketing department should give http://bazaar-vcs.org/Benchmarks some love, seeing as how the most recent thing cited there is bzr version 1.1dev [02:29] * mwhudson needs his "bzr oh-crap-ive-been-editing-in-trunk" plugin again [02:30] extra bonus points if it can somehow convince emacs to reload all its buffers from the branch it should create... [02:33] mw:) [02:33] mwhudson: :) [02:51] jelmer: pingpong [02:54] jelmer: (that was really just a pong, not a ping) [02:58] Peng_, Any chance you can unsubscribe from lp:~bzr-svn/bzr-svn/trunk ? [02:58] lp won't let me remove it otherwise [03:00] jelmer: rename it from "trunk" to "please-unsubscribe-kthxbye"? ;) [03:00] spiv, well, peng is the only subscriber, this seemed easier :-) [03:13] Heh. [03:14] jelmer: lp:~jelmer/bzr-svn/trunk? Done. [03:14] You're deleting it? Poor branch. [03:15] Peng_, thanks [03:15] yeah, people seem to end up using it while it is not actively developed [03:15] I'll just readd it when I work on it again [03:16] Ah. [03:17] It had a bunch of associated bugs, and a merge proposal. [03:27] hi all [03:29] Good morning. [03:31] jelmer: having something called trunk not be the active branch is ... weird. [03:32] lifeless, perhaps; that's why it's gone now === mwhudson_ is now known as mwhudson === Mario__ is now known as pygi [05:48] poolie: I just sent you some insert_record_stream RPC perf numbers. Fairly basic at this stage, but it should be easier to get more numbers as the code gets less quirky. [05:53] thanks [06:20] spiv, can you please measure something for an incremental push too? [06:22] poolie: sure, just a moment. [06:25] poolie: pushing bzr.dev onto bzr.dev -r-100: 74 hpss calls (bzr.dev), 39 (streaming-push) [06:27] poolie: (and 20.9s/6.5s wall/user time vs. 24.4s/5.2s) [06:32] poolie: pushing one rev onto bzr.dev: 47 hpss calls vs. 24. [06:33] (And there's 3 easy to remove calls in that 24, I think) [06:37] so the wall time got worse? [06:43] poolie: yes, although the need for topological sorting is a likely culprit there. There's possibly also some extra time due to the server doing more thinking now. [06:44] shouldn't need topo sorting [06:44] poolie: oh, and tee'ing the stream in case a fallback is needed hurts a fair bit too. [06:44] bah, I'm on leave. Honest. But dig up the mail I wrote about this some months back; topo sort is /one/ parameter in the api [06:44] lifeless: it's not needed in principle, it is with the current implementation :) [06:45] lifeless: which calls down to insert_record_stream([one_record]) many times on the server. [06:45] lifeless: that's certainly fixable, but getting things working comes before making them fast :) [06:50] lifeless: also, enjoy your leave! [06:54] is it just me or does the bzr-gtk test suite require the user to click the right buttons to make things pass? [06:54] spiv, anyhow, thankyou, that's helpful [06:55] poolie: great. [07:07] hi all [07:08] poolie: what bzr-gtk version are you using ? A bug was fixed long ago about that [07:08] poolie: could be a new one though.. [07:10] hello vila [07:10] it might be quite old... [07:11] poolie: Just checked: I'm up to date and 'bzr selftest -s bp.gtk' runs flawlessly [07:12] I see that our test suite seems to import plugins even with --no-plugins atm. [07:16] * spiv sends off a quick patch about that. [07:16] Ok, that's me done for the day. [07:23] night spivvo [08:19] is it at all possible to do something like single-file branching in bzr? [08:20] not really [08:20] you could branch and delete all but one file [08:20] i'm developing a CMS website and want to use bzr for version control of the content [08:21] so now if a user wants to edit content, i want to branch that content [08:21] and merge it back in when the user is done editing [08:21] but if i have a lot of users and content, it will get impractical to branch all the content for every user [08:23] so actually, i just want to do a lightweight checkout of a single file [08:23] might it be possible with "manual" api calls? [08:24] rkistner: yes, have a look at a MemoryTree or PreviewTree [08:26] poolie: thanks, will have a look [08:45] are there any documentation on MemoryTree and PreviewTree, apart from the API? [09:34] rkistner: maybe in doc/developer? [09:36] actually, i couldn't even find the api documentation for previewtree so far [09:39] http://starship.python.net/crew/mwh/bzrlibapi/ [09:40] http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.memorytree.MemoryTree.html [09:40] is probably what you want [09:40] ok [09:41] but what you're going to do will be a bit atypical [09:41] so it might be better to write about wherever you get up to to the mailing list [09:42] ok [13:34] jelmer: i really think you should undeprecate "svn+http(s)" ;) [13:34] rocky, why/ [13:34] ? [13:36] hi [13:36] what does "No handlers could be found for logger "bzr" " mean? [13:38] <\sh> guys, what is the right way of updating bzr imported svn branches from svn repo? [13:38] <\sh> forget the question.../me needs to clean glasses [13:39] BUGabundo_work: Are you using bzrlib or running "bzr"? [13:40] bzr Peng_ [13:40] brz commit . [13:40] local repo of files [13:40] stand alone [13:40] \sh, :-) [13:40] BUGabundo_work: 1.) It's not really a big deal; it's just a warning, 2.) It means the debug log isn't working for some reason. [13:41] <\sh> jelmer: svn-upgrade is too obvious ;) [13:41] BUGabundo_work: Run "bzr version" to see where it's located. Maybe you don't have write permissions? [13:41] but really nasty when used with autocomplete TAB TAB [13:41] \sh: not sure I follow, svn-upgrade should only be necessary if you used to use bzr-svn 0.3.x which is over a year old by now [13:42] I see a few exceptions there [13:42] <\sh> jelmer: then I'm lost ;) /me wants to do something like "svn update" on bzr imported svn branches :) [13:42] \sh, Just do whatever you would do on a regular bzr branch :-) [13:42] \sh, just "bzr pull " should work [13:43] or "bzr update" if it's a checkout [13:43] <\sh> jelmer: bzr pull? oh xmas is near :) [13:43] Peng_ can you take a look please [13:43] http://paste.ubuntu.com/86261 [13:45] BUGabundo_work: Haha. That issue was fixed in 1.10. [13:45] I'm on jaunty [13:45] I have 1.9-1 [13:45] should I test a PPA? [13:45] You could. [13:45] is there a bug I can track=? [13:46] BUGabundo_work: For what? [13:46] for this version error? [13:46] BUGabundo_work: No, a bug was never filed about it. [13:46] I'll file it when I come back [13:46] Jaunty runs an alpha version of Python? [13:46] I have no idea! [13:46] BUGabundo_work: Like I said, the "bzr version" bug was fixed in 1.10. [13:47] http://paste.ubuntu.com/86263/ [13:47] and http://paste.ubuntu.com/86264/ [13:47] brb === beuno_ is now known as beuno [13:49] BUGabundo_work: You can use the PPA to upgrade to bzr 1.10 if you want to, but it's not necessary. https://launchpad.net/~bzr/+archive [13:49] BUGabundo_work: I only wanted you to run "bzr version" to find out the location of .bzr.log, but it's probably ~/.bzr.log. [13:50] Wait, Jaunty? It doesn't look like there is a PPA build for Jaunty in the first place. [13:50] Eh. === sdboyer-laptop is now known as sdboyer|sprint [14:10] <\sh> jelmer: any clue how to resolve this? or what would be a trigger for this? bzr: ERROR: Must end write group before releasing write lock on KnitPackRepository('file:///home/shermann/workspace/zend-framework/standard/.bzr/repository/') [14:10] \sh, that's actually masking any real errors [14:11] can you pastebin the full backtrace? [14:11] <\sh> jelmer: there is no one [14:11] \sh, when does this happen? [14:12] can anyone point me to docs on how to use nautilus-bzr? [14:12] I have it installed but don't see how to use it. [14:12] <\sh> jelmer: after svn-import --all --incremental [14:12] knighthawk, it should just start showing small icons for your bzr managed files in nautilus [14:12] <\sh> jelmer: he was in the stage of creating the revisions (I could do that again ;)) [14:12] Peng_: back [14:13] \sh, are you running 0.4.16? [14:13] <\sh> jelmer: 0.4.13 from intrepid [14:14] jelmer yeah that's what I figured but it doesn't seem to be doing that. [14:14] knighthawk, do you have python-nautilus installed? [14:14] jelmer: you have any idea about http://cluebin.appspot.com/pasted/4002 and http://cluebin.appspot.com/pasted/3611 ? that's with bzr 1.10 and bzr-svn-0.5 branch as of a few days ago (and just updated and confirmed it's still happening) [14:15] \sh, It may be fixed in a newer version, or at least give a better error. [14:16] rocky, the first is a bzr-svn bug that's been fixed in the 0.5 branch [14:16] <\sh> jelmer: trying 0.4.16 [14:16] jelmer, rpm -q python-nautilus [14:16] package python-nautilus is not installed [14:16] I'll see about that. [14:16] jelmer, doesn't seem to be a package name. [14:17] knighthawk, I don't know what it's named on RPM-based systems, and whether it's packaged at all there, sorry. [14:18] jelmer, well that gives me a place to start thanks. [14:21] Oops, now I was awya. [14:21] away* [14:21] jelmer: both those msgs come from the same error, and i am running the latest code and get the same error (even if those pastes are a couple days old) [14:21] rocky, you're running r2270 ? [14:22] jelmer: yep [14:23] jelmer: a more recent paste (definitely from r2270) is cluebin.appspot.com/pasted/4006 [14:23] jelmer: and you can try it as well as the svn repo is publically available i believe [14:25] * jelmer gives it a try [14:26] jelmer: if that url doesn't work for you, just try the non-https version, i definitely know it's available to anonymous users [14:26] it works without svn+ even :-) [14:26] jelmer: it never works properly for me without svn+ because pycurl barfs [14:26] jelmer: but regardless... did the branch/checkout work for you? [14:27] still running [14:27] kk [14:27] for me it gets really far before it bails [14:27] jelmer: If you changed bzr-svn's version_info from (0, 5, 0, 'rc', 1) to (0, 5, 0, 'candidate', 1), bzrlib._format_version_tuple() wouldn't barf on it anymore. [14:27] Hmm. [14:28] Peng_: bug #308578 [14:28] Launchpad bug 308578 in bzr "bzr: ERROR: exceptions.ValueError: version_info (2, 5, 3, 'alpha', 0) not valid" [Undecided,New] https://launchpad.net/bugs/308578 [14:28] I filled it [14:29] BUGabundo_work1: Yeah, it was definitely fixed in 1.10. [14:30] humm can you mark it in progress? or fix available? [14:30] where can I get the patch? [14:30] bzr repo? [14:31] BUGabundo_work1: http://bazaar.launchpad.net/~bzr/bzr/trunk/revision/3849 [14:33] so bzr branch lp:bzr should do it for me? [14:33] BUGabundo_work1: Well, yes. [14:33] * BUGabundo_work1 admits to be very new to this [14:34] BUGabundo_work1: You could also get 1.10 off the website. Or you could just patch your 1.9 installation. [14:34] * BUGabundo_work1 wants to learn [14:36] Peng_: $ cd /tmp/;bzr branch lp:bzr; [14:36] Disconnecting: Corrupted MAC on input. bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) [14:36] jelmer: i have to take off for some errands but feel rest assured that i will ping you on the issue a little later :) [14:38] Peng_: https://launchpad.net/~bzr/+archive already has 1.10, but no version for Jaunty... kinda strange.. [14:38] BUGabundo: Now _that_ I don't know. Is it really worth all this effort for the "bzr version" bug? :P [14:39] its just to fix that stupid warning ... LOL [14:39] but I can wait. [14:39] BUGabundo_work1: The logging thing isn't related to hte "bzr version" thing. [14:40] I'll test deb http://ppa.launchpad.net/bzr-beta-ppa/ubuntu jaunty main and see if both are fixed [14:42] Hmm, why *does* "bzr version" traceback when plugins have a bad version_info anyway? The plugin code works around that (e.g., "bzr plugins" works). [14:44] no idea! [14:44] I'm just a simple user [14:44] who gets anoyed every day, when doing regular commits [14:45] BUGabundo_work1: Does ~/.bzr.log exist? [14:45] * BUGabundo_work1 checking [14:45] yes [14:45] and is owned by root [14:46] can it be the origen of the prob? [14:46] BUGabundo_work1: Probably. [14:46] maybe I did a commit with the wrong user? [14:46] BUGabundo_work1: Try renaming/deleting/chowning it. [14:46] I have several repos [14:46] one for /etc [14:46] that is done with sudo [14:47] sudo chown bugabundo:bugabundo .bzr -R [14:47] ahhhhhhhhhh [14:47] that works... [14:47] Ohnoes, clones. [14:47] no more warning [14:47] eheh [14:47] laptop with ubuntu [14:48] Office PC here [14:48] but I still get the brz version trace [14:48] upgrading bzr now [14:49] it now works fine too [14:49] :D [14:49] Bazaar (bzr) 1.10rc1 [14:49] If you install bzr from source, you should compile the C extensions. [14:49] humm? [14:50] too complicated for me LOL [14:50] brb [14:50] thanks Peng_ [14:50] BUGabundo: 1.10 final is out too. [14:50] its what the PPA sent me [14:53] Ah. [15:47] hello [15:47] i am trying to checkout a repo that has a symlink, but i'm on windows so it fails [15:47] what can i do, apart from get a normal OS? [15:51] symlinks? anyone? [15:53] Stavros: There's a symlink plugin. [15:56] Peng: ah, thanks [16:25] if I've made a commit to a local branch that I havn't yet pushed anywhere, is there some way to change the commit message after hand? Thanks =) [16:26] Only by uncommit/recommit [16:27] aha, thanks LeoNerd [16:29] jelmer: any progress on the issue i mentioned earlier? :) did you at least reproduce it ? [16:30] I know there's been discussion in the past of support for plugins adding content-aware merge algorithms; has anyone implemented such a thing as of yet? [16:31] rocky, Yes, I can confirm it's still there [16:31] haven't found out what's causing it yet; hopefully later tonight [16:31] nDuff, Not that I've seen [16:32] nDuff, I think Odd_Bloke was working on it [16:32] Nominally, yes. [16:32] In reality, I haven't started. [16:32] But I think you can already plug your own merge algorithms in. [16:33] And so you could do some content-checking in there. [16:33] But I don't really know any more than that. [16:41] If I've got a bound branch, (a checkout), is there a way to get it to use the parent/push locations? [16:41] parent/push locations of the branch it is bound to? [16:49] <\sh> jelmer: I'm trying latest bzr + latest bzr-svn...same error no traceback...but when restarting the same import, he has less revisions to copy... [16:49] \sh, that's correct, some revisions have already been copied in that case [16:49] Odd_Bloke, ah, thanks [16:49] \sh, can you comment out that exception and see what exception it is masking? [16:49] I'm cloning an SVN repo...it gets to about version 4000 of 8500 and then I get the following error: bzr: ERROR: parent_id {3842@daff2dd8-1c3d-0410-9cd2-f6297dd8f964::trunk%2Fjetty-master%2Fsrc%2Fhtml} not in inventory [16:49] (This is with bzr-svn 0.5) [16:50] (trunk) [16:50] <\sh> jelmer: how do I do this? === enigma1 is now known as enigma42 [16:52] \sh, bzrlib/repository.py:1142 [16:52] just replace the raise with a "pass" [16:54] <\sh> jelmer: which method? in my source there is line 1142 in repository.py a "return result" [16:55] \sh, unlock [16:55] enigma42, hi [16:56] <\sh> jelmer: thx...now it takes some more time [16:58] AmanicA, hi [16:58] hi [16:58] AmanicA, I always forget - do you have PQM access? [16:58] no [17:00] AmanicA, Ok; I've submitted your tags-range patch [17:01] thanks! [17:01] *goes for dinner [17:13] jelmer: Hi [17:14] jelmer: I had just stepped out for a bit to take all the garbage cans out to the curb. ;-) [17:17] enigma42, hi [17:18] enigma42, are you on r2270? [17:20] jelmer: Let me check [17:21] jelmer: No....I'm on 2266 [17:21] Let me update. [17:23] OK...I'm trying again. Should I clear the svn cache? [17:24] no, that shouldn't be necessary [17:24] OK [17:26] jelmer: bzr-svn 0.5 deals well with a previously branch-scheme breaking mv, thanks! [17:27] jelmer: unfortunately copies still seem to stop it dead in its tracks. [17:27] LarstiQ, not sure I follow? [17:27] LarstiQ, Copies of files you mean? [17:27] jelmer: no, svn cp trunk branch [17:28] now branch and trunk don't share history [17:28] afaiui [17:28] LarstiQ, they should, if you did a "bzr branch" of "branch" [17:28] LarstiQ, or did you already push to both using older versions of bzr-svn? [17:30] LarstiQ, oh, and "branch" would have one extra (pointless) commit after a "svn cp" [17:30] jelmer: no bzr has been used on that branch afaik [17:30] but maybe it wasn't an svn cp, but manually, hmm [17:32] jelmer: would the svn log -v -r svnrev; where svnrev is the svn revno of the branch bzr first revision be helpful? [17:32] LarstiQ, yes [17:32] it's a bunch of adds :/ [17:32] not a copy? [17:32] it mentions (from: /..) [17:33] that's a copy [17:33] ok [17:42] jelmer: the README refers to BzrForeignBranches/Subversion/mapping , http://bazaar-vcs.org/BzrForeignBranches/Subversion/mapping doesn't seem to exist though? [17:43] jelmer: Wow! bzr-svn 0.5 is *much* faster for pulling lots of revisions! [17:44] enigma42, cool, that's good to hear :-) [17:44] I'm able to pull down a 1000 revisions from a remote repo in about 1 minute. [17:45] LarstiQ, ah, yeah, it's part of the bzr branch these days [17:45] So this is the strange thing, if I just do a "pull", then it takes a really long time during "phase 0 of 2" [17:45] But if I do "pull -v -r 2000" it goes much faster. [17:45] enigma42, that's the "copying revisions" step or "fetching revision info" ? [17:46] The "Pull phase 0/2" [17:47] There's approx 8500 revisions in the svn repo. [17:48] So what I'm doing right now is pulling down the revisions 1000 at a time. [17:50] OK...I'm just around revision 4000 again and it's being slow. [17:50] Let me investigate a bit. [17:54] evening jam [17:57] What is "Pull phase 0" anyway? [17:57] Versus "1" and "2"? [17:58] hi LarstiQ === Hydrogen_ is now known as Hydrogen [18:10] enigma42, is it working any better this time? [18:12] Well...it's still slow, but I think I've narrowed it down to the problem revisions. [18:13] I think it's getting stuck on an SVN branch we made a while back. [18:21] <\sh> jelmer: I don't get any backtrace :( [18:21] \sh, so it just works ? Or does something else fail? [18:21] <\sh> no it failes after some time again..but no backtrace [18:22] how does it fail? [18:22] <\sh> same error message: bzr: ERROR: Must end write group before releasing write lock on KnitPackRepository('file:///home/shermann/workspace/zend-framework/standard/.bzr/repository/') [18:24] \sh, ah, looks like there's another place where that exception is raised.. [18:24] bzrlib/repofmt/pack_repo.py [18:24] any chance you can comment it out there as well and try again? [18:24] sorry :-/ [18:24] <\sh> jepp [18:28] <\sh> jelmer: I've to catch my train now...I'll leave it running, so I can see tomorrow morning what happened [18:29] <\sh> ah ... now bzr: ERROR: Lock not held: LockableFiles(lock, file:///home/shermann/workspace/zend-framework/standard/.bzr/repository/) but no backtrace ;) [18:29] <\sh> anyways..I'm on the run :) cu tomorrow [18:30] k [18:30] bye! [18:33] jelmer: I think I found the svn rev the pull is getting stuck on. [18:33] jelmer: What sort of information should I dump out to see what's going on? [18:33] Is just sits and sit here: | [ ] Pull phase 0/2 [18:33] svn log -v for the particular revision would probably be useful [18:34] but it's actually doing something ? [18:34] top shows that it's using CPU [18:34] But the progress bar is not ever moving. [18:34] And it just sits there for minutes and minutes. [18:35] if you run it with -Dtransport it will write the svn operations to ~/.bzr.log [18:35] Oh, OK. Let me try that. [18:35] you can also interrupt it with SIGQUIT (Ctrl-\), that will put you into a Python debugger [18:35] you should then be able to see what's going on [18:36] Ah...I see this log message: creating branch for POC of svn branching [18:36] A /branches/RELEASE_0_6_0 (from /trunk:4114) [18:39] hello [18:39] is there possible to create bzrdir without branch and checkout? [18:40] I'd like to have it in such state to prevent adding directory to toplevel branch and in the same to prevent creating checkout in this directory [18:40] jelmer: It all gets very slow after the following: [18:40] 25.838 svn update -r4115 [18:40] 26.259 'branches/RELEASE_0_6_0' copied from 'trunk':svn-v3-none:daff2dd8-1c3d-0410-9cd2-f6297dd8f964::4114 [18:41] jelmer: Maybe some kind of deep recursion following the copy? [18:41] still learning how to do remote checkouts bzr branch bzr+ssh://serverName/file/path works [18:41] jelmer: I pulled the top of the repo, so I should have a "root" layout. [18:42] but bzr branch userName@bzr+ssh://serverName/file/path doesn't [18:42] enigma42, yes, that will be slow indeed [18:42] how so I add the user name to the URL? [18:42] enigma42, There's not usually a reason to pull the top of the repository [18:42] enigma42, in fact, it should warn you if you do so [18:42] knighthawk: bzr+ssh://username@host/path [18:42] knighthawk: Just like HTTP. [18:43] jelmer: What I'm trying to do is clone the whole SVN repo. [18:43] enigma42, in that case, you'd want "bzr svn-import" [18:43] thanks Peng [18:43] enigma42: that will import all of the branches in the repository [18:43] enigma42: Right now you're cloning a repository as if it were a branch [18:44] I'm trying to clone the repo so that I can push it to a new server. [18:44]