[00:00] so i think somebody in LP made the other branches [00:00] because as bad as 1 branch is, i really want 4 of them [00:00] spiv: Were there any bugs in the format detection in 1.2? [00:00] abentley: I'm not sure. I don't see anything in NEWS about it. [00:01] abentley: can I force it? [00:01] co uses the bzr default branch format, instead of the remote format [00:01] abentley: I do vaguely recall something got fixed in that area, but I think before 1.2? [00:02] Oh, doh. I forgot I defaulted checkout to --lightweight. [00:03] ohh [00:03] Yeah, I get that failure too. [00:04] k, so I'm not nuts [00:04] doing the checkout now [00:05] The way to force it is: bzr init --dirstate-with-subtrees $DIR; cd $DIR; bzr pull bzr+ssh://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy; [00:05] hey guys [00:05] something weird just happened to me [00:06] New bug: #206886 in bzr "bazaar send should support inlined content" [Undecided,New] https://launchpad.net/bugs/206886 [00:06] I tried branching using 'bzr+ssh' from a server -- worked fine. Then I did branch using 'sftp' from the same server and got an authentication error. [00:06] Can a bzr smart server prevent clients from deleting tags? [00:07] the same machine appears under a different hostname & using a different port in my .ssh/config [00:07] abentley: but will that be fast? doing a bzr pull? [00:07] and when I use sftp://hostname:22/, branch works. [00:07] BTW, does pack-92 automatically mean you also have dirstate-tags? (or the ability to do bzr tagging) [00:08] is Bazaar using one mechanism for bzr+ssh and another for sftp? [00:08] warren: yes, pack-0.92 includes tag support [00:08] LaserJock: It certainly ought to be. [00:08] jml: it shouldn't, IIRC [00:09] abentley: and it won't let me do --dirstate-with-subtrees [00:09] my bad, no 's' on the end. [00:09] LaserJock: the training trees were meant to be getting upgraded by tetet [00:10] LaserJock: setup a local repository for them, then the cost of all 4 is minimally more than the cost of 1 [00:10] maybe it's a bug in openssh [00:10] bob2, thanks for the clarification. [00:10] lifeless: can I do that with an existing branch? [00:11] ValueError: invalid literal for int() with base 10: '# Loom' [00:11] http://rafb.net/p/PiTZ3863.html has the full error. [00:13] LaserJock: yes; make the repo locally, then bzr branch your existing branch into it [00:13] lifeless: oh! [00:13] I have an edubuntu-docs branch right here [00:14] lifeless: I just got an error pulling the loom trunk into my local copy, but it was resolved when I upgraded my local branch from dirstate to pack-0.92. [00:14] spiv: bizarre [00:14] lifeless: full traceback in the pastebin above [00:15] just looks like a corrupt file [00:15] lifeless: want a copy of the troublesome branch? Or a bug report? [00:16] spiv: it looks like the knit code being handed a loom current file [00:16] spiv: which is really bizaare [00:17] spiv: uhm, if you can make it reproducable sure [00:17] lifeless: yep, I can reproduce. [00:18] cool [00:18] :) [00:18] then I'd like enough stuff to reproduce it please :) [00:18] I can't reproduce spiv's error, though I think I've seen it before. [00:19] lifeless: http://people.ubuntu.com/~andrew/loom-pull-case.tar.gz has the branch [00:19] hmm, so how do I make a share repository? [00:19] lifeless: I simply did "bzr pull", which pulled from bzr+ssh://bazaar.launchpad.net/~bzr-loom-devs/bzr-loom/trunk/ [00:20] lifeless, btw, if I'm converting a huge repository from dirstate to pack-92, should I use bzr-1.3 or is 1.1 fine? [00:20] LaserJock: for a svn converted project, bzr init-repo --rich-root-pack path [00:20] warren: 1.1 is fine [00:20] New bug: #206890 in bzr "Help pages for merge and pull should tell users about bundles" [Undecided,New] https://launchpad.net/bugs/206890 [00:20] warren: after the conversion, just run bzr reconcile [00:22] Do tags come across in merges? [00:23] foo-trunk> pull ../foo-bar (which has its own tags); bzr merge; bzr ci, are tags from foo-bar visible in foo-trunk now? [00:25] lifeless: so does a shared repo mean that a new branch will take common revisions from the local repo? [00:26] lifeless: PQM has committed my last merge request, but not published it. [00:26] Could you give it a whack please? [00:27] abentley: 'log' ? [00:27] abentley: was the merge request for yoru log changes ? [00:28] No, it was for pulling lp: locations [00:28] so if pqm didn't publish, it will have rolled back [00:28] let me look for an error [00:29] Last time I tried, it told me "nothing to merge". [00:29] ok; weird then [00:33] dang, even a local branch takes quite some time [00:33] I seriously wonder if we shouldn't just start over [00:34] LaserJock: You're branching from a location in your shared repo into another location in your shared repo? [00:34] no [00:34] from a branch I already had outside my shared repo into the shared repo [00:35] but it's still local [00:35] A branch in a different format? [00:35] no [00:35] I don't think so [00:35] lifeless told you to use rich-root-pack. You didn't? [00:35] yep, same formate [00:36] oh, you're right [00:36] ok, that makes sense then [00:36] So what you are hitting is an unoptimized conversion path. [00:36] can two bzr instances run at the same time? [00:36] Sure. [00:37] They can't both write to the same thing at the same time, of course. [00:37] I started doing the local branch at the same time I'm doing a bzr pull [00:37] and the bzr pull doesn't seem to be doing anything [00:37] You should probably wait until the local branch is done anyhow. [00:38] But bzr+ssh doesn't give great progress indicators. [00:38] * LaserJock notes that after 26 min :-) [00:39] so it looks like it's gonna be about 40 min to do the local branch [00:39] How big is this data? [00:40] well, the branch is 217MB [00:40] .bzr is 211MB [00:41] that's why I'm wondering about starting over [00:41] we're carrying so much history around for like 6MB [00:43] That seems extremely disproportionate. [00:43] well, the size of the "working tree" has grown and shrunk quite a bit with time [00:44] the size of the files in my branch probably won't ever get over ~20MB [00:44] but the ubuntu-docs branch is probably more like 100-150MB [00:47] it's just a frustration because it used to take < 5min or so to do a SVN checkout and that worked well for us [00:47] we're trying to get to the same level with bzr [00:47] but I think our project is not a great example :/ [00:48] LaserJock: once you have your repo seeded, upgrade it to rich-root-pack, because that is lots faster :> [00:49] you mean push the new branch back up to LP? [00:49] LaserJock: with a shared repo locally and rich-root-pack as the format, it'll be much snappier. The coming stacked branches feature will also help. [00:51] spiv: I hope so :-) [00:52] LaserJock: no, I don't mean push [00:53] I guess I didn't get it then [00:53] what branch do I want to upgrade? [00:53] the one I'm making should be already rich-root-pack right? [00:54] abentley: your patch is published [00:54] lifeless: tx [00:54] LaserJock: what does bzr info on the repository you created say its format is ? [00:56] lifeless: just a sec, it's just finishing branching [00:57] Shared repository with trees (format: rich-root-pack) [00:57] that's the share repo obviously [00:57] and the new branch is: [00:57] Repository tree (format: rich-root-pack) [00:57] so that took about 36min to branch locally, just FYI [00:59] now I'm trying a bzr branch of one of the other branches [01:01] ohh, that's much better [01:08] james_w: so, were did we get to [01:09] james_w: right, file ids. are they deterministically allocated? do you generate correct merge graphs? (that is, does 'bzr check' give no errors on an imported branch) === mw is now known as mw|out [02:23] * igc food === arne^ is now known as _arne^ [02:24] where is bzr 1.3 for ubuntu? [02:25] https://launchpad.net/~bzr/+archive contains only 1.2.1 [02:25] aiui, coming [02:46] * mneptok jumps up and down on kgoetz [02:46] * kgoetz bruises painfully [02:48] how's tricks, Kaiserlicious? [02:49] mneptok: pretty good. gobuntu is a bit quiet atm, but other things i;m involved in a fairly lively :) [02:51] how is the support hotseat these days? [02:56] kgoetz: getting hotter as more customers don;t like the fact we don't officially support Hardy yet [02:58] mneptok: I'd have thought they'd have moved on to Intrepid by now. [02:58] mneptok: hehe. and i assume it'll keep warming up until well after release [02:58] kgoetz: you got that right [02:59] jamesh: usually that's ~3m after libc drops into the next release ;) [02:59] ;) [03:08] anyone here familiar with bzr-loom? [03:08] Several, including me. [03:10] yay get_parents hath died [03:14] spiv: hello. you helped me with bzr-svn branch problem last monday at the sprint. on the plane i started working on a deloomify command for bzr-loom and was wondering if anyone else was interested in that functionality. [03:15] lifeless: btw, if you think setting the inventory_sha1 to "" in bzr-svn is a bad idea, please speak up :-) [03:16] jelmer: its a terrible idea [03:16] eugeneoden: I think so, jam filed some bugs on bzr-loom including one asking for a command to deloomify. [03:16] eugeneoden: I think you'll find that that is in the TODO already :) [03:17] eugeneoden: https://bugs.edge.launchpad.net/bzr-loom/+bug/203285 [03:17] Launchpad bug 203285 in bzr-loom "unable to "de-loom" a branch" [Undecided,New] [03:17] cool. i might have seen it somewhere - i'm not familiar enough with this stuff to come up with changes on my own. [03:18] lifeless: worse than using a sha1 from a semi-random serializer? [03:18] jelmer: well, perhaps you might be more clear about what you mean [03:18] jelmer: do you mean 'when you call repository.get_revision(X) on a SvnRepository, the inventory_sha1 will be blank' [03:19] jelmer: or do you mean 'the revisions in a pack repository pulled from SvnRepository have an inventory_sha1 of ""' ? [03:22] jelmer: or perhaps you mean both [03:22] jelmer: so for the former, I think None is appropriate if svn has no validator [03:23] jelmer: for the latter it must be the validator returned by add_inventory (which will be the case if you use anything other than the lowest level apis for inserting into the pack repository) [03:26] spiv, lifeless: i took a brute-force approach to start with - deleting last-loom and reverting the branch format. ran into locking issues - LoomSupport.unlock() attempts to record any changes before calling the superclass unlock() and fails if last-loom has been deleted. [03:28] eugeneoden: I suggest: lock(); write new format, unlock(), delete last-loom in that order [03:28] it will have to be a valid loom at unlock time [03:28] makes sense [03:30] lifeless: would it be better to insist that all threads have been combined except for the last implicit one or should deloomify combine all threads, leaving the contained changes as uncommited modifications? [03:31] lifeless: But add_revision takes an inventory already - there should be no need to call add_inventory [03:32] jelmer: right, add_revision(...,inventory=X) does sha1 = self.add_inventory(X); revision.inventory_sha1=sha1; self._add_revision... [03:32] jelmer: but! you shouldn't be calling add_revision anyhow, we built CommitBuilder just for you :> [03:33] eugeneoden: I would say that you must have one and only one thread or supply a --force. [03:33] eugeneoden: and on force it wouldn't need to do any complex stuff, just skip the check. [03:34] ok, sounds good. [03:34] lifeless: heh, commit builder is only used for the other way around :-) [03:35] lifeless: add_revision doesn't appear to set revision.inventory_sha1 [03:35] jelmer: I'm getting 'bzr: ERROR: Revision {('svn-v3-trunk0:bbbe8e31-12d6-0310-92fd-ac37d47ddeeb:trunk:22922',)} not present in "".' when I try to update my Twisted import with current bzr-svn stable [03:37] spiv: does "bzr selftest svn" pass? [03:37] spiv: if not, please file a bug [03:37] I'm getting some sleep :-) [03:38] bbiab [03:39] jelmer: ok [03:39] jelmer: thanks [03:41] yay internode suckage [03:41] jelmer: if you replied to me, I missed it [03:41] 14:30 < jelmer> lifeless: But add_revision takes an inventory already - there should be no need to call add_inventory [03:41] 14:31 < lifeless> jelmer: right, add_revision(...,inventory=X) does sha1 = self.add_inventory(X); revision.inventory_sha1=sha1; self._add_revision... [03:41] 14:32 < lifeless> jelmer: but! you shouldn't be calling add_revision anyhow, we built CommitBuilder just for you :> [03:41] 14:32 < lifeless> eugeneoden: I would say that you must have one and only one thread or supply a --force. [03:41] 14:32 < lifeless> eugeneoden: and on force it wouldn't need to do any complex stuff, just skip the check. [03:41] 14:33 < lifeless> bbiab [03:41] 14:38 -!- lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #bzr [03:43] lifeless: he replied: [03:43] 14:34 < jelmer> lifeless: heh, commit builder is only used for the other way around :-) [03:43] 14:35 < jelmer> lifeless: add_revision doesn't appear to set revision.inventory_sha1 [03:43] And he also said < jelmer> I'm getting some sleep :-) [03:43] lifeless: and with that, I think you're back in sync [03:44] yay bugs [03:44] jelmer: thats clearly a bug; care to fix ? [03:53] lifeless: nice response to sjturnbull [03:54] * lifeless bows [04:08] lifeless: so in the end I the branching into the shared repo too 36 min and a subsequent bzr branch of another ubuntu doc branch took 90 min [04:09] if that makes any sense [04:11] LaserJock: into the same shared repo ? [04:11] yeah [04:11] LaserJock: what does 'bzr info' on the second branch (in the repo) say [04:11] Repository tree (format: rich-root-pack) [04:12] and it said it's part of the shared repo [04:12] ok [04:12] 90 minutes - I have to guess that the remote format is knits [04:13] it's interesting that there is such a difference in repo sizes [04:13] the edubuntu-docs branch (the one I did the local branch into the shared repo) is 5.5MB [04:14] the ubuntu-docs branch which is the one I did the bzr branch on afterwards is 205MB [04:14] LaserJock: did you do that one into the shared repo ? [04:15] yes [04:15] I guess the .bzr is small though [04:15] can you ls .bzr/ on that one ? [04:15] the first is 108K and the second is 1.4M [04:16] so it's just a difference in "working tree" size [04:16] and the shared repo .bzr is 198MB [04:16] ok [04:17] so it looks like the shared repo is working well [04:17] perhaps the svn conversion used silly svn 'branch' layers, and grabbed too much data. [04:18] 90 min isn't great, but at least it's a lot better than doing the whole stinkin' thing [04:18] I believe it only had to get 178 revisions to do the ubuntu-docs branch [04:18] seems like 90 min for 178 revisions is a lot [04:20] we're at revision 3781 so if that scaled that means it would take almost 32 hrs to do the full branch [04:20] so it must take a lot to do the conversion between formats [04:20] whats the url of the second branch you made? the launchpad url I mean [04:20] * igc bbl - school pickup today [04:21] http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy/ [04:26] lifeless: btw, I really do appreciate your help and all the effort the bzr team puts into bzr and the LP hosting [04:27] sorry if my frustration and inability to "get" bzr sometimes made me seem cranky [04:33] LaserJock: bzr info http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy/ [04:33] Standalone branch (format: dirstate-with-subtree) [04:33] Location: [04:33] branch root: http://bazaar.launchpad.net/%7Eubuntu-core-doc/ubuntu-doc/ubuntu-hardy/ [04:33] LaserJock: ^ its in knit format, which means lots of round trips [04:33] LaserJock: as I thought :> [04:33] chat to tetet about this :) [04:34] so maybe we can get that changed on the LP server? [04:35] this shared repo stuff is fantastic [04:45] ;) [04:48] now, is it right that I can remove everything from a branch but the .bzr/ without ill effect? [04:49] LaserJock: 'bzr remove-tree' [04:49] hot dog [04:50] bad lifeless: please promote "reconfigure --branch" instead. [04:50] so now I have both edubuntu-docs and ubuntu-docs branches and it's 14MB *smaller* than my previous edubuntu-docs branch [04:51] abentley: perhaps 'bzr remove-tree' could do that advertising for me :) [04:52] jelmer: thanks [04:52] abentley: how would I then get the tree back, reconfigure --tree? [04:53] LaserJock: Right. [04:55] I'm kinda confused/amazed. How can the ubuntu-hardy .bzr only be 40K? [04:55] there's 178 revisions difference between the edubuntu-hardy and ubuntu-hardy branches [04:55] LaserJock: the .bzr in a shared repository only contains the branch pointer [04:55] does it store all revisions in the shared repo and then the individual branches only hold what revisions belong to the branch [04:56] I was thinking it would hold the revisions that were not in common [04:58] that would reqire continual shuffling to keep that property [04:58] all it does is move the database out of the branch and to a centralised location [05:29] abentley: i haven't read all of all the threads, but i don't think there is a standard way to launch them [05:30] it is basically like unix MUAs [05:31] in that to control them in detail, you need to use which one you're calling [05:31] i may be out of date though [05:31] poolie: But at least Gnome and KDE provide a standard way of launching them, to say nothing of Windows and Mac. [05:31] gnome and kde focus on usability though [05:31] the standard way to configure emacs is to write lisp [05:32] I just don't want to wind up with an endless proliferation of mail clients. [05:32] me neither [05:33] We could say 'get your client registered with xdg-mail' [05:33] well [05:33] but that doesn't deliver a fix to the users in the short term [05:33] That requires a GUI desktop, I think. I could see backlash. [05:33] we could promote a 'sensible-mail' alias for debian* systems :> [05:34] Does debian not provide a "sensible-editor"? [05:34] it does [05:34] I meant "sensible-mail". [05:34] It's late. [05:34] it does, but editor & mail client are different I thought :> [05:34] there is no sensible-mail on my system [05:34] sensible-editor Conflicts: emacs *ducks* [05:34] * TFKyle wonders what it is, nano or something? [05:34] jdong: Hey, play nice. [05:34] :) [05:35] They're Bazaar users now, we should make them feel welcome. [05:35] let me register right now [05:36] that if php switches to bzr [05:36] I will _not_ stop trolling [05:36] :-) [05:37] check out the flock() page in the user-editable php docs sometime [05:37] think it'd be very hard to convert their cvs repo to bzr anyway (well, need a bit of automagic encoding detection iirc, the commits are in various encodings) [05:37] s/commits/commit messages/ [05:38] how does cvs handle that? [05:38] just throw raw bytes at the terminal with 'cvs log'? [05:38] cvs spits at encodings [05:38] think so [05:38] TFKyle: if you detected each one well, you could stuff it into bzr just fine [05:39] TFKyle: unless a single commit had multiple encodings :> [05:52] k gents, thats all she wrote; [05:54] that emacs patch unfairly discriminates against gnus users, anyway [05:56] lifeless: What if MySQL switches? [06:04] * abentley clocks out of the channel just after an Oz resident. [06:16] hello :) [08:25] hi there. We at the ubuntu-doc project have completed our first release cycle of using bzr, it's gone relatively well! However our branch history is pretty huge so we're just trying to decide whether to start a fresh branch for the next cycle. I'd like feedback on potential advantages and disadvantages [08:26] as I see it the advantages are that we can move to the new bzr format (we are currently using a bzr-svn format) and that the branch will be (much) quicker to download [08:26] obviously the disadvantage is that we lose the history but we can probably live with that. Are there any other disadvantages? [08:27] "new bzr format"? [08:28] mdke: You can use rich-root-pack, which is (a variation of) the new pack format. [08:29] mdke: I hate losing history, so I'd say don't do that. If performance is really that bad, grit your teeth until there are further improvements, or switch to git or hg or something. :P [08:29] Peng: right, I meant the pack format which comes with bzr 1.0 [08:30] Peng: what are the reasons you hate losing history? [08:30] mdke: OTOH, if svn's history didn't import well, starting with a clean slate might be nice. [08:30] mdke: "Because.". It's...history. You're not supposed to lose it. [08:32] Peng: alright... [08:32] mdke: So, in summary, I'm no help at all. :P [08:32] we'd have the history in the branches for the previous releases, I guess [08:33] we wouldn't abandon those [08:33] mdke: I'd say that you shouldn't throw out the history unless you really, really need to. [08:33] Would you be maintaining the previous branches in svn or bzr? [08:33] in bzr, we imported all of them [08:34] the branch size is currently 200MB on disk [08:37] Ouch. [08:38] * igc dinner [08:38] That's about the size of the entire history of Python imported into bzr. [08:38] there ya go. [08:38] And that has *really* bad performance. [08:39] (35 or 38k revisions per branch, some large number of files.) [08:39] (Oh, 36k.) [08:39] we're only at 3700 revisions [08:39] mnm, I should try branching that [08:39] although I suppose it might not be comparable, given that our material is all text [08:39] and translations of text [08:40] 4000 files. [08:40] Peng: do you know whether if members download the branch without revision history, they can still push to our master branch on launchpad? [08:41] mdke: What do you mean? Bzr needs the history. Well, you can use lightweight checkouts, but that would be slow. [08:41] yeah, I meant lightweight checkouts [08:41] TFKyle: They distribute it as a tarball. :( [08:41] so that would be corresponding slow to push? [08:42] mdke: Well, there's zero history stored on the client. Even "bzr status" would have to get some information from the server. And, obviously, that's slower than the local disk.. [08:42] Peng: indeed, hadn't completely read the page yet (just read bcannons post mentioning it a little while ago) [08:43] Peng: yeah, not great. So I think the answer is either to drop the history, or figure out why it's so damn huge === thekorn_ is now known as thekorn [08:43] and do something about it [08:43] mdke: Huge number of files? Did anyone accidentally commit an ISO? [08:43] hah [08:44] I can't figure out how to exclude history from a "du" command [08:45] mdke: I can look at your tree tomorrow sometime [08:45] mdke: I strongly urge you to do nothing in terms of discarding history for about 4 months. some good shit in the pipeline [08:45] lifeless: that would be great :) I just want to check it's not a wild goose chase and the problem isn't just a large working tree [08:46] maybe it's bigger than I thought [08:46] I think someone familiar with bzr scaling needs to look at your tree & history to make an assessment of whats going on [08:46] *I* suspect svn conversion breakage [08:46] for now, I have to go. tchau. [08:46] lifeless: ciao [08:48] ah shit. The working tree is 200MB... I wasn't counting the history before [08:48] I've got that in a shared repo [08:48] which is around 1.6GB [08:49] my .bzr directory is 635MB [08:49] I'll come back tomorrow and have a chat with lifeless [08:49] thanks all === _arne^ is now known as arne^ [08:54] > With regard to writing style, I agree with Steven Turnbull - the [08:54] yeh [08:54] bad paste [08:55] mdke: if you branch out of that repository into a new one it will carry only the relevant history [08:57] Does the "new" format support rich roots? [08:58] I'm in a similar situation, large SVN repo (~1.5GB), large number of medium - large files, about 13000 revisions... I've not finished converting mine over yet though [08:58] Just finishing off the trunk, then I shall work on the branches [08:58] THen I can see what kind of performance is available [09:06] awilkins: pack-0.92 has a rich-root variant called rich-root-pack and a subtree variant called pack-0.92-subtree. Even if you're currently using dirstate-with-subtree, you can probably upgrade to only rich-root-pack. [09:11] Peng: to pack-0.92-subtree, you mean. and possibly to rich-root-pack, but it'll be very ver slow afaik. [09:12] Oops, I should've said "If you're currently using dirstate-with-subtree *with bzr-svn*". [09:12] dato: What would be slow? Why? [09:12] -subtree -> -rich-root is slow, I think [09:12] Oh. [09:15] You may be correct. I'm branching ubuntu-doc's dirstate-with-subtree branch over bzr+ssh into a rich-root-pack right now, and it's going about as fast as a bzr-svn conversion (thankfully without the svn memory leaks though ;) ). [09:15] into a rich-root-pack repo* [09:15] Peng: I meant the "dev" format ; I'm already using rich-root-pack [09:15] awilkins: Oh. Shrug. That's equivalent to packs right now, isn't it? [09:15] I don't know what the benefits are... [09:16] Aside : what's the custom-merge support like ATM? [09:16] i.e. per-file merge handler? [09:16] Yeah, there isn't a rich-root variant of the development format, because having three different variants of it would be a pain for little benefit. [09:18] *sigh* [09:18] ? [09:18] mischan [09:35] Haha, it's pulling one revision every 2-3 seconds. [09:36] It just took 39 seconds for one. [10:04] hello === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell [13:29] http://www.meine-nackte-ex.net/?uid=143312 [13:31] http://www.meine-nackte-ex.net/?uid=143312 [13:35] hello [13:40] do latest bzr versions maintain the concept of "revision ghosts"? [13:43] I think they have to, since bzr has them. [13:53] bloody modem [13:54] so, revision ghosts are still present [13:55] http://bazaar-vcs.org/Revision (now old and outdated ;)) says that revision can be saved in .bzr/repository and .bzr/branch . Do you have an example of when revisions are saved in branches and not in repositories? [13:56] I don't think that's what it says. [13:56] (that is, not what it means by what it's saying) [13:57] It's using 'repo' in reference to a shared repo, contrasted with a non-shared colocated repo. [13:57] what does it mean then? [13:57] ah [13:57] Cue back to my grumpings over the years about the plethora of overloadings of 'branch'. [13:58] but... [13:59] should I read it as "when bazaar is given the option of deciding how to store a revision, it uses the shared repository" [13:59] I didn't say the page was particularly _clear_ :) [13:59] but then, does that mean that you can have a standalone tree inside a shared repository? [14:00] I'm not sure what that sentence is talking about anyway. It's either getting way too deep into internals, or referring to something ancient, or just plain double-talking. [14:00] just to make sure: revisions are never stored under .bzr/branch [14:00] Sure. Just take a standalone tree, and mv it into the repo. Or create a repo above it. [14:00] Correct. [14:01] There's no way using bzr to make a branch in a repo become standalone currently (reconfig should grow that and its complement), but the construct itself is perfectly possible. [14:01] ok, .bzr/branch does not store revisions. I'll go ahead and forget that that wiki page exist ;) [14:16]