[00:14] spiv: so, I'm nearly human again [00:15] spiv: want to pop over? [00:16] lifeless: to Epping? Sure. [00:16] cool [00:16] I'll finish humanising myself and head over. I'll let you know my eta. [00:16] kk === kiko-fud is now known as kiko-zzz [00:33] Odd_Bloke: if you're looking at bzr send [00:33] Odd_Bloke: apparently we should us xdg-email [00:33] *use* [00:36] lifeless: My next few cycles are going to be spent looking at shelf. [00:36] s/shelf/shelves/ [00:36] yeh if only i initialized the String :x [00:36] that wouldn't have made it less wrong [00:37] r0bby: Wrong channel? :) [00:37] What's brisbane-core? I keep seeing references to it, but missed the kicking off point. [00:41] Odd_Bloke: next gen format [00:42] is there any schema on how the database of the in bzr works? [00:42] (and if there are ways to extend it) [00:42] ronny: you can't really extend the core (though you can use it to do different things for you) [00:43] ronny: in terms of docs, there are the Classes stuff on the wiki, and docstrings in the code - pydoctor gives quite good results on that I believe [00:44] hmm, any listing ? i missed the stuff in the wiki [00:47] http://bazaar-vcs.org/Classes [00:56] lifeless: eta 1220 [00:57] roger wilco [00:58] lifeless: at what part of the src should i look? [01:00] ronny: well, what are you interested in? If you're interested in the 'db' implementation, btree_index, knit.py (the pack mapped index and access objets), and repofmt/pack_repo.py's RepositoryPackCollection class) [01:01] lifeless: mainly the db stuff [01:01] if you're more interested in the model, I don't think there is a single good reference [01:01] the model is important for me, too [01:01] just researching the different stuff [01:01] I'd cast an eye over doc/developers/ [01:02] so far git's model seems the most reasonable [01:02] just the rest of git isnt [01:03] :P [01:05] any reason why bzr did choose uuid's over content hashes other than the rehashing (aka switch hash algo) issue? [01:12] * ronny waves for attention [01:13] well, bzr-svn includes more information in the uuid [01:13] * RAOF is by no means a bzr hacker, but IIRC it allows better tracking of file moves. [01:14] RAOF: nope, not at all [01:14] mwhudson: like what? [01:15] ronny: uuid of the repository + revno of the import [01:15] ok, also nothing that would reqire a uuid [01:17] i think it's more a matter of style of approach than requirement [01:17] but way way before my time [01:18] RAOF: git's bad move tracking is derived in the fact that trees dont have parents, thus the parent/child relation is only in commits [01:26] so any comments? [01:31] ronny: I'm not sure the IRC channel is the most appropriate place to look for this kind of discussion. The mailing list might be better... [01:32] hmk [01:33] i mostly just want to know the reason tho, not discuss it over again [01:33] ronny: I still think a post to the ML is most likely to get a useful response. [01:34] Anyway, I intended to go to bed half an hour ago. [01:34] So, good night #bzr. [01:34] ronny: we chose uuids for revisions for a couple of reasons; not wanting to redo everything when sha1 is broken, and supporting imports from arbitrary systems is the other (and its been very susccessfuly) [01:34] ronny: for file ids, we use uuids as a memo, but equally could use just history pointers [01:36] hmm, why does import from others require uuid's? [01:41] ronny: transitive history is not always available [01:43] i dont see how that makes uuid's an requirement [01:44] i need to sleep [01:44] oh that's right, ghosts [01:45] i always forget that one... [01:49] not just that [01:50] having to calculate the contents in the native format for all contents in the ancestry of a revision is expensive [01:52] never mind, just read up on what transitive means :-) [01:57] ronny's design questions remind's me that poolie's design notes used to be available somewhere [02:00] like old.bazaar-vcs.org or bazaar-vcs.org/old (I've checked there) [02:01] mlh: http://doc.bazaar-vcs.org/obsolete-docs/ ? [02:02] thanks spiv [02:02] that's an excellent historical document. I remember meaning to give that link to ESR when he was going to (threatening to ? :-) write a history of (D)VCSs [02:20] * igc lunch [02:21] jml: we need to spend a few hours on 'how to represent skip etc for .unittest [02:21] ' [02:22] lifeless: yes. [02:22] lifeless: in fact, a mini-sprint on pyunit-friends stuff would probably be a Good Thing [02:22] lifeless: let's go to Perth and visit jamesh :) [02:33] jml: :P [02:34] lifeless: that reminds me. I uploaded a testresources branch implementing the make/reset/clean API I suggested. [02:34] yes, its in my aroundtuit pile :( [02:35] you said my original description was a bit hard to understand, so maybe some code will make it clearer :) [02:35] thank you [02:39] and I don't know whether you'd want to come to Perth at this time of year. It may be a bit dryer, but it is also a lot hotter [02:47] jamesh: yeesh, don't need more heat [02:47] jml: I was thinking dinner, wine, laptops [03:19] lifeless: sounds delightful === mthaddon_ is now known as mthaddon [03:58] Can I version a single file only? For example I want to keep my .emacs file in sync across a few computers, is there a simple way to do this? [03:59] lamalex: bzr init ~/my-emacs [03:59] mv ~/.emacs ~/my-emacs [03:59] lifeless: so "no" [03:59] ln -s ... [03:59] lamalex: yeah, sorry [03:59] no problem [03:59] it's not the point of bzr [04:00] that will probably be cleaner anyway, I'll just make a dir of my misc files, then link to them [04:00] sure, cd ~/ ; bzr init ; bzr add .emacs ; bzr ignore ".*" ; bzr ignore "*" ; bzr commit [04:39] can someone help me set up a shared repo? I can't get it to not do working trees in the repo [04:39] bzr init-repo --no-trees [04:39] you can alias init-repo to 'init-repo --no-trees' if you like [04:42] :P as soon as I asked i got it [04:42] thanks [04:53] vila: your --load-list is quite nice, thank you [04:53] * jml <3 branch-todo [04:54] jml: ? [04:54] lifeless: I'll explain later :) [04:56] jml: I have a feedback loop going with tests [04:57] jml: bzr selftest --load-list=foo.list, where foo.list is from selftest --subunit | subunit-filter | tail -n +2 > foo.list [04:57] jml: 'run only failing tests' [04:58] lifeless: *nod* that'd be very handy to have for lp [04:59] I'll do some more on it this evening I hope [04:59] would likst to get foo.list by $() rather than a file on disk, or something like that [05:09] jml: so, see my most recent post to bazaar@, it has the glue needed for a pyunitish runner [05:10] lifeless: cool [06:37] moin [06:38] * ronny still fails to see how transitive history needs uuid's [06:53] mlh: thanks [06:59] jml: what are you doing tomorrow evening? [07:03] hi all [07:03] lifeless: glad you like it :-) [07:41] hiya [07:42] pushing a branch to LP with bzr 1.11-1 I get "Permission denied (publickey)" although my pub key is exactly the same as the one I have on LP [07:42] is there any known issue? [07:44] dholbach: sure you're connecting as the right username? [07:45] mthaddon: I don't think I changed anything [07:45] email = Daniel Holbach [07:45] launchpad_username = dholbach [07:45] dholbach: ok, just checking - not sure if it's a known issue, haven't used bzr 1.11-1 myself [07:46] it's in jaunty now [07:46] brave soul - still on intrepid here [07:47] where do I use "-Dhpss"? [07:47] it tells me to use it [07:48] argh, now it worked [07:48] ok... whatever [07:48] I'll let you know when I run into it again [07:49] I won't be much use - not an expert in any way, just happened to be idling here... [07:49] but I'm sure someone else will [07:52] lifeless: travelling to Hobart [07:58] poolie: ping [09:16] lifeless: you'll be happy to know I have a working right arrow key again. [09:21] spiv: cool [09:21] spiv: you hit it harder? [09:21] jml: well then, upon your return [09:21] Obviously, it started acting right :p [09:25] lifeless: if by "hit" you mean "took the cap off and removed a pile of impacted crud", then I guess so... [09:26] It doesn't quite like new, but it basically works... [09:27] hello spiv, lifeless [09:29] lifeless: thanks for the post this morning about gc [09:30] I've managed to not have to do a significant keyboard cleaning on this one yet. Next month is its 18th birthday, too. [09:30] kiko, i'm writing up http://bazaar-vcs.org/Roadmap/BrisbaneCore [09:30] * fullermd should throw a party. [09:30] wow [09:31] fullermd: it must even predate PS/2 connectors? [09:31] Wikipedia says PS/2 was 1987. [09:32] But the cable is detachable, so it could have come with an AT connector originally I guess. === kiko-zzz is now known as kiko [09:34] kiko ^^ [09:34] I don't know a lot about PS/2 but brisbane sounds like just the place for summer [09:37] * fullermd recalls laughing his head off at http://ars.userfriendly.org/cartoons/?id=20010211 [09:57] mbp__, can you tablify that? tables beat lists [09:57] well maybe.. hmm [09:57] for the tasks? [09:57] working on it [09:57] maybe [09:57] at least a table is better if we have estimates [09:58] indeed, indeed [09:58] at the moment i'm adding more descripiton of the changes and digging up some numbers [09:59] yay numbers [09:59] the infallible indicator of objective truth :) [10:04] Except 8. I don't trust him. Shifty eyes and all that. [10:05] and 13 [10:05] unlucky n' such [10:05] Yeah, but it's reliably unlucky. So it's infallible in a way :p [10:07] Yegods, this "Python DVCS comparison" thread is long [10:08] I think the attitude that "We want all the benefits of a DVCS without changing how we work" attitude is rather blinkered though [10:09] If only that were the most blinkering I ran across in a day... [10:09] But it's worse than that - many people have already fought the learning curve to learn git, and now we seem both cumbersome and slow as a result. [10:10] awilkins: I dunno, we claim to be flexible, but are we actually? [10:10] (I think so, but maybe we could be more flexible) [10:11] Considering that the complaints all seem to boil down to "TOO flexible", how would that help? :p [10:11] that's a silly thing to complain about though [10:11] if you don't want to use the flexibility, don't [10:11] It's a silly world. [10:11] I suspect a global [per user, anyway] revision cache would help enormously. [10:11] bit late now, though [10:11] it's not foisted on you [10:11] I don't see it, personally. [10:12] To be much use, it would have to be several times the size of a "large" project. Otherwise anything you want would be cycled out by the time you'd profit from it. [10:12] And that's *BIG*. [10:13] fullermd: (if you're talking to me) no, I'm not talking about in-memory, I'm talking about never ever forcing someone to network transfer the same revision twice in from a remote location. I imagine `bzr init-repo ~` would do it. [10:13] Of course, the solution to the direct problem is "If you want to work just like svn, just use co --lightweight". Then we can move on to "zomfg that's slow" and make forward progress on letting them keep marching toward the cliff. [10:14] I don't mean in-memory, I mean wherever; it would have to be a couple gig at least to get a high enough hit rate to be worth it. I don't have a could gig to spare. [10:14] fullermd: but since that isn't what the Bazaar hackers expect you to do, it's not a good idea to suggest. [10:15] And "Use bzr, it'll keep anything you ever pass to it around forever cluttering your hard drive" isn't the best advertising either :p [10:15] fullermd: assume for a minute you don't know about a) shared repos and b) creating local mirrrors of remote branches. Then do bzr log on a large remote branch a few times and you'll start appreciating how awful Bazaar appears to people. [10:16] That is, in essence, the critique that the Python crew have levelled, and it has as a result disqualified us. [10:16] Did I say something that gave the impression that I fail to appreciate how awful performance is in many cases? [10:16] AfC: 'bzr init-repo ~' has a couple of problems. Firstly, it's not a cache (you can't delete ~/.bzr safely), and secondly, as noted on the mailing list, it assumes people work underneath a single directory. [10:17] Odd_Bloke: sure. Admittedly, though, most people work under ~ :) [10:17] * fullermd branches into /tmp with some regularity. [10:17] AfC: Windows users don't. [10:17] fullermd: I don't really think any of us in this channel qualify as normal users in so far as Bazaar (or any DVCS) is concerned [10:18] Odd_Bloke: that's fine. They can `bzr init-repo c:`. Suckers. [10:18] ENOSYMPATHY [10:18] :) [10:18] Anyway, the solution to logging large remote is to use a dumb server. [10:18] log --limit 10 bzr.dev. sftp: 7 seconds. bzr+ssh: 40 seconds. [10:19] Doesn't help when they branch into d: now does it? :p [10:19] fullermd: it doesn't matter that there is a "solution". The problem is that out of the box the way that most people try to use Bazaar turns out not to be wise. So then we tell them how they should use the tool (thus voiding most of the supposed flexibility) and then they bitch at us for being so presumptuous. [10:19] Er. I was being ironic... [10:20] * AfC has, in essence, given up advocating Bazaar. I'm tired of shouting at the rain. It's too bad we picked bzr because we really appear to be zealots out in left field for using it. [10:20] You seem to keep getting this impression that I'm defending the status quo and mocking the poor silly users who just don't Get why it's so vital to use the DUMB SERVER to get good performance... [10:20] Such a shame, because I'm very happy with it. [10:21] fullermd: I would advise against sarcasm in discussions like this. Most people won't get it. [10:21] fullermd: especially when we're exploring the question of whether it's too late for this project. [10:22] But back to the thread in question, the activity of hg would be exactly the same; a fresh clone would still pull everything across the network. The activity of git would be example the same; a fresh clone would still pull everything across the network. [10:22] fullermd: right, but in the Git case, the *second* transaction would NOT pull everything - or anything - across the network. [10:22] The difference is only when you pull another branch into an existing repo. That brings us back to metabranches. [10:22] fullermd: since we support NOT forcing a full mirror since we support anonymous remote operations, we look bad for doing 100s of MB of transfer just to do a log only to force another 100 MB of transfer to run the same command again. [10:23] Like I said, too late now. [10:24] Again, what are you trying to convince me of? Have you EVER seen me advocate to ANYBODY to do `log URL`? [10:24] fullermd: I'm not talking about YOU. Relax. I'm talking about the tool that you and I both have stuck our necks out for. The tool permits that behaviour, and so people think that's what they're supposed to do, and so they do, and then the tool looks horrible. [10:25] * fullermd shrugs. [10:25] I've lost much ability to care about those people. The train has long since pulled out of the station, and it doesn't matter anymore. [10:26] fullermd: you're lucky, then. I work in a community where virtually every other project has adopted Git, or will. So I'm odd man out, and suffering for it. [10:26] it sucks. [10:26] Projects will use bzr because political forces dictate (like emacs) or somebody with enough clout likes bzr and decides to impose it (like I did). Anybody else will look at it and say "slower than other choices", and game over. [10:26] yup [10:26] I use Bazaar because I had a project that needed really good merge support, it's being used by neophytes, on Windows ; hg can't handle the tree because it's too deep for it on Windows, git is too scary [10:27] The performance leaps of bzr between 0.9 and 1.6 on win32 were really gratifying [10:27] On the day when bzr reaches performance parity, it still won't gain much, because then it'll be "the program that's no longer as slow as it used to be" [10:27] fullermd: shit, I've been trying that line for over a year now. [10:27] It started off just "ooh, much faster than SVN" and became "wow, that's nice and fast" [10:27] fullermd: and indeed, it didn't help [10:27] Whatever. It's nice and fast for me. That's good enough. [10:28] But as you said, game over. [10:28] You then use it on Linux and go "Holy crap, WTF is windows DOING under the bonnet?" [10:29] The fact that it's written in a langauge I grokked easily enough to pick up was a real plus ; several windows bugs have been fixed that way [10:29] Obviously, the real trick is to slow everybody else down. [10:29] Look how well that strategy has worked for web browsers. [10:29] I'd like to see a 4-way DVCS/SVN benchmark on Windows [10:29] Remember when you refused to move to Netscape 4, because it was a stupidly slow unbelievably bloated pile of crap? [10:29] I'm not sure git would be such a clear winner on Win32 [10:30] * fullermd laughs in his past self's face. [10:30] The flaming death for bzr is network. The platform won't affect network that much. [10:31] I'm left with the assumption that, for whatever reason, bzr didn't grab enough mindshare early on, and the manpower deficiency has left it permanently in the hole. [10:32] I think bzr can still prevail within the "enterprise". [10:33] It is, after all, easy to use, and seeing how much effort is required to get people to switch from CVS to SVN, getting them to switch to git is going to be *ugh*. [10:33] Remember not all paid developers are uber-elite geeks :-) [10:33] Linux format had a "bluffers guide to git" this month [10:33] (And not every VCS user is a developer, either) [10:33] Paid developers do whatever the paymaster says. [10:33] hmm [10:33] Heck, we just covered "bzr is way more flexible than everything else". Flexible is kinda the opposite of what enterprise aims for ;p [10:34] i came to the conclusion that all dvcs's suck [10:34] What DVCS really needs for use in the enterprise is gui tools with a good visual metaphor for the distributed-ness [10:34] fullermd: I think Lo-lan-do's point is that it'll be easier to convince the paymaster than the paid developers. [10:34] awilkins: i will probably do such a gui tool that manages git/hg/bzr [10:35] My point was that it took me *years* to get people to use CVS at a previous job, and I left before managing to get them to switch to SVN even though the syntax/UI is identical. [10:35] I dunno if that's true. Really, the business case is pretty much like the open source case. [10:35] You'll never convince the bulk of the project to move to foo. [10:35] I always do think that Tortoise[DVCS] should just be one codebase with backend plugins [10:35] Some group of sufficiently interested and clouted parties will make the decision, and drag everybody else along. [10:35] awilkins: im working on such a thing ^^ [10:36] the catch is i dont yet have history/sync support implemented ^^ [10:36] bzr's advantages in flexibility and workflow just aren't obvious unless you (a) think carefully about it, or (b)(1) use it for a while without (2) trying to make it act like $OTHER_VCS. [10:36] Performance, however, is trivially easy to test and very easy to natter on about to convince people. [10:36] and the comclusion is - all dvcs's suck and are awfull (just less bad than the centralized ones) [10:37] -m+n [10:38] So really, there are 3 types of people who end up with bzr. [10:38] (1) the people who are already there [10:38] (2) the people who are drug there by someone with enough persuasive power [10:38] fullermd: re your original "flexibility and workflow just aren't obvious unless you (a) think carefully about it, or (b)(1) use it for a while without (2) trying to make it act like $OTHER_VCS", hear, hear [10:38] (3) the people who like VCS's in particular or tools in general enough to spend a lot of time playing and fiddling with the options, and have usecases where the performance is "good enough". [10:39] fullermd: i just recently moved some bzr managed projects i inherited to hg cause bzr wont let me do my workflow [10:39] Me, I'm used to using totally superior solutions that most people bypass for mostly ill-thought-out reasons. I run FreeBSD. [10:40] Is FreeBSD still totally superior? [10:40] (Genuine question -- it's been years since I last tried it) [10:41] Of course. That penguin doesn't stand a chance against something with horns and a trident. [10:41] it certainly has less stupid [10:41] ronny: What's your workflow? [10:41] I think so, obviously. It's just so much easier to manage long-term. [10:41] Odd_Bloke: inherited from using monotone, i want multiple heads in one place, and i dont particulary have to care if they get names [10:42] (now, if we could harness the elastic force of yanking that far off-topic...) [10:42] fullermd: bsd seems to be generaly free of micro-otimizing bullshit (compilers evolve for a reason) [10:42] bbl, gona eat [10:52] ronny: bzr can do that [10:58] Ono, not this discussion again... === kiko is now known as kiko-afk [11:09] are nested branches working yet ? [11:18] bbl, gona eat [11:19] bob2: until collated branches it can do it [11:20] eh cant [11:26] ronny: the ui is a bit dodge, but you can do it [11:26] ronny: push to a repository and the tips will just hang around forever. use 'bzr heads' to see the current ones. [11:27] * fullermd blinks. [11:27] Using explicit branches is too obnoxious for him, so you suggest grubbing around under the hood instead? :p [11:28] haha [11:28] bob2: fuck unnatural hacky in particular unplanned workflows - either it works good or it's useless [11:28] "I'd like a sandwich, but until bzr's bread comes presliced, it's too much trouble." "Well, bzr lets you grind wheat..." [11:29] ronny: ok! [11:33] anyway, on the conceptual level i dislike all common dvcs's [11:34] ronny: How would you do it differently? [11:36] Whoa, python just ate 101% of CPU time doing a bzr-fast-export [11:36] Odd_Bloke: collated branches for bzr will mostly solve it [11:36] Is that a known bug in `top` ? [11:36] awilkins: How many CPUs do you have? [11:36] This is a 1 CPU boxy (with HT) [11:37] That might do it. [11:37] I don't really know. [11:38] Odd_Bloke: oh, you mean how i would do dvcs different? [11:38] Rounding errors like that are hardly unknown in top :p [11:38] ronny: Yeah. [11:38] (rather, in stats reporting like that in general) [11:39] Race conditions and observer skew and yada yada yada. [11:41] this has me curious too [11:41] Odd_Bloke: gits model is nice, but it needs more metadata [11:41] and of course no git around it ;P [11:41] I bet you could write a bzr plugin to do it [11:42] no [11:42] bzw wont get content addressing [11:42] More like a git porcelain that looks like bzr [11:42] I dunno, people rate about gitk but I just fast-exported my big branch here and it looks a right mess in gtik [11:43] Maybe I'm not giving it enough hints [11:43] duno, git only tracks snapshoots of trees [11:44] makes it very messy for tracking history [12:05] Damn.... git _is_ fast [12:06] Just did git reset --hard on my fresh imported repo with no tree - p'chow! [12:16] any of the devvies around ? [12:19] Mez: Don't ask to ask, etc. :) [12:19] Odd_Bloke: I asked earlier :D noone responded :D [12:21] In re: nested branches? [12:21] I think the short answer is 'no'. [12:22] :( [12:22] long answer? [12:22] Real Soon Now. :) [12:24] * Mez headwalls [12:27] I believe LarstiQ is working on it. [12:27] Mez, there are very strong rumors that someone will be working on it full time-ish soon [12:27] so maybe we'll get that in a few months === asabil_ is now known as asabil === bac` is now known as bac === kiko-afk is now known as kiko [14:40] vila: ping [14:41] mrevell: pong [14:56] Odd_Bloke, beuno: http://bazaar-vcs.org/NestedTreeProgress should be the focal point of nt progress [14:58] Mez: ^ [14:59] LarstiQ: Thanks. :) [14:59] now, I'm down to a couple of conflicts in merge.py and transform.py, so updating that page is next [15:00] we're going to visit my girlfriend's brother now, so ciao :) [15:04] LarstiQ: Have fun. :) [15:10] * vila doesn't quite follow how the nested boyfriend comes into play... === kiko is now known as kiko-afk === thekorn_ is now known as thekorn [16:46] morning vila [16:47] hi jam, stop loonking above my shoulder I am *already* reviewing your patch ! [16:47] :), I was just saying good morning [16:47] :) [16:48] healthy paranoia [16:48] well.. paranoia, we can discuss the "healthy" part [16:49] 8) [16:49] On my right screen I was looking into bbc tests, I think the first failing ones are for you, but obviously your plate is already pretty full today [16:49] I say for you because they seem to be related to some '\n' splitting [16:49] ./bzr selftest -s bzrlib.tests.per_repository_chk.test_supported.TestCHKSupport.test_pack_preserves_chk_bytes_store [16:49] should include them all [16:50] -s rocks :-) [16:51] guys I want your advices on organizing my project repository [16:51] I'm writing a server/client gaming suite (for poker atm) [16:52] So I have the client + the server + the project website [16:52] Is it a problem to just have it all in the same tree :-) [16:52] Atm I've two branches: One branch mainline which contains two directotries (client and server) [16:52] and another one for the website [16:52] Why separate client/server branches? [16:52] someone think i can do better ? [16:52] awilkins they're not seperated [16:53] Ah, sorry, [16:53] Misread [16:53] Goundy, is the client open source? [16:53] it's the same branche and it contains the sources in different dirs :) [16:53] (is the server?) [16:53] beuno all's open source :) [16:53] I'm hosted on launchpad :) [16:53] Goundy, then I'd think the separation is good [16:53] Heh, 'in before'. [16:53] client + server on one side, and webpage on the other [16:53] Goundy: Sounds good to me. [16:53] beuno well I thought the same thing also but guess what a serie can only have one branche :/ [16:53] beuno client and server in the same branch ? [16:53] Goundy: It does depend how closely linked they all are. [16:54] That's what you're saying ? [16:54] Goundy, a LP series you mean? [16:54] beuno yes [16:54] If the website is going to heavily depend on code from the other branch, maybe you want it in the same branch... [16:54] Odd_Bloke well the link is the networking heh client <> server :è) [16:54] well the website is totaly in xhtml atm [16:54] the server is in C and the client in Java :è) [16:55] The server and the client aren't linked at a source level [16:55] and the website isn't linked to these sources. [16:55] ( https://code.launchpad.net/~auresdev ) [16:55] Here's my current organization [16:59] So you think I'm good keeping it that way guys ? === kiko-afk is now known as kiko === bac is now known as bac_lunch === bac_lunch is now known as bac === thekorn_ is now known as thekorn === KangOl_ is now known as KangOl [19:23] vila: yeah, that failing test is because we changed the serialization format, and didn't change it there [19:23] it isn't really about '\n', just about having another line of data [19:28] vila: fixed in brisbane-core [19:30] hey [19:31] i have a merge a repository and it want me to run bzr update but i do not want to run the merge i want to simply remove it cause it screws up my files [19:31] and when i try to run a push from another repository i says that nothing has changed [19:33] hello? [19:39] regarding nesting, isn't there some support for nesting in bazaar? [19:40] i'm trying to model several users with a copy of their own data, centralized into on place for reporting, by pulling from the user branches.... [19:55] fullermd: what do you mean by: "(b)(1) use it for a while without" [19:58] fullermd: you talk about: "flexibility and workflow just aren't obvious unless you..." [20:27] Mez: its not finished, and I don't know anyone currently developing it === kiko is now known as kiko-afk [20:59] lifeless: apparently LarstiQ is... [20:59] though, by-value should suffice for my needs [21:11] Mez: 'actively' :P [21:11] jam: ping, test_sprout_uses_bzrdir_branch_format [21:12] lifeless: pong [21:13] vila: "is used as an id by several tests" -> does this load them all, or fail to laod ? [21:13] jam: hi, I replied to the mail [21:14] jam: like to get this bedded down today so I can put the branch (which contains a lot more fixes :P) up [21:14] if somebody could have a quick look at my InterBranch patch, that would help me a lot [21:14] so what are you trying to change that would cause this test to break? [21:15] I can sort-of agree that RemoteBranchFormat doesn't contain a lot of info [21:15]