[00:01] hi poolie [00:04] Hey, how come there's a VCS flamewar going on on Slashdot and no-one mentioned Bazaar so far ? http://bsd.slashdot.org/article.pl?sid=08/06/04/1749233 [00:06] because we actually do stuff? [00:07] :-P [00:09] Heh. Begins switch to subversion. [00:10] It is a step up from CVS, I suppose (although someone points out all the core devs use Perforce [00:10] its worse than cvs in many ways [00:10] its user model particularly [00:10] however, it scales better than cvs [00:11] But it's easier to work with svn than cvs in a dvcs, I believe. So it's a step up in that respect :) [00:11] RAOF: not at all [00:11] cvs these days has atomic changesets believe it or not [00:12] lifeless: So my lack of exposure to bzr-cvs is due to my lack of exposure to cvs? [00:12] no, its due to old cvs data still being a pillock ;) [00:12] Right :) [00:12] bzr cvsps-import does exist and do a decent enough job though [00:13] (my point being that you could just cleanup the tree and go from there) [00:13] oh, also don't forget cvsup - distributed cvs ;) [00:13] poolie: call over ? [00:14] lifeless: not quite yet [00:14] bbiab === mw is now known as mw|out [00:54] -> doctors, back, well, later [01:29] I would like to create a bzr trunk on a private server to backup my home folder. Can anyone point me to some docs on how I might do that? [01:32] Zelut: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#branching-a-project [01:33] I don't think bzr is a very good solution for backing up your whole home dir [01:34] bob2: well mainly what I'm looking for is archiving and tracking my .folders, and upon a fresh install just being able to branch my ~ and be done. === BasicTheProgram is now known as Basic [01:34] storing all your config files and documents etc works well, though [01:34] bob2: seems simpler to branch that and get my .ssh, .gnupg, etc than manual backup/restore each time. [01:36] I'd be weary of putting ssh and ngupg private keys in, but I do version all my dotfiles [01:36] bob2: kind of like /etc/skel I guess, but just requires branching. [01:36] er, wary [01:38] I've been using bzr with LP but I'm unsure how to create a trunk on my own machine is the main problem. [01:39] Zelut: bzr init path/to/branch [01:40] mwhudson: lets say I've got a folder locally that I want to push to a remote server and then be able to branch from remote in the future, what else do I need? [01:40] bzr init in the folder [01:41] bzr add to add the contents of the folder [01:41] bzr commit to record these files [01:41] bzr push to the server [01:41] that's it [01:41] I swear I had done that before but all I have on remote is .bzr with no contents. [01:42] that is indeed what push does [01:42] unless it is pushing to a local directory [01:42] you can a) leave it, since you can still branch from that remote one fine, b) manually 'bzr co' in the remote dir after each push or c) install the 'up-afte-rpush' plugin that does b automatically [01:43] so I could branch from remote and get those files, even though they are not listed there? [01:43] (https://launchpad.net/bzr-push-and-update) [01:43] yup [01:44] interesting. I figured I had done something wrong because I didn't see anything on remote. [01:45] well how 'bout that. bzr co and its all there. bzr is some magical voodoo :) [01:51] is there a preferred method of defining bzr whoami? .bashrc or..? [01:52] using bzr whoami [01:53] I mean, does 'bzr whoami joe hacker ' define it long-term or per-session? [01:53] it writes it to ~/.bazaar/bazaar.conf (so per-machine) [01:54] perfect. [01:59] spiv: if mhammond comes up here in the 16th do you think you'll be free? [02:02] poolie: yes [02:11] poolie: has there been a change in plans? [02:13] jml, he can't get a meeting room at the hotel that week [02:14] so we can either meet at my house or postpone it [02:14] ahh ok. [02:14] jml, were you wanting to come for most of that time [02:14] poolie: yeah, I was. [02:15] spiv, jml, how would the week of the 23rd be? [02:15] poolie: pretty god. [02:15] good. [02:15] * jml smiles [02:18] poolie: that's fine too [02:44] back [02:44] hi lifeless :) [02:46] hi [02:48] oh you're back already? time flies [02:49] got lucky, only 10 minute wait [02:54] that is lucky [02:55] in fact, if you had witnesses, I'd suggest sending an email to the Guinness Book of Records :) [03:12] for that doctor its amazing [03:12] usually 2-3 hours === thumper_laptop is now known as thumper [03:31] lifeless: yes, please do (continued from -ops) [03:31] O:) [03:31] terrible man [03:32] lifeless: although my personal motto is "non universim sed singulatem fretus," which has a far more lapidary tone. [03:33] Sempre utor ubi-bracae perhaps [03:41] also mneptok whats with the no-idling attitude? [03:51] lifeless: channel rules [03:52] lifeless: i have no idea what caused their creation, though. [03:54] lifeless: Any thoughts on whether it is kosher to mutilate the in-memory inventory of a DirStateRevisionTree? [03:55] I.e. to feed it to apply_inventory_delta? [03:56] mmm [03:56] so what we do is try to either modify the dirstate, or the inventory, but never both [03:56] the inventory is re-flattened on unlock() if it has been modified (as checked by a flag in WorkingTree4) [03:57] thats for the wt; uhm for a rev tree [03:57] the in memory inventory is cached [03:57] if you modify it, other callers asking for it will get the same modified inventory. This could be bad. [03:59] Half of igc's branch speed gain comes from using the existing InventoryEntry objects, rather than re-calculating the data from the TreeTransform and working tree. [04:00] Is there a way to do this safely? [04:00] this is new clone ? [04:01] or build tree? [04:01] This is build_tree. [04:01] where is the dirstate rev tree coming into the picture? (I would have thought we grabbed a repository inventory ...) [04:02] The dirstate rev tree is the basis tree of the branch we are branching from. [04:03] When that revision isn't available as a basis tree, we do use a repository-backed RevisionTree. [04:05] If the source branch has a working tree that we can use, we use it to retrieve files from disk instead of the repo, which I've benchmarked as faster. [04:06] ok [04:06] so what do we need from the inventory - do we have an iterator we can use without upcasting from dirstate to a full inventory in the first place ? [04:06] (making an inventory is slow in the first place) [04:07] I realise I'm not directly answering the question. To directly answer it - add a private method to detach the inventory from the dirstate rev tree, then you own it can do $whatever you want to. [04:07] We are using iter_entries_by_dir which I don't believe creates a new inventory. [04:08] But if the cost of generating an inventory is in constructing the objects, then it's just as expensive. [04:09] Which is an unavoidable cost. [04:09] Given the input requirements of apply_inventory_delta. [04:11] abentley, lifeless: the meta-question I had while profiling local branch creation was ... [04:11] the major cost when I looked deeply at inventories was simply creating xK objects and stitching them together [04:11] given a pristine local mirror, can you reuse the source dirstate to get the target one fast [04:12] both apply_inventory_delta and set_parent_trees suck when run on an OOo tree [04:12] igc: pristine shouldn't matter. [04:12] in principle you can copy the dirstate basis column to an output dirstate with a iterator and filter (to remove renamed/deleted/added rows) duplicating entries to create current-disk values [04:13] igc: apply_inventory_delta should be good because it generally has to deal in 10's of objects not 10's of K of objects [04:14] lifeless: on branch, the delta is the whole 100K entries [04:14] lifeless: apply_inventory_delta is used by build_tree when creating inventories from scratch. [04:15] yes, I can see that. to me this comes back to 'python is slow, whats the best way to work around it' [04:15] subprocess.cmd('cp -a') [04:15] some benchmarks might be good to check I actually drew the right conclusions (e.g. create a 100K inventory 50 times) [04:16] abentley: I mean of the python primitives we have available' [04:18] * igc lunch [04:19] I can tell you that when building emacs, WorkingTree4._get_inventory is 2% of total runtime, and apply_inventory_delta is 3%. [04:19] That's according to kcachegrind, of course. [04:19] righto, step 1 - gather stats :P [04:19] how big is emacs btw ? [04:20] 400M [04:20] Sorry, 105M [04:23] With my current patch, actually reading and writing the tree files dominates. [04:23] that's good [04:24] I was seeing 20-25% on the iter_changes over the accelerator tree [04:26] That's bad. I haven't changed anything that should have affected that. [04:29] abentley: there's a mozilla repo in http://people.ubuntu.com/~ianc/benchmarks/repos/bzr/ that I was profiling against fwiw [04:29] it's a good size without being crazy [04:38] igc: Thanks. I'm pulling that down. [04:38] I also worry that we might be optimizing for the wrong case. We tend to benchmark against hot cache. [04:39] But when branching, the branch source is likely to be cold cache. [04:43] I would expect branch source and repository to both be cold [04:43] abentley: you know you can drop caches right? [04:43] Yep. [04:59] abentley: I agree that cold cache is the more important time [05:00] igc: Which have you been testing? [05:00] hot cache is important though: it's what most people benchmark the tools on, and it highlights what we have most control over [05:01] io patterns aside [05:01] I've been using hot cache [05:12] What would cause our extensions to get compiled with -Wall? [05:17] CFLAGS=-Wall [05:18] Pieter: It's not set. [05:20] abentley: see /usr/include/pythonX.Y/config/Makefile [05:20] distutils gets some flags from there [05:20] jamesh: Thanks. [05:20] including -fno-strict-aliasing and other necessary ones [05:20] Turned out that wasn't the problem after all. [05:21] It was the lack of libc6-dev... [05:21] actually, that should have been /usr/lib/pythonX.Y/config/Makefile [05:44] Pieter: apologies for not getting to your fastimport/export questions/improvements - knee deep in the stacked branches reviews right now. Will do soon though. [05:54] spiv: ping [05:57] lifeless: pong [05:57] oh, ringing you :P [06:36] lifeless: oops, my cheek mashed the "hang up" button [06:37] lifeless, poolie: all the stacked branches reviews/tweaks sent to the ML now [06:41] ml: see test_branch_shallow_branch_also_shallow_same_reference() in the patch [06:41] jml^^ [06:42] igc: has this changed from lifeless's branch of two weeks ago, or is this a difference between API and UI? [06:44] mwhudson__, I know your day is about to finish, so these are the benchmarks against loggerhead trunk, your zpt branch, and my zpt branch, for the same 36k diff: trunk, real 1m38.033s, 400mb+ RES mem. Your zpt, real 0m35.243s, 220mb RES mem. My zpt, real 0m23.116s, 120mb RES mem. [06:45] so it's more like a 8x improvement to the current trunk [06:46] I can still shave a few seconds/mb off of it once I finish refactoring some un-needed operations, and it's missing tests. But it's looking good :) [06:47] jml: it doesn't look like the UI controls this so I'm guessing it done under the API - will dig [06:47] * gour just read latest from bzr ml [06:48] igc: the patch I sent you for clone() addressed just this behaviour. [06:48] having gnome on bzr, won't be bad... [06:48] igc: it's possible that I'm confusing things, given my relatively shallow (no pun intended) knowledge [06:48] jml: I can't apply your patch yet sorry - I think it needs abentley's policy stuff first? [06:49] igc: yeah, that makes sense. I was working against abentley's branch. [06:49] igc: I've sent it to him to apply. [06:50] gour: I wonder how they decide [06:50] igc: if he bounces me, then I'll redo it for bzr.dev once your patches have landed. [06:50] * beuno is off to bed [06:51] Pieter: me too, but it's better that bzr become ready if something can be done with 1.6 release taking into consideration their needs [06:52] see http://guadec.expectnation.com/guadec08/public/schedule/detail/81 [06:52] jml: That patch seems like it could do serious harm. [06:53] seems a bit odd to rush a feature so that some party may perhaps choose bazaar [06:54] abentley: can you please elaborate? [06:54] jml: If I branch, I expect to have everything I need. [06:55] Pieter: I'm not rushing the feature - I've been hacking towards all the bits coming together for months [06:55] If I push, the resources I have locally may not be available to all users. [06:55] Pieter: I'm trying to ensure its not stuck in trunk with 3 weeks to go at a point where it may be extremely relevant for discussion [06:57] lifeless: sure. if stacked branches go into 1.6 and everything can be polished a bit, i do not object waiting for 1.6 some week more [06:58] Pieter: also, to invert things slightly, it would be strange not to work on the things that our users seem to want most :P [06:59] abentley: are we talking about my patch or the UI2 patch? [06:59] otoh, having big(ger) party using bzr is very good for bzr 'cause new workflows and/or user-cases are explored leading to bzr improvement in general [06:59] jml: Your patch. [06:59] s/bzr impr./bzr's impr. [07:00] It causes stacking without user intervention, no? [07:00] abentley: it preserves stacking without the users intervention [07:00] Tomato, potato. [07:01] jml: preserving stacking is surprising, it doesn't fit our current behavioural model [07:02] abentley: ok. I don't pretend to have a deep understanding here but it seems like a good idea for 'BzrDir.clone' to clone [07:03] lifeless: given that I wrote the patch based on your guidelines I'm more than happy to withdraw support for it if you no longer think it's a good idea, conditional on me understanding why. [07:03] oh - clone() should clone() for sure [07:03] abentley: bzr branch uses sprout [07:03] lifeless: push uses clone. [07:04] abentley: yes; hmm [07:04] so the case that identified this was 'how does launchpads hosting service clone a shallow branch most appropriately' [07:04] (without rewriting clone()) [07:05] lifeless: paramaterize clone to preserve stacking? [07:06] lifeless: Alternatively, does push *need* to use clone? [07:07] well clone fits push much better than sprout IMO [07:07] actually, this is high up the merge stck [07:07] Neither of them is exact [07:07] I'm going to head-down and finish the current patch [07:07] then I will have many more cycles to think [07:07] lifeless: fairy nuff. [07:08] jml: I can adjust the patch so the behaviour is optional. Does that appeal? [07:09] abentley: it fits my use case, certainly [07:09] abentley: the deeper bzr model issues I can leave to the experts :) [07:09] done. [07:09] thanks. [07:22] jml: Your patch's stacked_on selection will be overridden if there is a configuration directive. Is that what you expected? [07:23] abentley: no, it isn't. [07:23] i.e. if the user has a .bzrdir/config with a default_stacked_on set, your patch has no effect. [07:24] Okay then, I think we can simplify the patch. [07:25] abentley: what jml wants is to be able to do - in the puller: [07:25] if (we dont have the branch) [07:25] local_branch = remote_branch.bzrdir.clone(options) [07:25] and thats about it [07:27] lifeless: Yeah, I have a fairly good idea of the use case. I just wasn't sure whether that was a deliberate choice. [07:27] abentley: :) [07:42] jml: Some examples of how BzrDir.clone doesn't clone: [07:42] 1. if the target has a shared repository, it always uses it [07:42] 2. if the source is in a shared repository and the target isn't, it creates a target as a standalone branch [07:42] 3. it doesn't create remote working trees [07:42] Perhaps clone is simply misnamed. [07:42] abentley: hmm. [07:43] abentley: the evidence is certainly mounting [07:47] jml: As another example, when you branch a subversion branch, bzr-svn doesn't create a Subversion repository. [07:48] It's really more like a mimeograph than a clone. [07:48] branch uses sprout though [07:48] so that other example isn't one ;) [07:49] lifeless: Sorry, "push from" [07:50] abentley: can you actually push from a svn branch though? I didn't think they existed on disk, only conceptual branch references [07:52] lifeless: I haven't investigated. But I would assume push -d will specify a subversion branch. [07:52] oh interesting [08:09] ok i'm starting to merge the external reference patch [08:26] what would cause a NotBranchError when using bzr-svn on a previously working repository? [08:26] * igc pick up kids [08:28] i'm callin it a week [08:28] 5:30 time to crack a beer I think [08:29] cheerio lifeless [08:29] might see you online :P [08:29] otherwise tuesday [08:29] once i finish cleaning this up [08:29] btw mark is confirmed for the week of the 16th [08:29] uh [08:30] if you want to reply on tuesday to my mail re scenarios that would be cool [08:30] if only to say +1 [08:30] sure [08:47] igc: i think you forgot the attachment? [08:47] lifeless: if you're still around, abentley has suggested using a path in branch.conf vs a new branch format [08:48] is that the plan for making stacked branches production? [08:49] poolie: thanks. fixed. [08:52] lifeless: abentley had a bunch of other good feedback as well that I found today (post my review overnight). I think we should include most/all of his suggestions. [09:00] igc: if I understand the proposal correctly, its a bad idea, it will break, badly [09:01] its definitely not the plan - a new branch and repository format is required [09:02] Hi all. [09:02] Does anyone happen to know whether the Fedora Core 8 subversion packages contain the necessary patches for bzrsvn to work? [09:02] igc: however abently proposed using a branch.conf key rather than a new *file* for storing where things are stacked [09:02] igc: and that was a good idea [09:02] uws: the bzr-svn test suite can detect them [09:03] lifeless: ah - ok. Here was the thread: https://lists.ubuntu.com/archives/bazaar/2008q2/040079.html [09:03] uws: install it, run bzr selftest svn [09:03] igc: I'm really just passing through [09:03] igc: this can wait till tuesday [09:04] lifeless: enjoy your beer. I'm off to cook dinner. Have a good weekend all [09:05] lifeless: Installed Subversion version does not have updated Python bindings. See the bzr-svn README for details. [09:05] lifeless: Too bad :( [09:05] lifeless: I'll have to update/compile svn myself. Would you suggest the latest stable 1.4 release + the patch, or svn trunk instead? [09:08] bzr is quite ok at http://live.gnome.org/DistributedSCM [09:09] uws: svn-1.5rc9? [09:18] gour: http://bzr-mirror.gnome.org/ [09:19] uws: ohh, nice. it means it's a serious candidate [09:19] uws: there is a faq about this, bazaar-vcs.org/svn I think [09:20] lifeless: you mean http://bazaar-vcs.org/BzrForeignBranches/Subversion?highlight=%28bzr-svn%29#python-subversion-1-5 ? [09:20] lifeless: It only lists the patch, but doesn't suggest which one to use [09:25] uws, gour: bzr-mirror.gnome.org is my baby if you have any questions about GNOME and bzr... [09:27] Jc2k: Ah. haven't used it personally yet [09:27] though I use bzr mostly, my gnome development happens using svn for now [09:27] Jc2k: i do not use gnome myself (only xmonad + xmobar), except some gnome apps, but would like to see gnome adopts bzr [09:27] dunno what the jhbuild support for this is [09:27] gour: /me too :) [09:28] uws: thats my other project ;) [09:28] * gour hopes that this overly-complex-easy-to-shoot-oneself-in-the-foot VCS won't prevail [09:28] Jc2k: rock on :) [09:28] git-mirror.gnome.org is also coming by the way.. [09:29] i've never used git. it [09:29] 's interface is horrible [09:29] its* [09:29] agreed [09:29] i mirrored about half of GNOME in 2 days, then realised it was wrong [09:29] i don't care about the kernel hackers' opinion that much [09:29] i have to start from scratch [09:31] so i have a few questions actually [09:31] there are a few thing the GNOME GIT people do, and are likely to whine about if they can't with Bzr [09:32] (regardless of whether they are good ideas or not) [09:32] is there an equivalent to git rebase --interactive [09:33] Jc2k: nope, it needs someone to spend some time on the rebase plugin [09:33] james_w: i guess its not something that a bazaar code newb such as myself can really approach, either? [09:34] Jc2k: actually, I think it should be possible. [09:34] oh? [09:35] I would hope that the rebase itself would be demonstrated by the existing code in the plugin, and it would just be a case of coding the interactive stuff, which hasn't got a lot to do with bzrlib [09:35] I may be being optimistic, but we would certainly help you if you wanted to give it a go. [09:36] i was wondering if it was maybe better as bzr-refactor as i don't think hacking apart your branch is really the same as rebasing, but yes.. am interested in giving it a go [09:37] bzr-resequence? [09:38] Jc2k: I think "rebase --interactive" would be the way to go, as diverging from git here would probably just cause confusion. [09:39] ok [09:43] james_w: would a bzr-gitmode pluging be possible that emulated the git wc/repo/branches model? [09:44] you could do it as a repo format [09:46] there was a suggestion that someone could make a bzr-loom without the stacked looms bit [09:47] Jc2k: yes, it would be possible. [09:47] Jc2k: bzr-git allows you to work with git using the bzr ui, but it would also be possible to write a plugin that gave multiple branches in one directory. [09:48] james_w: its the 2nd one that i'm after [09:51] oh, is there any way to pull a whole repo? [09:51] multi-pull plugin [09:53] bob2: can that pull branches that i haven't already branched? [11:07] jamesh: jhuild groks bzr yeah ? [11:07] lifeless: I did some bzr support code way back, but I don't know if it is still in a working state or not [11:08] if it isn't working, it should be trivial to fix [11:10] * AfC tried to get that to work, oh, 8-9 months ago, but I couldn't make it go. I'm not a regular jhbuild user, so it may have been something else. [11:12] [the mapping or repository's type & href attributes to a Bazaar URL and the branch element being inside an autotools (which we don't use) one made it all a bit vague] [11:13] AfC: the nesting of the elements actually matches the modularity of the code [11:14] AfC: the autotools build rules can have various VCS backends plugged in to grab the code (including "download and extract the tarball" VCS) [11:14] there are other sets of build rules (e.g. Python distutils) which use the same VCS backend code [11:14] Oh, I don't doubt its design makes sense, but I couldn't grok it is all. [11:15] AfC: i'm going to look at some "bzr-mirror and jhbuild" notes [11:15] Jc2k: yo dude [11:15] :) [11:15] Here, let me pastebin what I wrote [11:16] http://rafb.net/p/f3e70j67.html [11:17] Jc2k: (note this is slightly different from "I want to use bzr to work with GNOME modules currently living in Subversion"; I wanted to add java-gnome to the GNOME jhbuild modulesets but couldn't quite figure it out) [11:19] AfC: sorry, i think i phrased what i said badly - i'm going to add some notes to the bzr part of live.gnome.org about jhbuild and bzr [11:29] Hi [11:30] so, rebase -i - I think that a low entry point one that is a clone of gits should live in the rebase plugin [11:31] james_w: bzr-git is not that complete fwiw [11:31] lifeless: hi. ah yeah, I know that, but I was just wondering what functionality they wanted. [11:42] Jc2k: yes, multi pull can replicate a full set of branches [11:43] Jc2k: I think its important to remember though 'the way git does it' is what contributes to the feeling you had that it wasn't the right thing when you played with it :P [11:43] Jc2k: so we want to be somewhat careful about dropping git workflow in wholesale - providing plugins for git users that don't want to change is definitely possible though [11:44] lifeless: yeah, its more about eroding pro Git arguments by supplying plugins for their workflows [11:52] what's the easiest way to configure bzr on a server so that it can be used over bzr-ssh://? [11:53] Jc2k: It was a shame to see that the imendio guys are using Git. So that means its probably too late for GTK, though if anyone respects letting others work together its them. [11:53] RainCT_school: install it so that's in the path [11:53] RainCT_school: assuming you have Bazaar installed on the machine in question, there's not really anything further you need to do. It'll Just Work™ [11:54] RainCT_school: the URL prefix is bzr+ssh:// rather than bzr-ssh://, btw. [11:55] s/prefix/scheme/ to be precise I guess. [11:55] spiv: good catch [11:56] Oh, OK. Commit privilegies just depend on the SSH configuration / system users then? [11:56] spiv: yeh.. bad memory ^^ [11:56] RainCT_school: Right, ordinary filesystem permissions. [11:56] great :) [11:56] thanks [11:57] well, gonna go. bye! [11:57] AfC: gtk will move to git? [11:58] gour: a lot of GTK hackers are already using it, which means its harder to get them to bzr [11:58] :-( [11:59] one reason more to try get gnome [11:59] gour: but they are using it in an unoficial capacity, much like the other GNOME hackers like me and AfC are using bzr-svn [11:59] Jc2k: not exactly. They are using Git exclusively for their 3.0 work. Whether or not that ever makes it back to Subversion remains to be seen. [11:59] gour: GNOME will be providing some "experimental" hosting for bzr branches, though :) [12:00] Between them and the Cairo / Pango people, I'd say it's probably a lost cause. But we can keep trying. [12:00] * gour has hard time to understand why people love git...powerful? yes. but utterly complex model which stands on the way [12:01] gour: because its fast, because it handles things like families of branches as single units, and because other projects they are familiar with use it. These things are viral. [12:02] s/its/it's/ [12:02] its not entirely a lost cause, git has no backing from a sysadmin. the git people need to provide a volunteer to ensure smooth operation of git.gnome.org. [12:02] gour: and, don't forget, these people are all power users. [12:04] Jc2k: at this point, with Imendio and Codethink and Collabora all hosting their own git repos, someone hosting a git.gnome.org is somewhat less relevant. Yes, Olav is on our side, but he's a sysadmin, not a hacker. [12:04] i understand that...but, e.g. families of branches are just one reason why i prefer bzr (coming from darcs) [12:04] AfC: With a bzr-rebase --interactive, codethink can be turned. [12:05] Jc2k: :) I forced Rob to use bzr to make some fixes to java-gnome. That got him started, at least. [12:05] AfC: :p, Rob said he'd be willing to give bzr more of a look with rebasing. [12:06] Fact is that's just the way a lot of people look at distributed version control. It's getting on towards pointless to tell them that they're wrong. I understand and accept the arguments made by the bzr hackers about history loss, but most people don't seem to care that much because it hasn't burned them so far as they can see. [12:08] right, no change until getting burnt [12:08] same here...i had few serious issues with darcs [13:17] AfC: I understand why git users rebase now better than I used to. [13:17] AfC: its because their log is broken. [13:19] (it sorts by date not by branch, so if you imagine 10 branches, each that last a week, all merging to mainline one after another, [13:19] if they have 10 commits each [13:20] and spread equally over that week [13:20] then git log does: [13:20] branch1-commit10 [13:20] branch2-commit10 [13:20] .. [13:20] branch10-commit10 [13:20] branch1-commit9 [13:20] ... [13:20] branch10-commit9 [13:20] ... [13:21] Ouch [13:21] now imagine trying to understand what has happened when you see that output [13:21] [of course, I am on record as being terribly unfond of `bzr log` but mostly `bzr viz` makes up for it] [13:22] lifeless: apparently bisection techniques are easier with linear history too [13:22] lifeless: so, from a marketing standpoint, can you just say "bzr doesn't need rebase because our logging works right"? [13:22] jamesh: its easier if you don't think about it :) [13:22] AfC: well, I can say 'bzr doesn't provide the same anti-social pressure that makes rebase so important to git users' [13:22] lifeless: (that would be something really concrete for the compare and contrast crowd) [13:23] or even remove the word anti- [13:24] I think the only time I've really used the bzr-rebase plugin was to move some commits that had been made to the wrong branch [13:24] basically a cherry picking operation [13:26]