[00:36] morning [00:47] lifeless or spm: can you go ahead and create a 2.0.1 branch from 2.0 and a 2.1.0b1 branch from bzr.dev@4734 ? [00:48] I'm going to be in and out a bit [00:48] (i decided to not release my last two patches from bzr.dev, instead waiting for 2.1.0b2 for the static tuple stuff) [00:48] I'd like to work on the releases tomorrow, though [00:52] I'm doing an update on the format docs [00:52] What should I change this to: For example, [00:52] you may need to select 1.9 instead of 1.14 if your project has [00:52] standardized on Bazaar 1.13.1 say. [00:55] Is this good? "For example, you may need to select 1.14 instead of 2a if your project has standardized on Bazaar 1.18 say." [00:55] I'm going to delete the say, it doesn't fit in. [01:01] Doesn't 1.18 support 2a? (with efficiency caveats) [01:03] Oops [01:03] When was the version before 2a was released [01:03] I'll fix that really quickly [01:07] Do I mark myself as the assignee and the status of the bug "Fix Commited" [01:07] I'm not sure how the bug-process works [01:11] Should I change the status to "In Progress", "Fix Committed", or just leave in the way it is? [01:33] jam: I can't anymore [01:33] jam: and spm is sick today [01:33] jam: you should mail RT [01:33] 1.16 and above support 2a [01:36] mathepic: thanks for working on that bug [01:36] igc: No problem. [01:37] Can anyone confirm that the info contained in it is correct? I don't know my history that well. [01:37] mathepic: while working on a bug, mark it "In Progress"; once you've pushed a branch with the fix, mark as "Fix Committed" [01:37] igc: Okay, thanks. [01:38] mathepic: I'd drop all the text about selecting a format prior to 2a. We need to *strongly* encourage everyone to upgrade [01:38] Okay. [01:39] mathepic: as lifeless mentioned, 1.16 and above support 2a [01:39] should I keep the paragraph about the rich-roots? [01:40] you can mention rich-root in a footnote but not the main text IMO [01:40] it tends to confuse more than enlighten [01:40] most readers [01:41] and after 2a, the issue effectively goes away because all future formats are rich-root implicitly [01:41] (as is 2a) === mnepton is now known as mneptok [01:42] How about this: "The newest format, 2a, is highly recommended to use. If your project does not support 2a, then you should suggest to the branch owner to upgrade." [01:42] (That replaces the whole list thing) [01:43] Or simply nothing at all? [01:45] I'll just remove that whole block of text. [01:46] mathepic: "does not support" -> "is not using" [01:47] Okay, added it back. "Branch owner" or "Project owner"? [01:47] project owner [01:48] Okay, I'm pushing it to my branch. [01:49] cool. Then propose it for merging please [01:50] Its been proposed. [01:50] ah - then you may need to resubmit the proposal [01:51] I sent another review request to bzr-core. Is that what you mean? [01:52] yep. Thanks. [01:53] Okay. [01:57] Ugh, spotted a type [01:58] igc: I pushed it again to fix a typo. Do I send a review request again? [02:00] mathepic: hmm - forget what I said about requesting another review [02:00] igc: Okay. [02:00] you need to click "resubmit proposal" [02:00] top right hand corner [02:01] Okay, done. [02:01] Well, I have to go. [02:01] mathepic: thanks for your work! [02:01] No problem. :) [02:01] shouldn't need the resubmit anymore [02:01] the diffs update [02:01] lifeless: ah - ok [02:02] lifeless: hi btw - welcome back to Oz [02:02] lifeless: I hope the sprint when well [02:02] yup [02:40] lifeless: k. Also, I don't think pqm is running the test suite on python2.4 anymore. At least, I thought that was the problem so I installed 2.4, and found out it wouldn't build [02:40] so I sent in a patch to make it build on 2.4, but the previous patch had been accepted. [02:41] jam: rt that too :) [02:41] jam: the chroot has been upgraded, probably the default python has been altered [02:41] lifeless: is the fix just configuring pqm to do "make check PYTHON=python2.4" ? [02:42] yeah [02:42] force the version in the pqm config [03:36] * igc lunch === abentley1 is now known as abentley [06:14] bbl [06:55] I was curious why a Loggerhead Package for Hardy was never released? [07:19] hi all [07:28] hello all [07:44] is there an equivalent of the hg export / import functionality in bzr??? [07:45] (export a changeset that I may import into another workspace) [07:47] thumper: there's 'bzr send' [07:47] ?? [07:47] spiv: tab fail [07:47] thumper: er, sorry, wrong nick :) [07:47] tab-complte FAIL [07:48] mneptok: hey [07:48] trondn: There's "bzr send" [07:48] thumper: ahoyhoy! [07:48] spiv: and to apply it into the other one (and preserve commit id etc)? [07:49] trondn: bzr pull or bzr merge from the file, like you would with the branch. [07:49] spiv but that will make it a merge set?? [07:50] If you use 'bzr merge', yes. But you can 'bzr pull' if you don't want to merge (assuming the history hasn't diverged). [07:53] hmm... bzr send -r -2 -o /tmp/foobar resulted in: Bundling 0 revision(s) ... [07:53] "bzr oh_god_i_killed_us_all" should undo the previous push. kthx. [07:54] mneptok: bzr alias oh_god_i_killed_us_all="push -r -2 --overwrite" ;) [07:55] spiv: but then i can't tell others about bzr's intuitive, natural language feature set [07:56] trondn: oh, right. "bzr send" really prefers to have access to the target branch so that it can bundle exactly the right set of revisions. [07:57] trondn: which is a bit annoying when you don't have the branch accessible :/ [07:58] spiv I have both available... the one I want to put the one changeset in is ../mget... bzr send --help would be a lot more helpful with an example.... [07:59] guess I should just try out the rebase thing.. that's the thing I really want to do... [07:59] (I just heard that it might not work the way I expected it to work ;-) ) [07:59] trondn: oh, if you have the target available, just "bzr send /url/to/target -o somefile" [08:00] trondn: or, if the target is writeable, just cd to it and do "bzr pull /path/to/other/branch", you don't need the indirection of a merge directive file. [08:02] rebase isn't ever exactly "the thing I really want to do" AFAICT; it's a means, not an end. What's the goal? [08:02] :( they have diverged so it tells me to merge :( [08:02] the goal: put my changeset at the _end_... [08:02] and don't fuck up the history with another merge set.. [08:02] Why is merging so terrible for you? [08:03] it makes the history unreadable... [08:03] I'm working on implementing a feature committing multiple times... but I still want to bring in the work happening on trunk... [08:03] Hmm, I don't find that. "bzr log" by default only shows the mainline commits. [08:04] and I want my changes to appear at the end in one bulk instead of a spagetti with the "merge from trunk".. [08:05] with git I normally just do git rebase, in Mercurial i use export / import... in bzr I currently apply each patch by hand and commits them again :( [08:05] So, if you want to squash things into a linear history when things have diverged, rebase is an alright way to do that. I personally find the original history quite readable, though. [08:05] There is a rebase plugin. [08:06] But I suggest you play a little bit with "bzr log" and its options, you might be surprised. [08:07] is the rebase plugin btw, in case you don't already have it. [08:07] I guess I could.. right now I find it terrible to track down a bug on let's say lp:drizzle.. bzr log mostly shows me merge "foo", so I run it with bzr log -n 0 -v, but then I see changes multiple times because multiple people merged the same changeset into their tree etc... [08:07] (downloading and installing now) [08:09] Normally I only want to see the mainline commits, I actually quite like that a long-running feature that took 30 commits to develop is shown as a single mainline commit, rather than as 30 separate pieces. (But also that the individual pieces are still there when I need them.) === smartgpx is now known as Guest45035 === smartgpx_ is now known as smartgpx === doko__ is now known as doko [09:09] when I use bzr qlog it chops off the first digit of the revision number - anyone else seen this before!? [09:13] also, shouldnt qcommit be a resizeable dialog? [09:13] i swear it used to be... [09:21] crisb: It is resizable. Change your monitor resolution. [09:22] davidstrauss: i'm at 1650x1080! its not that it appears maximised, it just wont let me resize it or maximiseit [09:23] crisb: No, I mean reducing your monitor resolution will make the window bigger. :-) [09:23] :) [09:24] so its not supposed to be resizeable in the same way as say qlog? [09:24] * davidstrauss actually has no idea. [09:28] sorted - dodgy qbzr.conf :) [09:30] revision number chopping still exists though :( === Adys_ is now known as Adys [09:37] * igc dinner [10:32] crisb: I'm seeing the first digit being chopped too in qlog if the re count is > 1000 [10:32] crisb: can you raise a bug for that please? [10:33] igc: sure, I already raised 450179 - looks like Alexander Belchenko has confirmed it too [10:33] crisb: ah - I see you already have - thanks [10:41] is it possible to quickly/cheaply determines how many revisions in the repository? not in the mainline revisions, but in repository overall? [10:41] crisb: there si hardcode limit for 4 digits in qlog [10:41] crisb: there is hardcode limit for 4 digits in qlog [10:42] bialix: yes, I noticed that in logwidget.py - but changing it to more than 4 digits didnt help [10:44] there is custom painting code [10:44] without looking into code I'd say there is several places which require to be fixed [12:04] Hi [12:06] I'm importing a svn repo into bzr, with 2324 revisions, but bzr says copying revision x/2304 -- is this normal? [12:11] Anteru: yeah, that could be correct [12:11] Anteru: bazaar only imports branches, and some commits in svn might have been outside of actual branches [12:11] err, I'm trying to import _the whole repo_ [12:12] Anteru: if you create a "branches" directory in svn that wouldn't show up in bazaar anywhere [12:12] with /branches, /tags, /trunk [12:12] hm ok [12:12] I previously tried git, where you have to specify the layout [12:12] and git imports everything, including branches from svn [12:13] Anteru: Git doesn't import these commits either afaik [12:13] Anteru: e.g. if you add a file called README in /, which branch would you expect it to end up in? === mrevell is now known as mrevell-lunch [12:15] well, I would expect an error [12:16] btw what are the parameters for the repository layout? [12:17] it says "Using repository layout: trunk0" [12:17] Anteru: yeah, that means the standard /trunk, /branches, /tags layout [12:17] and looking at the doc page, it lists none, trunk,, and default: auto [12:18] Ok, I'm halfway through, but I still don't get why revisions are missing [12:18] I had one branch or so in the past in /branches/, which has been deleted [12:20] I simply don't want to loose history [12:21] Anteru: are you using --keep ? [12:21] nope, will try [12:21] and --all? [12:22] why would I use keep when I use all? [12:22] I just want the whole history [12:22] that is, being able to restore anything which was stored in the SVN (d'uh, missed --all) [12:34] ah ok, looks good [12:37] thanks! [12:37] sorry, was aaway [12:38] Anteru: np, glad it worked [12:39] just double-checking, with --all, it says copying revisions x/2314 [12:40] du, which is still 10 too few :/ [12:40] even with --keep --all [12:41] I guess tags are skipped? [12:45] ah damn, the folder /branches was called /branch some time back in ancient history [12:46] Anteru: it should follow that [12:46] Anteru: tags are not versioned in bazaar, so they wouldn't count as revisions [12:46] ok I got 8 tags [12:47] so 2 revisions ... one might be the /branch -> /branches rename [12:47] and one might be the initial commit [12:49] igc: Does fastexport/fastimport follow renames? [12:49] (looking at the samba import) === mrevell-lunch is now known as mrevell [12:52] I guess even if there is something missing, it can't be a lot [12:54] hi jelmer [12:54] jelmer: yes it does, though I think one needs to explicitly ask git-fast-export to detect them [12:55] and export them [12:55] (and I didn't do that) [12:55] igc: that might explain the big repo size [12:55] interesting [12:56] not that we've implemented copy support yet [12:58] igc: copy support would help too I suppose [12:58] igc: samba trunk has two top-level directories that have a lot of code in common [12:59] w00t, just managed to work with a SVN repo from bzr [13:00] though the "push" speed is kinda slow [13:00] Anteru: it should be faster the second time around [13:01] Anteru: the first time it has to update caches, etc [13:01] jelmer: fyi, I changed the file-id algorithm and the repo size dropped from 500M+ to 350M. [13:01] jelmer: jam gave me the tip to do that [13:01] igc: wow, I wouldn't expect it to matter that much [13:01] jelmer: I was generating file-ids using the full-path - now I just use the basename [13:02] jelerm: scary ah - one line change having that sort of impact! [13:02] igc: Yeah, indeed [13:03] I should remember to do a similar thing next time I update the mappings for bzr-{git,hg} [13:04] jelmer: I tried twice, it says something about finding tags each time [13:04] Anteru: what version of bzr-svn are you using? [13:04] jelmer: btw, how easy/hard would it be for you to convert svn-fast-export.py to use subvertpy instead of the std bindings? [13:04] jelmer: bzrlib 2.0.0, python 2.5.4 (latest stable installer for windows) [13:06] igc: should be fairly easy [13:06] jelmer: it would be sweet if you could take a look - bug 273361 is driving me nuts [13:07] Launchpad bug 273361 in bzr-fastimport "svn-fast-export.py crashes with too many open files" [High,Confirmed] https://launchpad.net/bugs/273361 [13:07] * jelmer has a look [13:07] jelmer: the all-but-identical C implementation works fine [13:07] jelmer: so I suspect the bindings [13:08] jelmer: and furthermore, using the same bindings you are makes it easier for Windows users because they don't need to install extra pieces IIUIC [13:10] jelmer: well, gotta go for a mo', gonna test more thoroughly later, thanks for the starting help! I'm evaluating a switch from SVN -> git/hg/bzr, and right now, bzr is back in the race ;) [13:13] one thing that makes bzr a big contender in that regard - for commands that apply, `svn blah` almost always maps directly to `bzr blah` [13:13] igc: ah, right [13:13] Anteru: cool :-) [13:14] ciao === jblount_ is now known as jblount [14:04] jam: ping === SamB_XP_ is now known as SamB_XP [14:40] jelmer: ping [14:42] lifeless: ping [14:55] jam: ping [14:57] night all [14:57] hi vila [14:58] wow, Ian, still up ? [14:58] vila: we should catch up soon - I'm heading to bed now [14:58] vila: just packaging up explorer 0.8.3 in time for the 2.0.1 release [14:58] night [14:58] k [15:08] * fullermd sneaks up behind vila and ties his shoelaces together. [15:08] 8-) [15:30] vila: pong [15:31] jam: I'm not sure if this is related to bug #449776, but babune failed hard [15:31] Launchpad bug 449776 in bzr "_simple_set_pyx is incompatible with Pyrex <0.9.6.3" [Undecided,New] https://launchpad.net/bugs/449776 [15:31] and it's clearly related to not being able to run without extensions [15:32] jam: so frebsd7. freebsd8. tiger and leopard all failed [15:32] jam: can you have a look and tell me ? [15:33] jam: search for the last midnight run on babune, I'm running on specific branches since [15:33] I'd hope not. pyrex is way newer than that on BSD... [15:33] and not installed on my OSX slaves, so :) [15:34] vila: It is giving me times in "CEST", should I look for 00:00 ? [15:34] jam: yes [15:34] jam: build36 for freebsd7 [15:35] yeah, looking now [15:35] ok [15:35] self.assertIs(k1, obj.add(k2)) AssertionError: ('foo',) is not ('foo',). [15:35] that is a bit strange [15:36] it hints that the hashing may be putting objects in different locations [15:36] I know I had a bug there, but I had fixed it before submitting. [15:36] jam: looks like you have another then :) [15:37] vila: are any of the others failing? [15:37] note that I'm planning on cutting 2.1.0b1 from before those patches for now [15:37] jam: hardy, jaunty and karmic are ok [15:37] since if I can't land everything, it isn't worth releasing part of it [15:37] jam: gentoo too [15:38] vila: is this a 32/64 bit issue? [15:38] it shouldn't, karmic is a 64bits slave while hardy is a 32bits one [15:38] k, and do you know the versions of python there ? [15:38] and jaunty is 64 bits too [15:39] freebsd7 is 2.5.4, errr, you have a selftest output, everything is mentioned there :) [15:40] bzr-2.1.0dev python-2.5.4 FreeBSD-7.2-RELEASE-amd64-64bit-ELF [15:40] mthaddon: ping (are you the LOSA online right now?) [15:41] jam: yep (but we all highlight on losa, so you can just ping losa) [15:41] mthaddon: ah, good. I always have trouble tracking you guys down :) [15:41] I need to cut 2 new branches for pqm [15:41] can you help me? [15:42] jam: I can do, but it'd be ideal if you could put it all in an RT request [15:42] mthaddon: I can, though the rt system honestly confuses me quite a bit [15:42] I'm never really sure what I need to put into the request [15:42] and "RT" isn't a great search term on the canonical wiki [15:57] vila: do you have access to the freebsd machine, that I could try testing directly? [15:57] The test suite passes for me on python2.5.2 on Jaunty [15:58] also, do you know why tiger and leopard are failing the test suite? [15:58] well, failing to build [15:59] jam: not really, I think the MIN MAX are warnings only, the 'lipo: can't figure out the architecture type of: /var/tmp//cczgHHiH.out' is a bit puzzling [16:01] so, warning "MIN" redefined is code I didn't touch., and as you say it is only a warning [16:01] bzrlib/_static_tuple_c.c:32:33: error: bzrlib/_static_tuple_c.c:32:33:_simple_set_pyx_api.h: No such file or directory [16:01] That fails because we need to compile _simple_set_pyx.pyx first [16:01] as it auto-generates the api.h file [16:02] and since you don't have pyrex... [16:03] ..which is a conf we want to support [16:03] ..no pyrex, no C files [16:03] until we version the C files [16:03] *I* don't care to support people building *from source* who don't have pyrex/cython [16:03] ...which we won't do in the coming minutes as you and I know damn well :) [16:04] Tarball is a little bit different [16:04] though again, if you are building from scratch, install dev tools [16:04] we require gcc [16:04] hmm [16:05] yeah right, this predates babune running explicitly without extensions, so indeed I should install pyrex there [16:05] pyrex used to be a lot more rare... [16:05] AIUI I should be able to easy_install it.... [16:06] let's check that myth... [16:06] I believe so [16:12] pffff, easy_install is for 2.5 not 2.6.... how do I install it for 2.6... [16:15] vila: I use easy_install here w/ py2.6 [16:16] though there is a huge discussion on python-dev about how setuptools is not properly maintained, you should use "Distribute", etc. [16:16] jam: it's a distro problem, OSX came with 2.5 and easy_install, I needed 2.6 and installed it from python.org, but no easy-install there :-/ [16:16] vila: http://pypi.python.org/pypi/setuptools#cygwin-mac-os-x-linux-other [16:16] http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c9-py2.6.egg#md5=ca37b1ff16fa2ede6e19383e7b59245a [16:35] jopong === EdwinGrubbs is now known as Edwin-afk === beuno is now known as beuno-lunch [17:49] vila: https://code.edge.launchpad.net/~jameinel/bzr/2.1-pyrex-64bit/+merge/13292 [17:49] should fix your freebsd issues [18:08] mthaddon: any progress on creating the pqm branches? [18:08] jam: I'm afraid I've been tied up with other things all day and am close to EOD - I should be able to get to it tomorrow if another losa hasn't by then [18:10] k === AnMaster_ is now known as AnMaster === beuno-lunch is now known as beuno === AnMaster- is now known as AnMaster === mnepton is now known as mneptok [20:21] How can I get bzr-svn to not use the svn 1.4 client I have also installed? [20:22] davidstrauss: make sure subvertpy is linked against the right vcersion of subversion [20:22] jelmer: how can i do that? [20:23] davidstrauss: when building subvertpy, make sure that it finds the deveopment files for the version of subversion you'd like to use [20:23] you can override the svn prefix with the SVN_PREFIX environment variable [20:23] jelmer: I'm not building it. I'm just using the Bazaar DMG installer [20:24] davidstrauss: doesn't that come with its own copy of the svn libs then? [20:24] jelmer: not sure [20:24] jelmer: but it keeps complaining about needing a newer svn to use my working copies [20:24] jelmer: I'm using svn 1.6 for my own work [20:24] davidstrauss: I suspect you're out of luck in that case, I think a ndewer version of svn would have to be included in the DMG [20:33] moinish [20:39] . o 0 ( fullermd and his jokes...) [20:45] Jokes? Hm, I'm fresh out today. Maybe there's one in the pantry somewhere... [20:47] You tied my shoelaces earlier and when I stood up... all my PCs crashed (gee, even my macs.... [20:48] ... in fact the whole block suffered a power outage.... [20:48] Crap, you mean I missed the next block over? [20:48] I'll try harder next time, I swear. [20:48] ...so thank you very much all the same [20:49] it took nearly an hour to get out of the power outage (ok 45 minutes, 4-5 m-i-n-u-t-e-s ! 2009 ! [20:49] :D [20:49] http://www.absurdnotions.org/page18.html :p [20:49] add to that nearly an hour more to get an internet back [20:50] hey vila, /wave [20:50] url ? you think I can already use url ? All I have right now is a poor emacs irc client running on borrowed wifi (thank neighbour !) [20:50] ha jam ! [20:50] ouch [20:51] jam: Were you still connected ? [20:51] Wait, you can use emacs? I figure with your shoes tied together, you didn't have enough appendages available to use it... [20:51] I went offline for the last... 30 min or so [20:51] * jam went to the coffee house [20:52] jam: I crashed exactly 3 hours ago [20:52] I saw your client go offline [20:52] and 3 mintes [20:52] jam: that was it, no more power [20:53] jam: I won't restart the full monty until tomorrow, did you have anything important or was everything in your submission already ? [20:53] vila: how big of an outage? (house/street/block/city)? [20:53] block [20:53] vila: I think everything is submitted [20:53] no worries about babune et al [20:54] jam: good, I won't be able to review it tonight either so if you need it for some release, nag the aussies :) [20:54] no, I'm not releasing that code [20:54] good [20:54] I want it to bake in bzr.dev for most of a cycle [20:55] so I can (untie my shoelaces first) enjoy my evening ;-) [20:55] though I won't be releasing until a losa responds to my rt request for new branches anyway [20:55] vila: absolutely [21:06] is there any good reason why "bzr explorer" does NOT open a view of the branch you started it in? [21:13] zsquareplusc: 'bzr explorer .' [21:14] igc knows why, my guess is that you have the option by specifying '.', that if you don't specify it, it is assumed maybe you want the generic start [21:16] igc: Okay, I fixed that typo. Do I resend merge request or do I resend review request? [21:16] heh, i'd make an option for the generic start as i don't care --how-long-an-option-is-when-i-click-a-link. but ok, good to know about "." [21:16] mathepic: just reply to the thread saying its fixed [21:18] Okay, thanks. [21:28] I accidently sent that second review request on my merge, can someone approve that? [21:57] hey folks. i was wondering if someone could point me to simple (one app install) for bzr explorer or another good mac gui [22:01] mfer: I've enjoyed bzr-gtk, but I don't know whether it works on a mac. [22:02] mfer: it is 'being worked on'. PyQt is a major dependency on the Mac, because there isn't a pre-built version [22:02] I'm not sure on the current state, but the 'bzr-mac' mailing list talks about getting one built [22:03] jam: PyQT is a huge pain of a dependancy [22:03] jam: thanks, i'll check out the mac list [22:03] Any idea how to merge revisions from a git repo? Someone imported my head revision then made several changes, and I'd like to merge it without manually replaying each revision. [22:04] bzr-mac@lists.launchpad.net [22:04] I think it is a launchpad group [22:04] https://edge.launchpad.net/~bzr-mac [22:04] bzr-git can browse and convert the repo, but I haven't had any luck merging. [22:06] 'bzr merge' by itself bails due to having no common ancestor, which makes sense. [22:07] 'bzr merge -r 1.. ../git-branch' does nothing and claims "All changes applied successfully." [22:07] 'bzr merge -c 2 ../git-branch' fails with a conflict (even though the patch applies cleanly). [22:08] ToyKeeper, why do you need to specify a revision? [22:08] This works, except for losing timestams, commit messages, and other metadata: bzr diff -c 2 ../git-branch | patch [22:09] beuno: I'm specifying a revision because 'merge' by itself can't find a common ancestor. [22:09] I'd like to tell it "local rev 123 equals remote rev 1" somehow, then merge normally. [22:09] ToyKeeper, ahd, I *think* you can force it to merge with -r -1 [22:10] or -r 0, I can't remember [22:10] beuno: -r 0..-1, but he at least thought he was doing that [22:11] ToyKeeper: you tried "bzr merge -r 1..-1" ? [22:11] jam: seems the mac ui isn't going to come soon from the main lists. Most are interested in bzr explorer for mac which is a pain to install with the 140MB/3 dependencies you have to install first. and, the mac ui is only slowly being developed. [22:11] that *might* be equivalent to -r 1.. [22:12] jam: Similar result as '-c'; it thinks there's a conflict. [22:13] ToyKeeper: are you sure there isn't a conflict? [22:14] The resulting commit is basically the same as if I had just rsync'd the content; no metadata or record of any intermediate revisions. [22:14] ToyKeeper: so if you did '-r 0..' then it would record a merge [22:14] If merge can't find a common ancestor itself, you're probably going to end up with a bit of a mess... [22:14] but by doing a named rage [22:14] range [22:14] There isn't a conflict. Everything applies cleanly if I "diff | patch" each rev. [22:14] then we are considering that to be a cherrypick [22:14] * ToyKeeper tries again from 0 [22:14] ToyKeeper: diff + patch a series of patches can still conflict on the endpoints... [22:15] but I won't say it has to here [22:15] you might try just merging and rejecting the first revision, to create a common ancestor [22:15] and then applying from there [22:15] (bzr merge -r 0..1; bzr revert .; bzr commit -m 'sync at the first rev') [22:15] then again [22:15] my guess is you are getting conflicts because of file-id differences [22:16] but I can't guarantee that === AnMaster_ is now known as AnMaster [22:21]