| jml | hey guys. | 00:01 |
|---|---|---|
| * beuno waves at jml | 00:02 | |
| jml | I'm just catching up on some older email and came across Soren's post to the ml about bug 227340 | 00:02 |
| ubottu | Launchpad bug 227340 in bzr "Simple way to prepare patches for submission" [Undecided,New] https://launchpad.net/bugs/227340 | 00:02 |
| james_w | hi jml | 00:02 |
| james_w | jml: you got my email ok? (I'm not after a response to it, I just want to check you got it) | 00:03 |
| jml | james_w: yes I did, thanks for sending it. | 00:03 |
| james_w | no problem, thanks for reading it | 00:04 |
| * james_w hopes he at least got that far :-) | 00:04 | |
| jml | yeah I did. | 00:06 |
| jml | I'm a little behind in email, I've been buried hip deep in a thorny branch and have only just surfaced. | 00:07 |
| jml | (yay metaphor mixing!) | 00:07 |
| === kiko is now known as kiko-afk | ||
| === mw__ is now known as mw | ||
| fbond | Okay, I was here earlier about this: | 00:25 |
| fbond | bzr: ERROR: Must end write group before releasing write lock on KnitPackRepository('file:///home/forest/.bzr/repository/') | 00:25 |
| fbond | I have a log file, anyone care to look at it? | 00:25 |
| fbond | I use this branch many times a day, and never had this issue before. | 00:25 |
| fbond | This error was encountered while pulling over bzr+ssh | 00:25 |
| james_w | fbond: if you stick the log up then I can take a look. | 00:43 |
| fbond | http://pastebin.ubuntu.com/12337/ | 00:52 |
| fbond | james_w: thanks | 00:53 |
| james_w | fbond: ah, it's autopacking when it errors it seems, that would explain why it is happening on this pull in particular. | 00:56 |
| james_w | I'm not sure how to get more information at this point though. | 00:57 |
| fbond | james_w: If I manually pack, perhaps that will help? | 00:58 |
| fbond | james_w: I already tried reconcile. | 00:58 |
| james_w | fbond: yes, I think that will help, but it would only be temporary, and it would hide the problems. | 00:58 |
| james_w | can you save the branch (cp -a, not branch), then pack and try again? | 00:59 |
| james_w | it will allow you to work, but we can look deeper in to it when we have a better chance of getting the needed information. | 00:59 |
| fbond | james_w: Should I just cp -a the .bzr dir? | 00:59 |
| fbond | james_w: And what ought I do with the branch so that it can be looked at? | 01:00 |
| james_w | that should be enough | 01:00 |
| james_w | are you willing to just keep it around for a few days and then ping me? It's not a good week for me to debug it. | 01:01 |
| fbond | james_w: Okay, `bzr pack' fixed things WRT pull. | 01:01 |
| james_w | is it a public project? | 01:01 |
| fbond | james_w: No, it's actually my home directory :) | 01:01 |
| fbond | Going all the way back to November of 2006. | 01:01 |
| james_w | sure, if you're willing to keep it around then we can work out how to get the information we want. | 01:01 |
| fbond | james_w: Okay, perhaps a bug would be a good idea. | 01:02 |
| james_w | yeah, I think so, we can always close it :-) | 01:02 |
| james_w | it will probably break later, but "bzr pack" will save you most times. | 01:02 |
| fbond | james_w: So this is an error in the repository data? | 01:03 |
| james_w | I expect it's a logic problem in the code with exceptions or something | 01:04 |
| fbond | https://bugs.launchpad.net/bzr/+bug/230902 | 01:04 |
| ubottu | Launchpad bug 230902 in bzr "BzrError: Must end write group before releasing write lock on KnitPackRepository" [Undecided,New] | 01:04 |
| james_w | though the data could cause the exception and this is just masking it. | 01:04 |
| fbond | james_w: I push/pull this branch all over the place, and haven't seen this issue with any of the other branches out there. | 01:05 |
| fbond | james_w: Anyway, thanks for the help. Feel free to ping me for more info. | 01:06 |
| james_w | no problem, as I said it's not a good week, if I've not got back to you for a while please kick me. | 01:07 |
| james_w | though the bug will help with that. | 01:07 |
| fbond | That's what I figured. | 01:07 |
| Verterok | moin | 01:47 |
| beuno | is LP painfully slow for bzr or is it just me? | 02:15 |
| mwhudson | it shouldn't be particularly slow | 02:16 |
| mwhudson | (the machine seems quiet right now) | 02:17 |
| beuno | hrm, I can't do anything with bzr+ssh, but I'm able to branch/checkout with http | 02:17 |
| spiv | beuno: strange | 02:18 |
| spiv | beuno: which branch? | 02:18 |
| beuno | spiv, any branch | 02:18 |
| beuno | I've tried with lp:bzrtools and lp:bzr-xmloutput | 02:19 |
| beuno | they stall for ages downloading small amounts of bytes | 02:19 |
| beuno | everything else here works fone | 02:19 |
| beuno | *fine | 02:19 |
| mwhudson | beuno: getting new branches? | 02:19 |
| beuno | http is fast | 02:19 |
| beuno | mwhudson, seems like anything with ssh | 02:19 |
| mwhudson | you can always try bzr -Dhttps lp:// | 02:19 |
| mwhudson | see if it really is the server taking a long time to respond | 02:20 |
| spiv | I just grabbed lp:tribunal with no trouble. | 02:20 |
| beuno | mwhudson, branching through http works fine | 02:21 |
| beuno | bzr co http://bazaar.launchpad.net/%7Eabentley/bzrtools/bzrtools.dev/ | 02:21 |
| beuno | completed in a minute or so | 02:21 |
| mwhudson | beuno: yes, so the problem is why is ssh different? | 02:21 |
| spiv | And I just branched bzrtools over bzr+ssh in 42s | 02:21 |
| mwhudson | and it's interesting to know whether it's the smart server being dumb, the server being slow to respond | 02:22 |
| mwhudson | or something else entirely | 02:22 |
| spiv | beuno: could you try with -Dhpss, and paste bin the relevant .bzr.log please | 02:22 |
| beuno | spiv, sure, on it | 02:22 |
| spiv | Because it's certainly working just fine from here. | 02:22 |
| beuno | spiv, http://paste.ubuntu.com/12352/ | 02:24 |
| spiv | beuno: and it doesn't stall completely? The chunks still come through, just very slowly? | 02:25 |
| beuno | spiv, chunks, slowly | 02:25 |
| spiv | 19.111 1113 byte chunk read | 02:26 |
| spiv | 37.564 33346 byte chunk read | 02:26 |
| spiv | That snippet is weird. | 02:26 |
| spiv | It took less than a second for the corresponding transfer for me. | 02:27 |
| spiv | You're getting less than 2k per second. | 02:28 |
| beuno | spiv, it goes on: http://paste.ubuntu.com/12353/ | 02:28 |
| beuno | http is perfectly fine | 02:28 |
| spiv | What SSH client is it using? | 02:29 |
| spiv | (there should be a line like 2.456 ssh implementation is OpenSSH | 02:29 |
| spiv | ) | 02:29 |
| spiv | Could you try comparing with sftp://... rather than bzr+ssh://...? | 02:29 |
| beuno | spiv, yeap, OpenSSH, it's Ubuntu Hardy standard install | 02:29 |
| spiv | That's very odd. | 02:30 |
| spiv | Literally all that's happening in the server at that point is just writes bytes down the wire, as fast as it can. | 02:30 |
| spiv | I'm using OpenSSH and Ubuntu Hardy too. | 02:31 |
| spiv | So at this point I start to suspect weird voodoo like MTU strangeness. | 02:31 |
| beuno | spiv, branching with sftp now... | 02:34 |
| beuno | spiv, it's stuck at: http://paste.ubuntu.com/12356/ | 02:36 |
| spiv | Right, it's taking significantly longer than HTTP? | 02:37 |
| spiv | Ok, there's something funny going on with SSH connections for you. | 02:37 |
| beuno | spiv, yeap | 02:37 |
| beuno | ssh: connect to host code.launchpad.net port 22: Connection timed out | 02:37 |
| spiv | Oh, oops. | 02:37 |
| spiv | *bazaar*.launchpad.net | 02:37 |
| spiv | Not code.launchpad.net | 02:37 |
| beuno | right, bazaar.lp gave my a branch not found | 02:38 |
| spiv | Oh, right, dang. | 02:38 |
| spiv | sftp only gives you access to your own branches :( | 02:38 |
| beuno | let me do it with one of mine then | 02:38 |
| beuno | hm, it worked fairly well with sftp | 02:41 |
| beuno | let me try that smae branch with bzr+ssh | 02:41 |
| beuno | spiv, sftp is fine, bzr+ssh is painfully slow | 02:42 |
| spiv | beuno: that is bizarre. | 02:42 |
| spiv | Do you have access to bzr+ssh servers anywhere else? | 02:42 |
| beuno | spiv, this is the full log: http://paste.ubuntu.com/12357/ | 02:43 |
| beuno | spiv, yeah, I'll try it on a different server | 02:43 |
| spiv | beuno: thanks | 02:43 |
| spiv | beuno: I'd be mildly interested in a tcpdump of a bzr+ssh session too. | 02:45 |
| spiv | beuno: although I don't really expect it to help much. | 02:45 |
| beuno | damn ssh keys, I have to re-enable access to everywhere :( | 02:45 |
| beuno | spiv, other ssh work fine | 02:48 |
| spiv | beuno: wow | 02:49 |
| beuno | hmmm | 02:49 |
| beuno | the log output is similar though | 02:49 |
| beuno | 29.547 1107 byte chunk read | 02:50 |
| beuno | 37.620 41644 byte chunk read | 02:50 |
| beuno | 37.624 923 byte chunk read | 02:50 |
| beuno | 37.625 903 byte chunk read | 02:50 |
| beuno | it's not a massive improvement over LP | 02:50 |
| beuno | spiv, I'll try and gather more information, but it might my ISPs fault | 02:51 |
| beuno | (it's odd that http works fine though) | 02:51 |
| spiv | It is odd. | 02:51 |
| beuno | well, I'll wait around and see if anyone complains | 02:52 |
| spiv | It really shouldn't take 8s to send 40k though, unless you're on dial-up :) | 02:52 |
| beuno | right, and that's to a different server | 02:52 |
| spiv | Right. | 02:52 |
| beuno | would be wierd that my ISP is playing around with SSH port... | 02:53 |
| beuno | meh, anyway, it must be something on my side | 02:53 |
| beuno | thanks spiv :) | 02:53 |
| spiv | It's possible that the way SSH packaging the transfer is bumping into TCP MTU settings or something that HTTP doesn't, just by luck. | 02:54 |
| spiv | I used to have an ADSL connection where a bad MTU setting or something would cause large rsyncs to fail, but everything always seemed fine. | 02:54 |
| spiv | It was a real pain in the neck to figure out :) | 02:55 |
| beuno | I hope it's a temporary thing, because it may be months to switch ISP | 02:55 |
| spiv | Well, in the end it was a misconfiguration on my end. | 02:55 |
| spiv | (My MTU setting or whatever it was didn't match what the ISP said to use) | 02:55 |
| beuno | ah, well, there really isn't anything to configure, it's a standard linksys router with dhcp, from a cablemodem | 02:56 |
| spiv | Ah, ok. | 02:56 |
| spiv | I'd try looking at tcpdumps (on both ends), maybe something will become obvious. | 02:57 |
| beuno | spiv, will do, thanks again | 02:57 |
| spiv | If you do figure out, let me know. I'm very curious! :) | 02:57 |
| beuno | spiv, hehe, absolutely | 02:57 |
| libwilliam | I am looking through the API's and am not seeing a way of checking to see if a directory is a valid branch. Is there anything like this? | 03:00 |
| spiv | libwilliam: there is | 03:01 |
| libwilliam | check runs consistency checks, but not seeing where it shows how to interpret the error | 03:01 |
| spiv | Well, "check" is more in depth than just "is this a valid branch". | 03:01 |
| Odd_Bloke | libwilliam: Yes, you try Branch.open(<URL>) and if it raises a particular exception, <URL> isn't a branch. | 03:02 |
| spiv | Depending on what you mean by "valid", I guess. | 03:02 |
| beuno | libwilliam, http://bazaar-vcs.org/Integrating_with_Bazaar might be worth taking a look at | 03:02 |
| Odd_Bloke | "NotBranchError", I think. | 03:03 |
| libwilliam | by valid I mean being able to open a WorkingTree out of it. | 03:04 |
| libwilliam | I'll try the open method and check for an exception, sorry to keep bugging, thanks again | 03:04 |
| spiv | A WorkingTree is a separate concept to a Branch. | 03:04 |
| spiv | You want WorkingTree.open, I thin. | 03:04 |
| Odd_Bloke | If you want a WorkingTree, you'll... yeah. | 03:05 |
| Odd_Bloke | I thin so too. | 03:05 |
| spiv | Odd_Bloke: :) | 03:05 |
| libwilliam | ok, i already have that part in so that shouldn't be so bad. | 03:06 |
| rockstar | Alright, interesting problem: Developer branches a bzr repo, deletes the .bzr folder, and does bzr init again. When I go to merge back into target repo, it complains that they have no common ancestor (obviously). Is there a way to merge them manually? | 03:38 |
| rockstar | The target for the merge is identical to what the user branched two weeks ago. | 03:39 |
| rockstar | But he's got ~35 versions in his broken repo. | 03:39 |
| beuno | rockstar, I know that is some kind of magic using bzr merge -1.. | 03:39 |
| beuno | to merge unrelated branches | 03:40 |
| beuno | but I'm not 100% sure how it works | 03:40 |
| rockstar | Yea, looking through that now. | 03:40 |
| jml | want to rename threads :( | 03:41 |
| rockstar | Well, I guess I could have him re-branch and then make patches from the old repo and put them in the proper branch. | 03:43 |
| mwhudson | rockstar: i think all the fileids will be different, which will make like painful | 03:44 |
| * AfC speculates that this might be a legitimate cause for using `rebase` | 03:44 | |
| mwhudson | s/like/life/ | 03:44 |
| Odd_Bloke | mwhudson: If he made actual patches, rather than bundles, it'd be fine. | 03:44 |
| rockstar | mwhudson, I suspected as much. | 03:44 |
| AfC | Though I too thought that there was a way (magic or otherwise) to treat the empty branch as a common revision. | 03:44 |
| mwhudson | yes, so patches are probably the way to go | 03:44 |
| rockstar | But to do that for 35 revs would be rough. | 03:44 |
| mwhudson | ...so long as there aren't any renames or kind changes... | 03:45 |
| mwhudson | rockstar: sounds like a job for a shell script to me! | 03:45 |
| rockstar | Well, it's not my problem... It's someone else's... | 03:46 |
| AfC | Hm. Yeah, revno 0 | 03:48 |
| AfC | Well, `bzr merge -r 0..-1 $other` will pull it in. You'll have a right lovely mess trying to resolve the conflicts, though. That probably is no better than making patches. | 03:49 |
| rockstar | AfC, tried that, looks like the original repository is old. | 03:51 |
| rockstar | bzr: ERROR: Repository KnitPackRepository('file:///home/rockstar/Projects/entertainer/backend-refactoring/.bzr/repository/') is not compatible with repository KnitRepository('file:///home/rockstar/Projects/entertainer/entertainer/.bzr/repository/') | 03:51 |
| beuno | rockstar, it might be the other way around -1..0 | 03:52 |
| rockstar | And apparently, bzr upgrade doesn't work on the older repo... *sigh* | 03:54 |
| Odd_Bloke | rockstar: What message do you get? | 03:54 |
| rockstar | On the upgrade? | 03:54 |
| Odd_Bloke | Yeah. | 03:54 |
| rockstar | bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>. Does not support rich root data. | 03:54 |
| mwhudson | upgrade --rich-root-pack then | 03:57 |
| rockstar | Yea, I was thinking I would try that. | 03:58 |
| mwhudson | these two errors are actually reporting the same problem | 03:58 |
| mwhudson | (badly) | 03:58 |
| rockstar | :) | 03:58 |
| rockstar | bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack4>. Does not support nested trees | 03:59 |
| mwhudson | oh | 03:59 |
| mwhudson | is there pack-with-subree? | 04:00 |
| mwhudson | +t | 04:00 |
| rockstar | --development-subtree | 04:01 |
| rockstar | Holy hell that worked | 04:01 |
| === jamesh__ is now known as jamesh | ||
| jamesh | rockstar: in the short term, you probably want to avoid subtree format if possible | 04:06 |
| rockstar | jamesh, well, ideally, I'd like all of these branches to be in the same format. | 04:07 |
| jamesh | if you aren't using subtree features (e.g. if it is just an old bzr-svn import), you might be able to pull the branch into a rich-root-pack repo | 04:07 |
| rockstar | jamesh, that's exactly how this branch was created. With bzr-svn. Version is now unknown (that system was wiped and re-installed with a new OS) | 04:07 |
| jamesh | rockstar: right. While you can't "bzr upgrade" from subtree to non-subtree, you can branch from one format to the other | 04:08 |
| jamesh | provided no subtree features were used | 04:08 |
| jamesh | (which is probably the case if it is a bzr-svn branch) | 04:08 |
| rockstar | I created a new folder, bzr init, and then a pull from another branch. No go. | 04:08 |
| jamesh | rockstar: try "bzr init --rich-root-pack" | 04:09 |
| rockstar | jamesh, looks like that's working. | 04:09 |
| jamesh | while you can sometimes pull from subtree formats to rich-root, you can't pull to the default format | 04:09 |
| jamesh | and rich-root is closer to the main supported formats | 04:10 |
| rockstar | Yea, I've been trying to get into bzr development so I can start understanding all these terms. :) | 04:10 |
| jamesh | as I understand it, the differences are something like this: | 04:12 |
| Odd_Bloke | abentley is working on the One Format, to in the darkness bind them, I believe. | 04:12 |
| jamesh | in the default format, the file ID for the root directory of all branches is the special value "TREE_ROOT" | 04:12 |
| jamesh | for rich-root, it gets a pseudo-random file ID like all other directories | 04:12 |
| rockstar | Odd_Bloke, yea, we talked about that in Dunedin last week | 04:13 |
| jamesh | for subtree formats, directories in the branch can be references to other branches | 04:13 |
| jamesh | so provided there are no subtree references, you can go subtree -> rich-root | 04:13 |
| jamesh | but you can't go rich-root -> default without losing information | 04:14 |
| * igc lunch | 04:14 | |
| AfC | Odd_Bloke: that was hilarious | 04:38 |
| rockstar | Come to think of it, Dunedin is in the same country as Mordor | 04:41 |
| mwhudson | different island though | 04:45 |
| rockstar | Yea, don't you live down the street from the eye? | 04:50 |
| Odd_Bloke | Canonical's London offices are _near_ the London Eye... | 04:51 |
| mwhudson | it's a pretty long street | 04:51 |
| mwhudson | i guess about 2.5 hours drive | 04:52 |
| === mario_ is now known as pygi | ||
| gour | pygi: morning | 06:18 |
| === thekorn_ is now known as thekorn | ||
| poolie | spiv: how did you go with protocol 3 landings? | 08:13 |
| spiv | poolie: Running the final-final local test run now before I fire off to PQM. | 08:15 |
| poolie | yay! | 08:15 |
| spiv | The last change was updating the protocol version marker to say "bzr 1.6" :) | 08:15 |
| poolie | possibly we should have some kind of NEXT_RELEASE marker that's updated during the release | 08:16 |
| poolie | or immediately before merging | 08:16 |
| spiv | I haven't found it to be a significant burden for my work. | 08:16 |
| poolie | well, clearly you can just do it now, but i mean a convention | 08:16 |
| poolie | suppose it is no worse to just take a guess at it | 08:16 |
| spiv | (Not arguing against, just saying it wouldn't make a big difference to me) | 08:17 |
| spiv | poolie: actually, one last thing before I fire it off: the NEWS entry. | 08:21 |
| spiv | poolie: here's a first stab: http://rafb.net/p/1U7kMG26.html | 08:22 |
| spiv | poolie: Any suggestions for improving that? | 08:22 |
| spiv | Hmm, I guess there's a bug number somewhere I can include too. | 08:22 |
| poolie | probably | 08:22 |
| poolie | probably there is a bug | 08:22 |
| poolie | that looks good; the last sentence could be less passive though | 08:23 |
| poolie | how about this (if it is correct): | 08:23 |
| spiv | It addresses parts of https://bugs.edge.launchpad.net/bzr/+bug/83935 | 08:24 |
| ubottu | Launchpad bug 83935 in bzr "improvements to bzr protocol" [High,Confirmed] | 08:24 |
| poolie | Bazaar 1.6 will interoperate with 0.9 and later versions, but servers should be upgraded when possible. | 08:24 |
| poolie | you should get extra points for closing a 5-digit bug number :) | 08:24 |
| poolie | spiv, i think you should close that with this landing | 08:25 |
| spiv | Well, point 4 in that bug (authentication) is still open. | 08:25 |
| spiv | But really that ought to be its own bug | 08:25 |
| poolie | i think 3 and 4 should become separate wishlist bugs | 08:25 |
| awilkins | can you split bugs? | 08:25 |
| spiv | (maybe there already is one?) | 08:25 |
| poolie | awilkins: only by hand | 08:25 |
| awilkins | Yick | 08:25 |
| poolie | but there's a bug requesting that! :) | 08:25 |
| awilkins | You'd think with all the slitting and joining of branches you could do the same with bugs | 08:25 |
| awilkins | :-) | 08:25 |
| spiv | poolie: Actually, it will only interoperate with 0.16 and up; the autodetection doesn't try to detect v1 servers. | 08:26 |
| poolie | ok | 08:26 |
| poolie | i wasn't sure of the number | 08:26 |
| spiv | It's possible to reinstate that, but it's hard to do it 100% robustly. | 08:26 |
| poolie | i think it's reasonable | 08:26 |
| spiv | Phew :) | 08:26 |
| poolie | but news should say what it is | 08:26 |
| spiv | True. | 08:26 |
| poolie | can you work out a good phrasing to explain the impact of old servers? | 08:26 |
| spiv | "Bazaar 1.6 no longer interoperates with 0.15 and early via these protocols. Use alternatives like SFTP or upgrade those servers." ? | 08:28 |
| spiv | s/early/earlier/ | 08:28 |
| poolie | yeah | 08:28 |
| spiv | Ok. | 08:28 |
| poolie | sounds good | 08:28 |
| poolie | but isn't there an impact with 1.5 and earlier too? it needs to reconnect? | 08:28 |
| poolie | btw can i check you give a message in that case? | 08:28 |
| spiv | Yeah, it will reconnect, and it does give a warning about that now. | 08:29 |
| poolie | great | 08:29 |
| spiv | Oh, I see the reply I sent to your review was still sitting in my editor, oops. | 08:29 |
| fullermd | I don't think it has a prayer of interoperating with 0.9 smart servers :p | 08:29 |
| * spiv sends it | 08:29 | |
| spiv | fullermd: yeah, I think 0.11 had the first hpss | 08:30 |
| fullermd | 's the number I recall, yah. | 08:30 |
| spiv | "Server does not understand Bazaar network protocol %d, reconnecting. (Upgrade the server to avoid this.) | 08:31 |
| spiv | " | 08:31 |
| * spiv fixes the %d. | 08:31 | |
| spiv | (Hooray for dogfooding.) | 08:31 |
| gour | do you recommend DVC for emacs+bzr combo? | 08:33 |
| poolie | yes | 08:33 |
| poolie | i think that's the best option | 08:34 |
| poolie | i don't use emacs often though | 08:34 |
| gour | thanks | 08:34 |
| vila | yes | 08:35 |
| vila | i think that's the best option | 08:35 |
| poolie | hello vila! | 08:35 |
| Odd_Bloke | vila: o/ | 08:35 |
| vila | I use emacs often | 08:35 |
| vila | :) | 08:35 |
| vila | poolie, Odd_Bloke: hi ! | 08:35 |
| awilkins | Last time I used emacs was MicroEmacs on the Amiga about 15-20 years ago | 08:35 |
| vila | first time I used emacs was epsilon circa 88 :-) | 08:35 |
| vila | under DOS wayyyy before windows | 08:36 |
| awilkins | Heh, I think this was around the time of "GEM" | 08:36 |
| vila | GEM ! Yeah, we code a prolog interpreter under GEM in 87 ! :-) | 08:37 |
| Odd_Bloke | I've never used emacs. | 08:37 |
| Odd_Bloke | I like my pinky finger too much. :p | 08:37 |
| poolie | i might leave early today i think :) | 08:37 |
| poolie | spiv, can we have a quick call? | 08:37 |
| awilkins | I keep wondering if I should try it, being a slightly sim-ish person at the moment | 08:37 |
| vila | poolie: Did you have a look at wireshark traces ? | 08:37 |
| awilkins | s/sim-ish/vim-ish | 08:38 |
| vila | awilkins: use whatever fits your needs | 08:38 |
| poolie | vila, no, will look now | 08:38 |
| vila | poolie: thanks a lot | 08:38 |
| poolie | !! | 08:39 |
| spiv | poolie: sure. | 08:40 |
| uniscript | when merge has a conflict, 4 files are generated. Is there any way to make all 4 files contain the non-conflicting changes that have been merged? | 08:42 |
| uniscript | currently they are just copies of their corresponding originals plus one to show all the conflicts | 08:42 |
| Odd_Bloke | uniscript: Is this before or after you've resolved the conflicts? | 08:44 |
| uniscript | before | 08:44 |
| vila | the one showing the conflicts includes the non-conflicting changes | 08:45 |
| uniscript | right, so I'll have to parse that to generate the 3 files with non-conflicting changes. | 08:46 |
| uniscript | Is the clash marker consistent across all merge methods? | 08:46 |
| poolie | vila, replied | 08:46 |
| poolie | i replied* | 08:46 |
| Odd_Bloke | uniscript: Why do you want the 3 files with non-conflicting changes? | 08:47 |
| uniscript | because I want to track the conflicts and just the conflicts | 08:47 |
| uniscript | it's part of a sync operation I'm writing | 08:47 |
| uniscript | that allows conflict resolution to be delayed | 08:47 |
| vila | poolie: great, having the server logs will help alot (mneptok can provide that ?). | 08:48 |
| vila | sending the other headers is not an option though :) The connection get closed as soon as the GET is sent. | 08:49 |
| poolie | should do | 08:49 |
| poolie | vila, see my latest post | 08:49 |
| poolie | spiv, will call | 08:49 |
| spiv | poolie: ok | 08:49 |
| vila | poolie: hmmm, yeah, I could try that, thanks for the hint | 08:50 |
| gour | i installed DVC and it loads, but, based on manual, emacs complains that C-x T is undefined | 09:00 |
| * awilkins tries the Emacs tutor | 09:06 | |
| gour | awilkins: welcome ;) | 09:07 |
| awilkins | I hate it already I'm afraid | 09:07 |
| awilkins | M-v to move back a screen? This places ones fingers in an unnatural contortion. | 09:08 |
| awilkins | And I have double-jointed fingers | 09:09 |
| AfC | Oh goodie! An editor flamewar in a version control channel! | 09:10 |
| fullermd | Y'know who else used emacs?! THE NAZIS! | 09:11 |
| awilkins | "I hate it" isn't flaming | 09:11 |
| awilkins | "It's a pile of crap" would be flaming | 09:11 |
| * awilkins has unwittingly started a meta-flamewar | 09:11 | |
| spiv | AfC: all that's missing a GPL vs. BSD licence fight. | 09:11 |
| fullermd | I thought those were on indefinite hiatus until the GPLv2 vs. GPLv3 flamewars settled out. | 09:12 |
| AfC | Cats lovers vs Dog lovers, man | 09:12 |
| gour | awilkins: you're free to rebind everything to whatever you like ;) | 09:12 |
| * awilkins rebinds page up and down to page up and down | 09:12 | |
| poolie | night! | 09:13 |
| AfC | awilkins: whoa, that's innovative. | 09:13 |
| gour | :-) | 09:13 |
| gour | poolie: night...here is 10am, we're not going to sleep (yet) | 09:13 |
| fullermd | I tried to remap Page Up to "power down system", but I think Apple would sue me for patent infringement... | 09:13 |
| gour | :-D | 09:13 |
| awilkins | I think I'd enjoy learning Lisp though (if it wasn't for the syntax :-) ) | 09:14 |
| bob2 | try dylan | 09:14 |
| AfC | God I wish Bazaar actually gave useful feedback when pulling a large project. Sitting on "Copying invenory texts 2/5" for the last 9 minutes is thunderingly uninspiring. | 09:15 |
| awilkins | I open a file browser and watch the pack files gurgle around | 09:15 |
| fullermd | I comfort myself by saying "If I used git, it would be done by now, and I could spend the time bzr is copying trying to figure out what command to run next" | 09:17 |
| gour | lol | 09:17 |
| AfC | Hm. `baobab` as Bazaar progress user interface. | 09:18 |
| awilkins | I don't think git can speed up a slow network connection though | 09:18 |
| awilkins | Although sometimes I do find myself thinking "Hmm, git would do this better" when refactoring chunks of code out into separate files. | 09:19 |
| awilkins | BUt that's based on zero real-world experience of git | 09:20 |
| awilkins | I seem to have absorbed the fact that it versions chunks of code and not files | 09:20 |
| igc | night all | 09:27 |
| gour | heh, 1.5 tomorrow, 1.6 in few weeks :-D | 09:34 |
| gour | it looks i'm catching the bzr train in right moment | 09:37 |
| Kinnison | My only issue with bzr's speed is that I have yet to see it fill my link when pulling/branching | 09:39 |
| awilkins | How fast is your link? | 09:39 |
| Kinnison | 10Mbps | 09:39 |
| awilkins | Not filling 10Mbps is unlikely to be bzrs fault (unless you can verify that you can get a full 10Mbps to the target repo). | 09:40 |
| AfC | Kinnison: yeah, I have the same complaint | 09:42 |
| AfC | Kinnison: (where target has ~100x what I have) | 09:43 |
| Kinnison | mmm, the vast majority of large projects I talk to are launchpad so it could be them | 09:43 |
| * Kinnison ponders branching to his colo server and trying from there since I know I get the full 1.1MB/s (10Mbps) to that one | 09:44 | |
| awilkins | I remember thinking that using a diff algorithm that focussed less on space and more on speed might improve matters, having watched it peg the CPU. | 09:44 |
| awilkins | But without profiling of course, that is mere speculation | 09:45 |
| === weigon__ is now known as weigon | ||
| Kinnison | :-) | 09:45 |
| awilkins | 'twas my major nitpick of SVK ; mirroring a remote repo should be I/O bound, not CPU bound, especially in SVK where the source and target use the same repo format. | 09:47 |
| jamesh | Kinnison: lucky for you, bazaar.launchpad.net is in the same country | 09:55 |
| Kinnison | jamesh: It ought to be bandwidth rather than latency bound with TCP and packs though, surely? | 09:56 |
| jamesh | Kinnison: there are probably still a number of round trips to be killed off | 09:57 |
| jamesh | Kinnison: how much they affect things probably depends both on your latency and how much data you're transferring | 09:57 |
| spiv | Definitely there are plenty of round trips to kill off, still. | 09:57 |
| Kinnison | nod. | 09:58 |
| spiv | Killing some of them is my goal next week :) | 09:58 |
| * Kinnison is lucky for his ping-time to LP | 09:58 | |
| Kinnison | ca. 15ms | 09:58 |
| jamesh | maybe we should move bazaar.launchpad.net down to australia | 09:58 |
| jamesh | that'd improve performance | 09:58 |
| spiv | Or rather, faster pushing in general is. In additional to unnecessary round trips, there's also just plain old unnecessary work. | 09:58 |
| lifeless | Kinnison: raw pack pulls should saturate your link | 10:00 |
| Kinnison | lifeless: upsettingly they don't tend to | 10:00 |
| Kinnison | lifeless: although I cannot work out why, since I'm not CPU bound or anything | 10:00 |
| lifeless | Kinnison: are you using sftp or bzr+ssh ? | 10:00 |
| Kinnison | lifeless: http | 10:00 |
| lifeless | Kinnison: try sftp | 10:00 |
| Kinnison | for pulling? | 10:01 |
| Kinnison | really? | 10:01 |
| lifeless | sure | 10:01 |
| Kinnison | okay, what's the sftp url for bzr itself? | 10:01 |
| spiv | I don't think there is one. There is a bzr+ssh URL. | 10:01 |
| lifeless | sftp://bazaar.launchpad.net/~bzr/bzr/bzr.dev I think; but you currently have to be in ~bzr to read that | 10:01 |
| Kinnison | aah | 10:02 |
| Kinnison | :-( | 10:02 |
| spiv | (Unless you are in the 'bzr' team, as lifeless says) | 10:02 |
| jamesh | lifeless: I don't think branches you don't own are available via sftp | 10:02 |
| * Kinnison tries a 5.8MB fetch from his own server | 10:02 | |
| Kinnison | it's managing ca. 14kB/s over sftp | 10:03 |
| Kinnison | neither end is heavily CPU bound | 10:03 |
| gour | will 1.6 change its default format? | 10:04 |
| Kinnison | hmm, http sucks too, I wonder if this is old enough to be pre-pack | 10:04 |
| Kinnison | urgh it is, no wonder it sucked | 10:05 |
| Kinnison | sorry, I need to sort a remote pack repo first | 10:05 |
| AfC | spiv: I assume you have enough repos to test from, but I now have a few projects that are rather large and for whom both I/O and CPU seem underwhelmed. Given the audience is a sceptical one, it might be worth tackling them... | 10:07 |
| spiv | AfC: I'm seeing plenty of room for improvement just with bzr.dev, but I'd be happy to have some other real-world datasets to play with. | 10:11 |
| AfC | spiv: someone took my GTK ball and has run with it; he's done most of svn.gnome.org now. | 10:11 |
| spiv | (And also with the Launchpad codebase, which is pretty big and has a large history.) | 10:11 |
| AfC | s/someone/Jc2k/ | 10:12 |
| spiv | I'm particularly interesting projects that have a very branch-heavy history (like bzr and launchpad), because that's where some of the problems are. | 10:12 |
| jamesh | given that svn.gnome.org is in the Canonical data centre, it'd probably make sense to do a migration there | 10:13 |
| spiv | i.e. traversing complicated graphs, rather than mostly linear ones. Although obviously they need to work well too... | 10:13 |
| gour | spiv: have you tried to play with ghc? | 10:13 |
| spiv | gour: no; is it in bzr? | 10:14 |
| AfC | whatever, it's done now. | 10:14 |
| gour | spiv: no, it was in CVS, now is in darcs, but there are problems | 10:15 |
| spiv | gour: ah, ok. | 10:15 |
| gour | spiv: someone was doing darcs --> git and it was sloooow | 10:15 |
| jamesh | AfC: I'm not saying what you did was unimportant. Just that maintaining mirrors from there would probably be more efficient | 10:16 |
| AfC | He's in the UK | 10:16 |
| jamesh | and in general, pulling the converted bzr branch is faster than pulling with bzr-svn | 10:16 |
| spiv | Interesting. I don't know what the state of darcs -> bzr is like at the moment. Probably just tailor? | 10:16 |
| AfC | and I'm bitching about the performance of pulling the converted bzr branch | 10:16 |
| jamesh | AfC: I'm talking about machines that are in the same room | 10:16 |
| AfC | jamesh: he was given rsync access to the entire repo, so is doing svn+file://. | 10:17 |
| gour | spiv: see http://nominolo.blogspot.com/2008/05/thing-that-should-not-be-or-how-to.html | 10:17 |
| jamesh | AfC: ah. | 10:17 |
| gour | yes, probably tailor...i'm interested for it as well | 10:17 |
| gour | in any case, i think ghc is nice for bzr testing | 10:17 |
| gour | 18500 patches, 12yrs history | 10:18 |
| jamesh | gour: it sounds like a good example of a long linear history | 10:19 |
| jamesh | gour: spiv is talking about also testing on branches where sizeof(ancestry)/sizeof(linear history) > 1 | 10:20 |
| jamesh | that is, where there is a more complex graph | 10:21 |
| fullermd | Considering the effects emacs shows on sizeof(linear history)... | 10:21 |
| gour | i see | 10:22 |
| gour | darcs is not so big but had two branches for a long time: main + unstable which are merged recently | 10:22 |
| * spiv -> dinner | 10:24 | |
| * Kinnison cheers as bzr gets 1.2MB/s over sftp from his colo box | 10:25 | |
| * Kinnison bounces lifeless | 10:25 | |
| Kinnison | mmm interesting. http took marginally less cpu, but twice as long wallclock | 10:34 |
| Kinnison | sftp for the win, thanks lifeless | 10:34 |
| * Kinnison manages to get bzr-svn to break | 10:48 | |
| * Kinnison tries to see if we do anonymous access to this svn repo so I can report the issue | 10:48 | |
| lifeless | vila: ^ I think its http buffering | 11:27 |
| vila | lifeless: sounds plausible enough, I wonder why we never encounter it before, but some bugs just love to stay dormant like that, I'll have a look asap | 11:28 |
| * vila gotta run now | 11:29 | |
| lifeless | vila: we encounter it always I think | 11:33 |
| lifeless | vila: bye | 11:33 |
| vila | lifeless: sry, I'm in a hurry, but I'd be very interested in discussing it a couple of minutes with you, cu later | 11:37 |
| * Odd_Bloke impotently shakes his fist at the mutable-commit-messages ML discussion. | 11:40 | |
| jelmer | hi Odd_Bloke | 11:41 |
| Odd_Bloke | jelmer: o/ | 11:41 |
| jelmer | Odd_Bloke: any news on file-type-specific merges ? :-) | 11:41 |
| Odd_Bloke | jelmer: Yeah, I'm starting on it after exams. :p | 11:42 |
| jelmer | ah, ok | 11:42 |
| pygi | morning gour | 11:59 |
| gour | pygi: it's noon (by Son) already ;) | 12:06 |
| dennda | Doesn't bzr allow to bzr push sftp://... to another port than 22? | 12:10 |
| james_w | dennda: I would have thought that it does, how are you specifying the port? | 12:11 |
| dennda | james_w: tried adding -p $port and -P $port | 12:11 |
| dennda | does accept neither of those | 12:11 |
| james_w | ah, no, it won't | 12:11 |
| james_w | try sftp://server:port/path/ | 12:11 |
| dennda | great, thanks. I was almost working around that with .ssh/config :) | 12:13 |
| dennda | uff, takes ages to push 2,9 MB | 12:16 |
| gour | to import darcs repos, tailor is the only solution? | 12:18 |
| dennda | hu... it says it created a new branch remotely but all it did was creating a .bzr directory. the actual branch doesn't contain anything else | 12:18 |
| luks | dennda: .bzr is the actual branch | 12:18 |
| gour | dennda: you mean no working tree? | 12:18 |
| dennda | luks: yes, I know. but the location to where I pushed is empty except the .bzr folder | 12:19 |
| dennda | gour: yes | 12:19 |
| luks | dennda: yes, that's correct | 12:19 |
| luks | bzr push will never create or update remote working tree | 12:19 |
| luks | only the branch | 12:19 |
| dennda | so I need to branch that again? | 12:19 |
| luks | why? | 12:20 |
| dennda | I need a working tree remotely | 12:20 |
| james_w | dennda: ssh in and run "bzr checkout ." in the directory | 12:20 |
| luks | http://bazaar-vcs.org/FAQ#head-942dfcf9fc6787bb81dd6c1ffe0c32b16c71d496 | 12:20 |
| dennda | james_w: done that, worked. although I used branch instead of checkout | 12:20 |
| Peng | ...You branched a branch to the same directory? | 12:20 |
| james_w | when you push again "bzr update" will update the working tree, to automate this you may want to look at the "push-and-update" plugin. | 12:20 |
| dennda | and branched to another directory | 12:21 |
| daniels | this might strike you guys as a stupid question, but how do i actually check out a tag? | 12:24 |
| daniels | bzr tags shows me the tag i want, with its revision number, but neither bzr checkout nor bzr branch seem to do what i want (make my working copy be that tag) | 12:25 |
| luks | bzr checkout -r tag:foo ? | 12:25 |
| james_w | if you just want your tree to be that tag for a minute to look at it then use "revert" | 12:25 |
| james_w | if you want a separate branch at that tag then use "branch -r tag:foo branch new-branch" | 12:26 |
| james_w | I'm not sure if checkout does it, I know pull will, but bear in mind that that will make your current branch tip | 12:26 |
| james_w | hard to get at | 12:26 |
| * gour is looking for some advice to import darcs repos | 12:27 | |
| daniels | okay, so what i probably want is: bzr branch -r tag:the-tag-name directory-the-repo-is-in directory-to-check-that-tag-out-into | 12:27 |
| TFKyle | not sure if there's anything better, but tried tailor already gour? | 12:27 |
| james_w | daniels: yup, that's what I'd suggest. Though by "directory-the-repo-is-in" do you mean "the directory of the branch"? | 12:28 |
| james_w | you point it to a branch, not to a shared repository (init-repo) if you are using them. | 12:28 |
| daniels | james_w: yeah, that's done what i want, brilliant -- ta | 12:28 |
| gour | TFKyle: i did in the past, but not with bzr | 12:28 |
| daniels | (and yeah, i mean directory of the branch. my terminology is heavily git influenced, and i'm only using bzr because one particular project does.) | 12:28 |
| james_w | daniels: ah yeah, I know this is a pain when changing between the two. | 12:29 |
| daniels | james_w, luks: cheers for the help | 12:32 |
| CroX | What bugtracker system do you people use when working with Bazaar? I had wanted something that integrates with the VCS. | 12:36 |
| james_w | there is a trac-bzr plugin | 12:37 |
| james_w | launchpad has some integration | 12:38 |
| james_w | there is bugs-everywhere if you want to get really integrated. | 12:38 |
| CroX | Know anything about Mantis' possibilities? | 12:38 |
| CroX | Never heard of that one. I'll need to check it out. | 12:38 |
| james_w | I haven't heard of any integration with mantis | 12:39 |
| igc | gour: can you try fastimport for getting from darc to bzr? You'll need http://repo.or.cz/w/darcs2git.git as the front-end | 12:44 |
| gour | igc: do you think it's better than tailor? | 13:07 |
| igc | gour: well I wrote bzr-fastimport so I hope so :-) | 13:07 |
| gour | igc: ohh, let me try it then ;) | 13:08 |
| igc | seriously, ... | 13:08 |
| igc | it will convert a repo, not just a branch | 13:08 |
| igc | assuming the exporter does the right thing | 13:08 |
| gour | so, i need to install plugin 1st | 13:08 |
| igc | yes. See http://bazaar-vcs.org/BzrFastImport | 13:09 |
| igc | and that links to http://bazaar-vcs.org/BzrFastImport/FrontEnds where ... | 13:09 |
| igc | I'd love to move Darcs "up the page" if that makes sense | 13:09 |
| gour | ok, plugin is installed and listed in bzr...what's next | 13:10 |
| gour | igc: how do i get darcs2git? | 13:13 |
| igc | gour: git clone http://repo.or.cz/w/darcs2git.git | 13:14 |
| spiv | vila: thanks for finding the dupe of that smart server auth bug, I looked but couldn't find it. | 13:14 |
| igc | gour: I'd like to bundle this if it works and licensing permits | 13:14 |
| igc | that's why someone testing it is good :-) | 13:15 |
| gour | igc: some problems http://rafb.net/p/f7pChO29.html | 13:15 |
| gour | i'm totally ignorant of git - another reason to move to bzr | 13:16 |
| igc | gour: ah - I got that link from http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-0c139c28cd0c9c34c6e08375ef10ad5ed5810271 | 13:17 |
| igc | gour: try git clone http://repo.or.cz/r/darcs2git.git | 13:19 |
| igc | note the 'r' instead of the 'w' | 13:19 |
| igc | sorry for the wrong url | 13:19 |
| gour | will it work with http://git.sanityinc.com/?p=darcs-to-git.git ? | 13:20 |
| gour | that one was ok | 13:20 |
| igc | gour: don't know - probably not | 13:21 |
| gour | ok, let me try yours | 13:21 |
| igc | the key thing is generating the 'fastimport' stream - not getting it into git | 13:21 |
| gour | done. | 13:22 |
| === jamesh_ is now known as jamesh | ||
| gour | igc: i invoked python ~/repos/git/darcs2git/darcs2git.py | bzr fast-import - | 13:25 |
| igc | gour: cool | 13:25 |
| gour | but got: bzr: ERROR: line 1: Invalid command 'Usage: darcs2git [OPTIONS] DARCS-REPO' | 13:25 |
| igc | gour: ok, so get the export part working first | 13:26 |
| gour | you mean without piping? | 13:26 |
| igc | i.e. just do ... python dards2git.py WHATEVER > myrepo.fi | 13:26 |
| igc | you can then inspect that file to confirm things look ok | 13:27 |
| igc | if so, then do ... | 13:27 |
| igc | bzr fastimport myrepo.fi | 13:27 |
| igc | gour: how's your python coding skills? | 13:27 |
| igc | you might want to manually inspect darcs2git.py before running it | 13:28 |
| gour | igc: none | 13:28 |
| gour | it does something.. | 13:28 |
| igc | in particular, you don't want it implicity piping the 'output' to git-fast-import | 13:29 |
| igc | because we want to consume the output instead | 13:29 |
| gour | hmm | 13:30 |
| gour | maybe i should try with some smaller repo | 13:30 |
| gour | igc: does darcs2git works with darcs-2 format repos? | 13:36 |
| igc | gour: I have no idea sorry | 13:38 |
| igc | gour: if darcs-to-git works, then you can always use it and then use git-fast-export | 13:39 |
| igc | gour: that may be easiest in the short term | 13:39 |
| gour | igc: it works with older format. i changed it create darcs-2. let's see | 13:40 |
| gour | when i s/darcs init/darcs init --darcs-2, it crashes | 13:48 |
| TFKyle | jam: hmm, I could be blind, but I don't see the bzr-merged plugin anywhere | 13:52 |
| TFKyle | (well, on the plugins page, and bzr ls lp:bzr-merged == no such project | 13:53 |
| lifeless | jam: yo | 14:00 |
| pickscrape | Any idea when bzrtools 1.5 is going to hit the bzr PPA? | 14:04 |
| jelmer | pickscrape, poolie should be able to tell you | 14:04 |
| pickscrape | One of my worries about rolling bzr to my team is that the packages in the PPA rarely seems to be consistent with each other. | 14:05 |
| pickscrape | At least they haven't in the time I've been using it. | 14:06 |
| lifeless | pickscrape: thisi s a liimtation with ppa's, we're looking at ways to address this including a more stable ppa for users | 14:16 |
| pickscrape | Would "more stable" mean missing on on monthly releases, or just more consistent and excluding things like RCs? | 14:18 |
| pickscrape | s/on on /out on/ | 14:20 |
| === mw is now known as mw|errands | ||
| lifeless | nore consistent and not having rc's | 14:22 |
| pickscrape | That sounds perfect. :) | 14:23 |
| madduck | bzr: ERROR: pycurl.error: (60, 'server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt') | 14:25 |
| madduck | how can i work around that? bzr *should* really be giving me a choice here, no? | 14:25 |
| lifeless | its comeing up from curl | 14:25 |
| madduck | but shouldn't bzr catch it and handle it appropriately? | 14:26 |
| lifeless | apparently its not that easy | 14:26 |
| madduck | so i can't clone this repo...? | 14:26 |
| madduck | https://penta.debconf.org/~joerg/bzr/debconf8 ftw | 14:27 |
| lifeless | try | 14:27 |
| lifeless | https+urllib:/... | 14:28 |
| madduck | that works | 14:31 |
| james_w | hi madduck | 14:40 |
| madduck | hi! | 14:41 |
| jam | morning lifeless | 14:42 |
| jam | TFKyle: I believe 'merged' is a plugin that statik uses, I'm not sure where he got it | 14:42 |
| jam | I believe he said it was public, and he was asking the author if they would mind hosting on LP | 14:42 |
| madduck | thanks, lifeless ! | 14:44 |
| lifeless | jam: :pserver: support for cvsps would be nice | 14:55 |
| bac | hi jam -- i was trying to update a very old version of a rocketfuel trunk (on a laptop i haven't used in a while) and i got raise AssertionError('%d != %d' % (len(history), revno)) | 15:03 |
| bac | AssertionError: 25 != 6299 | 15:03 |
| bac | jam: it's probably easier for me to start from scratch, unless this represents a bzr bug you'd like to investigate | 15:06 |
| james_w | bac: hi, that's a bug that has been filed I think. | 15:08 |
| bac | james_w: ok, thanks. is there a work-around? | 15:08 |
| james_w | I'm looking for the bug now, I don't remember the details. | 15:09 |
| bac | james_w: thanks. as i said it isn't imperative that this repo be repaired. | 15:10 |
| james_w | https://bugs.edge.launchpad.net/bzr/+bug/177855 looks like it | 15:10 |
| ubottu | Launchpad bug 177855 in bzr "assertionerror trips on pull --overwrite in dirstate branch with non-canonical history" [High,Fix released] | 15:10 |
| james_w | what version of bzr are you running? | 15:11 |
| bac | 1.5rc1 | 15:12 |
| james_w | hmm, I guess it's a different bug then. | 15:13 |
| james_w | are you doing a "pull" or an "update"? | 15:13 |
| bac | james_w: i was attempting a pull | 15:14 |
| james_w | I'm not sure how to debug that, sorry. | 15:14 |
| bac | james_w: ok. not a problem. | 15:16 |
| gour | tailor rocks in comparison with darc2-git | 15:24 |
| ricardokirkner | hi. what authentication scheme is mostly used in order to share a common branch for a project, using bzr? on the other hand, what guarantees that the user committing a change is actually the person that is authenticated? (for example, I can authenticate using user1 but in my bazaar config I specify myself as user2; in that way I 'could' blame user2 for introducing mistakes, or something like that) | 15:43 |
| james_w | I don't think there is any protection against that. | 15:44 |
| === kiko-afk is now known as kiko | ||
| === thekorn_ is now known as thekorn | ||
| jam | bac, james_w: The "fix" is that you have to run "bzr reconcile" on the branch | 16:32 |
| jam | ricardokirkner: the fix is to gpg sign your commits | 16:32 |
| bac | jam: thanks | 16:32 |
| ricardokirkner | jam, thanks for the idea, though in our case that might be a little bit overkill. but don't mind, my previous question was more out of curiosity than of need | 16:33 |
| jam | ricardokirkner: we trust the user, partially because you may be "pushing" code from someone else | 16:33 |
| jam | And that *should* be valid | 16:33 |
| igc | night all - have a good weekend | 16:47 |
| gour | igc: night | 16:47 |
| igc | hope the release good well jam | 16:47 |
| beuno | jam, if you need any help with the packaging today, let me know | 17:25 |
| * beuno ducks | 17:25 | |
| jam | igc: good night | 17:46 |
| jam | beuno: I might, how did you do the earlier ones? | 17:49 |
| jam | (we'll be marking these as 1.5.0, just to get the ordering correct) | 17:50 |
| beuno | jam, I basically followed the docs | 17:50 |
| jam | beuno: ok, I was just wondering if you used builddeb or something like that | 17:50 |
| beuno | and, for the first one, I built it in a pbuilder enviroment | 17:50 |
| jam | pbuilder? | 17:50 |
| beuno | to make sure it was clean | 17:50 |
| beuno | jam, it's a clean chroot-like enviroment, which doesn't save changes done to it | 17:51 |
| beuno | do you can build anything you want, and will always reset to a clean system | 17:51 |
| beuno | but just following the docs wirks fine | 17:51 |
| beuno | s/wirks/works | 17:52 |
| beuno | anyway, I'll be happy to help out | 17:52 |
| jam | beuno: we'll see how things go here, I have to wait for PQM to merge everything anyway | 17:59 |
| beuno | jam, good luck with that :) | 18:00 |
| jam | beuno: well, the submissions are in the queue | 18:14 |
| beuno | jam, but they only get in if they pass all tests, right? | 18:17 |
| awilkins | I love it when you hammer the keyboard for three hours straight and at the end of it have to patch less than 30 lines of code to fix the bugs :-) | 18:37 |
| pickscrape | From time to time you write code that really does work first time. Those moments are special :) | 18:41 |
| awilkins | The best bit it is that it's some really nasty/elegant (depending on your tastes) Java code thats very heavy with generics | 18:42 |
| awilkins | Ok, I was only refactoring it.... | 18:42 |
| lifeless | awilkins: depends how long those lines are :) | 19:04 |
| === mw|errands is now known as mw | ||
| nv1 | Thinking of using bzr for project revision control at my company. I understand tha Bazaar is GPL, so what are rules of using bzrlib from proprietary Python code? Should subprocess only be used? | 19:13 |
| awilkins | Does that particular restriction apply to scripting code? My understanding was that it applies when you link.... but IANAL | 19:15 |
| nv1 | that is what I am wondering | 19:15 |
| lifeless | nv1: hi | 19:17 |
| lifeless | there may be a delay; evolution is saturating my homelink | 19:17 |
| lifeless | nv1: as long as you don't distribute your code you can do anything - the GPL licence applies to *distribution* not use. | 19:18 |
| nv1 | I am thinking they are both (bzrlib and proprietary code) running in the same process... but no traditional C-style linking goes on | 19:18 |
| TFKyle | I think it depends on who you ask, GNU seem to say that even importing shouldn't be allowed, but I disagree sort of | 19:18 |
| nv1 | we sell our product and it gets installed on customer's systems | 19:18 |
| awilkins | That's rather broader than "at my company" | 19:19 |
| nv1 | yes | 19:19 |
| vila | Then you distribute it and are bound by the GPL | 19:19 |
| TFKyle | vila: are you bound by the GPL just for the bzr code or any code that imports bzr though? | 19:19 |
| nv1 | If we import bzrlib, but if we call it via subprocess then I understand that it is not | 19:19 |
| TFKyle | s/bzr/bzrlib/ | 19:19 |
| vila | IANAL, but AIUI, playing tricks with the GPL is quite risky | 19:20 |
| luks | TFKyle: any code that links to (imports) GPL-licensed code | 19:20 |
| lifeless | whoa no | 19:20 |
| awilkins | Release it GPL and charge for support, not the actual program ? | 19:20 |
| lifeless | slow down folk | 19:21 |
| lifeless | linking invokes the gpl because the output copies data from the input | 19:21 |
| TFKyle | luks: is importing really linking though? and what't the "level" of linkage? | 19:21 |
| luks | TFKyle: well, that's always questionable. but there are companies that run busineses based on that, so I guess they checked with enough lawyers | 19:22 |
| TFKyle | s/what't/what's/, I can't type properly these days | 19:22 |
| lifeless | http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL | 19:22 |
| nv1 | I don't want to take advantage and skirt the law on GPL, if it is a gray area I'd rather play it safe | 19:22 |
| lifeless | this mentions the FSF stance, which we share | 19:23 |
| lifeless | which is that a GPL'd module in an interpreted language requires that users of it also be GPL | 19:23 |
| awilkins | Yeah, but it's not just the interpreter being GPL ; the code running in the interpreter is GPL too | 19:23 |
| luks | lifeless: using a GPL interpretter and importing GPLed code are different things | 19:23 |
| lifeless | luks: I know that; please a) read what I said, and b) read the thing I linked to | 19:23 |
| awilkins | The bottom two paragraphs of that section are relevant | 19:24 |
| lifeless | nv1: we would expect that a proprietary piece of code could only use bzr if it was not being distributed | 19:24 |
| TFKyle | lifeless: another random question, can you get around that by not requiring the module exist but working with it if it does? (remember reading something about that somewhere else in the FAQ, wrt. dynamic linking) | 19:24 |
| lifeless | nv1: which is to say that you should use bzr via a subprocess | 19:24 |
| lifeless | nv1: you will likely find the 'ide integration' work being done of great interest, because it is aimed at providing a low level machine readable interface to bzr | 19:25 |
| nv1 | lifeless: makes sense too me | 19:25 |
| nv1 | I suspected that | 19:25 |
| lifeless | nv1: suitable for use by IDE's (including visual studio etc) | 19:25 |
| TFKyle | (well, by that I mean continuing to work without having to import the module) | 19:25 |
| lifeless | TFKyle: the usual example for that is a BSD readline and a GPL readline | 19:25 |
| nv1 | bzr is used as a backend for our project models (written in an s-expression format) | 19:25 |
| lifeless | nv1: cool | 19:26 |
| awilkins | Having some reasonable success here using bzr over a socket in Eclipse. | 19:26 |
| nv1 | s/used/hoping to use | 19:26 |
| awilkins | That's not linking | 19:26 |
| pickscrape | I had an idea last night that could be pretty cool (if it's not been done already). | 19:26 |
| nv1 | awilkins: that means to get status we'd have to either 'import bzrlib; bzrlib.get_status...' OR call via subprocess "bzr status" and parse the output | 19:27 |
| pickscrape | Would I be right in thinking that a bundle which represents a number of commits includes the commit log for each of those commits? | 19:27 |
| lifeless | TFKyle: I'm not really that interested in looking at 'ways around' the GPL :). Bzr is free software, folk that build on bzr to make bigger things which are not free software can't really expect to be working with the same interface as free software does | 19:27 |
| awilkins | nv1: There is expressly an XML output plugin for such a thing. Grab the bzr-eclipse source for examples if you are a Java type of person. | 19:27 |
| lifeless | awilkins: we're folding that into the core FWIW | 19:28 |
| lifeless | pickscrape: it does, yes. | 19:28 |
| pickscrape | Then how difficult would it be for bzr visualize to be able to load up a bundle, appending it to what it's currently displaying? | 19:28 |
| awilkins | pickscrape: I think a bundle is to all intents and purposes the only stable implementation of a shallow branch :-) | 19:29 |
| nv1 | lifeless: No problem with that ,we use python, linux plenty of other free software here, but we don't want to take advantage and skirt the law | 19:29 |
| pickscrape | That would allow a review of the bundle on a change by change basis to supplement the whole diff. | 19:29 |
| nv1 | awilkins: thanks, that would be helpful to use | 19:29 |
| lifeless | nv1: I appreciate that :). And I'm glad that you want to use bzr | 19:29 |
| lifeless | pickscrape: it would be nice; bundles are essentially a static partial-branch anyway | 19:29 |
| pickscrape | Then I thought that Bundle Buggy could potentially do the same thing too. | 19:30 |
| vila | pickscrape: you can pull or merge a bundle and then you have a real branch to work with | 19:30 |
| nv1 | all: thanks for help and for your time! | 19:30 |
| lifeless | vila: its not as convenient though :) | 19:31 |
| cr3 | I'm trying to branch a project and I get: bzr: ERROR: Revision {email-200804...} not present in "revisions.kndx" | 19:32 |
| pickscrape | My idea is just for review purposes. Basically looking at each diff can sometimes give a better understanding than the whole lumped patch | 19:32 |
| pickscrape | Is it worth a wishlist bug for bzr+gtk do you think? | 19:32 |
| lifeless | pickscrape: definitely | 19:32 |
| pickscrape | ok | 19:32 |
| jam | beuno: well, a lot of the changes are doc only, but it turns out I accidently submitted them to bzr.dev instead of bzr-1.5. So they ended up failing right away with NEWS conflicts, which is good for me :) | 19:33 |
| jam | beuno: So I have 1 more to go, so maybe in 1-2hrs... | 19:33 |
| beuno | jam, I'll be around for at least 6 more :) | 19:34 |
| Lo-lan-do | G'day all | 19:34 |
| Lo-lan-do | I seem to have a problem with bzr and bzr-svn in sid | 19:34 |
| Lo-lan-do | $ bzr checkout http://svn.gnome.org/svn/f-spot/trunk | 19:35 |
| Lo-lan-do | bzr: ERROR: Transport error: Server refuses to fullfil the request | 19:35 |
| Lo-lan-do | I guess I need to poke jelmer, unless someone already knows about it :-) | 19:35 |
| jam | Lo-lan-do: this sounds like a recurring problem we have been seeing with the gnome.org servers | 19:37 |
| jam | let me look up the bug | 19:37 |
| jam | Lo-lan-do: possibly bug #229076 | 19:37 |
| ubottu | Launchpad bug 229076 in bzr "'Connection reset by peer' error when branching repository" [Undecided,Confirmed] https://launchpad.net/bugs/229076 | 19:37 |
| cr3 | the problem doesn't occur if I use sftp rather than bzr+ssh | 19:38 |
| awilkins | Lo-lan-do: try | 19:38 |
| awilkins | bzr checkout svn+http://svn.gnome.org/svn/f-spot/trunk | 19:38 |
| Lo-lan-do | awilkins: Seems to work better indeed. Thanks! | 19:39 |
| jam | statik: ping | 19:40 |
| statik | jam: hi there | 19:43 |
| jam | statik: where is the 'merged' plugin | 19:43 |
| abentley | Is anyone here from fluendo? | 19:43 |
| jam | I've gotten several requests for it, probably by the same person | 19:43 |
| statik | jam: bazaar.launchpad.net/~jml/bzr-removable/trunk | 19:44 |
| jam | statik: that is "merged" with a name like "removable" ? | 19:45 |
| statik | jam: we'll have to beat up jml and teach him how to name plugins | 19:45 |
| jam | statik: so should it be locally called "removable"? | 19:45 |
| statik | i guess if a branch is merged that makes it removable | 19:45 |
| asabil | abentley: you will catch more fluendo people is you ask in #gstreamer :p | 19:45 |
| jam | I'm guessing he started it thinking XX and ended up writing YY | 19:46 |
| statik | jam: I think with this plugin you have to add a symlink in your plugin dir, because of how the tree is laid out | 19:46 |
| abentley | asabil: Yes, but someone from fluendo is trying to use bundle buggy, and has misconfigured it to spam me. | 19:46 |
| asabil | lol, I see :) | 19:46 |
| lifeless | abentley: I humbly suggest different default config values :) | 19:48 |
| abentley | Well, I take your point, but there are no defaults, only examples. | 19:49 |
| abentley | I like to use examples that I know work. | 19:49 |
| lifeless | root@localhost then? | 19:49 |
| jam | statik: looking at the log, the last entry is: | 19:49 |
| jam | Add a command to show reasons why a branch cannot be removed. | 19:49 |
| jam | This branch adds 'unremovable' and renames the existing command | 19:49 |
| jam | 'merged-branches' to 'removable'. Both commands have the same structure and | 19:49 |
| jam | use similar code. | 19:49 |
| lifeless | anyhow, I would personally use @example.com | 19:49 |
| jam | statik: so it seems like the plugin name has officially changed, along with the command | 19:50 |
| statik | jam: that makes more sense. | 19:50 |
| statik | i've renamed it locally now | 19:50 |
| jam | statik: I updated the blog post as well | 19:57 |
| statik | excellen | 19:57 |
| statik | t | 19:57 |
| lifeless | abentley: jam: we don't seem to use @property much - is there a reason (other than propertes being a rate thing to use) | 20:01 |
| lifeless | s/rate/rare/ | 20:01 |
| jam | lifeless: because pretending a method is an attribute is something we try to avoid | 20:01 |
| jam | I believe | 20:01 |
| jam | from what I remember, we only really use it for things which used to be attributes | 20:02 |
| jam | but we wanted to make readonly | 20:02 |
| jam | like WT.branch | 20:02 |
| lifeless | well, we tend to use | 20:02 |
| lifeless | def _foo | 20:02 |
| lifeless | foo = property(_foo_ | 20:02 |
| lifeless | there | 20:02 |
| jam | lifeless: I think also because for "@property" you can't do read + write portions | 20:03 |
| jam | so if you want an attribute that can be set under certain conditions | 20:03 |
| lifeless | thats more likely; anyhow, I have a attribute I want to add for these stores | 20:03 |
| jam | you have to do "foo = property(reader, writer, doc)" | 20:03 |
| lifeless | and RemoteRepository needs to forward in the interim | 20:03 |
| jam | lifeless: I don't have any problem with @property, but do you need to forward "setters" as well? | 20:06 |
| asabil | jam: there are various recipes to have RW properties | 20:07 |
| lifeless | no | 20:07 |
| lifeless | someone setting this attribute gets to keep all the pieces | 20:07 |
| lifeless | gnight | 20:22 |
| pickscrape | Does there exist a plugin to diff openoffice documents? | 20:41 |
| demod | pickscrape: i doubt it unless you are using some xml format (.fodt) or use the diff tools plugin to call something external | 21:15 |
| beuno | vila, ping | 21:29 |
| fbond | lifeless: ought I be able to merge between threads in a loom? | 21:44 |
| fbond | i.e. what if I want to move changes down the loom to a lower thread. My first instinct was: `bzr switch {thread below where I want the changes}; bzr create-thread foo; bzr merge -r thread:bar..thread:baz' | 21:45 |
| fbond | But that gets me a traceback :) | 21:46 |
| fbond | Which is obviously a bug, one way or another. I'm wondering if my expectation for it to do the right thing is reasonable? | 21:46 |
| krow | Hi! | 21:48 |
| krow | Is there a simple "how to host my code with bzr with https" | 21:48 |
| krow | ? | 21:48 |
| beuno | vila, unping, email :) | 21:53 |
| beuno | krow, are you having problems using https? | 21:53 |
| krow | beuno: I want to find a hgweb like CGI for bzr. Looking through the manual it implies that this is not an option. | 21:55 |
| krow | beuno: So I am wondering if it exists outside of the manual. | 21:55 |
| beuno | krow, well, have you seen loggerhead? | 21:56 |
| krow | beuno: I've seen it mentioned, but the link I found to it was dead. | 21:57 |
| krow | beuno: I am assuming someone must have done this/wanted it :) | 21:57 |
| beuno | krow, https://launchpad.net/loggerhead/ | 21:57 |
| beuno | krow, working demo: http://bazaar.launchpad.net/~mwhudson/loggerhead/better-navigation/files | 21:58 |
| krow | beuno: Can you push to it via https but allow others to browse via http? It works under apache? | 21:59 |
| beuno | krow, no and no :) | 22:00 |
| krow | beuno: Know of anything that does? | 22:00 |
| beuno | krow, not with bzr, no | 22:01 |
| krow | beuno: Gotcha... | 22:05 |
| pickscrape | demod: amazing what you learn. I wasn't aware of .fodt files: this has actually pointed me at something else I'd been looking for for a while. :) | 22:05 |
| beuno | krow, their will be something eventually, so keep your eye out for it :) | 22:06 |
| demod | pickscrape: ,) | 22:07 |
| pickscrape | Shame it's stuffed everything into three lines though... | 22:07 |
| pickscrape | Is there a decent demonstration of loggerhead anywhere on the net? | 22:07 |
| beuno | pickscrape, on launchpad :) | 22:08 |
| beuno | (code browse *is* loggerhead) | 22:08 |
| pickscrape | eeeeenteresting.... | 22:10 |
| beuno | isn't it? | 22:12 |
| pickscrape | I'm now thinking about using the trac bzr plugin just to track 'mainline' changes and using loggerhead for all other branches etc. | 22:14 |
| pickscrape | Loadsa options... | 22:15 |
| ricardokirkner | hi, I was trying out the sftp (and bzr+ssh) transports. I tried (but was unable to achieve it successfully) to connect using a user that could be authenticated by ssh, but who was not allowed a shell on that machine (which are my requirements). Is this possible in some way? I want to use authentication to check out and commit branches, but I dont want to give those users shell access to my host | 22:18 |
| pickscrape | git provides a 'restricted shell' for this purpose. I wonder how hard it would be to do the same for bzr? | 22:19 |
| ricardokirkner | I am not asking for this to be part of bzr (because I know this has been discussed several times), but merely if anyone has had any experience with this kind of scenarios | 22:22 |
| fullermd | Any of the random "restricted shells" out there should work; you just list bzr as an allowed command. | 22:23 |
| ricardokirkner | so, what I need (on the server side) is to be able to execute the bzr client, even if I have the bzr smart server running? | 22:24 |
| ricardokirkner | fullermd, just to clarify, I am calling the bzr client from a remote machine, not trying to invoke it in the machine I dont have shell access to (but which has the bzr smart server running) | 22:28 |
| jam | beuno: 1.5-final has been officially finished at http://bazaar-vcs.org/bzr/bzr.1.5, I'll try to put together the tarball and the debs, but I might end up asking for help | 22:39 |
| beuno | jam, congrats :) | 22:40 |
| beuno | and, sure, I'll be here | 22:40 |
| === beuno changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | bzr-1.5 is out! | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!