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