| === frakturfreak_ is now known as frakturfreak | ||
| CyberDomovoy | i have a trouble using bzr to branch on a nfs mount, ("bzr branch ...", $(pwd) is a nfs mounted directory), i get an error saying "Could not acquire lock ... No locks available", googling it told me it is a trouble with nfs locking. But, i have lockd running on both client and server, i tried doing a "mount -o remount,nolock" for my nfs mount, but it tells me "an incorrect mount option was specified" (???). Any idea? | 07:34 |
|---|---|---|
| AfC | Can you generate a bundle of an entire branch? I tried -r 0.. . but that didn't work | 14:50 |
| mathrick | jelmer_ / jelmer__: hi | 14:52 |
| mathrick | mathrick@hatsumi:/tmp$ bzr get https://github.com/dto/iosketch.git | 14:52 |
| mathrick | bzr: ERROR: Invalid http response for https://github.com/dto/iosketch.git/info/refs: Unable to handle http code 0 | 14:52 |
| mathrick | any idea what's wrong? | 14:52 |
| mathrick | git seems pretty happy cloning that repo | 14:52 |
| jelmer__ | mathrick: hi | 14:56 |
| mgz | I get a 200 from that url with curl, but if I add an Accept-Encoding header I don't get a valid response back | 14:56 |
| jelmer__ | mathrick: when cloning from github, use git:// | 14:56 |
| jelmer__ | mathrick: they don't support "dumb" access over http at the moment | 14:57 |
| mathrick | jelmer__: oh | 14:57 |
| mathrick | are there different modes of access over HTTP for git? | 14:57 |
| jelmer__ | mathrick: yeah, two | 14:58 |
| mathrick | odd | 14:59 |
| mathrick | jelmer__: but speaking of github, I have another odd failure | 15:00 |
| mathrick | ah, not actually github | 15:00 |
| mathrick | just git | 15:00 |
| mathrick | 3623kB 4kB/s - finding revisions to fetch 132 <-- huh, that's a lot of data sent for 132 revs | 15:02 |
| mathrick | jelmer__: okay, got it | 15:02 |
| mathrick | mathrick@hatsumi:/tmp$ bzr get http://common-lisp.net/project/parenscript/git/parenscript | 15:02 |
| mathrick | bzr: ERROR: [Errno 2] No such file or directory: 'pack-027b9225cdb4a06f422e6321d92328dfb7103b92.pack' | 15:02 |
| mathrick | that's after the above revision-finding | 15:02 |
| jelmer__ | mathrick: git access over "dumb" http is really inefficient | 15:03 |
| mathrick | again git seems perfectly happy | 15:03 |
| mathrick | jelmer__: I see. Well, that's what I got for the URL, so guess can't blame anyone but the author here | 15:03 |
| mathrick | but I'm more concerned with the fact this thing fails ultimately | 15:04 |
| * jelmer__ is trying locally | 15:05 | |
| === jelmer__ is now known as jelmer | ||
| mathrick | jelmer: does it fail for you too? | 15:10 |
| jelmer | mathrick: it's working so far.. fetching revisions 506/609 | 15:11 |
| mathrick | huh | 15:11 |
| mathrick | it errors out right as it tries to fetch revisions for me | 15:11 |
| mathrick | that, or during revision-finding, hard to say | 15:13 |
| mathrick | jelmer: it might be some outdatedness in my setup, lemme check | 15:13 |
| mathrick | bzr-git 0.5.0 | 15:14 |
| mathrick | seems to be in my ~/.bazaar/plugins and not distro package | 15:14 |
| jelmer | mathrick: yeah, that's fairly old | 15:14 |
| jelmer | mathrick: You might also want to try the daily builds PPA | 15:14 |
| mathrick | I will, yeah | 15:14 |
| mathrick | huh | 15:15 |
| mathrick | now I got 0.5.2 from distro, and it errors out with "not a branch" | 15:15 |
| AfC | jelmer: is the bzr-git 0.5.2 from Ubuntu Maverick sufficient, or is this one of those "would have been updated if we could convince Canonical to SRU the thing" occasions? | 15:15 |
| jelmer | AfC: I think it's not really about being able to convince Canonical to accept the SRU, it's more about the effort involved in doing a SRU vs the benefits | 15:17 |
| jelmer | AfC: SRU's can't really be new upstream releases, and cherrypicking bugfixes is often tricky (and also carries risks) | 15:18 |
| AfC | jelmer: sure. I guess you know about mere users's frustration at constantly being told "it works in the next (unreleased) release of the distro" | 15:19 |
| AfC | For me personally your work has always been caught by that. Kinda a shame. (for example, I want almost 8 months without being able to use Bazaar to work on GNOME stuff. It's working now, though, for which I compliment you and the others working on bzr-git!) | 15:20 |
| jelmer | AfC: Yes, I realize that - I've hit it as well myself. | 15:20 |
| jelmer | AfC: But this isn't specific to Bazaar, it's specific to bleeding edge code in general - I see the same thing with Samba 4. | 15:21 |
| jelmer | well, specific to bleeding edge code and the fact that releases happen only every 6 months | 15:21 |
| mathrick | jelmer: where exactly is the daily build PPA you mentioned? | 15:21 |
| jelmer | mathrick: https://launchpad.net/~bzr/+archive/daily | 15:21 |
| AfC | [as a slightly broader theme, Fedora is utterly unusable because no one runs release - developer throw stuff at rawhide without really caring about it, and meanwhile corporate sustains RHEL, but no one is actually trying to live on current and the result is always "wait for the next release"] | 15:22 |
| AfC | jelmer: right, but if we never get the code [in Ubuntu's terminology, SRU | 15:22 |
| AfC | jelmer 'ed] then the code will always be bleeding edge :) | 15:23 |
| AfC | anyway, not meaning to nag | 15:23 |
| jelmer | AfC: SRU's are fairly heavyweight (for a good reason, we don't want to break existing stable users) | 15:23 |
| AfC | Yeah, but when shit wholesale doesn't work, then who cares that it's "not broken"? | 15:23 |
| jelmer | AfC: http support in bzr-git was only added recently anyway - most people use git:// | 15:24 |
| AfC | Of course, we are dealing with this in GNOME land right now - GTK 3.0 is still not out and GNOME 2.26 aka GNOME 3.0 is due out in less than three months. Total dogs breakfast. | 15:25 |
| mathrick | jelmer: ah, but that doesn't have bzr-git in it, does it now? | 15:25 |
| mathrick | no, it does | 15:26 |
| mathrick | it showed something different when I googled | 15:26 |
| * mathrick confused | 15:26 | |
| jelmer | mathrick: https://launchpad.net/~bzr/+archive/daily lists it for me | 15:29 |
| mathrick | yeah, it does | 15:29 |
| mathrick | jelmer: re: SRU, bzr seems to be particularly hard-hit by always being in the "will work in the next release" limbo | 15:32 |
| === AfC is now known as AfC|zzz | ||
| mathrick | I'm not quite sure what makes it so prone, but it's always there | 15:32 |
| jelmer | mathrick: I'm not sure either :-/ | 15:34 |
| mathrick | probably because there's so much tricky interop code (hello, Mr Jelmer sir), which never quite works until it's been bashed at by many people for a long time, which means every time you hit a bug, you're pretty much required to wait or go to the -dev anyway | 15:34 |
| * jelmer will probably be a bit more involved in the Ubuntu packaging of Bazaar as of January | 15:34 | |
| mathrick | which suggests it'd be actually stabler for end-users if they could get recent packages in stable | 15:35 |
| jelmer | mathrick: I think if the packages are that error prone we should probably not have them in stable releases at all :-/ | 15:35 |
| mathrick | jelmer: but then they will never get tested and brought up to the real-world quality | 15:36 |
| mathrick | at some point, the shit has to hit the fan. If you want bzr to talk to git and SVN seamlessly, somebody has to test it in real-world broken scenarios | 15:36 |
| jelmer | mathrick: Users who are interested can always use the daily builds PPA or backports | 15:36 |
| jelmer | and that has a much quicker feedback + fix cycle | 15:37 |
| mathrick | true | 15:37 |
| jelmer | mathrick: fwiw the clone of the http git repo just succeeded here | 15:37 |
| mathrick | yeah, it's at 469 / 609 here with PPA | 15:37 |
| exarkun | Urff. Negative revision numbers? | 15:41 |
| exarkun | Not quite what I was going for. | 15:41 |
| exarkun | How should I extract some (quite well isolated) changes from one branch and put them into another unrelated branch, preserving their history? | 15:42 |
| exarkun | I thought rebase would work, but it kept too much history. | 15:42 |
| exarkun | does the remove-revisions plugin do what I want? | 15:52 |
| mathrick | exarkun: what exactly do you mean by "preserving their history"? | 16:00 |
| exarkun | There's 11 or 12 revisions, with their own diffs and commit messages and such | 16:03 |
| exarkun | I should have put them in a different branch than I did | 16:03 |
| exarkun | I want what I would have gotten if I'd put them in the right branch in the first place | 16:03 |
| mathrick | exarkun: then probably bzr-fastimport is what you want | 16:09 |
| exarkun | Thanks | 16:10 |
| mathrick | it won't preserve the tree equivalence (that is, you won't be able to merge properly before and after), but the commits will look the same | 16:10 |
| exarkun | sounds like just what I want | 16:10 |
| mathrick | jelmer: so yes, a PPA bzr-git works fine with that repo, thanks | 16:14 |
| jelmer | mathrick: great | 16:14 |
| mathrick | I also need a way to export all revisions from one repo (shared repo, not branch) into another, and move all the branches based in that repo there | 16:14 |
| mathrick | because it's corrupted and hits me hard, particularly when I touch anything git-related | 16:15 |
| mathrick | any idea how to do it? | 16:15 |
| mathrick | I don't mind a bit of programming against bzrlib if that's what it takes | 16:15 |
| jelmer | mathrick: this is a bzr repo? | 16:19 |
| mathrick | yes | 16:20 |
| jelmer | mathrick: how is it corrupted? | 16:20 |
| mathrick | jelmer: sec, I'll get the errors it throws | 16:20 |
| exarkun | humph, `bzr: ERROR: Unable to import library "fastimport": No module named fastimport`? I branched fastimport directly into my ~/.bazaar/plugins/ | 16:22 |
| jelmer | exarkun: do you have the fastimport python module installed? | 16:24 |
| txdv | is there a standard for the bzr commit message? I know that the first line has to be short, but do i have to break up the subsequent lines up or can i use long long lines? | 16:25 |
| exarkun | jelmer: All I did was branch fastimport into ~/.bazaar/plugins. Is there something beyond that I should do? The README suggests that's intended to be sufficient. | 16:25 |
| jelmer | exarkun: you need the python-fastimport package or the fastimport module from http://launchpad.net/python-fastimport | 16:26 |
| jelmer | txdv: it's up to you | 16:26 |
| exarkun | I see | 16:26 |
| jelmer | exarkun: I've clarified the error message | 16:28 |
| exarkun | cool, works now, thanks | 16:29 |
| txdv | bzr so fucking lacks --amend | 16:38 |
| exarkun | oh man | 17:07 |
| exarkun | trying to merge that fast-imported stuff, http://codepad.org/stXoQ9jp | 17:08 |
| jelmer | exarkun: what are you trying to do? | 17:09 |
| exarkun | fix one tiny mistake :( | 17:10 |
| jelmer | exarkun: are you trying to merge into an empty branch? | 17:10 |
| exarkun | yes | 17:10 |
| jelmer | exarkun: That doesn't work at the moment - there's an open bug about it. Is there any reason for not pulling? | 17:11 |
| jelmer | txdv, exarkun: yes, we need better tools for history editing :-/ | 17:11 |
| exarkun | no, I just didn't know there was a special case around empty branches for merging | 17:11 |
| jelmer | exarkun: it's a bit of an odd situation. hg and git both simply default to a pull in this situation, perhaps that's what we should do too for the moment. | 17:35 |
| exarkun | jelmer: even refusing to merge would be better than corrupting the target branch :) | 17:36 |
| exarkun | I don't have an opinion beyond thinking that the current behavior is kinda bad. | 17:36 |
| mathrick | exarkun: there's no special case really, it just fails because of the nature of the operation | 17:36 |
| exarkun | mathrick: it's a special case for me. | 17:36 |
| mathrick | it's that git and hg both silently replace it with pull when possible | 17:37 |
| mathrick | which bzr doesn't | 17:37 |
| exarkun | and I have no experience with git or hg in this situation | 17:37 |
| mathrick | I've seen good arguments against bzr's behaviour | 17:37 |
| exarkun | so don't think I'm trying to impose another system's behavior on bzr :) | 17:37 |
| mathrick | exarkun: well, they basically go "oh, I can pull, so I'll just interpret it as a pull request instead of merge" | 17:37 |
| mathrick | bzr, OTOH, sticks to merge unless you tell it not to with --pull | 17:38 |
| exarkun | merge and data corruption | 17:38 |
| exarkun | :) | 17:38 |
| mathrick | and pull and merge are two different situation. Pull can succeed on an empty tree, merge not really | 17:38 |
| mathrick | exarkun: sure, it _shouldn't_ corrupt the tree. That is clearly a bug. But it also helps to know that merge on an empty tree is sort of meaningless | 17:38 |
| mathrick | s/situations/operations/ | 17:39 |
| exarkun | whereas merge on any non-empty tree is not sort of meaningless. so how is it not a special case? | 17:39 |
| mathrick | exarkun: because it's not _coded_ to be a special case. It's just an edge condition in which the algorithm fails. So it's the opposite, it fails to special-case the situation it should | 17:40 |
| exarkun | alright | 17:40 |
| mathrick | sort of like throwing -1 at sqrt() function that's not prepared to deal with negative numbers | 17:41 |
| mathrick | jelmer: sorry, I got completely sidetracked there, lemme get the error | 19:08 |
| mathrick | jelmer: it doesn't seem to error out in the same way as before so far, but one of the things I get is that when I do "bzr get git://github.com/dto/iosketch.git", I get "updating git map" about 20 times | 19:30 |
| mathrick | some of them are like 1/2, some 1/41, and now one 1/1245 | 19:31 |
| jelmer | mathrick: that's because of the repository you're cloning into | 19:31 |
| peitschie | hi everyone :) | 21:54 |
| RenatoSilva | Ursinha-afk: help me please | 23:16 |
| === spiv changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | 2.3b4 is officially out ! (rm vila) | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!