[00:00] aedan: only make framework changes on the framework branch. or at least put the changes you want to send the other way in self contained commtis. [00:00] I dunno how smart bzr is about cherrypicking these days [00:01] bob2: Ooh, so you're saying, if possible, commit only the changed framework files, then I can pull from that revision? [00:04] spiv: ugh [00:20] mwhudson: its rsyunc [00:31] lifeless: thanks for the suggestions you provided me earlier today. already migrated and all issues fixed. [00:32] marianom: excellent [00:37] heh, bzr.dev is too old to work with bzrtools.dev [00:52] spiv, lifeless: did my no-LockableFiles.__del__ patch fail tests? [00:54] mwhudson: no it was pending a prior patch, one sec [00:54] k [00:57] lifeless: i still get [00:57] error: Error -5 while decompressing data [00:57] on the bzr.dev.chk [00:57] i have a 64 bit install, could that be related? [00:58] lifeless, did you see my reply about default-rich-root ? [00:59] mwhudson: from what? (I have a 64-bit install too) [00:59] jelmer: no [00:59] lifeless, http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/53957 [00:59] lifeless: bzr log --short -l 10 [00:59] lifeless: brisbane-core @ 3875 [00:59] bzr-groupcompress @ 47 [01:01] rollback to 43 [01:01] lifeless: ah, now we're go [01:01] jelmer: you want a new format, default-rich-root, which should be an alias for another format right? [01:03] lifeless, Yes, but what format it is an alias for will change in the future [01:03] just like --default does [01:03] jelmer: right, which is what aliases are all about [01:03] lifeless, right [01:03] jelmer: so just register an alias [01:04] lifeless, that's what I'm doing afaik [01:04] no, you're adding a new method [01:04] well, a new method to maintain the alias [01:04] you just need to register a new format that is an alias [01:06] lifeless, so you basically want me to move the contents of set_default_rich_root() to the top-level of bzrlib/bzrdir.py ? [01:07] lifeless, imho it's cleaner having that stuff in a separate method [01:07] uhh [01:08] lifeless, jam, etc: bzrlib/_chk_map_pyx.pyx seems to have an error in brisbane-core [01:08] /home/mwh/canonical/repos/bzr/brisbane-core/bzrlib/_chk_map_pyx.pyx:232:25: Expected an identifier or literal [01:09] jelmer: no; I'm suggesting you do what the other alias formats do [01:09] jelmer: which would be consistent :) [01:09] oh [01:09] my pyrex does' [01:09] lifeless, which means duplicating the branch format / repo format in a couple of places [01:09] n't support ++ [01:09] += [01:11] lifeless: anyway, if it's consistent I'll fix my patch but the way the aliases work seems suboptimal to me [01:11] jelmer: one place only. You could also put in a patch to make alias formats easier to manage; I object to the patch you have put in because it widens the registry interface specially rather than generally [01:11] when the thing that is needed is already in general use. [01:14] * mwhudson is thinking that delta computation must be a little tiny bit faster in chk repos: http://pastebin.ubuntu.com/130001/ [01:14] strangely though log --short -l 10 still takes 3 seconds [01:15] and heck [01:15] *-l 1* takes 3s [01:17] spiv: (Pdb) ll = bzrlib.registry._LazyObjectGetter('bzrlib.branch', 'Branch.hooks') [01:17] (Pdb) ll.get_obj() [01:17] *** AttributeError: 'module' object has no attribute 'Branch.hooks' [01:17] something is killing "start up" time on chk branches [01:17] spiv: I am not liking this :( [01:27] spiv: I would like a hand, otherwise I will feel that the code I have that works is better [01:39] mwhudson, lifeless: the startup time could easily be the time to unpack the one large group for all of the revision texts. [01:39] we have a couple ideas of how to make that better [01:40] and I'll go ahead and work out a fix for broken old pyrex versions :) [01:40] jam: we might want to do something about that [01:41] 'bzr visualize' is a completely awesome thing [01:41] thank you all [01:41] mwhudson: --lsprof on log --short -l 10 might be useful [01:41] for making it possible [01:41] glyph: you're welcome [01:42] suggestion though: "bzr glog" might be a good alias for it [01:42] jam: http://pastebin.ubuntu.com/130009/ [01:43] is 'dvc' the generally preferred emacs integration mechanism for bzr? [01:43] lifeless: http://pastebin.ubuntu.com/130010/ [01:43] * mwhudson not feeling so good, biab [01:44] glyph: glog would be an awesome alias [01:45] mwhudson: what is the 'iter_inventory_xml_keys' change? [01:45] glyph: vila: will know [01:45] otherwise, I understand the += => = a + change [01:45] jam: something lifeless gave me yesterday, i didn't mean to give that to you :) [01:45] and it is committed to brisbane-core 3876 [01:45] jam: the .pyx fix is all i needed to make it compile [01:45] cool :) [01:47] mwhudson: try setting _NO_LABELS = True [01:47] in groupcompress.py [01:48] and see how that changes "bzr log --short" time === mneptok_ is now known as mneptok [01:50] mwhudson: ah, that won't actually make a difference, as it parses the labels if they are there [01:51] I can give you a one-line change to the parser, though, just a sec [01:56] mwhudson: you can cherrypick revno 48, or use: http://pastebin.ubuntu.com/130013/ [01:57] (sorry it isn't 1 line, but it was cleaner this way) === timchen1` is now known as nasloc__ [02:20] mwhudson: that patch has some typos, this one is better: http://pastebin.ubuntu.com/130019/ [02:20] it drops off about 300ms for me on 'bzr log --short -r -10..-1' [02:32] vila: quick fyi: new patch is up [02:43] jam: it gets me back to "error: Error -5 while decompressing data" [02:45] jam: oh no, pebkac; it just doesn't apply cleanly to r43 of groupcompress [03:02] so my branch of loggerhead is less of a dos attack on servers, i hope [03:02] it still does a pretty good job on firefox if you ask for it... [03:27] mwhudson: cool [03:28] oh and the code is horrible beyond all belief [03:28] :*( [03:28] why [03:28] because i've been hacking [03:29] now i know it works and feels ok, it's time to do it right [03:29] wat have you done [03:30] some ajaxy loading [03:30] play, if you like: bzr+ssh://bazaar.launchpad.net/~mwhudson/loggerhead/finite-revision-pages [03:33] what does it do though [03:41] mwhudson: like, is it just skipping html rendering on the server? [03:44] lifeless: it's more about not including stuff in the initial page sent to the browser [03:44] lifeless: so for example, in the changelog view, not sending the list of changed files until the disclosure triangle is clicked [03:51] mwhudson: cool [04:01] I'm having difficulty figuring out when one branch originated from another. I thought bzr viz would show it but I don't see anything obvious. Is there some other way? [04:14] glyph: I have no idea if it's preferred, but if you find any bugs please report them on launchpad ;-) [04:14] re: dvc [04:16] jml, http://imgs.xkcd.com/comics/not_enough_work.png [04:20] mwhudson: your patch landed [04:27] poolie: yeah, I've seen it. [04:27] glyph: welcome to #bzr :) [04:38] * SamB wonders why *bzr-status* is in dvc-diff-mode [04:39] lifeless: thanks for the hooks registry :) [04:39] is there a way to get structured information out of bzr status ? [04:43] SamB from another process? you can try the bzr-xmloutput plugin [04:44] but then I'd have to parse the XML ... no json? [04:44] (just because it's a heck of a lot simpler to parse than XML, not that I'm writing AJAX or anything) [04:45] not currently I believe [04:45] extending bzr-xmloutput could be extended to provide json I guess [05:11] LarstiQ: Hi there, I've started work on nested trees, starting with merging bzr.dev into your latest. [05:28] spiv, not to interrupt you too much, but did you already fix something like bug 341535? [05:28] Launchpad bug 341535 in bzr "hpss SmartMedium doesn't handle eintr" [Undecided,New] https://launchpad.net/bugs/341535 [05:31] poolie: I did, for the TCP client medium [05:31] poolie: there's a osutils.until_no_eintr helper [05:32] thanks [05:32] i don't think i care quite enough to do it right now [05:32] maybe when fetch progress is a bit more cooked [05:37] is there a way to cancel a bzr rm ? [05:39] SamB: if you mean undo, then 'bzr revert filename' works === abentley1 is now known as abentley [05:42] jml: well ... I have files still [05:43] SamB: I don't follow. [05:44] they had gotten moved away from where they should have been, is all [05:45] and then I foolishly ran "bzr rm" with no arguments [05:48] SamB: so you have a change in your working copy you want to revert, the change being that some files were unversioned; "bzr revert filenameA filenameB ..." as jml says is the way to undo that. [05:49] hm, should upgrading a bzr.dev mirror to --development take like hours and spin at "checking repository format 1/1" for 2 or so? [05:54] bob2: possibly :P you'reusing bzr.dev? [05:55] lifeless: yeah [05:58] rfc: there should also be a 'connecting' activity indicator to show that's what we're waiting for [05:58] activity as opposed to a progress thing [05:59] i.e. a spinner [06:03] poolie: it would be nice, although a little bit hard to implement accurately perhaps? I'm thinking of when bzr+ssh delegates the connecting to an openssh subprocess... [06:04] spiv, i'm basically saying it should do [06:05] spiv: what would it mean for it to be accurate in that situation? [06:05] > report_activity(self, 'connecting') [06:05] before running openssh [06:06] so it won't spin but at least it'll show that rather than just '0kB' [06:08] oh [06:08] you just want a message [06:08] "hey this is what's I'm about to do, just hold on, I'll be right back!" [06:09] poolie: ah, right. +1 [06:09] SamB, exactly [06:10] SamB: Well, there's arguably a significant difference between "waiting for SSH to connect" and "waiting for remote bzr to reply to my first request" [06:11] I'm not sure it really matter too much in practice. At least at the moment our first requests don't require much processing time on the server. [06:11] spiv: well, it would at least tell you that bzr wasn't ransacking your local storage ... [06:12] though I guess if you're actually sitting at your computer you'd know anyway ... [06:19] spiv, doing something for the hello would be good too [06:25] poolie: when probing for bzr+http? === abentley1 is now known as abentley [06:28] or on the first request to the smart server [06:28] just an idea [06:28] it might take a while to get going === abentley1 is now known as abentley === abentley1 is now known as abentley [07:34] spiv, remote.py has [07:34] 1509 if not resume_tokens: [07:34] 1510 # XXX: Ugly but important for correctness, *will* be fixed during [07:34] 1511 # 1.13 cycle. Pushing a stream that is interrupted results in a [07:34] 1512 # fallback to the _real_repositories sink *with a partial stream*. [07:34] 1513 # Thats bad because we insert less data than bzr expected. To avoid [07:34] 1514 # this we do a trial push to make sure the verb is accessible, and [07:34] 1515 # do not fallback when actually pushing the stream. A cleanup patch [07:34] 1516 # is going to look at rewinding/restarting the stream/partial [07:34] 1517 # buffering etc. [07:34] is that true? === kiko is now known as kiko-afk [09:30] Can i push a branch i was working on to another server? I did a push and i just get the .bzr directory on the other side (no files) [09:31] stefanlsd, right, remote pushes don't create working trees [09:32] so you have the branch, but not the actual files [09:32] if you want the files, you need to run: bzr co . [09:32] but subsequent pushes won't update them [09:32] you need the push-and-update plugin for that [09:32] unless you *only* care about the actual files remotely, then you can use bzr-upload [09:33] beuno: mm. im trying to setup that another guy in my office can work on some of the projects with me. So i made a place on a remote server. I wanted to take my local bzr stuff and get it there. Would it be better to just scp it to the central server now? [09:34] stefanlsd, no, he can just branch from that [09:34] beuno: its not there yet. I have it all locally. i wanted to get it there first by pushing.. should I rather go central and branch it from me? [09:35] stefanlsd, it *is* there [09:35] if you pushed it, and there's a .bzr directory [09:35] that's the branch [09:35] you don't need the working tree (actual files) [09:36] beuno: oh. interesting. wasnt aware of that [09:40] beuno: thanks. so my understanding now is, if i want the working tree there also i need the push and update plugin. will look into that. thx! [09:40] stefanlsd, you're welcome [09:41] what is the diff between bzr push and bzr up [09:41] ? [09:42] cristi_an, one is used for checkouts, and one is used for branches [09:42] (there's more to it, but let's start with that) [09:42] beuno: thx...i did not find this in the 5 min tut :) [09:43] which one i sfor checkouts [09:43] cristi_an, how did that question pop into your head? [09:43] well...i explain [09:43] i get a project called openerp from launchpad [09:43] The help for up probably ought to mention the term "checkout" somewhere. [09:44] but after a few day since i was i cvs user before [09:44] i did bzr up [09:44] but it did not bring any of the changes done by others [09:44] cristi_an, did you branch it, or did you make a checkout? [09:46] beuno: i run a script that get all those projects for me... [09:46] http://paste.pocoo.org/show/107535/ [09:47] cristi_an, ok, so you branch them [09:47] 'bzr update' won't come into play at all for now [09:47] in terms of using cvs [09:47] i checkout them... [09:47] :) [09:48] well, you can do a checkout with bzr as well [09:48] and then it's basically the same [09:48] when you commit, it will commit directly to the online branch [09:48] "update" brings in new changes, etc [09:48] a checkout is bound to it's parent [09:48] but can you tell me what that script does [09:48] branches, on the other hand, are independant [09:48] i seee [09:48] yes, it creates branches [09:49] so i have c copy locally [09:49] and i work local [09:49] then i can merge with some server branch [09:49] ? [09:49] somthing like commit will commit on my local branch [09:49] not on server ? [09:50] cristi_an: Your script takes a --checkout option. Supply that option with your launchpad username to make the script do "bzr checkout" and "bzr update" instead of "bzr branch" and "bzr pull". [09:51] i have to read about this more.... [09:51] :) [09:51] but i got the picture.... [09:52] thx === abentley1 is now known as abentley === bac` is now known as bac [13:00] Can anyone help me with setting up a bug tracker within Bazaar? The documentation I've found tells me about it, but not how to do it === `6og is now known as Kamping_Kaiser [13:25] nick_: What kind of bug tracker are you talking about? [13:25] hmeland: a custom made one - I basically want to know what things I need to put in the bazaar.conf file in order to get it working with --fixes [13:30] You've seen http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#bug-tracker-settings already? [13:37] hmeland: yes, but it seems to be lacking explanation [13:37] hmeland: for example, I don't know what parameters Bazaar passes my bug tracker when I mark a commit as --fixed [13:37] I'm assuming it HTTP POSTs by default? [13:38] nick_, no, it's metadata on the branch [13:38] no http communication at all [13:40] beuno: ahhh, so how does the tracker get this information, through a post commit hook? [13:40] nick_, well, it's up to the tracker [13:40] tip-change [13:40] cronjob [13:40] whatever [13:40] beuno: I see [13:40] beuno: are you familiar with the shell_hooks plugin at all? [13:41] nick_, not really, no [13:41] beuno: ah, just I can't get it to work :) [13:41] beuno: I'm not well versed with Python [13:43] does anyone know of a post commit hook that can HTTP POST to a URL? [13:54] * SamB wishes bzr-gtk didn't have that unintended seahorse dependancy :-( [13:58] When I bring in changes from someone else's branch via 'bzr merge', I have to write a new log message when I then do 'bzr commit', even though the other person already wrote a log message. I can even see the original log message when I do 'bzr status' ("pending merge tips: ...", or with -v, "pending merges: ..."). Is there some way to commit the merged change(s) locally such that they automatically get the same author and commit message as [13:58] the originals? [13:58] kfogel, not atomatically, no [13:59] beuno: hmrm. Okay, thanks. So it sounds like there isn't really a way to say (in a non-mirror branch) "Just bring in these changes, I don't want to have to specify anything more about them, I just want them incorporated into my local branch." [13:59] ? [13:59] kfogel, right, the merge is always explicit [14:00] *nod* [14:00] beuno: thx [14:00] :) [14:01] beuno: is there at least some way (immediately after 'bzr merge') to get the full information about all merged-but-not-committed changes? Specifically, I want to list their source branch and revision number, in my commit message. [14:01] beuno: or is that pointless, because bzr will already record those when I commit? [14:02] other than bzr status? [14:02] (in which case, great, but I'd still want to *see* the pending revs before committing) [14:02] beuno: bzr status -v shows committer, date, and msg, but not source branch or rev num [14:02] right, so there's not way that I know of to see those [14:02] that may be useful [14:03] so it sounds like you're cooking a bug there [14:03] :-) [14:03] Yeah, it would be nice to be able to see the exact identity of what I'm about to commit. For an especially paranoid developer, that might be part of a sanity check. [14:03] high in protein! [14:03] SamB: breakfast of champions! [14:04] but at least you know their descriptions -- darcs isn't even capable of telling me what revisions have conflicted [14:05] * kfogel looks at bzrlib/status.py:show_pending_merges() [14:05] (apparantly it's not even easy in theory!) [14:09] * awilkins is totally awesomed out by how awesome uploading things to a PPA is [14:10] Why the hell does it build fricking Atom builds of things though..... [14:15] beuno: crimminy, don't even have the information available in bzrlib/revision.py:Revision, as far as I can tell. [14:17] Atom ? [14:18] you mean it converts them to RSS feeds? [14:19] (Yeah, I know Atom isn't actually named RSS -- but then basically no two versions of RSS expand to the same name either) [14:20] * SamB wonders how glyph found out about dvc [14:21] jelmer: bzr svn-import is currently failing for me (after a few mins of running) on htps://dev.serverzen.com/svn/cluemapper [14:21] jelmer: that's with bzr 1.13rc1 and bzr-svn 0.5.3 [14:23] policy question: when bzr can receive a setting from either an environment variable or the bazaar.conf file, which overrides which? Does the env var dominate the config setting if both exist, or the other way around? [14:31] (this is for implementing a new thing -- if it were an existing feature, I'd just test) [14:54] kfogel: well, usually the env var, I hope [14:54] SamB: that's what I picked [14:55] might depend on the setting a bit, but for instance if I have an emacs package that wants to turn off the progress bar ... [14:56] ... then I'm going to be annoyed by https://bugs.launchpad.net/bzr/+bug/339385 [14:56] Ubuntu bug 339385 in bzr "bzr: BZR_PROGRESS_BAR is ignored" [Medium,Confirmed] [14:57] * SamB wishes ubottu would get it right and say "Launchpad bug" [14:58] SamB: well, that's just because of the bug, right? It doesn't change the correct ordering. [14:58] yeah [14:59] I was just being silly with that last message [14:59] going to a conclusion unrelated to the premise [15:00] (the premise that the env var should override the conf file, that is) [15:00] (I don't think there is a conf setting for this?) [15:01] I certainly don't see a progress bar setting in my bazaar.conf [15:02] * SamB wonders if there's some sort of script to manually convert an svn:ignore property to .bzrignore [15:03] jelmer: is there a way to query SVN revision properties from bzr-svn ? [15:03] no, wait, this would be a file property [15:03] well, both things would be good anyway [15:04] and the way should be mentioned in "bzr help svn", of course [15:06] * SamB wonders if there's a way to get launchpad to build and serve docs [15:16] * SamB re-opens https://bugs.launchpad.net/bzr-svn/+bug/174947 [15:16] Ubuntu bug 174947 in bzr-svn "Commands for changing/viewing file properties" [Wishlist,In progress] [15:19] does anyone know how to get word-wrap in emacs (without altering the buffer data)? [15:19] i.e. yes, I know how to use M-q, that's not what I want ;-P [15:25] oh, emacswiki says LongLines [15:25] SamB, I think we did have them at some point but they got removed, since they were just aliases for "svn propset / svn propget" [15:25] jelmer: how's that going to work in a bzr-native format checkout/branch/etc? [15:26] SamB: there's no way that can work in a bzr native format [15:26] oh [15:26] SamB, but with a bzr-specific command it can't work in a bzr native format either [15:26] since the bzr native format can't store custom file properties [15:26] wait, I din't need an answer to how is "svn foo" going to work in a bzr-native directory ;-P [15:26] that was rhetorical [15:27] leon@bespin:~/Documents$ bzr update scrip/ [15:27] Permission denied (publickey). [15:27] bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) <-- What does this usually mean? I know it's something to do with my messing around backing up the branch to Dropbox and changing keys, but I'm not sure what I can do to make it work now. This branch is hosted on Launchpad and I can check it out without problems. [15:27] I thought you were giving the second (bzr format can't handle that) answer already ;-) [15:27] SamB, I also mean "bzr svn-propset" can't work in a bzr-native directory [15:27] * Leon_Nardella sorry for the multiple lines [15:27] SamB, since there's no place it can store the properties [15:27] jelmer: oh [15:28] SamB, the way you've changed the bug report right now indicates I'm working on it.. that's not the case :-) [15:29] jelmer: well, you can change it to something more appropriate [15:29] I thought maybe you'd somehow hidden it where I couldn't see it :-) [15:29] given it a funny name or something [15:29] SamB, are you still interested in it if it's just going to be an alias for "svn propset" / "svn propget" ? [15:30] not if it requires a .svn dir, no. but some documentation about the uselessness of such a thing would be good. [15:31] SamB, I'll comment in the bug report [15:31] and I would be interested in extensions to bzr to allow it to be useful, as well [15:31] jelmer: how about adding it to the FAQ? [15:31] SamB, that's the sort of documentation you meant, right? [15:31] in addition, I mean [15:33] like: "Q: How can I look at my file properties?" "A: If you're in an svn checkout, the usual way. If in a bzr native tree, there aren't any to see." [15:35] SamB, Care to send a patch ? :-) [15:40] how can I take the difference of two branches? [15:40] one has a bug, one doesn't :-) [15:41] ah --old [15:42] hmm... well that is lying [15:42] SamB, just curious, what sort of properties would you want to set ? [15:44] sohail: How so? [15:45] Odd_Bloke, bzr switch buggy-branch; bzr diff --old non-buggy-branch -> no diff which is not true [15:46] oh do I have to give the full path to the old branch? [15:46] that's annoying but ok [15:46] sohail: Yeah, that'll be it. [15:47] sohail: Though there should probably be an error message if there isn't a branch at non-buggy-branch... [15:50] Odd_Bloke, I'd agree with that [15:56] ok I need to binary search where this bug was introduced... how do I do that with bzr? is there an equivalent to svn up -r $FOO ? [15:56] sorry if my question is ignorant :-) [16:00] you can either make new checkouts at given revisions, or bzr revert might help you since you can pass that -r $FOO [16:00] but I'm not a power-user, so I could be wrong [16:01] I just found the bzr bisect plugin [16:01] lets hope it doesn't screw up my repo :-) [16:03] how does one unbind a bound branch [16:04] glyph, bzr unbind :-) [16:04] jelmer: I figured that out a split second before you said it, and felt appropriately foolish :) [16:06] glyph, :-) === gorozco is now known as p4tux [16:10] haha... bzr bisect: 1115 no, 1118 yes, 1116 yes, 1116, 1116, 1116, 1116, explode [16:10] lol! [16:10] screw this, I'm going ot exercise [16:12] heh [16:22] Does anybody here know how to mirror a git repository into a launchpad branch? [16:35] ripps: jelmer might? [16:35] then again maybe you can't [16:36] I think it will involve a cron job on a system you have a shell on, though [16:36] ripps, small repositories should be convertable with git-import from bzr-git, alternatively you can use git fast-export/ bzr fast-import [16:36] ripps, there's nothing in launchpad to have it mirror for you automatically (yet) [16:36] jelmer: so, back to manually uploading it [16:36] or if you control the git server you could use some kind of post-hook [16:37] ripps: cron! [16:37] hmm, how come you can't just give launchpad svn:// URLs to mirror the bzr way, anyway? [16:38] why does it have a special vc-import thing for that? [16:38] SamB, hysterical raisins [16:38] SamB, vcs-imports predate bzr-svn [16:38] I suppose it's good for the users anyway [16:38] jelmer: oh. how does it work then? [16:38] SamB, there has been talk about using bzr-svn on lp [16:38] SamB, but the problem is it will cause disruption for users of the existing mirrors [16:39] I mean, it would be kind of confusing to expect users to just enter an SVN url as if it was a BZR url [16:39] SamB, it use cscvs [16:39] SamB, what would be confusing about that? [16:39] jelmer: well, for new users anyway [16:39] SamB, there are mirrors of "regular" bzr branches too [16:40] SamB, In general the format of a branch shouldn't matter, whether it's Subversion or native Bazaar [16:40] anyway ... the obvious way to go to bzr-svn would be to allow people to start entering those SVN urls in the field, then tell them about it after a while ... [16:40] and just keep doing vcs-import the same way as before [16:41] SamB, yeah [16:41] SamB, unfortunately there's no shared history between stuff imported with vcs-imports and bzr-svn [16:41] SamB, so users can't really migrate from vcs-imports to bzr-svn [16:41] yeah [16:42] but giving new users the option is good [16:42] does bzr-rebase share git-rebase's "no revision 0" flaw? [16:42] SamB: well, it means that if somebody you work together with happens to do a commit based on a bzr-svn branch and your branch is a vcs-improts branch it breaks [16:42] jelmer: oh [16:42] it breaks? [16:43] SamB, "breaks" in the sense that it doesn't have any shared history [16:43] it doesn't just ... not show up nicely? [16:43] vcs-imports doesn't grok SVK attributes? [16:43] anyway, that doesn't sound much worse than using SVN in the first place ... [16:43] SamB, and will attempt to merge from rev 0 as it doesn't see common revisions [16:43] jelmer: huh? [16:43] SamB, I'm not sure I understand what SVK has to do with it [16:43] what do you mean? [16:44] SamB, it will attempt to merge *all* revisions from the bzr-svn branch as none are present in the vcs-imports branch [16:44]