[00:02] hi poolie [00:06] * AfC waves to Verterok [00:11] hi AfC :) [00:36] jelmer: ping [00:36] lifeless: pong [00:37] jelmer: re your virtual files things [00:37] jelmer: I'm guessing you want to avoid code dup between bzr-git and bzr-svn ? [00:37] jelmer: if so, perhaps a good staging place would be bzr-foreignformatsupport or something ? [00:38] lifeless: as in a separate plugin you mean? [00:38] I'm not against the things you are producing coming into the core bzr, but perhaps for other core devs the overall shape of what you are producing is not visible yet [00:38] yes, as in bzr.plugins.foreignformatsupport [00:38] ah, in a plugin but shipped with core? [00:39] well [00:40] I was actually meaning 'keep it completely separate until its more clear' [00:40] I'd rather not require a separate plugin to be installed for bzr-svn and bzr-git to work [00:40] we have the open bug about shipping > bzr's tree on make dist [00:40] hmm, perhaps thats what I should do today [00:40] that means an extra plugin to package and it means requiring users to install yet another plugin for either to work [00:40] well [00:41] you've got a month till 1.7 anyway [00:41] so packaging would be premature right now; and I will have a poke at a dist-many thing today [00:41] evolution is *still* importing :( [00:42] Jc2k: how long did the full evo import take initially ? [00:42] jelmer: Has bzr-svn -.4 moved much in the last week ? [00:42] poolie: bug 252428 as requested [00:42] Launchpad bug 252428 in bzr "stacking must always grab full inventories" [Critical,New] https://launchpad.net/bugs/252428 [00:43] lifeless: well, even though something may be planned to land rsn it may take far more than that so I'd rather not rely on anything until it's actually there [00:43] jelmer: fair enough [00:47] lifeless: alternatively, do you think it's a sane goal to allow repositories to not provide the inventories and revisions versionedfiles? [00:48] instead allowing functions that provide the unmarshalled objects to be returned [00:48] we don't generally want to go up to objects at all [00:48] e.g. diff shouldn't need a full Inventory; that doesn't scale [00:48] (for inventories I mean) for revisions we have object methods already [00:49] sorry, I should've phrased that differently [00:49] The stated goal of the versionedfiles attributes is that other objects that *understand* a particular serializer can use them to do direct access [00:49] e.g. stacking [00:49] I don't mean Inventory objects just python objections in general, e.g. inventory deltas as well [00:50] so, I think its completely fine to have None for those attributes as long as you have a unique serializer, and your code knows how to do all the operations that in the generic Repository are implemented in terms of those attributes [00:51] at the moment, that would horribly break stacking though [00:51] I don't think its desirable, but I will agree that having unoverridablecode require them is a bug [00:51] that's why I've got them implemented at the moment [00:51] jelmer: stacking will always depend on them [00:51] jelmer: at least for the foreseeable future [00:52] (the 1.6 format stacking logic depends on the same /representation/ to apply deltas across repositories) [00:52] and these attributes are about providing access to representation [00:53] that's what my question was though [00:53] if/when we get a stacking facility that does not depend on representation (which group-compress is shaping up into fwiw) then we can do the (non-trivial) work to make every single method stacking aware [00:54] do you think it's a sane goal to work on allowing stacking on repositories that don't have the same representation? [00:54] yes [00:55] ok, that's what I was hoping to hear :-) [00:55] I may look into that depending on how hard it is, but I probably won't have enough time [00:55] I suspect its non trivial [00:56] for now I'll just keep copies of my VirtualVersionedFiles classes in both bzr-git and bzr-svn [00:56] *every* method that accesses the storage attributes today will need to be taught to stack, and every data-access method needs to fail in such a way that lookups can then be made to the different source [00:57] it was hard enough doing it on just the 8 or so methods of VersionedFiles [00:57] lifeless: this would only be for revisions and inventories though [00:58] k [01:02] lifeless: "bzr branch" works in bzr-git now (again?) btw [01:02] I haven't been able to figure out why though [01:03] it seems just implementing get_revision(), revision_tree() and get_ancestry() on Repository was sufficient [01:03] which is quite scary, really [01:03] lifeless: would it also work to require the first commit of an inventory in the new repository to require a full text? [01:03] i mean store a full text [01:05] poolie: pull(other repo) can introduce deltas [01:05] poolie: so I don't think its sufficient, or necessary === sdboyer_ is now known as sdboyer [01:22] lifeless: it seems like we need to check the models are compatible every time we add_fallback_repo, do you remember if we do [01:25] poolie: yes, we do [01:26] if not self._add_fallback_repository_check(repository): [01:26] raise errors.IncompatibleRepositories(self, repository) [01:26] which is [01:26] return InterRepository._same_model(self, repository) [01:29] jelmer: I'd really suggest a plugin for the common code rather than having duplication; one extra branch command for early adopters really shouldn't be a show stopper IMNSHO [01:30] jelmer: but up to you [01:30] lifeless: I'm getting enough bug reports from people not using the right combination of (bzr, bzr-svn, svn) as it is, would rather not make that a 4-tuple [01:31] lifeless: also, not looking forward to finding a sponsor for yet another debian package [01:32] jelmer: well, you could always roll the code into either bzr or each plugin at release time; but like I say, its your call [01:33] lifeless: sounds like more overhead for myself than copying two files over each time I change them [01:33] of course, I could always make bzr-git depend on bzr-svn.... :-P [01:34] lifeless: any reason why having two copies is a particularly bad idea, other than the fact that code duplication in general is bad? [01:36] jelmer: because it makes testing the impact of a change harder for you [01:38] poolie: did you see bug 251871? [01:38] Launchpad bug 251871 in bzr "assumes source_branch format is the same as result branch format" [High,New] https://launchpad.net/bugs/251871 [01:43] bye bye firefox, OOM killed === abentley1 is now known as abentley [01:53] bOOM headshot. [02:07] Odd_Bloke: :) [02:11] jelmer: can you make 'bzr branch lp:bzr-svn' DTRT - that is download the current development bzr-svn suitable for use with bzr.dev ? [02:14] lifeless: that should already be the case [02:14] jelmer: cool [02:18] jelmer: not yet, looking [02:22] lifeless, did you intend to close the bzr-svn task of bug 252259 as invalid as well? [02:22] Launchpad bug 252259 in bzr-svn "SystemError: Parent module 'bzrlib.plugins.search' not loaded" [Undecided,New] https://launchpad.net/bugs/252259 [02:23] jelmer: no, that was my comment 'lets see if launchpad knows what I mean' :) [02:26] jelmer: what did my email do to the bug precisely? [02:27] lifeless: it marked the bzr-search task as invalid and opened a task for bzr-svn [02:27] then the next email seemed to mark the bzr-search task as invalid again [02:27] did it mark the bzr-svn task as invalid too ? [02:27] (the next mail ? ) [02:27] no, that's New atm [02:27] no, that just marked the bzr-search task as invalid *again* [02:28] so I sent one email; and I wanted it to make the bzr-svn bug invalid and the bzr-svn one new [02:28] oh [02:28] I sent two emails [02:28] lifeless: You may want to rephrase that :-) [02:28] EContext [02:29] marking the bzr-svn bit as both invalid and new doesn't make sense [02:29] righto, I think its probably some nasty import error somewhere [02:29] the SystemError smells of svn bindings or something to me [02:29] but yeah, I would have like to close the bzr svn bit too [02:29] done by hand [02:49] Sorry for the off-topic question, but which channel would I go to with PPA problems? ubuntu-motu? [02:51] launchpad I think [02:54] #launchpad for PPA specific issues (timeouts, crashes in the facility etc) [02:55] #ubuntu-motu if you just want a hand driving PPA's as they have most of the mentors etc [02:55] Gotcha. [04:21] Where can I read about sending bzr patches over email? [04:22] bzr help send? [04:22] er [04:22] Too slow, apparently. [04:23] yeah, lift your game :-) [04:23] Where can I read about sending bzr patches over email? [04:23] ooh here he is again :-) [04:23] bzr help send [04:24] sorry, I accidentally quit. =\ [04:24] happens to the best of us old chap [04:24] alecwh: also, http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#sending-changes === thunderstruck is now known as gnomefreak === jamesh_ is now known as jamesh [06:27] * mwhudson pushes the new loggerhead theme to trunk!!! [06:29] mwhudson: congrats [06:29] beuno: you too [06:40] woo [06:40] well done [07:00] Yay. :) [07:15] http://www.toolness.com/wp/?p=71 is interesting. I guess these people would really like bzr's checkout workflow? [07:21] spiv: i wondered whether that was 'ooh, don't really like hg' or 'oooh, don't really get dvcs' [07:22] (sprinting so didn't really have enough spare brain cells to actually read the blog post properly) [07:29] mwhudson: it's hard to tell from this distance, really. Especially if the only dvcs they've used is hg... [07:57] spiv/lifeless: i want to give better messages when repositories are not compatible [07:57] for stacking or other reasons [07:57] at the moment you just get told they're not and that's it, so not much help to a user [07:57] i'm planning to add an alternative api to InterRepository.is_compatible which raises an exception (rather than returning False) if they're not [07:57] so we get to keep that information [07:57] any comments? [07:58] * bob2 gives polite 'yay' [08:00] poolie: I like the sound of that. [08:03] eg https://bugs.edge.launchpad.net/bzr/+bug/206258 [08:03] Launchpad bug 206258 in bzr "incompatible repository error messages are unhelpful" [Undecided,Confirmed] [08:04] poolie: is_compatible is used for selecting an optimiser [08:05] poolie: so having one that raises an exception doesn't feel right to me, I can just see use spewing out 10 different incompatibilities [08:05] s/use/us/ [08:06] if you're searching for one where it passes you would not print them [08:06] and we can keep a method that just says 'did it pass' [08:06] I'm talking the failure mode [08:06] essentially we have at the moment [08:06] if not foo(): raise Exception(generic) [08:07] and i want to invert that [08:07] hm unless there is one method for matching and another for checking? [08:07] there are N optimisers [08:07] when none match that will give you N exceptions [08:07] which one will you show? [08:08] I think what you want to achieve is good; I'm all in favour of clearer error messages [08:08] Jelmer has a patch that improves the KnitRepository __str__ to make the rich-roots->plain case more understandable [08:08] hm [08:09] at the moment i actually want to change _same_model, which while it lives in InterRepository is apparently not multiply-dispatched [08:09] being a static method on the base class [08:09] but a different model doesn't imply an error message [08:09] its a very specific combination of models that generates an error [08:09] Do we need "incompatible_model"? [08:10] *everything* is compatible except for "rich-root or subtrees to plain" [08:11] i don't think that's actually true [08:11] there are more implementations of it that check requirements with weaves and knits [08:12] oh? [08:12] to answer your earlier question if we are searching for a match and none of them matches [08:12] no, i don't think it would be useful by default to tell the user of every possible thing we tried and why it failed [08:12] but i can believe having that information available for debugging might be useful [08:12] into the log or something [08:12] via a -D flag perhaps [08:13] right [08:13] quite seriously though, I don't believe there are any other cases where is_compatible falls all the way back to the default implementation [08:14] there are various InterFORMAT ones [08:14] there is InterSameData [08:14] and InterModel1and2 [08:14] ok [08:14] i'm going to poke at it a bit more [08:14] so the only case I know of is Model2and1 that will fail [08:15] *other* fetch failures can occur [08:15] but they occur once a selection has been made [09:21] jelmer: ping [10:06] lifeless: sorry i have no idea [10:06] the initial import of all of GNOME ran over a few days, with me stopping and starting as i hit bzr-svn leaks [10:06] and the initial import of SVN was only of trunk, i then used svn-import to "top up" and pull the 2000 branches over [11:41] http://www.toolness.com/wp/?p=71 [11:42] I'm not posting that as "Bazaar is better than Mercurial", it's s/Mercurial/Bazaar/ as you read and get an idea of how some people dislike DVCS. === doko_ is now known as doko [12:02] james_w: yeah, I saw that [12:02] james_w: although I think bzr's checkout workflow would answer a bunch of the concerns tehre [12:03] it's odd that he seems to consider a clean merge more dangerous than a clean update [12:03] james_w: there's room for argument, but it's certainly possible to read the core problem as "I don't want the overhead of tracking/merging lots of branches, but the tool doesn't give me any options other than to make branches" [12:04] that's true [12:14] I think it's more about that svn allows you to do 'implicit' update [12:14] that is, you can commit even if your tree is out of date [14:12] hi [14:13] how do I tell bzr that the current versions I have are the latest, it seems to think that there are conflicts. [14:15] hi keithy [14:16] I'm not sure what you mean, could you expand on your question please? [14:19] I found it bzr resolve --all [14:34] hello [14:36] when making a change in a file got by bzr how to upload only that change? [14:36] hi TuniX12 [14:36] what do you mean by upload? [14:37] upload that change to bzr branch [14:37] "bzr push" to an existing branch will push only the difference between that branch and yours, if that's what you mean. [14:37] ah thank i thought it push all files [14:38] no, it won't, but it will push a bit more than just the diff to the changed file, as it will have to push the revision information as well. [14:38] and sorry for my bad english :p [14:38] no problem :-) === mario_ is now known as pygi [14:41] hi, I'm testing 1.6beta3 and I get a error when trying to create a new copy of a branch. The error is AttributeError: 'property' object has no attribute 'initialize' in bzrdir.py, line 1384. Has anyone seen this? is there a fix? [14:42] i get this error bzr: ERROR: Cannot lock LockDir [14:42] Transport operation not possible: http does not support mkdir() [14:42] any solution? [14:44] ah, found bug report. [14:44] would be nice to have a beta4 [14:46] ping [14:53] these people don't have any patience nowodays... === mw|out is now known as mw === mthaddon_ is now known as mthaddon === thekorn_ is now known as thekorn === orospakr` is now known as orospakr [16:11] yay! new theme landed! === andrea-bs_ is now known as andrea-bs [17:15] [24601] 2008-07-28 17:56:28.680 INFO: Committing to: sftp:/..... [17:15] Mon Jul 28 18:14:50 CEST 2008 [17:15] [========================================================================================== ] Uploading data to master branch - Stage 4/6 [17:15] 18 minutes and counting, for a few lines of commit [17:15] Bazaar (bzr) 1.5 [17:16] strk, can you take a look in ~/.bzr.log ? [17:16] low bandwidth, all used -- still, is a developer really supposed to suffer this much ? or is it a bad bug ? [17:16] there should be something in it [17:16] lots of 601.406 SFTP.readv() 13 offsets => 1 coalesced => 1 requests [17:17] 497.074 Auto-packing repository , which has 17 pack files, containing 10300 revisions into 4 packs. [17:17] ^^ you're interested in this one most likely [17:17] or : [17:17] 128.259 Using fetch logic to copy between KnitPackRepository('file:///home/strk/src/gnash/bzr-local-repository/.bzr/repository/')() and KnitPackRepository('sftp://strk@bzr.savannah.gnu.org/srv/bzr/gnash/.bzr/repository/')() [17:17] strk, right, it's autopacking [17:17] it happens every now and then to make things faster [17:17] it's always autopacking [17:17] is there a way to make it happen NEVER ? [17:17] strk, no, it should only happen once every N commits [17:17] not currently. [17:18] That would be bad for performance. [17:18] there is a bug open so that bzr will tell you that it's doing that [17:18] well, until I'm back on a good connection and ready to wait x*10 minutes [17:18] performance of what ? [17:18] it's 24 minutes I'm starving on a commit !! [17:18] hopefully we'll have server-side packing soon, which should be much much quicker. [17:18] james_w: That won't help sftp. [17:18] james_w, although server-side packing probably won't work with sftp [17:18] :) [17:19] what happens if I comment out the line where N commits is checked ? [17:19] I mean, what happens if autopack is NOT done ? where's the performance hit going to be noticed ? [17:19] or, when [17:19] strk: without packing performance will degrade over time. [17:20] by performance you mean time a commit takes to complete ? [17:20] Performance in general. [17:20] That would include committing. [17:20] some things will scale with the number of packs, without packing this is the same as scaling with the number of commits, with packing it scales log(number of commits) [17:20] can it be worst than it is now ? 30 25 minutes ? [17:21] I'm used to a *few* seconds for similar commits with CVS [17:21] yeah, it would include committing. Basically anything that needs to access information in the repository. [17:21] it's a very small patch [17:21] and I can thinkg of a few lines of log [17:21] what else am I missing that needs to generate so much traffic ? [17:22] it is packing locally, which means that it is pulling down all of the repository data and pushing it back up organised slightly differently I believe. [17:22] argh [17:22] crazy [17:23] strk, yes, it is. It will be fixed [17:23] would a lightweight checkout avoid all of this ? [17:23] no, I don't think so. [17:23] damnit, it's depressing [17:24] maybe we should setup a cvs commit-hook doing the bzr commit remotely [17:24] james_w, I think he should be able to run a cron that packs? [17:24] that may mitigate it a little bit [17:24] done [17:25] 30 minutes [17:25] I'm on low bandwidth [17:25] yeah, that should help. I assume that the autopack logic looks at the number of packs as well as the number of commits. [17:25] can't do "offline-commit" forever [17:25] hard to collaburate with others if I keep all the commits locally [17:25] was used to do very frequent small commits [17:25] strk, you could run a cron to execute "bzr pack" on the branches every... week? [17:25] beuno: would it need bandwidth ? [17:26] that will probably avoid hitting autopacking remotely most of the time [17:26] strk, not of the cron runs on the server, no [17:26] oh [17:26] that'd be savannah [17:27] well, I've been online way too much now. lifeless: I hope you can take care of this with savannah hackers. [17:27] thanks for your patience [18:30] as an aside, if you ^C during the autopack, the commit still was pushed [18:31] so it still counts as valid [18:31] though it isn't something I would generally recommend. [19:02] I've got a test problem where calling branch.bzrdir.open_workingtree() seems to either give a different tree to the one that I expect, or doesn't have the changes that were made in the test code. [19:02] I think it is the latter, as the path in the repr is correct. [19:03] so I create a tree, make a couple of commits, and then make a call that eventually ends up the code I am testing. That code receives a branch, and I need a wt, so I try and open it, and the tree I am given has no revision history. [19:04] does this indicate a problem, and that I need to modify the code to provide a working tree directly, as I can never be sure that re-opening the working tree will do the right thing? === cjwatson_ is now known as cjwatson [19:31] james_w: well, re-opening the WT should give the right answer, unless you are using a MemoryTree [19:31] also, are you sure you are changing the right paths? [19:31] Often, you might have created the branch/tree in a subdir [19:31] but then possibly modified the files in the current dir [20:07] hello, [20:07] if it some is available, i have a question : [20:08] it's possible to push on a server my modified file ( not the revision file .bzr ) [20:08] The commande bzr export work but only on local ( sftp not work with export ...) [20:08] Thx [20:08] Roumanos, you mean the files, but not the revision data? You can use bzr-upload, which will just upload the working tree [20:09] yes [20:10] Roumanos, https://launchpad.net/bzr-upload [20:10] Perfect ! [20:10] very thx !!!! [20:11] exactly what i research ! [20:11] Roumanos, your welcome [20:22] the download page is empty, not yet available ? [20:22] need to get this by bzr ? :P [20:22] Roumanos, not as a release. Are you on Ubuntu? [20:22] yes, you get this through bzr :) [20:23] mkdir ~/.bazaar/plugins && bzr co lp:bzr-upload ~/.bazaar/plugins/upload [20:23] and you're set [20:23] no sorry, gentoo .... [20:24] that should work on Gentoo just as well [20:24] yes, just need to dl this plugin .... [20:25] Roumanos, the command above will work in Gentoo [20:26] Yes, it's working great ! [20:26] big thanks for this very quick reponse ! [20:26] Roumanos, it's what we do (tm) [20:27] feel free to file bugs if you need any additional features [20:27] ;-) [20:27] ok, i will look on this plug-in and make a summary later ! [20:27] thansks [20:33] I'm sure this gets asked a lot (so do please point me at URLs), but what would be the benefits of using bzr rather than svn for keeping my home folder in a VCS? One .bzr folder (rather than one per folder) is good; are there other benefits I don't know about? [20:35] keeping your home folder in a VCS is a bad idea, no matter what VCS you use [20:36] luks: really? I'm forever losing things, and having numerous different machines and having to repeat the same configuration changes and installations on all of them is jolly awkward. [20:37] what kind of things are you losing? [20:37] versioning config files is fine, versioning your whole ~ is not (IMO) [20:39] random files that I accidentally delete, or that I create on one machine and then don't have on others. [20:39] I'm not going to drop my music collection into svn :) [20:41] if you can accidentally delete a file, I don't think you will always add and commit those random files to a VCS [20:41] no, I agree. I'll still miss some. Not all, though. === mw is now known as mw|food [20:42] I don't know, I really don't like this "versioned file system" idea [20:43] or, maybe I'd like it, but not in a VCS intended for source code [20:44] but if you decide to go this way, I don't think you would enjoy using bzr for this (too slow for that kind of working tree) [20:44] * luks waits for people to disagree [20:45] * aquarius nods. That's useful advice, and thanks. [20:47] * Jc2k would disagree [20:47] we are thinking of using bzr instead of git for our versioned file system [20:47] though, to be fair, rewriting the bits of bzr we need in c === oohlaf is now known as oohlaf_ [20:57] I wonder why people in #svn so often mention a non-existing command 'bzr unversion' [20:57] They're just being subversive. === oohlaf_ is now known as oohlaf [21:15] If I've got a bzr copy of a project in Launchpad, and I want to publish the changes I've made so the project team can look at those changes, am I supposed to publish them to my +junk folder on LP or to the project itself in a branch named by me? Bit confused... [21:16] Odd_Bloke: congratulations. Isn't that your first package in Debian? [21:16] aquarius: ~aquarius/project/branch-name [21:16] hey LarstiQ [21:16] hey james [21:16] LarstiQ: ah, excellent. === mw|food is now known as mw [21:26] hrm. Confused, again. I bzr pushed to launchpad (thanks, LarstiQ) and it's created that branch, but it's not clear to me that there's actually code there for people to look at. https://code.launchpad.net/~sil-launchpad/gwibber/system-buttons [21:27] aquarius, http://bazaar.launchpad.net/~sil-launchpad/gwibber/system-buttons/changes [21:27] Launchpad takes a while to scan the commit messages [21:28] but your branch is there [21:28] wow! did I miss a link to that page or is it just not there yet? [21:29] aquarius, it's not there yet, I cheated. It should be on there soon-ish, and there is a bug open to show that link right away [21:29] * aquarius grins [21:29] so I was right to be confused :) Your bug: good work there :) [21:29] aquarius, :) [22:22] lifeless: ping [22:34] aquarius: at the bottom of https://code.launchpad.net/~sil-launchpad/gwibber/system-buttons [22:34] it does say "This branch has not been scanned yet" [22:34] though I won't say it is very obvious [22:40] aquarius: there is a LP rollout shortly that should fix the scanner problem [22:41] jam, thumper: yeah. I didn't know what "scanned" meant -- it seems to mean "no-one can get at this branch yet", which I don't mind, but having a thing which says "this can take a few hours" might not hurt. (Or, just fix the problem by making scanning happen straight away, if that's possible.) [22:42] well, it is supposed to only take 5 min or so [22:42] I don't know what the hold up is [22:42] jam: the hold up is a bug which causes a mysql branch to fail after 12 minutes [22:42] jam: which it tries every time [22:44] thumper: so it is a 12-min timeout, then it gets another branch scanned, repeat ? [22:45] jam: so it gets everything to scan (which may include multiple mysql branches), then does them one after the other [22:45] jam: any that fail, get tried the next time around (1m cron) [22:46] aquarius: scanning takes bzr metadata and stores it in a database [22:46] aquarius: until the branch is scanned we don't show stuff as we don't know what to show [22:47] aha, got it. So the branch might be private in some way or something, so the public can't pull from it until scanning has happened? [22:52] aquarius: it is pullable / branchable, but the webapp doesn't know that [22:53] oh, cool. So people who already know their way around LP will be able to get it, at least? [22:55] aquarius: yes [23:06] Could someone help me figure out why I can't bzr init? http://paste.ubuntu.com/31484/plain/ [23:06] Can anyone tell me how to convert an existing "shared repository with trees" into a "shared repository"? [23:07] ryanakca: bug in bzr-svn, which has been fixed in newer versions of bzr-svn [23:07] ryanakca: as a workaround, try "bzr --no-plugins init" [23:07] dvheumen: You mean into a shared repository without trees? [23:08] jelmer: yes that what I mean... I tried out 'bzr reconfigure' but I don't know how to change it to treeless [23:08] jelmer: splendid, thanks :) [23:11] dvheumen: would you file a bug about that, I think it should know [23:11] james_w: do you mean as a feature request? [23:12] yes please [23:12] k, I'll do that, tnx [23:12] dvheumen: and to do it now you can use "touch .bzr/repository/no-working-trees" [23:12] "bzr remove-tree" will remove any existing working trees that you don't want. [23:13] james_w: I already found out about that command, that wasn't the problem... it's just that new branches would still have trees [23:14] james_w: should I report the bug as a missing feature for 'bzr reconfigure'? [23:15] or should I just say 'Can't convert repository to treeless repository' (in a few more words) [23:15] yes please, I've been looking for somewhere to put that function and reconfigure seems like the best place [23:15] well, if you just report the latter I'll follow up and recommend the former. [23:17] jelmer: untill I get to upgrade, any other workarounds? "bzr --no-plugins init" gives ``bzr: ERROR: No repository present: "file:///home/ryan/work/kubuntu-startpage-mockup/"'' [23:18] ryanakca: Is there perhaps a .bzr directory in that location already? [23:18] james_w: Isn't this bug report about the same issue? https://bugs.launchpad.net/bzr/+bug/145033 [23:18] Launchpad bug 145033 in bzr "need a command to switch a repository between trees and no-trees" [Medium,Triaged] [23:18]