[00:20] lifeless: what "problematic limitations"? [00:34] Hi. Would anyone have any code that hooks post-push to send an email? [00:35] ecognito, maybe you're looking for: https://launchpad.net/bzr-email/ [00:37] That sends an email on a commit. I want it on the push, so it will notify the members of the group automatically when there is something useful to pull. [01:16] xif: no versioning of symlinks,directories,renames[hg does renames now, but by copy+delete semantics] [01:27] abentley: ping [01:28] abentley: I'm seeing the index as being about 30% of runtime using my branch to checkout --lightweight bzr.dev with no accelerator tree [01:28] abentley: where is your branch again; I'll merge it in and test [01:48] I'm really impressed that bzr detects criss-cross merges and helps me figure out how to make completing the process as painful as possible. bzr rocks! It sure does! :) [02:03] where abouts is the main configuration for bzr kept? [02:04] bzr --version will tell you [02:04] thanks! sorry in a hurry, otherwise I would have scoured more [02:24] Is anyone here familiar with the email post commit hook plugin? the post_commit_to setting is put in bazaar.conf? [02:24] 'bzr help email' should describe how to configure it [02:25] Yeah, I tried that, I am quite new to bzr, it says to set the post_commit_to setting but not exactly where. I am thinking in bazaar.conf? [02:26] yes, bazaar.conf or locations.conf [02:26] thanks [02:26] docs.bazaar-vcs.org has complete documentation on the config files [02:30] New bug: #190096 in bzr "doc use of revert --forget-merges to create commits without history" [Undecided,New] https://launchpad.net/bugs/190096 [02:30] thanks lifeless [02:45] lifeless: http://code.aaronbentley.com/bzr/bzrrepo/fast-iter-files-bytes [02:47] lifeless: that branch caches nodes, and when I accidentally disabled the cache, it seemed about a second slower. [02:48] abentley: caches nodes? [02:48] abentley: do you mean an additional cache on top of the index? [02:48] Yes. [02:48] It shouldn't help but it seems to. [02:48] abentley: ok; I'm doing a quick-fix to reduce index queries, I hope it will fit well with what you;ve done (its about a 30-minute thing), I'll post it in a minute [02:51] basically just tweaking get_components_positions to only ask the index once per component rather than 3 times [03:00] lifeless: I don't think I use get_components_positions at all. [03:01] * igc food [03:06] I have an unbound branch I'm working on [03:06] is there any way to have bzr push just go to wherever I branched it from? [03:06] so I don't have to specify where? [03:07] skvidal: You only have to specify the first time. [03:07] It remembers after that. [03:07] okay [03:07] skvidal, and if you want to overwrite the current one, just add --remember [03:07] abentley: _get_component_positions was teh core workhorse before your patch; I'd hope you either refactored or deleted or something :) [03:07] thanks [03:07] abentley: anyhow its doing a test run across all tests then I -> send and forget [03:09] lifeless: Not yet, because so far, I'm only supporting packs. [03:11] k, well I'll look at your patch shortly, I may have some feedback for you ;) [03:15] So far, the best time I've gotten out of yours is 4.554, which is at least 500 ms faster than my best time without indices. [03:16] without your index fixes, I mean. [03:16] well thats promising [03:16] Sorry, 50ms, not 500 [03:16] pushing a new version now [03:17] up to 1/2's the number of IO round trips [03:17] ooh, 4.514 [03:18] 4.429 [03:18] revno 3221 is pushed [03:21] I don't see it. [03:22] abentley: on people ? [03:22] No, on bazaar.launchpad.net [03:22] it will be up to 6 hours behind [03:22] but, but, it supports the smart server. [03:23] rather useful huh? But the lp guys tell me that I won't get a button to tell it to mirror till > lp 2.0 at least [03:23] pack streaming is ~=. The index stuff is however much nicer in bzr+ssh now [03:23] I should get bzr+http up on my people branches. [03:23] give the sysadmins something todo. [03:23] :> [03:24] seriously speaking I will need a place to test that if we ever want it to come up to scratch speed wise [03:24] Why do you prefer it? [03:24] I make new branches continually [03:24] (and yes, I've got it now.) [03:24] abentley, beuno: thank you for the help - it does work happily now [03:25] Until we fix the cost of uploading new branches to the hosted site, it is prohibitive for me [03:25] that index fix is sent to the list as well [03:25] Hmm. Maybe I have bzr+ssh on rookery... [03:26] wooo [03:26] 4.6 seconds! [03:26] that knit index fix shaves 1 second user time [03:28] The best time I've seen with 3221 is 4.589 [03:28] wall clock I have 5 seconds down from 6 seconds [03:28] (I'm using the patch I just sent to lp with my rev 3221 [03:28] I'm going to merge your branch now and compare [03:29] 4.461 [03:29] ooh, 4.380 [03:30] So wall clock time is ~4.4 - 4.7 [03:31] your branch gives me 4.4 wall clock [03:31] so 6 seconds bzr.dev, 4.4 yours and my range-map, 5 range-map + knit-index-tweaks [03:31] I'm looking at your branch's code now, and callgrinding [03:32] oh, it has storage in it :(. I'll go reply to that thread now. [03:32] I'm following your (kind, (file_id, version)) suggestion for the index_keys, and that seems to work nicely. [03:33] cool [03:33] lifeless: I don't insist on Storage for this code, but I still think it's the right idea for other reasons. [03:33] Anyhow, that's why I said not to freak when you saw it. [03:34] abentley: ok! I'm not freaking, just fixing up a procrastinated mail-reply I owe you :) [03:48] lifeless: bzr+ssh kinda works on rookery. Gives bzr: warning: unsupported locale setting [03:48] Could not determine what text encoding to use. [03:52] LANG=C "fixes" that. [03:57] spiv: do your magic thing to pull plz [03:57] sorry, push [03:59] spiv: why does get_data_stream_for_search return a single read function for the results? [04:00] It seems to require buffering stuff in a StringIO [04:00] I would have thought something more like what you did with containers. [04:03] abentley: a comment on the approach; rather than a lot of static methods, did you consider just generalising *KnitIndex's responsibilities to be for (type, id) rather than just a single id ? [04:04] abentley: a fairly trivial adapter could implement that for normal Knits on top of the current _KnitIndex [04:04] abentley: and the current KnitGraphIndex could actually become simpler and faster by not doing StripPrefixAdapter usage [04:05] abentley: actually, skipping the (type) and just allowing a file_id into the keys would probably be cleaner in the short term with the way that maps to a single logical index [04:06] I guess I hadn't really thought about it. [04:07] I was focusing on making Storage present an apparently-unified index for all item kinds. [04:08] in this particular case if you called 'Storage' 'MultiKnit' or something [04:09] and had it implemented in knit_repo and pack_repo as appropriate, I think it would fall out quite nicely; particularly if we move our callers to it. [04:10] ok, your branch is definately nice and fast [04:10] get_build_requirements is 33% for me [04:10] Sure, I can rename it. [04:11] 20% in _read_and_parse [04:11] And I do want to support it for both knit_repo and pack_repo. [04:11] abentley: (well I meant renaming and not having all those static methods :)) [04:12] 18% in _parse_regioj [04:12] I'll focus on _parse_region [04:12] Nice. [04:13] 15% in _parse_lines though, perhaps its time for a C extension there [04:13] abentley: if you could eyeball my knit speed patch, its quite a win in and of itself [04:14] Those static methods are a bit thorny for me, because I'm using them in ways I wouldn't want to use a KnitGraphIndex. But I can't remember the details ATM. [04:14] right, this is what I mean about generalisation [04:14] KnitIndex can be unchanged [04:15] MultiKnitIndex creates new knit indices and calls onto them [04:15] GraphKnitIndex gets renamed to something like LegacySingleGraphKnitIndex [04:15] a new GraphKnitIndex is one that supports a single key space from the get-got [04:16] and KnitVersionedFile gets its api changed, and is given the new index type directly [04:16] this avoids needing to get at internal index methods from your super-efficient class, because it is now part of the structure rather than an outsider [04:17] (paraphrase: roll the Knit api forward to be more powerful( [04:20] I see what you're saying. [04:21] Man, I have got to find the time to work on my gtk merge-directive-applying tool. === asac_ is now known as asac === Verterok is now known as Verterok_ [05:02] lifeless: The next key bit I see for my branch is ensuring it doesn't consume all available memory. [05:02] After that, compatibility with standard knits. [05:03] it's a pitty the trac plugin doesn't really work [05:03] :( [05:04] well.. trac doesn't work very well with distributed vcs [05:04] atm [05:04] it only works really well with subversion, it was written too tightly around it [05:04] they are working on it [05:04] for the next version of trac [05:04] Yeah, it's got too many wrong assumptions about the APIs a VCS might use. [05:05] any of the plugins are hacks [05:05] is there anything like trac for bzr? [05:05] or is there at least some kind of webinterface to browse files etc.? [05:05] launchpad? [05:05] hehe [05:05] For example, in order to tell you what files have changed, it gets the two versions and compares whether they've changed. [05:05] Instead of just asking the VCS which files have changed. [05:05] ii'm sure there is a way to browse files for bzr ... [05:06] gotta be [05:06] c1|freaky: there are a couple of web interfaces to browse files in bzr branches. [05:06] Is the launchpad code available? [05:06] no [05:06] closed source [05:06] c1|freaky: there's loggerhead, which launchpad uses (e.g http://codebrowse.launchpad.net/~bzr/bzr/trunk) [05:06] not yet [05:06] maybe some day [05:06] and what is the best webinterface for bze repos? [05:07] (And loggerhead is open source.) [05:07] ok im having a look at it [05:07] There's also the "bzr webserve" plugin, but I think loggerhead looks nicer. [05:07] in the cases where they are multiple options, very rarely is one better than the other to everybody [05:07] at that point it's usually a matter of opinion [05:07] just like all open source stuff :) [05:07] spiv: where can i download it [05:07] pull it via bzr [05:08] how to do that? [05:08] ill search for it [05:08] there we go :) that's a good answer :) [05:08] c1|freaky: https://launchpad.net/loggerhead [05:08] thank you [05:08] :) [05:08] ok.. grocery store time [05:09] lifeless: I bb:approved your patch. Guess the list is slow. [05:09] abentley: cool; I'll submit it now. I'm about to head trainward [05:10] any changes needed - my mail client is closed [05:10] No. [05:10] thanks [05:14] * lifeless waves [05:16] There's also bzrweb. [05:16] And I think another. [05:16] hi im c1|freaky [05:16] umm [05:16] im trying to run loggerhead but it says [05:17] ImportError: No module named bzrlib [05:17] someone knows what is missing? [05:17] um [05:17] is bzr installed? [05:17] yea [05:17] are you running loggerhead with the same python as the one that has bzr installed? [05:17] one moment [05:19] freakyy: There's also bzrweb, and I think another one. [05:20] hm i have to set up every repo with loggerhead [05:22] you can point it at a directory of branches [05:24] i can't find the port setting [05:24] :\ [06:05] http://bzr.code-1.de everything working now :D <-- loggerhead with http proxying :D [06:05] Anyone know of a good CGI interface for bzr? [06:05] Like to manage a bzr tree from a web server. [06:05] Absolutely must be GPL/FOSS though. [06:06] https://launchpad.net/loggerhead is a viewer [06:08] That would be useful. I also need a management interface though. I was planning on writing it in house but if there is something available I would like to consider it and at least look at the design. [06:10] what do you mean by management? there's things like bundlebuggy and cart. [06:10] I could probably Adapt logerhead for that really. [06:11] I mean doing things like bzr add, commit, resolve, merge, update, etc, and be able to configure default arguments for each of the commands. [06:11] but with a web interface [06:12] so no shell login is needed [06:12] does cart yet have a developer team or a website? [06:13] Obviously there are other things on the server side and security side that I have already implemented to make something like that work for multiple users in a secure way. Do cart or bundlebuggy do those things (the bzr mgmt stuff) [06:14] I am really just looking at getting bzr vcs functionality to our users without making them login to the system and learn all the commands. [06:14] it kinda sounds like a cms is more waht you want [06:17] no this is for the vcs of source code [06:17] code maintained by users for users on a remote server [06:18] so bzr is the way to go I think, or some other vcs, but I prefer bzr [06:18] there's olive, a tortoise*-alike [06:19] olive is, as you know, run locally [06:19] and not on the server, nor is it cgi [06:19] it is in GTK I am pretty sutre [06:19] sure* [06:20] Trust me. I know what I need. I just don't know if it already exists in some form or not. [06:24] I think cart might work very well if I add some things here and there, but I am not sure since I have not really looked at it yet. [06:30] How would one work with that? How would you edit files? [06:35] How does bzr deal when I want to make a lot of small changes, but then later squash them into a big change for inclusion into the main branch? [06:36] Peng: Well you log in, and you then have edit rights to any files that you own and create files in your personal space, project, or in a team space of a team you are a member of. The editing is done in a JS test editor or in an editor of your choice that can be configured in your profile and when you are done the edited version of the file would be sent back to the server. In order to use a local editor you would obviously need to [06:37] Peng: And the bzr commands are available to any user to use on any branch that they have rights to. [06:44] etteyafed: Your first line ended with "In order to use a local editor you would obviously need to". [06:44] Peng: install a launcher script that will collect the edited file from the a temp dir (like /tmp in a *nix) [06:45] must have gotten cut off by the server [06:45] IRC line length is limited. [06:45] Sure is [06:45] Your client should've been smart enough to break it for you. [06:45] My client knows that and should have cut it sooner [06:46] but that limit varries form server to server and apparently pidgin has decided not to ask the server and just assumes a "resonable default" or something [06:47] but I have found that even in the case of line limits you are something like -40 chars in reality. not sure why, but I had that same problem with an irc bot. [07:59] Yikes! What on earth does [07:59] bzr: ERROR: Pack 'f8987ec441dc91318f8fd1a99e6c5f42' already exists in [07:59] mean? [08:00] I s'pose it could mean you found a hash collision. [08:02] [was during an attempted `bzr push bzr+ssh://...`, both sides bzr 1.1] [08:02] You could probably repack the far side to get rid of it... [08:02] repack? [08:03] Yeah, assuming it's not all in one pack already. That would get rid of the colliding name. [08:03] Not sure why you'd end up with it in the first place, short of a real collision (which is impressively unlikely). [08:03] But it's a workaround. [08:04] I kicked off a `bzr check`. We'll see if it reports anything, and then I'll try again. [08:05] Hm. Second attempt at push "just worked" (and quickly, too). [08:06] * AfC wonders if there was network damage somewhere along the way, and what the likelihood of repository damage is. [08:07] night all - have a good wekkend [08:12] like brain damage, its hard to tell ;) [08:12] heh [08:12] unless its profound [08:12] then its all screwed anyway [08:13] Well, I did a full branch to a blank repository and have the test suite running. That's a reasonably astute check. [08:17] yeah. figure you have X revisions times x files of x bytes in size / packets transmitted blah blah blah - 3.14 = the chance of any one revision getting messed up [08:17] by some unknown network data coruption [08:18] that is in its own rather unlikely [08:18] because malformed packets are generally disgarded [08:19] so I like bzr how about you :). yeah I am nuts and going to bed. [08:28] etteyafed: there is corruption at the nic level [08:28] etteyafed: which sadly, I have actually seen multiple times this last year [08:28] etteyafed: essentially, the NIC checksum offloading was lying :) [08:30] that is just terrible. I have not come across such things I am happy to say, at least not that I knew of. I have had to replace bad cards though. [08:33] It's unpleasantly un-rare, especially with cheaper NIC's. [08:40] I just tried adding a branch to launchpad, and it bombed out with «The URI scheme "bzr" is not allowed.» That's famous. [08:40] Pfft. So much for bothering to add data to that thing. [08:41] AfC: for a mirrored branch? [08:44] mwhudson: yeah. I was just trying to Do The Right Thing as I happened across the fact that I had previously registered a branch there some time ago. So I thought I'd add a few more, and boom. Most impressive. [08:45] AfC: hmm [08:45] AfC: file a bug, i guess [08:52] Hi. I'm currentöy using svn as the single developer on multiple projects. I need to work in a centralized environment. Why should I switch to bazaar? I branch a lot in svn, which is a pain and I hear you've fixed. And refactor a lot, but I think svn rename works ok. [08:54] Why do you need to work in a centralized environment? [08:55] appcine: Bah, just mentioning branching and subversion in the same sentence gives me nightmares. :( [08:55] (That's not an attempt to be combative, BTW; it's to quantify the real constraints. 'centralized environment' means too much and too little most of the time) [08:58] hdima: privet [08:59] hi [09:03] fullermd: Well, because I'm behind a firewall [09:03] fullermd: I need a drop-point [09:04] fullermd: so, that's what I need more than a CVCS :) [09:06] OK. Which way is that a problem? Do you mean "I need a repo outside the firewall, so I can see it from somewhere else", or "I need a repo inside the firewall, 'cuz I can't see out"? [09:09] I have three client and a svn server today. The three clients are on separate networks with no portforwarding possibilities and they all have dynamic ips. So, I need _something_ to use as a drop-zone or whatnot, be it a svn server, ftp http :) [09:10] OK. Well, you can use a central branch and checkouts, which will give you pretty much the svn workflow (just better dealing with branches etc, and faster ops since checkouts have a local cache) [09:10] You could step back from that a bit and use regular branches, but push to the central server "when necessary" (if you can quantify that 'when necessary' well enough, and trust people to do so) [09:11] And of course you can mix and match; use checkouts on a central branch, but also make local branches for stuff. [09:13] Ok, sounds good to me :) By the using the svn workflow, what am I missing really? [09:13] Well, you're missing all the power and flexibility of ultimate-distribution full-mesh style workflows. [09:13] You're also missing the irritation and frustration of ultimate-distribution full-mesh style workflows ;) [09:14] The key thing to grab onto is that it's not all-or-nothing. You can have a SVN-style workflow that everybody BUT you uses, and you can still work more distributed yourself, just tieing into the central branch when you have stuff to land. [09:14] And you can change over time how you do stuff; the way you set it up initially doesn't have to tie you in forever. [09:16] Ok [09:16] is there a way I can push to a branch so that that branches working tree is updated and maybe commited at the same time? [09:16] So you can set it up pretty much like you use svn now, and worry about changing one thing at a time. [09:17] fullermd: Sounds about perfect [09:17] fullermd: The reason I'm here ist hat people say that branching is so easy in bzr. How do oyu do it in bzr? [09:18] Well, branching and that people say it's renaming facilities are better, even though I've never eally had any problems witht hat in svn (unless in a huge refactoring session adn you forgot to branch :) [09:19] appcine: I use bzr branch FROM_LOCATION [TO_LOCATION] [09:19] etteyafed: Then cd TO_LOCATION and hacka awy? [09:19] away [09:20] appcine: but there are other ways of accomplishing basically the same thing [09:20] etteyafed: To update the working tree, look in to the push-and-update plugin. I'm not sure what you mean by 'commited at the same time'... [09:20] Odd_Bloke: Well it doesn't need to be commited, and that is actually kindof wrong [09:20] Odd_Bloke: But this plugin is it part of bzr? [09:21] appcine: Right, just that. 'bzr branch trunk work_on_foo ; cd work_on_foo ; ' [09:21] etteyafed: You'll have to install it yourself, but it is a bzr plugin. [09:21] appcine: Now, that creates a local branch. If I want to make that an additional central branch that I can work lockstep with other people on, I'd push it up to the central server, then use 'reconfigure' to change my local branch into a checkout of it. [09:22] I am looking for it at this very moment [09:22] fullermd: So I kep working on trunk and refactor in work_on_foo, then I merge them how? bzr merge work_on_too trunk? [09:22] appcine: You _could_ directly create a remote like "bzr branch bzr+ssh://server/foo bzr+ssh://server/bar", but I don't think there's any optimization of that, so it would probably copy all the info across your network twice :| [09:23] Ah [09:23] etteyafed: https://code.edge.launchpad.net/bzr-push-and-update [09:23] appcine: Well, depends on which way you merge. If you're done with 'foo', you can "cd trunk ; bzr merge ../work_on_foo", check the result, and commit it. [09:23] Ok [09:23] appcine: Or if you've done a lot of trunk, and you've got more left to do on foo, you can do it the other way; be in foo and "bzr merge ../trunk" to resolve the differences then (and save yourself trouble later), then keep going on. [09:24] And if foo is multi-part of course, you can merge it into trunk as in the first example, then keep working on it and merge again later. [09:24] Sounds easy enough. I'm printing the manual now, so I shouldn't exhaust you .. but there is one last thing I'm wondering about :) [09:24] Does bzr have anything like svn hooks? [09:25] Like, If I commit to the server, can it automatically do something? [09:25] Yes and no and much better and sorta. :) [09:25] Currently, none of the hooks fire on the server side; they're all client-side. We've just had (or are still having) a thread on the list about moving that forward. [09:25] So I'd expect movement on that over the next few months. [09:26] Ok [09:26] I'll give it a run for its money then :) [09:26] Thanks a lot for the introduction [09:27] No prob :) [09:30] Odd_Bloke: How do I install that? [09:30] just user the script? [09:32] etteyafed: Assuming you're on a *NIX, "bzr branch http://bazaar.launchpad.net/~bzr/bzr-push-and-update/trunk ~/.bazaar/plugins/pushandupdate" [09:32] yeah linux [09:33] heh. I branched to my home dir. [09:33] ill just mv it [09:33] maybe [09:33] Move it to something along the lines of "~/.bazaar/plugins/pushandupdate". [09:34] The "pushandupdate" can change, but needs to be a valid Python module name. [09:37] Odd_Bloke: Sweet. Thanks. Now I can don't have to bounce back and forth between terminal windows to get a change in the main tree. === doko_ is now known as doko [09:40] Server hooks would be awesome. but I need sleep, so I guess ill dream about them. [09:41] etteyafed: Glad I could help. :) [09:47] ls [09:47] . .. === `6og is now known as Kamping_Kaiser [10:04] hello [10:04] guys, is it possible to download bzr documentation in some form? [10:05] i mean ok, i can mirror it via wget [10:05] but it is strange the documentation cannot be downloaded (at least i could not find the place) in some form of chunked html or pdf [10:05] :) [10:05] bzr is excellent [10:06] Dejan: it *should* come bundled with your packages, debian's and ubuntu's eg. ship it [10:07] Dejan: if you installed from source, you can *build* the html, using docutils [10:07] dato, i am getting the source at this moment [10:07] it is kinda slow for some reason [10:08] (bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr.dev is on 30% and it is so for 20min) [10:08] i guess ktorrent is the reason :) [10:09] Dejan: I'm afraid it's just slow, but the doc also comes in the tarballs [10:10] dato, i tried to find tarballs on the website [10:10] bazaar-vcs.org [10:10] no doc packages there [10:11] to download [10:11] i must check if they have some "request for enhancement" place [10:11] so i can file a request :) [10:12] Dejan: the tarballs have a doc/ subdirectory [10:15] ah, i have it! [10:15] in /usr/share/doc/bzr-1.1 [10:15] :) [10:15] sorry mate, i was lazy to check that [10:17] actually it is even better than i thought [10:17] it is in asciidoc format [10:18] so i can build documentation myself [10:18] great [11:05] somebody can help me for start using bazaar? [11:14] Hiya. Is there any simple way to do this... I want to pull some vendor code into my project but still be able to update it. Their repository is subversion - so I want to import the code into my bzr branch, and then occasionally update it from their repository? [11:20] bzr-svn is what you want [11:22] ok cool. so say I have a working copy at "myproject", and I do "bzr pull svn://whatever myproject/vendor". Then can I later do "bzr update myproject/vendor" and it will get the latest changes from the upstream svn? [11:23] I'm running bzr 1.0 and I want to upgrade the branch format. Which is the best/safest/recommended at this stage? [11:24] cammoblammo: Just running "bzr upgrade" will upgrade the branch to the default format [11:26] jelmer: Hmm, I did that and I got "bzr: ERROR: Cannot convert to format . Does not support rich root data." [11:26] cammoblammo: Ah, this is a branch created by bzr-svn you're trying to upgrade? [11:26] cammoblammo: try "bzr upgrade --rich-root-pack" [11:27] jelmer: Cool. Are any of the formats preferred on low memory (32MB) machines? [11:28] I think packs are more efficient wrt memory usage, but 32Mb may still be a little bit low [11:28] jelmer: Ha, that seems to be working. [11:28] jelmer: It seems to go okay, I've just got to give it time! [11:30] jelmer: Great, that seems to have worked. Thanks! [11:31] cool [11:31] looks like we need to file a bug about upgrade not choosing the right default [11:33] jelmer: I'm using the debian sid version. Should I file a bug there? [11:34] cammoblammo: yes, please do [11:40] Further to my question above, I am having trouble working out how to do what I want to do... I am really looking for something like Piston: http://piston.rubyforge.org/ which works with bzr [11:40] ooooooh [11:40] In other words, I want to "mount" an upstream checkout in my branch and be able to update it [11:41] bzr shell allows normal commands like vi and ls [11:41] turnip: If it were me, I'd keep a pristine vendor branch and merge it in as necessary. [11:41] turnip: this is something that you can do with by-value nested branches [11:42] jelmer: can you point me to some docs for that please? [11:43] I'm not sure there are any [11:43] :) [11:43] I've got to go for a bit, will be back in ~30 minutes [11:43] I'll see if I can find some docs on it then [11:44] jelmer: thanks [11:44] for now I'll try branch-and-merge way fullermd described [11:45] By-value nested branches are roughly the same thing, just with a little more magic. [11:45] (at least, AIUI) [11:46] jelmer: I've reported that bug to Debian. In answer to your question, the branch was originally an svn repo that came to me via bzr-svn. [11:51] fullermd: this seems to be what I want, if only it explained how it worked ;) [11:52] abentley: I guess I'm late for the party, but... thanks a lot for `bzr shell` [11:57] anybody seen cvsps-import hang on wait4() right after it says it is generating a dump file? [11:58] fullermd: I have done a "bzr branch ~/svnupstreamproject" and then a "bzr merge ~/svnupstreamproject ~/myproject/vendor/upstreamproject" but it says: bzr: ERROR: Repository KnitPackRepository('~/myproject/.bzr/repository/') is not compatible with repository KnitRepository('~/svnupstreamproject/.bzr/repository/') - any ideas? [11:59] (it wasn't those commands exactly but you get the idea) [11:59]