jamlifeless 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:47
jamI'm going to be in and out a bit00:48
jam(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
jamI'd like to work on the releases tomorrow, though00:48
mathepicI'm doing an update on the format docs00:52
mathepicWhat should I change this to:  For example,00:52
mathepicyou may need to select 1.9 instead of 1.14 if your project has00:52
mathepicstandardized on Bazaar 1.13.1 say.00:52
mathepicIs 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
mathepicI'm going to delete the say, it doesn't fit in.00:55
maxbDoesn't 1.18 support 2a? (with efficiency caveats)01:01
mathepicWhen was the version before 2a was released01:03
mathepicI'll fix that really quickly01:03
mathepicDo I mark myself as the assignee and the status of the bug "Fix Commited"01:07
mathepicI'm not sure how the bug-process works01:07
mathepicShould I change the status to "In Progress", "Fix Committed", or just leave in the way it is?01:11
lifelessjam: I can't anymore01:33
lifelessjam: and spm is sick today01:33
lifelessjam: you should mail RT01:33
lifeless1.16 and above support 2a01:33
igcmathepic: thanks for working on that bug01:36
mathepicigc: No problem.01:36
mathepicCan anyone confirm that the info contained in it is correct? I don't know my history that well.01:37
igcmathepic: while working on a bug, mark it "In Progress"; once you've pushed a branch with the fix, mark as "Fix Committed"01:37
mathepicigc: Okay, thanks.01:37
igcmathepic: I'd drop all the text about selecting a format prior to 2a. We need to *strongly* encourage everyone to upgrade01:38
igcmathepic: as lifeless mentioned, 1.16 and above support 2a01:39
mathepicshould I keep the paragraph about the rich-roots?01:39
igcyou can mention rich-root in a footnote but not the main text IMO01:40
igcit tends to confuse more than enlighten01:40
igcmost readers01:40
igcand after 2a, the issue effectively goes away because all future formats are rich-root implicitly01:41
igc(as is 2a)01:41
=== mnepton is now known as mneptok
mathepicHow 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
mathepic(That replaces the whole list thing)01:42
mathepicOr simply nothing at all?01:43
mathepicI'll just remove that whole block of text.01:45
igcmathepic: "does not support" -> "is not using"01:46
mathepicOkay, added it back. "Branch owner" or "Project owner"?01:47
igcproject owner01:47
mathepicOkay, I'm pushing it to my branch.01:48
igccool. Then propose it for merging please01:49
mathepicIts been proposed.01:50
igcah - then you may need to resubmit the proposal01:50
mathepicI sent another review request to bzr-core. Is that what you mean?01:51
igcyep. Thanks.01:52
mathepicUgh, spotted a type01:57
mathepicigc: I pushed it again to fix a typo. Do I send a review request again?01:58
igcmathepic: hmm - forget what I said about requesting another review02:00
mathepicigc: Okay.02:00
igcyou need to click "resubmit proposal"02:00
igctop right hand corner02:00
mathepicOkay, done.02:01
mathepicWell, I have to go.02:01
igcmathepic: thanks for your work!02:01
mathepicNo problem. :)02:01
lifelessshouldn't need the resubmit anymore02:01
lifelessthe diffs update02:01
igclifeless: ah - ok02:01
igclifeless: hi btw - welcome back to Oz02:02
igclifeless: I hope the sprint when well02:02
jamlifeless: 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 build02:40
jamso I sent in a patch to make it build on 2.4, but the previous patch had been accepted.02:40
lifelessjam: rt that too :)02:41
lifelessjam: the chroot has been upgraded, probably the default python has been altered02:41
jamlifeless: is the fix just configuring pqm to do "make check PYTHON=python2.4" ?02:41
lifelessforce the version in the pqm config02:42
* igc lunch03:36
=== abentley1 is now known as abentley
eferraiuoloI was curious why a Loggerhead Package for Hardy was never released?06:55
vilahi all07:19
bialixhello all07:28
trondnis there an equivalent of the hg export / import functionality in bzr???07:44
trondn(export a changeset that I may import into another workspace)07:45
spivthumper: there's 'bzr send'07:47
thumperspiv: tab fail07:47
spivthumper: er, sorry, wrong nick :)07:47
mneptoktab-complte FAIL07:47
thumpermneptok: hey07:48
spivtrondn: There's "bzr send"07:48
mneptokthumper: ahoyhoy!07:48
trondnspiv:  and to apply it into the other one (and preserve commit id etc)?07:48
spivtrondn: bzr pull or bzr merge from the file, like you would with the branch.07:49
trondnspiv but that will make it a merge set??07:49
spivIf you use 'bzr merge', yes.  But you can 'bzr pull' if you don't want to merge (assuming the history hasn't diverged).07:50
trondnhmm...  bzr send -r -2 -o /tmp/foobar resulted in: Bundling 0 revision(s) ...07:53
mneptok"bzr oh_god_i_killed_us_all" should undo the previous push. kthx.07:53
spivmneptok: bzr alias oh_god_i_killed_us_all="push -r -2 --overwrite"  ;)07:54
mneptokspiv: but then i can't tell others about bzr's intuitive, natural language feature set07:55
spivtrondn: 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:56
spivtrondn: which is a bit annoying when you don't have the branch accessible :/07:57
trondnspiv 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:58
trondnguess I should just try out the rebase thing.. that's the thing I really want to do...07:59
trondn(I just heard that it might not work the way I expected it to work ;-) )07:59
spivtrondn: oh, if you have the target available, just "bzr send /url/to/target -o somefile"07:59
spivtrondn: 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:00
spivrebase 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
trondn:( they have diverged so it tells me to merge :(08:02
trondnthe goal: put my changeset at the _end_...08:02
trondnand don't fuck up the history with another merge set..08:02
spivWhy is merging so terrible for you?08:02
trondnit makes the history unreadable...08:03
trondnI'm working on implementing a feature committing multiple times... but I still want to bring in the work happening on trunk...08:03
spivHmm, I don't find that.  "bzr log" by default only shows the mainline commits.08:03
trondnand I want my changes to appear at the end in one bulk instead of a spagetti with the "merge from trunk"..08:04
trondnwith 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
spivSo, 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
spivThere is a rebase plugin.08:05
spivBut I suggest you play a little bit with "bzr log" and its options, you might be surprised.08:06
spiv<https://launchpad.net/bzr-rebase> is the rebase plugin btw, in case you don't already have it.08:07
trondnI 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
trondn(downloading and installing now)08:07
spivNormally 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.)08:09
=== smartgpx is now known as Guest45035
=== smartgpx_ is now known as smartgpx
=== doko__ is now known as doko
crisbwhen I use bzr qlog it chops off the first digit of the revision number - anyone else seen this before!?09:09
crisbalso, shouldnt qcommit be a resizeable dialog?09:13
crisbi swear it used to be...09:13
davidstrausscrisb: It is resizable. Change your monitor resolution.09:21
crisbdavidstrauss: i'm at 1650x1080!  its not that it appears maximised, it just wont let me resize it or maximiseit09:22
davidstrausscrisb: No, I mean reducing your monitor resolution will make the window bigger. :-)09:23
crisbso its not supposed to be resizeable in the same way as say qlog?09:24
* davidstrauss actually has no idea.09:24
crisbsorted - dodgy qbzr.conf :)09:28
crisbrevision number chopping still exists though :(09:30
=== Adys_ is now known as Adys
* igc dinner09:37
igccrisb: I'm seeing the first digit being chopped too in qlog if the re count is > 100010:32
igccrisb: can you raise a bug for that please?10:32
crisbigc: sure, I already raised 450179 - looks like Alexander Belchenko has confirmed it too10:33
igccrisb: ah - I see you already have - thanks10:33
bialixis it possible to quickly/cheaply determines how many revisions in the repository? not in the mainline revisions, but in repository overall?10:41
bialixcrisb: there si hardcode limit for 4 digits in qlog10:41
bialixcrisb: there is hardcode limit for 4 digits in qlog10:41
crisbbialix: yes, I noticed that in logwidget.py - but changing it to more than 4 digits didnt help10:42
bialixthere is custom painting code10:44
bialixwithout looking into code I'd say there is several places which require to be fixed10:44
AnteruI'm importing a svn repo into bzr, with 2324 revisions, but bzr says copying revision x/2304 -- is this normal?12:06
jelmerAnteru: yeah, that could be correct12:11
jelmerAnteru: bazaar only imports branches, and some commits in svn might have been outside of actual branches12:11
Anteruerr, I'm trying to import _the whole repo_12:11
jelmerAnteru: if you create a "branches" directory in svn that wouldn't show up in bazaar anywhere12:12
Anteruwith /branches, /tags, /trunk12:12
Anteruhm ok12:12
AnteruI previously tried git, where you have to specify the layout12:12
Anteruand git imports everything, including branches from svn12:12
jelmerAnteru: Git doesn't import these commits either afaik12:13
jelmerAnteru: e.g. if you add a file called README in /, which branch would you expect it to end up in?12:13
=== mrevell is now known as mrevell-lunch
Anteruwell, I would expect an error12:15
Anterubtw what are the parameters for the repository layout?12:16
Anteruit says "Using repository layout: trunk0"12:17
jelmerAnteru: yeah, that means the standard /trunk, /branches, /tags layout12:17
Anteruand looking at the doc page, it lists none, trunk,, and default: auto12:17
AnteruOk, I'm halfway through, but I still don't get why revisions are missing12:18
AnteruI had one branch or so in the past in /branches/, which has been deleted12:18
AnteruI simply don't want to loose history12:20
jelmerAnteru: are you using --keep ?12:21
Anterunope, will try12:21
jelmerand --all?12:21
Anteruwhy would I use keep when I use all?12:22
AnteruI just want the whole history12:22
Anteruthat is, being able to restore anything which was stored in the SVN (d'uh, missed --all)12:22
Anteruah ok, looks good12:34
jelmersorry, was aaway12:37
jelmerAnteru: np, glad it worked12:38
Anterujust double-checking, with --all, it says copying revisions x/231412:39
Anterudu, which is still 10 too few :/12:40
Anterueven with --keep --all12:40
AnteruI guess tags are skipped?12:41
Anteruah damn, the folder /branches was called /branch some time back in ancient history12:45
jelmerAnteru: it should follow that12:46
jelmerAnteru: tags are not versioned in bazaar, so they wouldn't count as revisions12:46
Anteruok I got 8 tags12:46
Anteruso 2 revisions ... one might be the /branch -> /branches rename12:47
Anteruand one might be the initial commit12:47
jelmerigc: Does fastexport/fastimport follow renames?12:49
jelmer(looking at the samba import)12:49
=== mrevell-lunch is now known as mrevell
AnteruI guess even if there is something missing, it can't be a lot12:52
igchi jelmer12:54
igcjelmer: yes it does, though I think one needs to explicitly ask git-fast-export to detect them12:54
igcand export them12:55
igc(and I didn't do that)12:55
jelmerigc: that might explain the big repo size12:55
igcnot that we've implemented copy support yet12:56
jelmerigc: copy support would help too I suppose12:58
jelmerigc: samba trunk has two top-level directories that have a lot of code in common12:58
Anteruw00t, just managed to work with a SVN repo from bzr12:59
Anteruthough the "push" speed is kinda slow13:00
jelmerAnteru: it should be faster the second time around13:00
jelmerAnteru: the first time it has to update caches, etc13:01
igcjelmer: fyi, I changed the file-id algorithm and the repo size dropped from 500M+ to 350M.13:01
igcjelmer: jam gave me the tip to do that13:01
jelmerigc: wow, I wouldn't expect it to matter that much13:01
igcjelmer: I was generating file-ids using the full-path - now I just use the basename13:01
igcjelerm: scary ah - one line change having that sort of impact!13:02
jelmerigc: Yeah, indeed13:02
jelmerI should remember to do a similar thing next time I update the mappings for bzr-{git,hg}13:03
Anterujelmer: I tried twice, it says something about finding tags each time13:04
jelmerAnteru: what version of bzr-svn are you using?13:04
igcjelmer: 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
Anterujelmer: bzrlib 2.0.0, python 2.5.4 (latest stable installer for windows)13:04
jelmerigc: should be fairly easy13:06
igcjelmer: it would be sweet if you could take a look - bug 273361 is driving me nuts13:06
ubottuLaunchpad bug 273361 in bzr-fastimport "svn-fast-export.py crashes with too many open files" [High,Confirmed] https://launchpad.net/bugs/27336113:07
* jelmer has a look13:07
igcjelmer: the all-but-identical C implementation works fine13:07
igcjelmer: so I suspect the bindings13:07
igcjelmer: and furthermore, using the same bindings you are makes it easier for Windows users because they don't need to install extra pieces IIUIC13:08
Anterujelmer: 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:10
Takone 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
jelmerigc: ah, right13:13
jelmerAnteru: cool :-)13:13
=== jblount_ is now known as jblount
vilajam: ping14:04
=== SamB_XP_ is now known as SamB_XP
johnfjelmer: ping14:40
johnflifeless: ping14:42
vilajam: ping14:55
igcnight all14:57
igchi vila14:57
vilawow, Ian, still up ?14:58
igcvila: we should catch up soon - I'm heading to bed now14:58
igcvila: just packaging up explorer 0.8.3 in time for the 2.0.1 release14:58
* fullermd sneaks up behind vila and ties his shoelaces together.15:08
jamvila: pong15:30
vilajam: I'm not sure if this is related to bug #449776, but babune failed hard15:31
ubottuLaunchpad bug 449776 in bzr "_simple_set_pyx is incompatible with Pyrex <" [Undecided,New] https://launchpad.net/bugs/44977615:31
vilaand it's clearly related to not being able to run without extensions15:31
vilajam: so frebsd7. freebsd8. tiger and leopard all failed15:32
vilajam: can you have a look and tell me ?15:32
vilajam: search for the last midnight run on babune, I'm running on specific branches since15:33
fullermdI'd hope not.  pyrex is way newer than that on BSD...15:33
vilaand not installed on my OSX slaves, so :)15:33
jamvila: It is giving me times in "CEST", should I look for 00:00 ?15:34
vilajam: yes15:34
vilajam: build36 for freebsd715:34
jamyeah, looking now15:35
jam    self.assertIs(k1, obj.add(k2)) AssertionError: ('foo',) is not ('foo',).15:35
jamthat is a bit strange15:35
jamit hints that the hashing may be putting objects in different locations15:36
jamI know I had a bug there, but I had fixed it before submitting.15:36
vilajam: looks like you have another then :)15:36
jamvila: are any of the others failing?15:37
jamnote that I'm planning on cutting 2.1.0b1 from before those patches for now15:37
vilajam: hardy, jaunty and karmic are ok15:37
jamsince if I can't land everything, it isn't worth releasing part of it15:37
vilajam: gentoo too15:37
jamvila: is this a 32/64 bit issue?15:38
vilait shouldn't, karmic is a 64bits slave while hardy is a 32bits one15:38
jamk, and do you know the versions of python there ?15:38
vilaand jaunty is 64 bits too15:38
vilafreebsd7 is 2.5.4, errr, you have a selftest output, everything is mentioned there :)15:39
vila   bzr-2.1.0dev python-2.5.4 FreeBSD-7.2-RELEASE-amd64-64bit-ELF15:40
jammthaddon: ping (are you the LOSA online right now?)15:40
mthaddonjam: yep (but we all highlight on losa, so you can just ping losa)15:41
jammthaddon: ah, good. I always have trouble tracking you guys down :)15:41
jamI need to cut 2 new branches for pqm15:41
jamcan you help me?15:41
mthaddonjam: I can do, but it'd be ideal if you could put it all in an RT request15:42
jammthaddon: I can, though the rt system honestly confuses me quite a bit15:42
jamI'm never really sure what I need to put into the request15:42
jamand "RT" isn't a great search term on the canonical wiki15:42
jamvila: do you have access to the freebsd machine, that I could try testing directly?15:57
jamThe test suite passes for me on python2.5.2 on Jaunty15:57
jamalso, do you know why tiger and leopard are failing the test suite?15:58
jamwell, failing to build15:58
vilajam: 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 puzzling15:59
jamso, warning "MIN" redefined is code I didn't touch., and as you say it is only a warning16:01
jambzrlib/_static_tuple_c.c:32:33: error: bzrlib/_static_tuple_c.c:32:33:_simple_set_pyx_api.h: No such file or directory16:01
jamThat fails because we need to compile _simple_set_pyx.pyx first16:01
jamas it auto-generates the api.h file16:01
jamand since you don't have pyrex...16:02
vila..which is a conf we want to support16:03
vila..no pyrex, no C files16:03
vilauntil we version the C files16:03
jam*I* don't care to support people building *from source* who don't have pyrex/cython16:03
vila...which we won't do in the coming minutes as you and I know damn well :)16:03
jamTarball is a little bit different16:04
jamthough again, if you are building from scratch, install dev tools16:04
jamwe require gcc16:04
vilayeah right, this predates babune running explicitly without extensions, so indeed I should install pyrex there16:05
jampyrex used to be a lot more rare...16:05
vilaAIUI I should be able to easy_install it....16:05
vilalet's check that myth...16:06
jamI believe so16:06
vilapffff, easy_install is for 2.5 not 2.6.... how do I install it for 2.6...16:12
jamvila: I use easy_install here w/ py2.616:15
jamthough there is a huge discussion on python-dev about how setuptools is not properly maintained, you should use "Distribute", etc.16:16
vilajam: 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
jamvila: http://pypi.python.org/pypi/setuptools#cygwin-mac-os-x-linux-other16:16
=== EdwinGrubbs is now known as Edwin-afk
=== beuno is now known as beuno-lunch
jamvila: https://code.edge.launchpad.net/~jameinel/bzr/2.1-pyrex-64bit/+merge/1329217:49
jamshould fix your freebsd issues17:49
jammthaddon: any progress on creating the pqm branches?18:08
mthaddonjam: 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 then18:08
=== 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
davidstraussHow can I get bzr-svn to not use the svn 1.4 client I have also installed?20:21
jelmerdavidstrauss: make sure subvertpy is linked against the right vcersion of subversion20:22
davidstraussjelmer: how can i do that?20:22
jelmerdavidstrauss: when building subvertpy, make sure that it finds the deveopment files for the version of subversion you'd like to use20:23
jelmeryou can override the svn prefix with the SVN_PREFIX environment variable20:23
davidstraussjelmer: I'm not building it. I'm just using the Bazaar DMG installer20:23
jelmerdavidstrauss: doesn't that come with its own copy of the svn libs then?20:24
davidstraussjelmer: not sure20:24
davidstraussjelmer: but it keeps complaining about needing a newer svn to use my working copies20:24
davidstraussjelmer: I'm using svn 1.6 for my own work20:24
jelmerdavidstrauss: I suspect you're out of luck in that case, I think a ndewer version of svn would have to be included in the DMG20:24
vila. o 0 ( fullermd and his jokes...)20:39
fullermdJokes?  Hm, I'm fresh out today.  Maybe there's one in the pantry somewhere...20:45
vilaYou tied my shoelaces earlier and when I stood up... all my PCs crashed (gee, even my macs....20:47
vila... in fact the whole block suffered a power outage....20:48
fullermdCrap, you mean I missed the next block over?20:48
fullermdI'll try harder next time, I swear.20:48
vila...so thank you very much all the same20:48
vilait 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
fullermdhttp://www.absurdnotions.org/page18.html    :p20:49
vilaadd to that nearly an hour more to get an internet back20:49
jamhey vila, /wave20:50
vilaurl ? 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
vilaha jam !20:50
vilajam: Were you still connected ?20:51
fullermdWait, you can use emacs?  I figure with your shoes tied together, you didn't have enough appendages available to use it...20:51
jamI went offline for the last... 30 min or so20:51
* jam went to the coffee house20:51
vilajam: I crashed exactly 3 hours ago20:52
jamI saw your client go offline20:52
vilaand 3 mintes20:52
vilajam: that was it, no more power20:52
vilajam: I won't restart the full monty until tomorrow, did you have anything important or was everything in your submission already ?20:53
jamvila: how big of an outage? (house/street/block/city)?20:53
jamvila: I think everything is submitted20:53
jamno worries about babune et al20:53
vilajam: good, I won't be able to review it tonight either so if you need it for some release, nag the aussies :)20:54
jamno, I'm not releasing that code20:54
jamI want it to bake in bzr.dev for most of a cycle20:54
vilaso I can (untie my shoelaces first) enjoy my evening ;-)20:55
jamthough I won't be releasing until a losa responds to my rt request for new branches anyway20:55
jamvila: absolutely20:55
zsquarepluscis there any good reason why "bzr explorer" does NOT open a view of the branch you started it in?21:06
jamzsquareplusc: 'bzr explorer .'21:13
jamigc 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 start21:14
mathepicigc: Okay, I fixed that typo. Do I resend merge request or do I resend review request?21:16
zsquarepluscheh, 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
lifelessmathepic: just reply to the thread saying its fixed21:16
mathepicOkay, thanks.21:18
mathepicI accidently sent that second review request on my merge, can someone approve that?21:28
mferhey folks. i was wondering if someone could point me to simple (one app install) for bzr explorer or another good mac gui21:57
ToyKeepermfer: I've enjoyed bzr-gtk, but I don't know whether it works on a mac.22:01
jammfer: it is 'being worked on'. PyQt is a major dependency on the Mac, because there isn't a pre-built version22:02
jamI'm not sure on the current state, but the 'bzr-mac' mailing list talks about getting one built22:02
mferjam: PyQT is a huge pain of a dependancy22:03
mferjam: thanks, i'll check out the mac list22:03
ToyKeeperAny 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:03
jamI think it is a launchpad group22:04
ToyKeeperbzr-git can browse and convert the repo, but I haven't had any luck merging.22:04
ToyKeeper'bzr merge' by itself bails due to having no common ancestor, which makes sense.22:06
ToyKeeper'bzr merge -r 1.. ../git-branch' does nothing and claims "All changes applied successfully."22:07
ToyKeeper'bzr merge -c 2 ../git-branch' fails with a conflict (even though the patch applies cleanly).22:07
beunoToyKeeper, why do you need to specify a revision?22:08
ToyKeeperThis works, except for losing timestams, commit messages, and other metadata:  bzr diff -c 2 ../git-branch | patch22:08
ToyKeeperbeuno: I'm specifying a revision because 'merge' by itself can't find a common ancestor.22:09
ToyKeeperI'd like to tell it "local rev 123 equals remote rev 1" somehow, then merge normally.22:09
beunoToyKeeper, ahd, I *think* you can force it to merge with -r -122:09
beunoor -r 0, I can't remember22:10
jambeuno: -r 0..-1, but he at least thought he was doing that22:10
jamToyKeeper: you tried "bzr merge -r 1..-1" ?22:11
mferjam: 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
jamthat *might* be equivalent to -r 1..22:11
ToyKeeperjam: Similar result as '-c'; it thinks there's a conflict.22:12
jamToyKeeper: are you sure there isn't a conflict?22:13
ToyKeeperThe 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
jamToyKeeper: so if you did '-r 0..' then it would record a merge22:14
fullermdIf merge can't find a common ancestor itself, you're probably going to end up with a bit of a mess...22:14
jambut by doing a named rage22:14
ToyKeeperThere isn't a conflict.  Everything applies cleanly if I "diff | patch" each rev.22:14
jamthen we are considering that to be a cherrypick22:14
* ToyKeeper tries again from 022:14
jamToyKeeper: diff + patch a series of patches can still conflict on the endpoints...22:14
jambut I won't say it has to here22:15
jamyou might try just merging and rejecting the first revision, to create a common ancestor22:15
jamand then applying from there22:15
jam(bzr merge -r 0..1; bzr revert .; bzr commit -m 'sync at the first rev')22:15
jamthen again22:15
jammy guess is you are getting conflicts because of file-id differences22:15
jambut I can't guarantee that22:16
=== AnMaster_ is now known as AnMaster
ToyKeeperjam: The last approach worked: merge -r 0..1 ; revert ; commit ; merge22:21
ToyKeeperI don't think I would have tried that.22:22
ToyKeeperOther than that bit of weirdness with merging, the git support works impressively well.  :)22:28
ToyKeeperD'oh.  "different rich-root support" made my coworker give up and go back to git.  :(22:48
ToyKeeperPerhaps I'll wait until most people have bzr 2 before trying again.22:50
fullermdYou can use rich-root-pack on anything newer than 1.0.22:51
ToyKeeperfullermd: Yes, it just didn't happen that way and I think the guy was looking for an excuse to stop using bzr.  I guess I can't expect much else from kernel devs.23:38
lifelessthe rich root transition hurts23:56

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!