[00:00] dato: ^ [00:00] yeah, I was thinking [00:01] :P [00:01] james w mentioned the index's support for review etc as being very useful [00:02] yeah, the index is actually very useful for that [00:02] I tend to review my stuff before committing a lot [00:02] I wrote a proposal for review support in bzr [00:03] so it's very useful to say, "ok this part is definitely ok, don't show to me in `diff` again please" [00:03] have you seen that? [00:03] no, subj? [00:03] ah [00:03] probably RFC: supporting code review and partial commits better [00:03] yes I was just digging it up :) [00:04] if you have the time I would love your feedback on that as someone that used bzr for ages, knows the feel we aim for etc, but also is fluent with sophisticated use of git's index [00:05] It is not written as a comparison to the index; we wanted to derive something useful from first principles [00:05] right [00:05] ok, I can read the thread [00:05] but git's index is clear prior art :) [00:06] that would be lovely; thanks [00:20] ok, bzr push --overwrite and bzr uncommit work on svn repositories now >-) [00:20] holy cow [00:20] that is full of awesome [00:21] So (other than proper integration in push) that means full coverage I think [00:22] well that lhs parent bug thing [00:23] I've got most of that covered, working on tests atm [00:23] sweeet [00:25] nice work jelmer, that's pretty cool [00:37] I shudder to think how it works [00:37] jelmer: planning merge support for svn trees now ? :) [00:37] you could just edit the files in the svnroot [00:49] lifeless, probably at some point :-) There's some other things I'd like to work on first though, such as integrating the svn-push command [00:50] jelmer: do you have the rebase based mode for bzr-svn now? [00:51] james_w, not sure I follow - what sort of mode of mode? [00:52] it was discussed a little while back, more like git-svn I think [00:52] for those that didn't want the properties tracking etc., and could put up with having one hand tied behind their back [00:54] ahh [00:54] yep, that's in now, under the command dpush [00:54] cool [00:54] I'll have to play sometime in case anyone asks me about it [01:30] i can't seem to upgrade my bzr repo [01:30] are you getting an error? [01:30] ok so it went like this [01:30] my main trunk got a bzr upgrade [01:31] so when i went to merge it into my branch [01:31] it said to upgrade, so I did and it all worked [01:31] I then did the merge [01:31] that worked [01:31] then when I do bzr push [01:31] it tells me to upgrade [01:31] which i already did [01:32] what is the exact message it giveS? [01:32] Using saved location: bzr+ssh://jassmith@bazaar.launchpad.net/~jassmith/do/Optimizer/ [01:32] bzr: ERROR: Tags not supported by BzrBranch5('bzr+ssh://jassmith@bazaar.launchpad.net/%7Ejassmith/do/Optimizer/'); you may be able to use bzr upgrade --dirstate-tags. [01:32] i ran the command it suggested and it says its already up to date [01:32] bzr upgrade sftp://jassmith@bazaar.launchpad.net/~jassmith/do/Optimizer/ [01:33] oooo [01:33] we really should stop recommending people to upgrade to --dirstate-tags.. [01:33] that error is a bad one [01:33] jelmer: care to submit the obvious patch? [01:33] what does it do? [01:33] is sftp faster than bzr+ssh, or just shorter to type? [01:33] (just remove the --dirstate-tags) [01:34] meteoroid: sftp works ;P [01:34] I thought James had one which improved some of the upgrade error messages [01:34] james_w, Whatever happened to that? [01:34] jelmer: not this one [01:34] meteoroid: upgrade doesn't work over bzr+ssh. (I think that might've been fixed in bzr.dev last week though.) [01:34] ah ok [01:34] so erm, how long is this command supposed to take Peng_? [01:34] I thought that was Andrew that wrote that patch [01:34] DBO: dirstate-tags is an older format that should be avoided generally; that error message is one we missed - it should just say 'bzr upgrade' there. [01:35] DBO: Well, it has to download everything and upload it again. [01:35] Peng_, ok, long time, I'll go make a sammich [01:35] Hm, all you'd really have to do for tag support is upgrade the branch, though. [01:35] DBO: That branch isn't ver large, only ~4.5 MB. Unless you're on dial-up, it shouldn't take forever. [01:35] Peng_: a branch5 branch is knit based already [01:36] Peng_: so upgrading to packs is a good thing anyhow [01:36] Peng_, im on something that averages around 100kbps down and slightly better than dialup up =P [01:36] lifeless: True. [01:36] DBO: Oh. [01:36] anyhow, thanks for the wizardry that is bazaar, its the best tool we use =) [01:37] DBO: I've filed a bug against launchpad asking for a "upgrade this branch" button, since launchpad could do it locally much, much faster. [01:38] RAOF, sweet [01:38] bzr+ssh should support upgrades properly without involving the VFS code [01:42] lifeless, submitted to the list [01:42] james_w, yeah, it was spiv indeed. sorry [01:43] hey, I don't mind being credited with more than I've done [01:45] :-) [01:51] * meteoroid wonder if it is always necessary to type the full upstream svn url when interacting with a bzr branch of an svn repo, and pushing / pulling changes. [01:52] meteoroid: it shouldn't be [01:52] plain "bzr pull" should use the remembered URL [01:52] hm. [01:52] bzr: ERROR: No pull location known or specified. [01:52] interesting [01:52] i'm a little bit old, using ubuntu package, looks like 1.3.1 [01:53] it should remember it when that happens [01:53] that shouldn't matter for this [01:53] hm. [01:53] In my experience, bzr-svn has a habit of forgetitng the URL. I've never tried to track down what exactly happens. [01:53] A pull --remember fixes it. [01:53] It's a known bug in older versions [01:53] 0.4.11 will have it fixed [01:53] Oh, good. [01:53] jelmer: Has it already been fixed in the 0.4 branch? What exactly happened? [01:54] nice. are there beta debs for bzr-svn to go with the bzr beta debs? [01:55] There haven't been any beta releases of the next version of bzr-svn. [01:56] Peng_, yes, it's fixed in the 0.4 branch [01:56] Peng_, Missing set_parent() call, as simple as that :-) [01:57] jelmer: What was it missing from? Branching? [01:57] Peng_, yes [01:57] Oh. [01:58] That's simple enough. Thanks for fixing it. :) [01:58] Did it affect svn-import too? [01:59] that's also doing the set_parent() call at the moment [01:59] I'm not sure when that was added though [02:00] Well, I'm gonna go. Bye. :) [02:03] Peng_: --remember did the trick, thanks [02:03] * meteoroid looks forward to a new release [02:15] wooo, phase 3 of 4 [02:15] * DBO sighs [02:15] Ya. It's not speedy. [02:17] the best part of that last commit? it will drop a whole 1, you heard that, 1, machine (as in assembly level) instruction from our code [02:17] yep =) [02:17] its an AWESOME optimization [02:17] it also fixes a bug... [02:17] inner loop ? [02:18] its inside a loop that gets run upwards of 100 million times a minute if you are a heavy user [02:18] it can be run never also... all depends on how much you use the program =P [02:37] DBO: how do you make sure someone doesn't add an instruction back to the loop ? [02:43] lifeless, i have ninjas [02:44] :P [02:44] so its GnomeDO right ? [02:45] GNOME Do, yes. [02:47] meh caps schmaps [02:48] anyhow [02:48] what search engine(s) are involved there? [02:49] This depends on what you mean. Do has its own search on its item collection. There are plugins which use locate, google, an arbitrary Firefox search provider, xesam, and others. [02:50] hey RAOF, are you on Intrepid yet? [02:50] Yup. [02:50] so it calls into each per-keystroke I guess (for completion?) [02:50] metacity? [02:50] * RAOF moves stupidly early in the cycle. [02:50] james_w: Indeed. [02:50] is your do window off to one side? [02:50] mine's not central on the screen [02:51] james_w: Mine seems to be pretty much in the middle. [02:51] hmm, I'll try and work out what's going on then [02:51] lifeless: This is currently in a bit of flux. Currently all items are known by Do before any searching occurs, and the keypresses search through this internal list. [02:52] wheee memory use [02:52] RAOF: I'm asking because I'm doing some IR stuff at the moment [02:52] IR? [02:52] information retrieval [02:53] Ah. The memory use isn't bad; Do is currently at ~30MiB. [02:54] RAOF: thats 50% of my free memory :) [02:54] RAOF: I restarted it and it it's now central, but a little high, I suspect X wackiness. [02:54] james_w: It's intended to be a little bit above the middle. [02:55] lifeless: Here's 50 cents, go buy yourself another gig of ram :) [02:55] RAOF: ah, that will be it then :-) [02:55] RAOF: laptop slots are full kthx [02:56] How much ram is _in_ that laptop? [02:56] well there is 300MB back by killing flash [02:56] 2G [02:57] Same here. What's eating your ram? [02:57] ff hs 570M res, evo is 390M res, npviewer *was* 330M or so res (but I just killed the bugger) [02:58] next is xorg at 30M and a bug around that size [02:59] ff at 200, evo at 156, banshee-1 at 150 resident. Everything else is below 100. [03:01] so do you ask xesam for a concordance before you do any search? [03:01] I'd have thought something like that that could be indexing gb's of data would be slow used that way [03:04] The xesam plugin is sitting somewhere on launchpad; it's not a default plugin. [03:04] ah [03:04] I'm not sure how it does its think. [03:04] s/k/g/ [03:04] k [04:12] oh, bollocks [04:30] so, i want to use bzr and bzr-svn as a passthrough for a project where i am forking upstream code in one svn repo, and wish to provide an svn repo for the team working on the fork, merging perhaps in some cases bidirectionally through a bzr repo on my svn server. [04:31] i get an error trying to push code to my svn which is pulled from another, is this perhaps a limitation of bzr-svn? [04:31] meteoroid, what error message? [04:31] one sec [04:31] if this is a new branch you're pushing into subversion, use svn-push rather than push [04:32] ah [04:32] http://paste.plone.org/22937 fyi [04:32] will try that RW [04:32] RQ [04:33] svn-push did the trick [04:33] awesome! full speed ahead! :) [04:33] thanks jelmer [04:51] Is there a clever way to get a boolean value from bazaar.conf without having to parse it myself? [04:52] get_user_option just returns a string [05:04] hm, where does bzr-smart.py come from? [05:05] (to run smart server in apache httpd mod_python) [05:12] I think the content of it is just whats in teh docs [05:14] ah, just wsgi config, any idea if the smart server works with mod_wsgi? [05:20] I think it does [05:20] that would be much simpler, i bet i can figure it out [06:02] As a general rule should plugins not be using print for output? [06:03] I see that builtin commands tend to use self.outf.write() [06:03] Though some do use print [06:09] command objects should always use self.outf [06:09] and mutter etc [06:09] Is mutter for debug info rather than general user output? [06:14] OIC, the --quiet and --verbose options work by determining what mutter levels get shown to the user... [06:15] [OT] http://adweek.blogs.com/adfreak/2008/07/then-well-grab.html [06:15] ROFL === mtaylor_ is now known as mtaylor [07:44] Oops. Must remember not to bzr upgrade until at least a month after bzr starts telling me to do so. [07:45] Launchpad doesn't like the new format. [07:48] Which one? bzr is only likely to ask you to upgrade to pack-0.92, I think, and that's hardly new. [07:50] I was using pack-0.92 [07:51] Oddly enough, after updating bzr.dev (it was about a week old), it no longer tells me I'm using a deprecated format. [07:51] Whatever was broken in the old bzr.dev seems to be fixed now. [07:52] It complained that pack-0.92 was deprecated, and listed a '--1.6' option for upgrade which didn't work. Both are fixed now. :) [08:17] uhm, i get problems configuring loggerhead, if i have /top/a/c and /top/b/c, the second "c" wont appear :( [08:17] (in "auto_publish" mode) [08:52] * meteoroid whistles innocently while branching around 600 revisions of a public subversion [08:53] meteoroid: How many prebuilt dlls does it contain? :) [08:53] not a one, just python code. [08:54] i'm just worried i'll crash mod_dav_svn and wake some poor fool up ;d [08:55] Soft. I've been trying to branch google-gdata, and that contains ~15Mb worth of prebuilt code. [08:58] lots of revisions of each prebuilt file? [08:58] Quite a number, yes. [08:58] fun [08:58] why prebuilt code in svn? [08:59] I have _no_ idea. [08:59] heh [08:59] They have a Makefile and Visual Studio project which builds them. [08:59] someone teach them about svn:ignore ;d [09:00] They're deliberately there. Oh, and there's an x86 and arm build of zlib in there, too. [09:00] hm. [09:06] * awilkins is branching the SVN of JTidy [09:06] It's taking a looong time [09:10] Some things are a total sod to build on windows ; maybe those pre-built files are there for that reason [09:11] These things are built from the source in this very svn repo, and have no dependencies outside of the .NET corelib stack. [09:11] Ok then, they are daft [09:11] Well, the zlib dlls aren't, true. [09:12] With VB6, you at least have the excuse you need to preserve the GUIDS for binary compatibility [09:12] What, really? [09:12] A _rebuild_ breaks VB6? That's awesome. [09:12] Yeah, VB6 uses an existing compiled binary to refer to for interface IDs and type IDs [09:13] Because of COM [09:13] And how it abstracts it all away from the developer [09:13] I always make a copy in a "compat" subfolder [09:13] That is made of pure win. [09:14] It's the source of endless swearing in many codebases [09:14] I can't possibly imagine why ;) [09:15] I've written build tools arranged around determining VB6 dep trees and fixing the compatibility settings [09:18] and now i will find out how long it takes to branch ~10k revisions ;d [09:27] i just found out that one project us using git on savannah. is bzr also supported there? [09:28] *is [09:29] Yes. [09:30] really? then i can suggest to devs to move to bzr instead of CVS [09:32] gnash is hosted on savannah, and uses bzr. I would be amazed if anyone was suggesting that something be moved _to_ cvs, though :) [09:34] well, they already use CVS :-) === AnMaster_ is now known as AnMaster [10:15] pmezard: hello [10:15] pmezard: do you have some kind of status for the forest extension? [10:16] pmezard: oups, wrong chan : [10:16] :) [10:40] any handy url to answer question in http://article.gmane.org/gmane.comp.gnu.medical.devel/12670 ? [10:43] (how switching from CVS to bzr might help to get more contribution to the project) [10:51] Using Bazaar means that everyone gets the benefit of using a VCS ; using CVS limits that to a select few with commit access [10:51] gour: No particular URL comes to mind, but it'd be easy to make an argument based on user interface and benefits of DVCS over a single central repository. [10:52] The launchpad tour is full of good reasons too, though only some of that is bzr-related. https://edge.launchpad.net/+tour/index [10:53] ToyKeeper: how about http://ianclatworthy.wordpress.com/2007/10/11/why-distributed-version-control-matters/ [10:55] * ToyKeeper wonders why that document is PDF instead of HTML [10:57] gour: There's also the social aspect... cvs these days is about as hip as having toilet paper stuck to one's shoe. It can deter potential contributors just because it doesn't have a good "smell", so to speak. [10:58] Even if it's used correctly, people may assume it's a bad sign. [10:58] rotfl [11:00] * gour sent url for ian's paper [11:01] I'm in the middle of reading his manifesto for community-agile software guidance. He has some good texts. [11:01] that's good one too === pbor|afk is now known as pbor [12:17] jelmer: pong [13:14] for some reason bzr builddeb during a build using bzr bd --merge --dont-purge --builder='dpkg-buildpackage -rfakeroot -kA5C42601 -i.bzr' . wont allow me to sign it but with -S -sa it lets me sign it [13:14] this has been happening for a while maybe a month or so now [13:15] it results in a failed build but it built fine jsut failed to sign so maybe the error message can be tweeked as well? [13:18] gnomefreak: sounds like filing a bug might be appropriate? [13:18] gnomefreak: are you sure you want -i.bzr btw? [13:18] LarstiQ: i might have already ill check since i cant remember [13:18] LarstiQ: yes im sure [13:19] we dont want .bzr being uploaded with package [13:19] gnomefreak: maybe it's specific to building bzr packages, but .bzr also ignores 'files.bzr' and such [13:19] or built for that matter [13:19] gnomefreak: right right, but that ignore pattern is ignoring more than just /.bzr/ :) [13:20] LarstiQ: shouldnt it only ignore .bzr since that is what i told it to ignore, with everything inside .bzr of course [13:23] gnomefreak: it's a regex pattern, not a shell glob. [13:23] gnomefreak: I guess if you don't have any files with 'bzr' in their name you are fine. [13:23] i dont outside of .bzr [13:23] ok, no problem then [13:25] does bzr use LP for bug tracking? [13:27] gnomefreak: yes, but you want bzr-builddeb I think? [13:28] yeah i just relized it is needed instead of bzr i was thinking it was a plugin but i remember installing it as a package [13:29] gnomefreak: you don't need -i.bzr [13:33] james_w: when was it changed? [13:33] ok bug is filed [13:34] james_w: ive been using -i.bzr for a long time since i was told to leave .bzr out of it [13:35] bzr-builddeb takes care of that [13:35] if it doesn't please file a bug explaining your setup [13:38] it didnt used to so ive just been using same command not knowing it had changed [13:38] well important problem has been reported https://bugs.launchpad.net/bzr-builddeb/+bug/254400 [13:38] Launchpad bug 254400 in bzr-builddeb "when building a package with bzr-builddep it fails to promt me for a password to sign package" [Undecided,New] [13:39] thanks for the input im gone again for store [13:39] james_w: I also needed to use -i ('^/.bzr/'?) in the past. [13:39] interesting [13:39] do you know why? [13:40] it was just the way it was [13:40] afaik [13:40] but i dont know the code for bzr [13:40] thanks guys ill see you later [13:42] gnomefreak: bzr-builddeb, not bzr [13:42] james_w: iirc your initial decision was to mirror svn-buildpackage? [13:42] yeah [13:43] it's all a bit hazy in my mind, but I thought without it I'd end up with .bzr/ in my packages. I admit my memory is fallible. [13:45] it does and "export" so it shouldn't [13:45] maybe there's a case that I missed though [13:49] What will be the good place to propose a patch for loggerhead? [13:51] the bazaar mailing list, or a bug against loggerhead probably [13:51] you could put a branch on launchpad and propose it for merging [13:54] ok [15:04] lifeless: http://repo.or.cz/w/topgit.git?a=blob;f=README === prateeksaxena is now known as prTk [15:06] lifeless: the announcement: http://article.gmane.org/gmane.comp.version-control.git/91197 [15:19] hi, i'm trying to do a merge, but i get a Content conflict in a file that i deleted, which also appears in the removed list. How do I solve this? [15:50] /B 2 [17:24] jelmer: have a minute for more information about my mysterious can-keep-committing-same-revisions problem? [17:26] is there any way for me to tell where a branch came from? like see that it was branched from branch1 which was branched from branch2 which was branched from trunk ? [18:11] rocky, hi [18:11] hey rocky, didn't know you were a bzr user :) [18:11] rocky, still there? [18:11] jelmer: yep [18:11] meteoroid: yep ;) [18:12] rocky, is there svn repo where you're experiencing this problem public? [18:12] jelmer: couple questions first... i should always be using svn-push when pushing a local branch changes back to svn right? [18:12] rocky, You can, but there's no reason to [18:13] jelmer: i should use bzr push ? [18:13] rocky; i think only if you are creating the branch, e.g. if the parent dir doesn't exist upstream. [18:13] rocky, the only situation where you have to use svn-push and nothing else is when nothing exists yet in svn [18:13] rocky, in all other situations bound branches or regular push should work as well [18:15] gotcha [18:15] and regular pull should work fine too right? [18:16] yeah [18:16] back in ~30 min [18:17] rocky: in current release, though i believe fixed in 0.4.11 or whatever the next is, there is a wierd issue where sometimes the repo is forgotten. if 'bzr pull' doesn't work, give it a url and --remember, e.g. 'bzr pull --remember https://svn.rocky.org/svn/rocky/rockys-stuff' [18:17] jelmer: btw, the public svn repo for my work is at: https://dev.serverzen.com/svn/cluemapper/ClueMapper/ but i've been fiddling with this all morning so i could have everything messed up [18:19] ClueMapper looks interesting.. [18:22] www.cluemapper.org === thekorn_ is now known as thekorn [18:50] jelmer: does the svn cache have to be per-user, can i set it up to be owned by a group that handles merges on the svn server? [18:50] well owned by is easy, but i mean, not in some location like ~/foozle/ [18:50] rocky, Thanks, I'll have a look at that in a sec [18:51] meteoroid, no, the location is pretty much hardcoded atm [18:51] * meteoroid nods head [18:52] jelmer: just an fyi, i figured out kinda what the problem was ... everytime i checked out ClueMapper/trunk with bzr it somehow got remembered (with the bzr svn props) that it was ClueMapper/branches/rocky so when i would do a commit, it committed to ClueMapper/branches/rocky instead of trunk ... after i removed all of the bzr svn props from the svn repo, things started working predictably again [18:52] rocky, that doesnt sound right [18:52] yeah i assume i triggered a corruption bug somewhere [18:53] rocky, the props don't contain information about locations [18:53] oh? well i tried blowing away all my local checkouts/branches then checking out trunk again, adding a change, committing, and voila, it went back to the rocky branch (incorrect) ... it was only after i deleted those bzr svn branches that it finally started working [18:54] hmm, I'll see if I can find out what was going wrong then [18:55] corruption is not nice :-( [18:55] rocky, you're running 0.4.10? [18:56] yes i am [18:56] atm, i'm running bzr 1.5, bzr-svn 0.4.10, svn 1.5 [18:56] ubuntu hardy heron [18:58] jelmer: fyi, i'm writing up a blog post on my experiments with bzr-svn as in how to get started ... i'd love to have you proof-read it to ensure i'm not making gross mistakes [18:58] hm, i will hang back on bzr 1.3.1, bzr-svn 0.4.9-1, and svn 1.4.6 on hardy for now. did you build from source? afaict these are the latest debs. [18:59] rocky, sure, no problem [18:59] meteoroid: i used intreprid debs for all of those on hardy [18:59] k, i'm not done with the post yet [19:01] rocky: i wonder what sort of workflow you are describing, i also was going to write a guide on using bzr-svn to fork upstream projects while retaining the ability to push changes back into them, though i haven't quite figured out how to select only some changes for acceptance upstream. [19:01] "fork, n.: a branch with a middle finger logo." :-P [19:01] meteoroid: this is *very* basic [19:01] right on, perhaps i can build on yours when i write mine so i don't have to cover all that ground [19:03] sure [19:37] hey rocky you should open up non-https svn as well read-only, will lessen the load on your server when other people follow you in svn.. [19:39] meteoroid: http://www.cluemapper.org/svn [19:39] ah ok [19:39] i just tried as same url [20:06] i'm still trying to figure out the whole push/pull thing ... this is supposed to work on mirrored branches right? and won't work if the branches "diverge" ? could someone explain the simplest case of the branches "diverging" ? [20:07] i have more experience with that level of usage from bk, i'm not sure how similar bzr is, but generally in DSM there is some auto-conflict-resolution, and in some cases you need to hand-merge a conflict [20:07] er DSCM [20:08] other than the repo itself one of bk's strengths was, in the past, the conflict resolution code - in our team at rackspace we often had more than 20 branches a piece going between 12 or more people, the web / marketing team branched our code for the customer portal, networking had branches, etc.. [20:08] it was pretty nice except the not having source code and the paying lots of money [20:08] ;d [20:09] there were only a few of us who knew how to manage merges, but we handled that by having master branches for each team, so that if two entirely unrelated projects modified the same code, they'd have to sit down at some point and talk out what each of them did, or someone who knows the code and understand both projects use a 3-way merge tool like meld [20:10] i haven't tried meld with bzr yet but it's a pretty standard tool, works with svn [20:10] i suggest doing some experiments, i have been testing a lot of stuff over the past couple days and learned a good bit.. [20:14] the simplest case, i guess, let's say you modify one file in one branch, and another file in another branch, it should be straightforward [20:16] rocky: divergence happens if there are commits on two branches, so if I branch from you, and then we both commit on our own branch they will have diverged. [20:16] that then means we can't push/pull between us, one of us needs to merge [20:18] james_w: with non-overlapping changes, it should be straightforward though, yes? [20:18] meteoroid: yeah, it might be, but in bzr terms you *must* "bzr merge", you can't "bzr pull" [20:19] got it [20:19] commits on both branches invalidates pulling/pushing until one branch does merge from another -- that pretty much covers it right? [20:19] yeah, that's the essence [20:22] james_w: ah, ok, good to know.. [20:24] is there an intentional reason that bzr push / pull doesn't imply a merge if required? [20:25] so that it is an explicit step [20:25] okey doke. :) [20:25] it would be really hard to make push merge [20:26] you can make pull merge, but bzr doesn't, for a few reasons [20:27] i'm sure i'll learn more over time how bzr is different from bk, the only dscm i've used. hg seems more like bk in ways that i don't entirely appreciate. [20:27] the svn support in hg is esp wierd and sort of analogous to just doing an svn export on top of the hg branch ;g [20:28] well, it's a little better than that but still awkward imo. [20:35] anyway, i recall that in bk, push and pull were sort of analogous, only indicating direction, and that you could either pull changes from a developer workstation over ssh to merge them into a team branch, or push them up from the workstation, and pretty much the same stuff happened. if the merge failed or had conflicts or whatever the terminology is, a 3-way merge tool popped up, or a message was printed saying, like, "hey, you have to [20:36] i can see advantages to making it a conscious step, but it's also something else to teach users which may just fall upon more senior members of a team, creating bottlenecks. [20:37] rocky, looks like the bug you hit earlier was 250480 [20:37] (bug 250480) [20:37] Launchpad bug 250480 in bzr-svn "Doesn't preserve non-lhs parents for file texts" [Critical,Triaged] https://launchpad.net/bugs/250480 [20:37] jelmer: ahh... great ;) [20:44] hiya [20:45] what's the status of cherrypicking support and how much of what it depends on is done? [20:45] mathrick, cherrypicking itself is supported (has been for a long time); I'm not sure what the plans are for tracking cherrypicks [20:46] that's exactly what I mean [20:46] non-tracking cherrypicks are rather useless/harmful [20:46] why? [20:46]