=== mbp_ is now known as poolie [00:05] spiv, igc, i'm having some skype issues... [00:05] are you here? [00:11] lifeless: ping [00:35] Right 4 hours is enough. I may try again tomorrow [02:17] Is there anything special you need to do when pushing a loomified branch? I pushed a loomified branch to launchpad from my laptop and then branched that onto another machine, but it didn't seem to have the threads. [02:17] I have the bzr-loom plugin on both machines [02:20] gdoubleu: Did you 'bzr record' first? [02:20] i did not [02:20] I think you need to. [02:20] Though I don't really use looms, so am not sure. [02:21] I'll try that and attempt to push again [03:24] how do i make a branch7 branch? [03:26] poolie, spiv? [03:27] oh, done [03:40] hi all [03:41] fyi, I'll be working on porting/testing fastimport to use the new Repository API today [03:41] but I'll be offline for a few hours first - lunch & my daily hospital visit first [04:31] hey, can bzrlib.repofmt.pack_repo.RepositoryFormatPackDevelopment1 get a new name in bzr.dev really fast? [04:35] mwhudson: Why? [04:35] well, because it's a terrible name [04:36] What would you suggest instead? [04:36] SuperDuperFormat? [04:36] RockinFormat [04:36] not sure what the conventions are [04:36] It'll be renamed to SuperDuperFormat or somesuch once it's actually that. [04:37] But, ATM, it's a development format. [04:37] Something without "Development" would be nice, once it's no longer in Development. [04:38] well, i'm kinda hoping 1.6 is actually going to get released soon [04:38] mwhudson: I think this format will be in development during the 1.6 cycle. [04:38] s/1.6/1.7/ [04:38] So will be renamed before 1.7 is released. [04:40] So before then, users will only see it if they've opted-in to the use of a development format. [04:45] speaking as a launchpad developer, i really hope not :) [04:45] there's a difference between a development format and a non-default format, surely [04:48] In what sense? [04:49] well, in the 'option name' sense [04:49] rich-root-pack is a non-default format that isn't a development format, for example. [04:49] Well, it'll be hidden, I think. [04:49] It certainly should be hidden... [04:50] i.e. the option for it is relatively non-scary, it isn't hidden, etc. Whereas I think the --stacked option on a branch isn't going to be hidden? [04:50] ISTR some discussion about it on the list. === jamesh_ is now known as jamesh [05:06] mwhudson: i have a patch that makes it a stable format [05:07] poolie: excellent [05:11] how can i see things that are note()d or mutter()ed when prodding bzrlib interactively? [05:11] * mwhudson has vague memories of trace.enable_default_loggin()... [05:11] like from a python interpreter [05:11] yes that should do it [07:04] Odd_Bloke: about the pushing looms, it looks like it's not possible yet: https://bugs.launchpad.net/bzr-loom/+bug/201613 [07:04] Launchpad bug 201613 in bzr-loom "pushing looms does not work properly" [Critical,Triaged] [07:09] i think that bug is actually mostly fixed [07:09] apart from the 'when do i need to record' confusion [07:10] * mwhudson wanders off [09:03] How do I turn off the bzr prompt thing that seems to have installed itself into /etc/bash_completion.d ? [09:08] boys, my bzr got locked, what to do ? --> Unable to obtain lock lp-147252812:///~rapache-devel/rapache/rapache-stage0/.bzr/branch/lock === stub1 is now known as stub [09:08] break-lock doesn't seem to work [09:09] bzr: ERROR: Unsupported protocol for url "lp-147252812:///~rapache-devel/rapache/rapache-stage0/.bzr/branch/lock" [09:09] Is it a bug that bzr has installed /etc/bash_completion.d/bzrbashprompt.sh (breaking my prompt), or is there some way I need to turn it off? [09:10] tacone: is that long number supposed to be there in the protocol? [09:10] /msg tacone Oh, just FYI, there are women here, too. [09:10] stub: just have to rm it for now [09:11] girls, my bzr got locked :(. http://pastebin.com/m4a069b45 what to do ? [09:11] :) [09:12] stub: there is a bug report about that [09:12] tacone: maybe try `bzr break-lock bzr+ssh://tacone@bazaar.launchpad.net/~rapache-devel/rapache/rapache-stage0/` [09:12] * tacone is about to switch in scared-newbie-mode-on [09:12] tacone: "bzr break-lock bzr+ssh://tacone@bazaar.launchpad.net/~rapache-devel/rapache/rapache-stage0/" [09:12] AfC: beat me :) [09:12] lol [09:12] spiv: Hooray! [09:13] And then file a bug about the message that tells you to do different [09:13] stub: I'm just doing exactly that [09:14] worked [09:14] Terrific [09:14] I'll file a bug for that, thanks. [09:16] tacone: I just filed one [09:17] tacone: https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/250451 [09:17] Launchpad bug 250451 in launchpad-bazaar "bzr suggests wrong URL for break-lock with a LP hosted bra" [Undecided,New] [09:18] why does bzr-svn not want to store my creds :S [09:20] spiv: oh god. I was about to click submit :-) [09:21] ok, trashed :-D [09:22] thanks you all. goodbye [09:43] kiorky, it's not bzr-svn that doesn't store them [09:44] kiorky, it's bzr itself [09:44] kiorky, any chance you can file a bug about this? [09:45] Jc2k: is the conduit guy around at the moment ? [09:46] lifeless: he is [09:46] Jc2k: I have a few minutes before leaving for the train [09:46] rick_h__: hi [09:46] lifeless: *tries to lure him on to gnome-bzr* [09:47] 'morning lifeless [09:49] ohi jelmer [09:59] jelmer: yep, but i am at work, but sue i can when i l have time [10:00] jelmer: maybe around 12:30, so 11:30 for u [10:00] Thanks [10:00] jelmer: describe me what u want as backtrace or tests and etc [10:02] kiorky, just the fact that passwords aren't saved should be sufficient [10:06] Hi, I'm running the "merge3-per-file" version of bzr and it just pops into "pdb" all the time. Can't see that it has any breakpoint set ot anything. Typing "cont" will run for a while and then stop at the same line again. Any advice? [10:07] blaudden, Is that John Meinel's branch? [10:08] You'd probably want to talk to him - he's around here as "jam" but it's probably too early for him right now [10:08] yes, it looks like that from "bzr log" [10:08] ok, i'll hang around. Thanks! [10:14] blaudden: presumably there's a "pdb.set_trace()" either in your branch of bzr, or perhaps in a plugin [10:14] blaudden: I'd try grepping for pdb in your branch of bzr and also in ~/.bazaar/plugins [10:14] If you do "bt" at the (pdb) prompt it should give an indication of where the pdb.set_trace() line is [10:15] spiv: i'll try that. [10:18] 850 import pdb; pdb.set_trace(); [10:18] thanks! [10:20] blaudden: ta-da :) [10:25] hello [10:26] spiv,poolie: Hallo! [10:50] lifeless: still around? [10:53] rick_h__: yes, going v soon though to start travelling home [10:54] lifeless: cool, have a good trip then [10:54] just wanted to try to get this repo/branch thing right in my head [10:54] ok [10:54] check that "commiting to the repo" "add files to the repo" were good [10:54] and that creating a branch, and serving out the branch were right [10:55] the docs with the shared repository for multiple branches seemed to make some sense [10:56] I've just never set it up that way so repo == branch for appearance [10:56] yeah [10:56] branch is the user abstraction people work with [10:57] there is always a repository for abranch, its implicitly created if no explicit one was made by the user [10:57] so should I also commit your changes to the branch then? [10:57] and the only time really refer to the repository is if setting up a shared one? [10:57] yup [10:58] jelmer: hey [10:58] ok, sounds like a plan then [10:58] the tip of a branch is the latest revision [10:58] a branch has a tip, tags, and configuration details [10:58] yea, that comment in that article threw me a bit, but I found some of the docs that seemed to clear it up more [10:58] jelmer: how soon will bzr-svn be faster (the "find_tags is slow" bug)? :) [10:59] well have a nice trip lifeless and hopefully this article will be life in Oct and then I can bug you on some more advanced stuff :) [11:00] sure thing [11:25] spiv: couple of days hopefully [11:44] With one slow and large svn repository, bzr-svn spends a massive amount of time crawling the whole thing for tags even when I do a no-op "pull", and even though the branch I actually have checked out is quite tiny. [11:44] Peng, there's an open bug about this [11:46] Okay. Well, if you want an example branch, http://software.inl.fr/svn/mirror/tools/ipy/trunk (but I didn't try to reproduce it; I don't feel good about abusing random svn servers to test things). [11:46] Peng_, Thanks for reporting this. It'll hopefully be fixed in a couple of days [11:47] (see also spivs comments a couple of lines back) [11:47] Yeah, since the subject had been brought up, I just wanted to mention it. [13:05] jelmer: uhm i have another problem, i have a bzr+qsvn branch, then i rebranch locally, but it trys to acces the foreign repo. Why ? [13:06] jelmer: the work connection is pretty bad, soi like to work offline :) [13:09] hey [13:49] kiorky, hi [13:50] kiorky, I suspect you don't have an actual local branch but just a local working tree [13:50] kiorky: E.g. "svn co" will not create a local branch [14:07] jelmer: i used bzr branch svn+http://svncred:pass@foo [14:07] jelmer: then bzr branch ../path [14:08] kiorky: Where ../path was created with "bzr branch" ? [14:08] the first yes : "bzr branch svn+http://svncred:pass@foo" [14:08] not "bzr co" ? [14:08] nope [14:09] if that created "foo" then "bzr branch foo bla" should not access the network [14:09] i can redo it to double check [14:09] let me a minute === mw|out is now known as mw [14:11] jelmer: ~>bzr branch foo bar [14:11] Login LDAP Makina Corpus mpa password: [14:11] jelmer: :) [14:12] which a fresh bzr branch svn+... [14:12] (in foo) [15:50] bug in bzr-svn relating to checkouts: https://bugs.launchpad.net/bugs/248289 [15:50] Launchpad bug 248289 in bzr-svn "concurrent access problems" [Undecided,New] [15:50] It seems that bzr will try to lock the checked-out branch during a bound branch's commit... [15:51] but it can't lock an svn "branch", so it winds up rewinding history on the svn repo. :-( [15:53] I didn't even notice this had happened until recently... apparently I've done it four times in the last six months... [15:53] s/done it/triggered this bug/ === NfNitLoo` is now known as NfNitLoop [16:28] Is there something in bzrlib that I can use to list files in a remote directory? I'm specifically talking about a non-branch directory (e.g. a directory that might contain branches) [16:30] * pickscrape looks at bzrlib.transport === pmatulis is now known as pmatulis_afk [16:34] pickscrape: there is listdir(), but it doesn't work over http [16:36] james_w: I've got transport's list_dir working very nicely over bzr+ssh, thanks! === mw is now known as mw|brb [16:46] Bazaar can use a variety of different libraries for http, correct? [16:47] where 'variety' == two [16:47] urllib and pycurl? [16:47] but I think plain urllib2 is now the prefered one [16:47] yes [16:48] is one faster than the other? [16:48] faster in what way? [16:48] even if one is faster than the other, it won't be noticable [16:49] network will be limiting them, not CPU [16:49] it's just that bzr over http seems quite slow to me [16:49] bzr is slow over http [16:49] or generally, bzr is slow :) [16:49] especially with networking [16:49] bpeterson: slower than what? [16:49] hg [16:50] I still use Bazaar because st, diffing, and committing are pretty snappy, but not networking... [16:50] what format are you using? [16:50] (bzr info) [16:51] rich-root-pack [16:51] ah, not much you can do, I'm afraid [16:52] is rich-root-pack a comprise for space over something else? [16:53] bpeterson: I think what he means is that the pack-based formats are the most efficient formats right now, so there's nothing better for you to upgrade to for better performance over HTTP [16:53] bpeterson: static-http for hg? [16:53] yep [16:55] how does sftp compare to http for performance? [16:55] still the same bottleneck? [16:56] actually I'm more concerned with performance over bzr+ssh [16:56] No, I think sftp has all different bottlenecks :) [16:57] I'm pretty sure sftp eats more round trips, so it's probably a bit more latency sensitive. [16:57] it's over ssh, so shouldn't have state? === mw|brb is now known as mw [16:57] Well, bzr+ssh is a totally different beast from either, so... [16:58] mm === pmatulis_afk is now known as pmatulis [16:59] I think it must depend a lot on various factors (e.g. size of your repo). I just did some tests on a very small branch of mine... and bzr+ssh actually went slower than http. [17:00] probably because it has additional overhead of ssh connection and starting up bzr on the remote end [17:00] I'm working with the Python core bzr repo; ~200 MB [17:34] 'bzr st' still claims a pending merge, even though I've shelved it away for now... How might I clear that? [17:35] In actual fact I probably want to just revert it, but I'm keeping it shelved for now [17:35] LeoNerd: bzr resolve [17:35] bzr revert --forget-merges [17:35] Ah yes; the latter did it [17:35] bpeterson: isn't that for conflicts? [17:35] yes, never mind [17:40] luks: hi [17:40] hey [17:40] good evening [17:41] luks, Garyvdm was very helpful in fixing regressions [17:41] I think we are ready to release 0.9.2 [17:41] I haven't followed the latest fixes [17:41] I'm planing to prepare some screenshots with new features [17:41] but the current state is usable for me [17:42] me and Gary have fixed all known (for me) regressions so far [17:43] Does anyone know what happened to the bzr gentoo overlay? [17:43] luks: so I'm about to starting release process tonight or tomorrow [17:43] cool, thanks a lot [17:44] I've uploaded translations to launchpad, still waiting for review :( [17:44] I saw. [17:44] I'm confused because I could cange status of some translations [17:44] I'm confused because I could change status of some translations [17:45] I won't wait for translations and don't want to delay release [17:45] but if you wanna to update sk.po I'll wait [17:45] pickscrape: what's up with Gentoo? [17:47] Well, I added the overlay a while back to layman, which set it up as a bzr branch that it would pull [17:47] But lately it seems that the branch it pointed at has gone away. [17:47] Wondering if it has died or just been moved somewhere else. [17:47] luks, I can't create deb for linux. But it will be nice to have it for 0.9.2. This release will be a bomb [17:48] bialix: umm, I might do it [17:48] but I actually wanted to get rid of the PPA [17:48] it's easy to install it on linux [17:48] well, I'm fine either way [17:49] if you will close PPA, then I'll just need to update our wiki page properly [17:49] I did :) [17:49] or do you mean more than removing it from there? [17:49] Is bzr-gtk no longer going to be in the bzr PPA then? [17:50] this is about qbzr [17:50] oic [17:50] pickscrape: I'm actually using Windows, but I saw this: https://launchpad.net/bzr-gentoo-overlay May be it helps you [17:51] bialix: thanks, I just found that myself. I think they might have moved it, so I'm setting it up again to find out... [17:51] luks: I mean this: https://launchpad.net/~luks/+archive [17:51] I don't know PPA well, so maybe presence of 0.9.0 confused me a bit [17:52] let me see if I can remove 0.9.0 from there [17:52] ok. I'm just wanted to check this with you [17:53] I'll probably build 0.9.2 after the release [17:53] but in a ~qbzr-dev PPA [17:53] ah, ok. make sense [17:56] Hi. I work in a project that makes a lot of tags. |wc -l says "320". This brings into relief that tagging in bzr is kind of weird. [17:57] A tag is just a human-readable "friendly" name for a revision... same as a hostname is just a friendly name for an IP address [18:00] chadmiller: How are you using tags, and how is it a bit weird in bzr? [18:00] (eg, care to elaborate?) [18:00] You might be using branches for tags, which is an older way that is certainly clumsier [18:01] Consider this morning: Tim noticed that some tag was on the wrong revision. He used "bzr tag --delete", "bzr tag", "bzr push" to change it. Paul comes along and, on pull, gets "Conflicting tags:\n\tblah-blah". This concerns Paul. He's questions whether his tree is valid, completed "pull" correctly, et c. [18:02] chadmiller: well, tim could have used "bzr tag --force" but sure [18:02] He can't tell very much with "missing" or "log". [18:03] The problem is that tags aren't versioned [18:03] so when they disagree [18:03] we don't know which one is "more correct" [18:03] Right. [18:03] we've had some long discussions about it [18:03] it is hard to do better without introducing a whole lot of "meta" overhead [18:04] chadmiller: is there some ui polish we could apply to make it a bit more understandable? [18:06] I think my biggest problem with it is informational. Maybe the "Conflicting tags" message should also have "Don't Panic" in warm, friendly letters. [18:08] Conflicting tags: <3 <3 [18:08] Something like that? [18:08] now it sounds like bzr is enjoying your suffering [18:09] perhaps provide a bzr tag --rename command? [18:09] or document that you should use bzr tag --force if you want to rename [18:10] here, I'll send you a bundle [18:11] bpeterson: "bzr help tag" [18:11] --force Replace existing tags. [18:11] But if it is missing in other documentation, feel free :) [18:12] also, '--rename' sounds like it would change the name of the tag (but point to the same revision) [18:12] which isn't the same as pointing the same name to a different revision [18:12] :) "Your $(verb)s completed, but upstream disagrees about which revisions these tags should appear on. Your tags were not updated. Conflicts:\n" [18:12] isnt' that what chadmiller wanted? [18:12] "%", not "$", grr. [18:12] chadmiller: well, probably 'not all tags were updated" [18:12] but I understand [18:13] Something in the "tag{,s} --help" about resolving those would be good too. [18:15] And "bzr pull --clobber-local-tags" ? [18:15] so if you want to rename a tag (change the name, but keep it on the same revision), you should bzr tag --delete name and bzr tag --force name [18:15] ? [18:15] We actually encountered exactly this this mornin g [18:15] bpeterson: I would do "bzr tag new-name -r tag:oldname" [18:15] and then "bzr tag --delete oldname" if you prefer [18:15] A colleague changed a tag, and when I tried to pull I got the 'conflicting' message [18:15] but deleting tags doesn't propagate at the moment.. [18:16] The solution was for me to redefine the tag at my end, after that pull worked. [18:17] The problem is, I didn't know (other than talking to him myself) what revision he had changed it to [18:17] pickscrape: I *think* you can also "pull --overwrite" but I'm not 100% sure. [18:17] pickscrape: bzr log -r tag:NAME path/to/his/branch [18:18] jam: I was worried about --overwrite clobbering my local changes [18:18] or 'bzr tags -d /path/to/his/branch" [18:18] It would have been good if the message had told me which revision the tag was defined as upstream [18:24] uhh. that new launchpad ui sure gets me === mario_ is now known as pygi [18:52] is there anyway to save my password for HTTP auth [18:52] it's a pain typing it every time [18:52] even worse ... it asks me several time [19:04] Uhm, is the ppa "bzr-beta-ppa" a likely candidate for the real release? [19:05] There's some serious evil in there. [19:05] Care to list specific evil? [19:05] I know poolie plans a couple changes before an rc1 [19:06] etc/bash_completion.d/bzrbashprompt.sh . 1) clobbering $PS1. 2a) running a python interpreter twice for every shell prompt. 2b) running /bzr/ twice for every shell prompt. [19:07] chadmiller: ah, that is planned to be fixed [19:07] we weren't meant to install that file [19:07] it is a packaging issue [19:07] Whew! Okay, good. [19:07] in the short term you can just rm that one [19:08] that reminds me of when I installed git-core and it installed a bash completion file which ran git twice [19:08] unfortunately, there's another program I have installed in ~/bin called "git", which is an interactive fiction interpreter for Glulx games [19:09] so every time I started a new terminal two GUI windows would pop up and give an error message === mw is now known as mw|food [19:11] radix: at least it wasn't on every \t :) [19:11] heh, yeah [19:34] I'm writing a plugin for internal use that provides a main command with subcommands (shelf-style) [19:35] it's been going well, but I'm now having a problem adding options to the subcommands [19:35] It seems that bzrlib is trying to parse them as part of the main command, and complaining that it doesn't have the option [19:36] I suppose this is because subcommands are a bit of a hack, bit I'm wondering if anyone knows of a workaround [19:37] pickscrape: ah, you're overloading short options that already exist in bzr? [19:37] pickscrape: oh no, I see now. [19:38] pickscrape: well, as a hacky workaround, combine the main command's options from the subcommand options? [19:38] LarstiQ: I was just going to try that. It might work, the only problem being the options would show up againt the main command in the help output. I will give it a try though [19:43] pickscrape: yeah [19:46] pickscrape: you may be able to write a subclass of Command that works better with subcommands [19:47] james_w: I thought I'd find that when I originally looked at the shelf code, but didn't. Now that I've hit this obstacle I think I might revisit that idea again :) [19:47] it would be a useful thing to have in the core for other plugins to make use of, e.g. shelve [19:48] Yes, I was thinking that too. If I get one working I'll see about making it available to bzr. Thing is, nothing in bzrlib would actually need it right now. [19:49] pickscrape: but because it isn't there, no one feels invited to use it :) [19:49] chicken/egg :) [19:49] My concern is more related to testing/bitrot: if it gets added but not used etc... [19:49] pickscrape: right, I see. [19:50] I suppose shelf could keep it happy though if it was migrated to use it. [19:50] pickscrape: if there are two plugins using it though, I think the use part is reasonably covered. For it to be accepted into core it needs to be fully covered with tests anyhow. [19:50] * LarstiQ nods [19:51] Hmm, on that idea, perhaps it would be better added to bzrtools initially, and then to core once stable etc? === mw|food is now known as mw [20:04] if i want to move an entire directory that is versioned, how would i do so? i've tried "bzr mv oldDir path\to\newDir" but i get an error that newDir is not versioned. Do I have to create and add newDir first? Is it possible to move whole directories? [20:04] i'm using windows, if it matters [20:05] Is newdir inside the same branch as the directory you're moving? [20:06] yes, its executed exactly like that, ie. both paths are relative [20:06] Gilgad13: is path\to\ versioned? [20:06] Does path\to already exist and versioned? [20:06] no, should it be? [20:06] Gilgad13: yes [20:06] Gilgad13: I'd think so. [20:07] hang on... [20:07] is there a typo in oldDir [20:07] I think if that is the case it complains about the wrong thing [20:07] no, versioning path\to worked [20:09] and an obvious next question. can I undo a specific move, without reverting to last commit? [20:18] no handy undo-last? [20:19] bzr uncommit will undo your last commit, but it will cause problems if the commit has been published elsewhere [20:20] i'm talking about operations between commits, like complex reorg's with multiple moves. Right now i either bzr revert or move the moved file [20:20] Oh. I think revert should do what you need it to [20:20] but it would be nice to have the safety net [20:21] well, if i'm like 4 move's in, it would suck to redo them because of a typo [20:21] Gilgad13: if it's really complex there is no silver bullet. [20:21] revert won't undo only the last move I don't think [20:21] damn, i like silver bullets [20:21] AFAIK it just looks at the WC picture as a whole. [20:21] pickscrape: exactly [20:21] so i'd have to start over [20:22] starting over doesn't seem like the way to go? [20:22] Could you just bzr mv the file back again? [20:22] Gilgad13: but I don't have a clear enough picture of your situation to really give advice. [20:22] pickscrape: its what i've been doing [20:22] you can "bzr mv" back, and "revert path" would probably do it, but obviously would do the wrong thing if the files were modified as well [20:22] LarstiQ: its mostly hypethetical, so no worries [20:23] Gilgad13: are you looking for a revert that only undoes treeshape changes, not content changes? [20:23] LarstiQ: yes, and if possible lets me select specific changes [20:23] problem with that being creating a tree state that never existed in history, but yes. [20:24] Gilgad13: what do you mean exactly? 'bzr revert -r a..b path/' wouldn't be enough? [20:26] having experimented more, i think its a mental problem with how i thought bzr recorded moves [20:26] as in, i thought the recorded a log of actions, but i now see that only the beginning (ie, last commit) and end(now) state matter, not how many moves were applied inbetween [20:27] s/the/bzr in first line [20:27] Gilgad13: ah, indeed. [20:42] LarstiQ: I may be jumping the gun a bit here, but it looks like the only change needed to get subcommands working properly is to call parser.disable_interspersed_args() in _parse_args after retrieving it [20:43] Sorry, parse_args [20:43] (I moved it into a local subclass and called it _parse_args.) [20:43] So if that was moved into the Command class itself, a simple switch could potentially allow subcommands with options to function. [20:44] Hopefully I didn't make any other changes that I forgot to take into account here... [21:06] In fact, simply adding that right into bzrlib appears to make everything work, and doesn't appear to break anything else. [21:06] * pickscrape goes off to run the bzr unit tests for the first time ever :) [21:15] Yeah, it does break some things. :) This is what tests are for.,.. [21:36] Gilgad13: you can 'bzr revert FILENAME' [21:36] aye, but what would that do with regards to moves? unmove them? [21:37] revert content changes? [21:38] are transparent checkouts from svn supposed to 'just work'? [21:48] Gilgad13: it would put the path back and revert content changes; I think there i sroom for a --path-only flag or something [21:48] meatballhat: yes, though you can't pull or merge into a an actual svn tree [21:49] meatballhat: ((ecause svn can't add revisions without doing a commit to a branch) [21:56] lifeless: so there is nothing akin to the 'git-svn' interface, or do I misunderstand? :) [21:57] meatballhat: you misunderstand [21:57] meatballhat: 'svn co svn://... foo && cd foo && bzr merge bzr://...' -> FAIL (the .svn directory is not capable of representing a pending merge) [21:58] meatballhat: 'bzr branch svn://... foo && cd foo && bzr merge bzr://... && bzr commit && bzr push svn://...' -> WIN [21:59] lifeless: so I use bzr with 'svn://' urls? or are you only explaining the workflow? [22:00] rather, is the use case documented for "I'm at work and my company uses Subversion, but I'd like to interface with it using Bzr" ? :) [22:03] meatballhat: I think its documented on the FAQ [22:03]