[00:01] 1.0.0 [00:01] hi all and happy new year (to those celebrating it) [00:02] somebody mentioned a couple of weeks ago that he is working on creating a patched svn version [00:02] and a smarter install for Mac [00:02] any news on this? (I know there is a distro for 10.5, but the discussion was to make it available for Mac 10.4 too) [00:03] Keybuk: So in 1.0, the reason why it didn't support remote urls was that it always used working trees. [00:03] However, local URLs should work just fine. [00:05] In bzr.dev, diff has been reworked significantly, and now uses the last-committed-tree for remote URLs and for branches without trees. === luks_ is now known as luks [00:39] Anyone know how to get svn style status? There seems to be a short keyword arg to status.show_tree_status that does what I want, but I'm having trouble getting started with the api. I'm not really sure if I want to be writing a script to filter the bzr output, call status from within, or make a plugin that is called by normal bzr st. Can someone point me in the right direction? [00:39] zekel: bzr st -S ? [00:40] what sort of thing you would want to use really depends on what you're trying to write [00:40] Oh, I guess I got confused. What I really want is the paths outputted to be relative to the cwd, and I took that to be the svn thing. [00:40] and in what lnaguage [00:40] I was thinking python. [00:40] ah, ok. I don't think there's a way to report paths relative to the cwd yet [00:40] but I may be wrong [00:41] I think I asked if there was a builtin way and was told no, not yet. I find that I don't check in stuff as much if the paths are long, which is really bad. [00:41] I could do something with sed, but I thought I'd try to do it from within python instead. [00:43] I think what I need is to know the correct way to get a working tree object, so that I can call a status method, which I can then mess with. [00:43] uhm [00:43] just write a replacement formatter? [00:45] That sounds like a great idea. I should look at the normal one and make my changes? [00:45] it may not be fully pluggable right now; a good place to start looking is bzrlib.status [00:47] That's why I'm thinking it might just be a better idea to have a filter script to pipe it through. [00:51] perhaps [00:51] we do like making things pluggable though :) [00:52] I can't say I'm an expert, so hacking bzrlib vs. filter script might be the difference between impossible and doable. [00:53] At least based on trying to read it. [01:00] zekel: ah [01:00] zekel: well, let me have a quick check [01:01] look for 'if short:' in status.py [01:01] see _mod_delta._ChangeReporter [01:01] thats the interface you can use to write a new reporter [01:02] What exactly are rich roots? [01:02] you can subclass that too [01:02] and hardcode in a new class in status.py for now [01:02] Peng: versioned '/' [01:02] What does that gain? [01:02] bzr split; bzr join [01:05] How do rich roots help that? What information about directories is there? [01:06] last-change and file-id [01:06] (and children obviously) [01:06] Ok. [01:06] I still don't get it. [01:06] it stops new files in the root of the project you joined being merged to the root of the combined tree, rather than the correct child node [01:07] say you have project A: [/] and B: [/, /README] [01:07] if you join B to A at subproject you get: [01:07] A': [/, /subproject, /subproject/README] [01:07] if you commit to B a new file 'configure' [01:07] then merge B' to A' you want: [01:08] A'':[/, /subproject, /subproject/configure, /subproject/README] [01:08] this requires you to know that B''s '/' is A's '/subproject'. [01:09] if B's / has no file-id then you can't tell that. [01:12] Ok. [01:16] That could be inferred, but I guess it would require rewriting history a bit? [01:16] Or, I dunno. [01:16] It sounds really easy to infer that when the merge is done, but I guess it doesn't map well to being stored? [01:17] the only thing available to infer this is the presence of README [01:17] or a deep history search [01:18] the first fails if there is also another file, say AUTHORS, that became /AUTHORS rather than /subproject/AUTHORS [01:18] though it is arguable at that point that a conflict should be raised (but you should still be clear about the options) [01:18] and deep history searches are generally bad things to do [01:19] because they break when you deliberately truncate history (e.g. partial branches because you don't want the deep history for now) [01:21] Is there some reason other than backward compat not to go rich-root by default? [01:21] It seems like most of the dangerous/surprising bits are segregated in the -subtree variant now. [01:22] dunno; I'll think about that later. Coding now. Tchau. :) [01:23] Better choice :) [01:49] abentley: if you are pro the experimental format approach I put forward, consider a review :). [03:02] This is probably asked allot, but, I created a bzr branch and then tried to merge in something from a subversion repository and just can't seem to figure out how to get it to work. I have successfully branched a svn repo into a non-pre-existing bzr branch, but I was hoping to create a bzr repo and selectively merge in svn branches. I'm using the svn-bzr plugin. Any thoughts? Is what I'm trying to do even possible? I can give any det [03:02] ails that may be of help. [03:06] well, an error message would be a good start :) [03:06] ok [03:06] one sec [03:06] * fullermd presumes it'll be a repo format issue. [03:07] yes, that seems to be the case, here is the lead up [03:07] bzr init [03:07] bzr merge svn+file:///home/pfharlock/arc/subversion/snippets [03:07] bzr: ERROR: Repository KnitPackRepository('file:///home/pfharlock/test/.bzr/repository/') is not compatible with repository SvnRepository('file:///home/pfharlock/arc/subversion') [03:09] upgrade --pack-0.92-rich-root I think is what you need [03:09] Yeah. You'll need.... mmm... at least one of the rich-root formats, and maybe the -subtree one. Not sure how far bzr-svn pushes you currently. [03:09] --rich-root-pack [03:10] (no 0.92?) [03:10] ok, thanks for the advice, I'll try that, I'm on bzr 1.0 [03:10] bzr-svn is supposed to work with the rich-root formats. [03:10] just out of curiosity, why does the rich root format help? [03:11] it adds metadata svn exports need to do the right thing with some of the copy-to-make-branch operations [03:15] yeah, that seemed to have worked, thankyou very much, will the rich root formats eventually become the default in bzr? [03:16] yes [03:28] * igc lunch [03:28] one more silly question, if you create a rich root format branch or repo, can you merge from it into a standard default knitpack or is it simply not backwards compatible that way? [03:35] pfharlock: It is not compatible for the same reason SvnRepository isn't compatible. There is data in "rich-root" formats that pack-0.92 cannot represent. [03:36] I see, thanks again for the help, it's really appreciated. [05:39] abentley: you replied to me, rather than the list [05:39] Oh, thanks. [05:40] abentley: I guess my habitual "group reply" in mutt that does "To: you / Cc: the list" breaks in combination with your reply habits? [05:40] I blame New Year's celebrations :-P [05:40] Heh. [05:41] I usually use "reply all", but I've recently changed my email address, so I've been a bit out of sorts. [05:42] spiv: Does that subtract_plans docstring look helpful? [05:42] abentley: very! [05:42] Oh, great. [05:43] I'm just applying your tweaks now. === bigdog_ is now known as bigdog__ === doko_ is now known as doko [08:16] night all [08:56] lifeless: still here? [09:07] fsvo here [09:07] dinner is ready in 2 min [09:07] i was fighting getting tg installed on squid-cache [09:08] but now i'm on the phone to thumper [09:13] tg is installed system wide [09:15] it is? [09:16] maybe i'm running things with the wrong python... [09:16] 2.5 [09:16] ah yeah [09:50] lifeless: you're definitely special: http://www.squid-cache.org/bzrview/squid3/trunk/changes [10:07] is there a plugin to support individual hunks commits, darcs style? [10:08] mwhudson: did you put anything in a per-user python dir or something ? [10:08] mwhudson: and how are you starting it ? [10:17] lifeless: "python2.5 ./start-loggerhead.py -f" [10:26] how come the release notes (and actually releases thmeselves as well) are so irregularly linked from http://bazaar-vcs.org/news ? [10:26] doesn't that happen automatically? [10:37] urgh, for some reason "bzr branch http://michael.ellerman.id.au/bzr/plugins/diffstat/" takes about 2 minutes and heaps of bandwidth [10:37] for all of 11 revisions [10:38] even a simple bzr ls takes 20s [10:39] The remote repository contains a lot more. [10:41] (Probably a copy of bzr's branch.) [10:54] mwhudson: I was using 'python start-loggerhead.py' [10:54] Peng: bet that teh remote repository is knits ;) [10:54] lifeless: It is. [10:54] mathrick: thats an old format repository [10:55] ah === cprov-out is now known as cprov [10:55] night all [10:55] I wouldn't call it old, just not new. [10:56] G'night. [10:57] lifeless: ah ha [10:57] why the fuck does that make a difference [10:59] Peng: it's slow enough to be old :) [11:05] lifeless: as predicted, though i'm not sure why, deleting the [logging] section of the config seems to help [11:07] garh, how can I debug WHY a plugin can't be loaded? [11:08] ie. get whatever error makes it so [11:13] Can someone point me at the docs for what a Text conflict is, vs. a Contents conflict? [11:15] Kinnison: http://doc.bazaar-vcs.org/bzr.1.0/en/user-guide/index.html#conflicts-types [11:16] thanks [11:17] Contents conflict in vl.h [11:17] * Kinnison thinks bzr misclassified that file [11:22] mmm or perhaps not [11:22] urgh [11:25] I think upstream deleted that file [11:25] pants [11:25] thanks [11:25] I hate qemu [11:26] mathrick: look in ~/.bzr.log [11:33] mwhudson: aha, thanks [11:41] how can i work out with trunk and branch methodology [11:41] indu: eh? [11:41] what do you mean? [11:41] is there a specific way that a version control system should follow for publishing the source, to the community [11:42] mathrick, i just started maintaining a version control system for my project, prev i had used svn [11:43] now i am trying to shift to bzr which has much more better features [11:43] indu: aha, there's no One True Way [11:43] but I am confused how to organise it [11:43] there are many ways, depending on what your project needs [11:43] mathrick, my project has different releases, named as sethu, tarang, and anant [11:44] indu: how big is it? How many core developers do you have? Is it open source? Proprietary? Proprietary with external contributors? [11:44] its an opensource [11:44] mathrick, and in future i will have some more release, [11:45] thus, if I consider each as seperate repo, and then upload my souce as branches ( each repo has more than one branch) [11:47] indu: what are those releases? Are they versions, or separate codebases? Do you need to maintain each independently, or does one release make others obsolete? [11:47] mathrick, they are not versions, they are different releases [11:47] but what is a release? [11:48] are they separate programmes? [11:48] mathrick, i am working on a linux distribution, [11:48] based on debian [11:48] okay? [11:48] and to maintain its source i am trying this [11:49] you can have a look at http://packages.bosslinux.in/boss/pool/ [11:49] where there are three releases, and under each there is a main folder, and the source under that folder only need to be made version controlled [11:50] aha, so they are effectively versions, except that they bundle a lot of things together each [11:51] indu: is the source you want versioned related between releases (I assume yes)? [11:51] no its not versined between releases, [11:52] the source is independent for all the releases [11:52] okay [11:52] indu: so as far as you're concerned, sethu and tarang have no relationship at all? [11:53] mathrick, yes [11:53] mathrick, they are just under the project of our linux distro, but internally they are not related [11:53] indu: then it makes sense to set up a separate repo for each of them [11:54] indu: what is the structure of your team? Do you have any external contributors? How many internal ones do you have? [11:55] internal are 15, and external may extend to 100 [11:56] or more than that [11:57] okay, so you might want to set up a PQM for the internal ones, and pull from independent repos for external ones, if they are less active than internals. Otherwise you could grant access for the active external ones as well [11:57] PQM lets you set up things such as buildbots and automated testsuites easily [12:00] what is PQM ? first time i am hearing this terminalogy [12:00] mathrick, mathrick, one more thing, i also need a good gui for the users to easily view the structure so that they can download the source, if i use loggerhead, then each repo appears extended by default and thus my page in browser looks very big with sethu (80 branches under it) lll'ly tarang and anant [12:01] indu: https://launchpad.net/pqm http://bazaar-vcs.org/Workflows [12:03] indu: a lot is explained in http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html and http://bazaar-vcs.org/BzrPlugins [12:03] including GUIs [12:04] unrelated, could someone review this patch: http://pastebin.com/m22468f01 [12:04] is this the right thing to remove diff_cmd_helper? [12:05] mathrick, ok i will have a look at those docs, [12:05] it irks me somewhat I had to recreate spec_tree() from it [12:05] mathrick, one more small doubt [12:05] mathrick, i am unable to configure bazaar with apache [12:05] do u have idea on it? [12:06] indu: I don't know what you mean by configuring bazaar with apache, so no [12:06] and I have no idea about anything that involves the two together, so I'm unlikely to help [12:09] mathrick, ok. thanks for the help provided [12:09] no problem [12:13] any comments on the patch? [12:33] mathrick: What's that a patch too? Also, use bundles (bzr send -o foo.patch) when submitting patches so your commits won't be lost. [12:34] Peng: it's for diffstat plugin [12:34] mathrick: Oh. [12:34] and I know about bundles, I just wanted someone to look at the code [12:34] Ok. [12:35] I don't know anything, so I have no comment on the code. [12:35] ok [12:35] ah, right, I've fixed a buglet since I pasted it [12:41] mathrick, i want to use http protocol, for publishing the content [12:42] mathrick, that can be done by configuring apache web server for bazaar, is it right? or any other way is available [12:42] indu: then you just publish the directories, bzr repos are simple directories on disk [12:42] there's no configuring of apache for bazaar [12:43] indu: unless you mean a sophisticated repo viewer, a'la loggerhead [12:52] mathrick, yes, my problem is solved now, many thanx [13:07] could some one tell me, what this message mean http://rafb.net/p/yfdEH296.html [13:08] indu: You can't push over http. [13:09] I soren branch on http worked [13:09] Yes? [13:09] That's a read only operation. [13:09] push means that you want to send you changes somewhere. You can't do that over http. [13:10] soren, ok fine [13:13] soren, then i changed my command to bzr push /usr/local/boss-bazaar/Anant [13:13] and the o/p was created one branch, but where does it create? since its not available under /usr/local [13:14] under /usr/local/boss-bazaar/Anant [13:14] o/p ? === Keltia__ is now known as Keltia [13:15] o/p = output [13:17] "the output was created one branch"? I don't understand, I'm afraid. [13:18] in svn, to create a new project repo, we using svn import command to add files to the repository [13:18] but its not possible in bzzr [13:21] Ok, now I'm seriously confused. [13:21] What is your question? [13:22] If you want to start to use bzr, you issue "bzr init", add your files, bzr add them, and bzr commit them. [13:22] (Even better, you convert from your svn repo so you don't lose your history...) [13:45] Indu: When you bzr push, bzr get, etc., yes, you get one "branch" (the term "branch" has slightly different meanings in svn and bzr though, and I'm temporarily blurring the distinction). The "output" will go where you told it to; for example, "bzr push /usr/local/out" would create a directory called /usr/local/out and under it /usr/local/out/.bzr, in which the data for the branch would go. I'm not sure how much I'm helping here, but I [13:46] pack-0.92 is the latest-and-fastest format? [13:47] Latest non-experimental format yes. I'll let someone else tackle the "fastest" part. There's a newer format, but I understand it's still experimental. [13:50] mathrick: Yes. It's a lot slower for operations that read the entire history (like log) though (which is being worked on). Also, older formats cache all of the information "bzr annotate" uses, but packs don't, so that's slower too. (There's going to be an annotation cache in the future.) [13:51] okay, I was playing with a simple benchmark, and it seems that bzr rm on new files is pathologically slow [13:51] I'm doing it on ~30K newly added files [13:52] mathrick: (On the flipside, operations that only read part of the history are much faster. So is dumb server network access. It also makes read-write dumb servers easier because files are not modified, only added and deleted.) [13:52] mathrick: Nice. [13:52] and it has runtime at least 3m [13:53] Crapcrapcrap. [13:53] * Peng notes that running 'touch' 30,000 times isn't very fast either. [13:53] Crapcrapcrap. Ran it in the wrong directory. [13:54] * Peng kills it after 17,000 files. [13:54] Peng: dunno, git can add all of them in 2s :) [13:55] % seq -f %g.txt 30000 | =time -p xargs touch [13:55] real 2.08 [13:55] Peng: ^ [13:55] Peng: the trick is not starting a new touch process per file ;) [13:56] what's =? [13:56] is that csh or some other abomination? [13:56] zsh [13:56] =time -> /usr/bin/time; I use in order not to use the shell builtin time, which I don't like [13:57] oh [13:58] someone should tell /usr/bin/time about spaces [13:58] dato: I know. [13:58] mathrick: I like it with -p better [13:58] bzr rm still running... [13:58] * Peng blows up his file manager moving all of the files with python. [13:59] dato: ah, that's basically what bash's builtin time does :) [13:59] ah, oh :) [13:59] I've been meaning to check out zsh instead of bash. [14:01] Sigh. [14:01] guess what, it's still running [14:01] I think I really did freeze my file manager. [14:01] command-not-found --> bash wins [14:02] God, I hope it has runtime <= 30 mins [14:02] Oh nice. [14:02] I might add it pegs the CPU while it's running, too [14:02] ps says it's using 0.1% of the CPU. top says it's using 99.9%. [14:02] so there's definitely something wrong going on [14:03] mathrick: Don't kill it! It's running Folding@home! [14:03] Peng: more like Removing@tmp [14:04] That still helps solve cancer, right? [14:04] I don't think it does [14:04] Hopefully Konqueror will be faster than bzr. [14:04] heh [14:04] Craap. [14:05] Peng: y'know, if it does something exponential, it probably won't finish within my lifetime [14:05] even just O(n^2) is pretty bad on n = 30K [14:07] Yay, Konqueror is done! [14:11] okay, 20 mins, I'll kill it now [14:17] okay, I've tracked the problem [14:18] it's collecting the info about files [14:18] since all are new and can't be safely removed, "bzr rm" will error out [14:18] and some kind of info it's gathering there is taking forever [14:18] if I add --keep, it's fast [14:18] no --keep == exponential === cprov is now known as cprov-lunch [14:58] is it possible to create my own location aliases similar to the lp: prefix for branches? so that instead of always getting a new branch by typing 'bzr branch bzr+ssh://foo.host.com/code/branchname' I could just type 'bzr branch me:branchname ? [15:02] Statik: The Bookmarks plugin might be what you want: bzr branch bm:branchname should become possible with that. [15:03] dlee: cool, thanks! [15:22] Is this the right place to talk about bzr-gtk? [15:25] I use the per-file commit comments, so there can be a lot of data. I wish that there were a "cancel, but retain comments" option in "bzr gcommit". Also, if I just "bzr uncommit", it would be nice if the previous comments were default in the UI for the next commit. === cfbolz_ is now known as cfbolz [15:28] CardinalFang: yeah, this is the place [15:29] I'm not quite sure I follow -- you want to cancel the commit, but still retain the per-file commit messages for the next commit? [15:29] I guess it's possible, although we'd need to store the messages somewhere. [15:30] schierbeck, Yes, that's what I meant. And when we uncommit, store those messages in the same place also. [15:31] When you uncommit, the revision is not removed from the repository. You could store the revision ID somewhere and use it to get the message. [15:31] Ah, good to know. [15:32] Peng: yeah, we could do that... but to be honest, this stuff should go into bzr itself, or maybe a plugin [15:32] It's a somewhat different work model [15:33] Writing per-file messages on the fly, and then committing after a while [15:34] But yeah, a temporary solution would be to store the revision id, and clean it up after a completed commit [15:34] I'll have a look at it now [15:35] schierbeck, I think we should capture the global commit message also. All the state of gcommit saved and reloaded. [15:36] CardinalFang: yeah, but I think the easiest way to get started is to restore the commit messages after an uncommit [15:36] later on I'll figure out how best to do it with cancelled commits -- perhaps write them to the repository anyway, and save the revid [15:43] Holy crap [15:44] I've never looked inside commit.py before [15:44] We actually implement just about everything ourselves [15:44] That stuff really needs to be moved to bzrlib [15:46] CardinalFang: this'll need more work than I anticipated... could I get you to file a bug report? That way it'll be easier to keep track of the issues [15:46] schierbeck, Sure. [15:46] Thanks [15:47] No, thank you. [15:47] :) [15:56] New bug: #180107 in bzr "`bzr ls` should gain --modified and --added?" [Undecided,New] https://launchpad.net/bugs/180107 [16:02] my bash completion for bzr broke :( [16:05] New bug: #180109 in bzr "gcommit should load default comments (from "bzr uncommit" and UI button "cancel but retain")" [Undecided,New] https://launchpad.net/bugs/180109 [16:05] schierbeck, ^ [16:06] CardinalFang: got it! :) [16:12] dlee: I've got a patch for the bookmark plugin to list the stored bookmarks. Should I send it to you, or luks? [16:14] statik: hm, different to what `bzr bookmarks` does? :) [16:14] dato: now, how did I miss that :( [16:15] hmm, this might be polished still [16:15] I think the bookmark name should be listed first [16:15] it is, at least here? [16:16] I get the path, then the short name [16:16] it looks like the code is intending it to print the other way [16:17] so, I still have a patch, it's just shorter :) [16:17] * statik should learn to read more carefully [16:18] That bookmarks plugin is cool. [16:18] statik: maybe you should double check with an unmodified plugin, I still see the plugin name first? [16:18] That was something I liked from hg. [16:18] (but I only have 1 bookmark, so it may be that) [16:19] dato: this isn't about the plugin name. its about what is output when I run bzr bookmarks [16:19] this fixes it [16:19] - for name, url in sorted(bookmarks): [16:19] + for url, name in sorted(bookmarks): [16:19] statik: [16:19] % bzr bookmarks [16:19] forja svn+https://forja.rediris.es/svn/csl2-minirok/trunk [16:20] (err, s/plugin name/name/ in my line above, sorry) [16:21] dato: I see. it prints the opposite way in revno 3 from http://bazaar.launchpad.net/~luks/%2Bjunk/bzr-bookmarks/ [16:21] dato: what revno do you have? [16:21] I had 2, and pulled to 3 [16:22] dato: then the only explanation is that I stored the data wrong when I first added a bookmark. [16:23] and this whole thing has been me being confused [16:23] makes sense [16:23] from ~/.bazaar/bazaar.conf: [16:23] [BOOKMARKS] [16:23] forja = svn+https://forja.rediris.es/svn/csl2-minirok/trunk [16:23] yep, I have my bookmarks inside out [16:26] New bug: #180116 in bzr "bzr rm pathologically slow with new files and no --keep" [Undecided,New] https://launchpad.net/bugs/180116 [16:38] jelmer: ping [16:38] dato: pong [16:38] jelmer: trouble in bzr-svn paradise ;) [16:39] I have minirok.dev, which I push to svn+https://....../trunk [16:39] funny, I just discovered bookmarks plugin today [16:39] and I did svn mkdir https://..../branches; svn cp https://..../trunk https://...../branches/foo [16:39] and b get minirok.dev minirok.foo [16:40] but pushing from minirok.foo to svn+https://..../branches/foo won't work, is that expected? [16:40] dato: What error do you get? [16:40] bzr: ERROR: These branches have diverged. Try using "merge" and then "push". [16:40] what does "bzr missing" say? [16:41] AssertionError: Empty parent added, but child wasn't added !? [16:41] oo-oo [16:42] uhm, ok [16:42] that's definitely a bug [16:42] what version bzr-svn is this? [16:42] % cd .bazaar/plugins/svn && b revno [16:42] 826 [16:43] shall I pull? [16:43] Hmm, I don't think anything has changed since that could've fixed it. [16:44] Any chance you can file a bug? Links to minirok.dev, minirok.foo and the svn repository would be very useful [16:45] ok. in the meantime, I guess it's ok if I continue to commit in minirok.foo? [16:45] yep [16:57] I doubt we have this yet, but ... Do we have anything for handling line ending conversions? I just cvs-imported a 760+ revision CVS project that had been managed under Windows, but bzr co's now check out with LF, not CR+LF. I did the co under Window+Cygwin, then another one under just Windows using the stand-alone Windows binary bzr. [16:58] * dlee wishes everything including Windows could just use LF and be done with it :P [17:01] I still don't understand why workingtree 3 uses so much bandwidth [17:01] It's dangerous to alter the data. Is that file with ordinals 13 and then 10 a text file or a PNG image? Oops, wrong choice. [17:04] CardinalFang: Yeah I know...otherwise I'd just ask for a co option to deal with it. Svn used properties because of that problem, and CVS used something like a checkin-time "property." I think line endings are on the ToDo list but not addressed yet; I'm mostly just verifying, while I try to figure out how to keep selling the Bazaar concept to my entirely Windows-based company that has been using CVS for about five years... [17:04] dlee, Ah. We're in the same boat then. [17:05] dlee: CVS had a horribly broken solution for that, though [17:06] like for most things [17:06] hehehe [17:07] given that more people seem to be awake now, anyone care to take a look at this patch: http://pastebin.com/m682e5b7e ? [17:07] is this the correct way to remove diff_cmd_helper() use? [17:08] I don't like the fact that I had to steal the whole spec_tree() from inside diff_cmd_helper() [17:08] It worked well enough for us, *if* people remembered the required -kb on cvs adds of non-text files. But that's a big *if* there. I liked the svn property idea better, but I used "native," which operated about like CVS anyway. (I did that to avoid having to put ^M at the end of every line when actually editing in an LF environment.) [17:15] jelmer: bug #180128 [17:15] Launchpad bug 180128 in bzr-svn "Cannot push to a branch `svn cp'ied`" [Undecided,New] https://launchpad.net/bugs/180128 [17:15] thanks! [17:16] I'm accustomed to creating a new branch that I expect to pull into several branches that never themselves merge. How does one create a branch that is the greatest common ancestor of two branches? [17:17] * mathrick doesn't really understand what CardinalFang said [17:17] (Well, "never" is wrong. One is a ostensibly a superset, but it may not have changes that have been added into the subset.) [17:17] (Yet.) [17:20] CardinalFang: Verify this with more seasoned bzr users here, but I'd say bzr init-repo /path/proj, then cd /path/proj and bzr co projBranchThatWillAncestorNewOnes. To make a descendant, from /path/proj, bzr co ancestorBranchJustMade newBranchName. [17:20] mathrick, Suppose I have a v1.0 branch and a v2.0 branch. I can't pull v1.0 to v2.0 because there are some things that others have added but are not yet added. I know I can add to v1.0 and cherry-pick "merge -c" just one new revision, but is there a way to create a branch that has only changesets that are in v1.0 and in v2.0, so I can add a changeset to it and pull into both with no trouble? [17:21] ^not yet added^not yet merged to v2.0 [17:22]