| poolie | spiv, call in a sec | 00:01 |
|---|---|---|
| === vk5foss is now known as kgoetz | ||
| Necoro | hi there | 00:19 |
| Necoro | anyone an idea: http://rafb.net/p/v6LWKW51.html | 00:19 |
| Necoro | ? | 00:19 |
| beuno | Necoro, Permission denied (publickey). | 00:20 |
| beuno | it shouldn't be tracebacking | 00:20 |
| beuno | spiv, ^ | 00:20 |
| beuno | Necoro, but, it's likely due to Launchpad being down | 00:21 |
| Necoro | beuno: hmm - the web service is up and running ;) | 00:21 |
| Necoro | but the traceback is strange though | 00:21 |
| Necoro | AttributeError: 'ProtocolThreeDecoder' object has no attribute '_in_buffer' | 00:21 |
| jml | Necoro: the codehosting service is not yet fully up. | 00:21 |
| beuno | Necoro, the web service, but not the code hosting | 00:21 |
| Necoro | ok | 00:23 |
| Necoro | then I'll try again tomorrow morning ;) | 00:23 |
| Necoro | or in a few hours - depending on how long I stay awake | 00:24 |
| spiv | Necoro: that's a bug in -Dhpss | 00:25 |
| spiv | Necoro: it's fixed in bzr.dev (and 1.7rc I think) | 00:25 |
| Necoro | spiv: *g* - bugs in debug code pathes are always great :D | 00:25 |
| lifeless | spiv: did you see my comment on that merge request? | 00:30 |
| lifeless | down to 15 failures btw | 00:31 |
| spiv | lifeless: yeah, I did | 00:35 |
| spiv | lifeless: it's still flagged in my inbox as something to address | 00:35 |
| lifeless | cool | 00:36 |
| lifeless | 2.45 seconds now btw | 00:36 |
| lifeless | I've seen hg as low as 2.37 | 00:37 |
| lifeless | so, without plugins, my bzr branch is faster :P | 00:38 |
| spiv | When I land faster-startup (tomorrow hopefully) that'll get you another 30ms :) | 00:38 |
| lifeless | btw, did you try my status branch out ? | 00:42 |
| poolie | nice | 00:42 |
| === kiko-afk is now known as kiko | ||
| lifeless | ok, all tests pass | 01:20 |
| lifeless | (all the intertree unit tests I mean) | 01:20 |
| lifeless | still 2.45 seconds with everything passing, which is good | 01:22 |
| lifeless | lots of fat in there still I think | 01:22 |
| lifeless | breakfast now, test-parameterisation for this new extension after that, then people can pplay | 01:23 |
| jml | when's next bzr rc cut due? | 01:25 |
| jml | jam: ^^ | 01:26 |
| jdobrien | i f | 01:27 |
| jdobrien | i know this isn't a bzr question but, i know there's a way of getting a line count from bzr diff by piping it through something else. but i can't remember how | 01:28 |
| jml | jdobrien: bzr di | wc -l will get you a line count | 01:28 |
| jdobrien | that's it! thanks! | 01:28 |
| jml | jdobrien: but piping through 'diffstat' is also sometimes useful | 01:28 |
| jdobrien | jml: thank you | 01:28 |
| jdobrien | jml: diffstat, very nice | 01:29 |
| === mw is now known as mw|out | ||
| === ajaksu_away is now known as ajaksu | ||
| lifeless | 2.42 seconds :P | 02:40 |
| lifeless | btw | 03:21 |
| lifeless | there is a faster status branch pushed to ...readdir | 03:21 |
| lifeless | I'm tuning now, but its currently 1.4/3.84 seconds faster | 03:22 |
| mwh | lifeless: does it mean a faster diff against wt too? | 03:22 |
| lifeless | mwh: yes | 03:23 |
| lifeless | mwh: diff is built on iter_changes | 03:24 |
| mwh | right | 03:24 |
| * mwh tries to think what else is | 03:24 | |
| mwh | merge, i guess? | 03:24 |
| mwh | but that's between revision trees i suppose | 03:24 |
| lifeless | merge does a local diff | 03:32 |
| lifeless | so yes, merge on large trees should feel faster | 03:33 |
| lifeless | mwh: how long does 'bzr st' take you today on lp? | 03:34 |
| jml | ~540ms for me. | 03:35 |
| AfC | Is bzr 1.7-rc1 something you want me testing? (alternative answers to "duh, yes" are "ooops, no, it's horridly broken don't touch" and "wait until 1.7rc2" and "no stick with 1.6.1 for day to day use" and "please test the $X which we want feedback on") | 03:35 |
| lifeless | yah, you would see only a small improvement | 03:35 |
| lifeless | AfC: rc testing feedback is always welcome; I don't know if there are specific improvements there that are relevant to you | 03:36 |
| AfC | {shrug} | 03:36 |
| AfC | Then I'll pull it in. | 03:36 |
| lifeless | if 1.7c1 was horribly broken the IRC topic would likely say so | 03:36 |
| AfC | Uh huh | 03:36 |
| AfC | (I'm more getting at the tension between "it was just a snapshot on a given day" and "our dev tip is where it's at, but don't use that") | 03:37 |
| lifeless | oh | 03:46 |
| lifeless | well, I live ahead of tip myself; I think anyone that is interested can safely run tip - just need to track the rss feed for it to know what changes are occuring | 03:47 |
| jml | AfC: use the tip of the bzr 1.7 branch if you want to test. It's got a couple of fixes that aren't in the rc. | 03:53 |
| fullermd | I track tip, 'cuz it makes me feel special. | 03:54 |
| AfC | fullermd: you *are* special. Don't let anyone tell you different. | 03:56 |
| fullermd | That's what the counselors always told me, while they were smiling and backing away. | 03:56 |
| fullermd | Anyway, whaddaya get if you run released versions, anyway? All you do is trip over bugs that other people have already found. Where's the joy in that? | 03:57 |
| * spiv sometimes thinks that "Following the tip" sounds like "walking the plank" | 03:58 | |
| fullermd | I mean, that's all like "You: I found this bug lifeless: Yeah, it's bug 12345". | 03:58 |
| ubottu | Launchpad bug 12345 in isdnutils "isdn does not work, fritz avm (pnp?)" [Medium,Fix released] https://launchpad.net/bugs/12345 | 03:58 |
| spiv | Especially when lifeless says he lives ahead of the tip :) | 03:58 |
| fullermd | With tip, you can be all "You: I found this bug lifeless: o_O" | 03:58 |
| spiv | fullermd: the joy is that if the bugs are already known, then maybe the workarounds are too ;) | 03:59 |
| jml | spiv: 'patches accepted' is not a workaround. | 03:59 |
| fullermd | Piffle. What kinda wimp wants to live like THAT? | 03:59 |
| fullermd | That's like getting pre-digested food. | 04:00 |
| fullermd | Gotta have something you can sink your teeth into. | 04:00 |
| fullermd | Even if it responds by sinking teeth into you... | 04:00 |
| lifeless | mwh: so, did you try the branch? or just curious about whether it will help you ? | 04:49 |
| spiv | poolie: there's a mostly complete http://bazaar-vcs.org/SmartPushAnalysis1.8 now. I'm off to lunch. | 04:59 |
| poolie | hey, great | 05:01 |
| poolie | i was literally talking about it to thumper right now | 05:01 |
| * spiv does a couple last touches | 05:04 | |
| spiv | Ok, really lunch now :) | 05:04 |
| spiv | poolie: buried in the "analysis" section is a description of the 10s win I mentioned this morning. | 05:06 |
| poolie | spiv, can you tell me more (or add more) to that page about the streaming-push work | 05:06 |
| poolie | like sending a put_revisions_stream rather than working on packs | 05:07 |
| === Spaz is now known as Kittens | ||
| === mario__ is now known as pygi | ||
| === TheMuso_ is now known as TheMuso | ||
| mwh | lifeless: no, i didn't get around to it | 06:10 |
| poolie | spiv, are you back? | 06:16 |
| spiv | poolie: I am | 06:21 |
| poolie | quick call? skype or pots? | 06:21 |
| spiv | Either's fine with me. | 06:22 |
| jml | will 'bzr upgrade' in a shared repo upgrade the branches in that repo? | 06:26 |
| lifeless | jml: it didn't do so in the past, but I don't know if it does now | 06:36 |
| jml | lifeless: thanks. | 06:39 |
| lifeless | jml: easy enuff to find out | 06:39 |
| jml | lifeless: yeah, I know. | 06:39 |
| jml | the answer is "no" | 06:40 |
| vila | hi all | 06:52 |
| lifeless | jml: ping | 07:11 |
| jml | lifeless: pong. | 07:12 |
| lifeless | jml: AIUI bzr never stacks unless --stacked is passed | 07:12 |
| lifeless | I refer to your lp documentation | 07:13 |
| lifeless | if it is stacking without --stacked being passed, or a local default being set, I consider it a pretty big bug we should fix | 07:13 |
| jml | lifeless: ok. | 07:13 |
| lifeless | (because stacking generates a truncated database, it can lead to unrecoverable data loss if people think they actually have a full branch) | 07:14 |
| jml | lifeless: not 100% sure what to say to that. | 07:14 |
| lifeless | (and then delete something) | 07:14 |
| jml | lifeless: the work I've been doing on Launchpad has been predicated on the default stacking policy stuff in Bazaar 1.7. | 07:15 |
| lifeless | jml: I understood that policy to control *where* not *if* | 07:15 |
| jml | lifeless: ok, then that's definitely something to raise on the Bazaar mailing list. | 07:17 |
| mwh | <lifeless> jml: AIUI bzr never stacks unless --stacked is passed | 07:17 |
| mwh | not true, a*i*ui | 07:17 |
| lifeless | poolie: please read the above, then comment | 07:17 |
| lifeless | from 16:11 < lifeless> jml: ping | 07:18 |
| jml | lifeless: in any case, whether or not Bazaar needs to grow a local configuration option is incidental to Launchpad. | 07:24 |
| jml | lifeless: if the 1.7 release gets one I'll update my instructions. | 07:24 |
| jml | lifeless: this rollout only defines a stacking policy for projects on a pre-configured shortlist, so the impact is manageable. | 07:26 |
| poolie | hi | 07:32 |
| poolie | hm | 07:33 |
| poolie | my understanding was that it should not normally stack unless --stacked was given | 07:33 |
| poolie | but when pushing to eg launchpad the server could tell it to do so | 07:33 |
| jml | this matches how bzr behaves at the moment. | 07:35 |
| poolie | yay | 07:40 |
| poolie | i'm so haappy to hear thaht | 07:40 |
| poolie | that* | 07:40 |
| jml | :) | 07:41 |
| jml | ok. well I'm going to take a few deep breaths to recover from that little shock. | 07:42 |
| poolie | lifeless: is this ok with you? | 07:45 |
| lifeless | poolie: I don't really feel comfortable with that, but if you are, well, I have bigger fish to fry. | 07:45 |
| poolie | jml, can we change this later so the server just sends a suggested url but doesn't turn it on? | 07:47 |
| jml | poolie: I'm not sure I follow. At the moment, all the server does is specify a URL in a control.conf file. | 07:48 |
| jml | (and a billion things to deal with the fallout of that & Launchpad's own infrastructure) | 07:49 |
| jml | poolie: presumably Bazaar can change at a later stage to respond differently to this URL. | 07:50 |
| poolie | ok | 07:50 |
| poolie | lifeless: thanks for the status update that was super useful | 07:51 |
| poolie | aside from being a nice set of numbers | 07:51 |
| lifeless | I'd like to set usertest run across it | 07:52 |
| poolie | thanks for noting that it may be bottoming out too | 07:52 |
| poolie | ok | 07:52 |
| poolie | you can, or i can on escudero | 07:52 |
| lifeless | is there a HOWTO? | 07:53 |
| poolie | yes, just google it | 07:53 |
| lifeless | http://rabbit.eng.miami.edu/dics/amerlen/length08.txt ? | 07:53 |
| lifeless | thats the only hit | 07:53 |
| lifeless | for "'usertest' 'escudero'" | 07:53 |
| poolie | hee hee | 07:53 |
| poolie | http://people.ubuntu.com/~ianc/plugins/usertest/doc/usertest-tutorial.html | 07:54 |
| lifeless | uhm | 07:54 |
| lifeless | I meant on escudero | 07:54 |
| poolie | https://wiki.canonical.com/Orcadas | 07:54 |
| poolie | i mistyped | 07:54 |
| poolie | i'll be here for a few more hours so i'm going to take a break now | 07:55 |
| lifeless | ok | 07:55 |
| lifeless | well, I might poke tomorrow | 07:55 |
| lifeless | reading those two docs suggests to me the answer is 'no there is no howto for running a specific branch' | 07:55 |
| lifeless | so I'll look at it tomorrow | 07:55 |
| poolie | i can set it up | 07:55 |
| lifeless | gnight, enjoy your call :P | 07:55 |
| poolie | it's in the doc on that machine | 07:56 |
| lifeless | branch is http://people.ubuntu.com/~robertc/baz2.0/readdir | 07:56 |
| lifeless | thanks! | 07:57 |
| === Kittens is now known as Spaz|hedonism | ||
| === Spaz|hedonism is now known as Kittens | ||
| imyojimbo | hi, im trying to push a branch to lp , and i get "The server's host key is not cached in the registry" | 08:36 |
| Odd_Bloke | poolie: Did you see my email regarding payment for the summer? | 09:02 |
| poolie | Odd_Bloke: hi there | 09:03 |
| poolie | yes let's see about that | 09:03 |
| Odd_Bloke | poolie: I'm at work ATM, so email is better than IRC. :) | 09:07 |
| poolie | ok | 09:14 |
| poolie | sent | 09:25 |
| Odd_Bloke | poolie: Thanks. | 09:27 |
| Odd_Bloke | I'll deal with it when I get home. | 09:27 |
| Odd_Bloke | Or possibly tomorrow, I'm probably busy this evening. | 09:27 |
| poolie | maybe we can talk tomorrow my time/uk evening | 09:27 |
| poolie | lifeless: should be running now in http://benchmark.bazaar-vcs.org/usertest/log/usertest.log.inprogress | 09:34 |
| awilkins | ls | 09:35 |
| awilkins | Oops | 09:35 |
| robsta | hi | 12:57 |
| robsta | is there anything new in the BzrGit department? | 12:57 |
| === bac_afk is now known as bac | ||
| Odd_Bloke | robsta: jelmer wrote (most of) it, so he'll probably know. | 13:03 |
| robsta | is it usable already? | 13:05 |
| === kiko is now known as kiko-afk | ||
| lifeless | robsta: it can clone locally I believe | 13:49 |
| robsta | ok, guess i'll stick to svn server-side for the time being, then | 13:59 |
| === mw|out is now known as mw | ||
| === cody-somerville_ is now known as cody-somerville | ||
| antoranz | Hi guys! | 14:47 |
| antoranz | is it possible to list all the revisions in a branch but ordered by date instead of "revision/branch"? | 14:47 |
| antoranz | I mean.... instead of having the revision tree, I want toget all the revisions ordered by date | 14:48 |
| antoranz | is that even possible at all? | 14:48 |
| vila | jam: ping | 14:50 |
| Tak | in a bound checkout, does `bzr cat` hit the server? | 14:56 |
| bob2 | I'd assume yes for lightweight,no for regular | 14:57 |
| Tak | good | 14:58 |
| === raz is now known as razZz | ||
| === razZz is now known as raz | ||
| === Ng_ is now known as Ng | ||
| === jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | bzr-1.6.1 now available! please test bzr-1.7rc2 | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | ||
| Leonidas | how comes that bzr mv -q still shows what it moves? | 16:33 |
| james_w | Leonidas: it's a bug I expect | 16:34 |
| Leonidas | Yeah, I think so too. I just encountered again when I wrote it in a script | 16:34 |
| james_w | Leonidas: I would guess it's an easy fix | 16:35 |
| Leonidas | james_w: probably. It's not a problem currently, I just wanted to tell that to the developers, so they can fix it when someone has a bit of spare time. | 16:36 |
| james_w | Leonidas: a bug report would be a better way of doing that of course | 16:37 |
| Leonidas | james_w: sure, I'll write one in a moment. Just wanted to make sure I'm not the only one with this problem. | 16:38 |
| james_w | thanks, I'll check now | 16:38 |
| james_w | yup, I see it too | 16:38 |
| Leonidas | CLOSED: worksforme with the comment: "Do you think we'd miss something like this?" would leave me standing like an idiot ;) | 16:39 |
| james_w | true :-) | 16:39 |
| === ajaksu is now known as ajaksu_away | ||
| Leonidas | james_w: there it is: https://bugs.launchpad.net/bzr/+bug/271790 | 16:47 |
| ubottu | Ubuntu bug 271790 in bzr "bzr move ignores quiet option" [Undecided,New] | 16:47 |
| james_w | Leonidas: thanks, I triaged it | 16:51 |
| Leonidas | cool, let's see how it'll continue :) | 16:55 |
| Kittens | meow | 16:55 |
| Kittens | oh my | 16:56 |
| Kittens | 1.7 already? O_o | 16:56 |
| Kittens | (well, an rc, but still) | 16:56 |
| Kittens | did you hire a team of slaves or such? | 16:56 |
| awilkins | Kittens: 1.7 was hot on the heels of 1.6 | 16:58 |
| awilkins | 1.6 had a over-long release cycyle | 16:58 |
| Kittens | ah :p | 16:58 |
| * rocky is comforted by the fact that there are so few changes between 1.7rc1 and 1.7rc2 | 16:58 | |
| * awilkins just wants them to merge his switch-to-sibling patch so he can stop maintaining his own builds | 17:01 | |
| awilkins | markh: Is it hard to build the "exe" version? | 17:01 |
| Verterok | awilkins: ping | 17:35 |
| awilkins | Verterok: pong | 17:35 |
| Verterok | awilkins: hey there! | 17:35 |
| Verterok | awilkins: patch merged, and also a few other fixes/enhancements in bzr-java-lib (also in bzr-eclipse) | 17:36 |
| awilkins | Verterok: Excellent :-) | 17:38 |
| awilkins | Verterok: I love it when my patches get merged, I don't have to maintain the branch anymore :-) | 17:39 |
| Verterok | awilkins: hehe, indeed. | 17:39 |
| awilkins | Going to have to keep that callisto branch going though, methinks | 17:40 |
| awilkins | At least until my PM badgers Borland into coughing up upgrade licenses | 17:41 |
| Verterok | awilkins: (don't remember if already told this) about the dependency on core.expressions it's only used in the refresh hook | 17:41 |
| awilkins | So we can use the Ganymede version insdtead of Callisto | 17:41 |
| awilkins | Verterok: Yes... the refresh seems to work OK, so I'm not sure if it breaks anything to be on Callisto | 17:41 |
| awilkins | Is there any specific behaviour that it enables? | 17:41 |
| Verterok | awilkins: that's is only for a specific layout | 17:42 |
| Verterok | awilkins: when the project root is below the branch root | 17:42 |
| awilkins | Verterok: Flat or hierarchical or something else? | 17:42 |
| awilkins | Ah | 17:42 |
| awilkins | So it would come into play on bzr-eclipse, for example | 17:43 |
| Verterok | awilkins: i.e: bzr-eclipse project layout: mutliple projects in one branch | 17:43 |
| Verterok | yes | 17:43 |
| awilkins | It doesn't affect most of my stuff | 17:43 |
| Verterok | awilkins: that was my point :) I assume you can remove the refresh hook and so the core.expressions deps | 17:43 |
| awilkins | Verterok: What exactly is the bit that needs that version? Because if you just take the version number out of the manifest, it compiles and appears to run ok. | 17:49 |
| awilkins | And a version of "3.2.100" suggests a callisto component to my mind | 17:49 |
| Verterok | awilkins: I think the 3.2.100 was added in Europa (but just guessing) | 17:52 |
| Verterok | awilkins: I never specified a version :p | 17:52 |
| awilkins | Verterok: It's true that I can't find a 3.2.100 version in the Callisto updates, but a europa-specific component should be 3.3, no? I suspect it's a patched version of a europa-compatible library | 17:53 |
| awilkins | Sorry, callisto-compatible | 17:53 |
| awilkins | That would fit the version number scheme | 17:53 |
| Verterok | awilkins: here (3.4) seems to compile without the version number | 17:54 |
| awilkins | Also does so for 3.2 | 17:54 |
| Verterok | awilkins: the version scheme is not exactly like that :) | 17:54 |
| awilkins | Well, it should be :-) | 17:55 |
| Verterok | awilkins: mayor.minor.bug-fix, mayor change *only* if there are api breaks, minor when there are new api or visible changes | 17:55 |
| awilkins | Verterok: It just makes a sort of internal sense to me that a component of version 3.2 has had the same API since Eclipse 3.2 | 17:57 |
| awilkins | Since there are also 3.4s in Ganymede but not in Callisto | 17:57 |
| awilkins | esp. for actual eclipse bits | 17:57 |
| Verterok | awilkins: in ganymede, core.expressions is in version 3.3 :p | 17:58 |
| Verterok | awilkins: http://wiki.eclipse.org/index.php/Version_Numbering <- from there I taked my lame explanation of versions numbers :) | 17:59 |
| awilkins | Yes, but you have to admit that the large amount of "3.2" components in Callisto, and 3.3 in Europa, and 3.4 in ganymede... well, I reckon there's a convention operating within the rules there :-) | 18:01 |
| awilkins | What would fail if it wasn't working properly on this version | 18:01 |
| Verterok | awilkins: sure, it makes sense that most of the componentes get bumped to 3.3, 3.4, etc :) | 18:01 |
| awilkins | BUt if the API does not break... then not | 18:02 |
| awilkins | Hence 3.3. on Ganymede, etc | 18:02 |
| Verterok | awilkins: right :) | 18:02 |
| * Verterok just realized that bzr-eclipse should be 1.0.99 :p | 18:02 | |
| * awilkins has had to revise client code several times, you naughty dog | 18:03 | |
| awilkins | :-P | 18:03 |
| Verterok | :) | 18:03 |
| awilkins | Since you didn't choose a version number, I suggest it is removed | 18:04 |
| awilkins | Since it compiles just fine here | 18:04 |
| Verterok | awilkins: ah, all tests passing on *nix :-D | 18:04 |
| awilkins | And you don't support 3.2 anyway because you use 3.3 components | 18:04 |
| Verterok | awilkins: sure, I'll remove it in my next commit | 18:04 |
| awilkins | I have a little patch for your /tmp dir stuff | 18:05 |
| awilkins | Hmm. | 18:06 |
| Verterok | awilkins: patches are more than welcome :) | 18:06 |
| awilkins | Verterok: They fail to start a client here | 18:21 |
| awilkins | Verterok: My laptop is passing. | 18:21 |
| Verterok | awilkins: the client don't start? | 18:22 |
| Verterok | awilkins: also I added a few goodies related to preferences, let me know if the chicken-egg issue is solved for your case :) | 18:23 |
| awilkins | Verterok: It doesn't seem to be registering the client factories before it asks to create one | 18:35 |
| awilkins | It calls into createClient and factories is an empty mapo | 18:36 |
| Verterok | awilkins: hmm, let me check | 18:36 |
| Tak | argh, why does `bzr diff` return a nonzero value on a non-error condition? | 18:36 |
| awilkins | I'll trap my working one and see where regstierAdapterFactory is getting called during the tests | 18:36 |
| Verterok | Tak: it indicates the result of the diff | 18:37 |
| Verterok | Tak: take a look at the end of: 'bzr help diff' | 18:37 |
| Verterok | awilkins: it should be in TestsConfig/TestConfig (If I remember ok) | 18:38 |
| Tak | I see what they mean | 18:38 |
| Tak | but the shell treats !0 as an error condition and acts accordingly | 18:39 |
| fullermd | diff(1) returns non-zero on differences too. | 18:39 |
| awilkins | Verterok: Badgers, my fault | 18:40 |
| awilkins | I'm running with xmloutput 0.5 | 18:40 |
| Tak | meh, it does? I guess that answers my question then | 18:40 |
| awilkins | My thoughts on that are ; since bzr-java-client can manipulate the PLUGIN PATH, it could have it's own internal xmloutput plugin | 18:41 |
| awilkins | But it probably needs a test to check the plugin version | 18:41 |
| Verterok | awilkins: oh, ok. I was thinking that maybe the new "lightweight" checks for the executable broken something on win32 | 18:41 |
| awilkins | Verterok: All the bits of code I suspected haven't changed between our branches, I think | 18:42 |
| * awilkins pulls xmloutput | 18:42 | |
| Verterok | awilkins: that would be nice, I've been playing with eclipse regarding this "bundled-xmloutput", and it seems quite simple to achieve | 18:43 |
| Verterok | awilkins: do you know if the PLUGIN PATH override the default plugins location? | 18:43 |
| awilkins | Verterok: I don't know | 18:49 |
| awilkins | Verterok: It all passes here apart from index because I don't have the plugin | 18:49 |
| Verterok | awilkins: great, I must add a conditional in the execution of the test related to bzr-search | 18:50 |
| awilkins | Now I'll try a startup in a clean workspace | 18:51 |
| * Verterok cross fingers and wait | 18:52 | |
| Verterok | awilkins: the preferences page should be opened on startup | 18:53 |
| awilkins | Verterok: Ok, zero prefs | 18:56 |
| awilkins | So far. | 18:56 |
| awilkins | Imported a project (because I'd usually do that and forget about VCS for a while) | 18:56 |
| awilkins | Ok, menus are available.... go to prefs now | 18:57 |
| awilkins | Set the .bat file... it's happy | 18:58 |
| awilkins | Took a moment to show overlays because this is a large tree | 18:58 |
| awilkins | So the "can't set prefs" issue is clear | 18:59 |
| Verterok | awilkins: gooooood :D | 19:00 |
| awilkins | This is a slightly patched branch because I've removed callisto things to make it compile | 19:00 |
| awilkins | *europa | 19:01 |
| awilkins | But only those changes required (no SaveableEditor) | 19:01 |
| awilkins | My wife is waving cake | 19:03 |
| * awilkins departs, drooling | 19:03 | |
| === kiko-afk is now known as kiko | ||
| * beuno points everyone at: http://www.smashingmagazine.com/2008/09/18/the-top-7-open-source-version-control-systems/ | 19:38 | |
| Verterok | hi beuno | 19:39 |
| beuno | hey Verterok | 19:39 |
| beuno | lifeless, igc, jam, abentley ^ | 19:40 |
| LarstiQ | anam I missing some navigation, or isn't there much to the review? | 19:41 |
| beuno | well, it's not very profound | 19:42 |
| beuno | but it showcases bzr quite weel | 19:42 |
| beuno | well even | 19:42 |
| LarstiQ | ok :) | 19:44 |
| beuno | TBH, it's a site that normally features design stuff | 19:45 |
| beuno | so it was surprising to me to see that entry | 19:45 |
| beuno | so I had to share it :) | 19:45 |
| Tak | "Monotone places higher value on integrity than performance." | 19:50 |
| Tak | I thought that was bzr's claim :-P | 19:50 |
| LarstiQ | Tak: you obviously haven't tried monotone lately ;) | 19:58 |
| Tak | haha, no | 20:02 |
| Tak | one experience was enough for me | 20:02 |
| * awilkins has a monotone server that's run untouched on his DVR for ages | 20:03 | |
| awilkins | I think I'll transfer the source to bzr branches and leave it at that | 20:03 |
| ronny | yo | 20:04 |
| Spaz | ew monotone | 20:04 |
| Spaz | hello ronny | 20:04 |
| ronny | monotone is certainly nice and powerfull, just dog-slow cause poor data-store | 20:05 |
| awilkins | SQLite is not poor ... but RDBMS are a poor idea of version control | 20:05 |
| awilkins | Another reason to shy away from TFS | 20:06 |
| LarstiQ | it's a bit sad, they did some nice stuff | 20:06 |
| ronny | awilkins: well, given the context sqlite is poor | 20:06 |
| awilkins | VSS! With SQL Server as a backend! Yay | 20:06 |
| ronny | well | 20:06 |
| rocky | is there anything compareable to svn authz access via http/apache for bzr? where you can control access to various repos and/or folders-within-repos via a config file? | 20:07 |
| Tak | eh, tfs is a bit more like svn with sql server as a backend ;-) | 20:07 |
| awilkins | rocky: You can only do authorization on a whole-tree level | 20:07 |
| beuno | there is a script in contrib/ | 20:08 |
| rocky | awilkins: well, is there anything making that (on whole-tree level) simple for a http based bzr serving? | 20:08 |
| beuno | for SSH keys | 20:08 |
| ronny | hmm, well, will bzr branches stay to limited to one head and having the workdir point to that | 20:08 |
| rocky | beuno: what i'm asking for would need to be read/write via http | 20:08 |
| beuno | rocky, ah, webdav. vila is the man to ask about that | 20:09 |
| rocky | vila: ^^ :) | 20:09 |
| beuno | it's late-ish for him, so he may not be around | 20:09 |
| beuno | if you don't get an answer, sending an email to the list is the next best thing | 20:09 |
| awilkins | Hmm, I like the domo-kun eating trees on their picture of git, why isn't the real git like that.... | 20:10 |
| rocky | since the main bzr http serving thing is just a python wsgi app (well at least it looks that way) it seems fairly straightforward to write my own access middleware for that | 20:10 |
| rocky | but i'd love to see if someone's already one that | 20:10 |
| rocky | *done | 20:10 |
| === kiko is now known as kiko-phone | ||
| beuno | rocky, well, contributions to loggerhead are *very* welcome :) | 20:11 |
| awilkins | I've only gone as far as configuring access via IIS auth | 20:11 |
| AmanicA | I've managed to do read & write through apache (bzr+http://) | 20:11 |
| beuno | anyway, I'm off to the dentist | 20:11 |
| awilkins | You just use IIS user impersonation and normal NTFS ACLs | 20:11 |
| beuno | IIS, eeeeew! | 20:11 |
| Spaz | ew | 20:11 |
| beuno | ok, that's it for unproductive comments from me | 20:11 |
| awilkins | I know, but the production site is ASP classic | 20:11 |
| rocky | ew is right ;) | 20:11 |
| * Spaz threw up a little | 20:11 | |
| awilkins | I could change it to PHP in short order though | 20:12 |
| awilkins | THe ASP is only being used for a very few things | 20:12 |
| awilkins | Mostly inserting "1" and "0" into links in strategic places | 20:12 |
| awilkins | Might be nicer... but without it, Bazaar would not have working IIS support yet, so ner. | 20:13 |
| AmanicA | rocky: using AuthType Basic and AuthUserFile like with svn | 20:13 |
| LarstiQ | awilkins: I for one think you're a hero :) | 20:13 |
| Spaz | i think IIS discussion is off-topic in here | 20:13 |
| Spaz | and quite frankly i think it's flamebait :P | 20:13 |
| rocky | well as long as everyone here acknowledges that MS tech beats all i don't need to argue.... | 20:14 |
| * rocky couldn't resist throwing out some bait | 20:14 | |
| Spaz | hurhurhur | 20:14 |
| Spaz | :P | 20:14 |
| awilkins | Yes, MS tech is a violent assault, we agree | 20:15 |
| Spaz | i think m$'s technology is their attempt at conquering the world...and it seems to be working | 20:15 |
| Spaz | :p | 20:15 |
| * Spaz forks himself into the background | 20:15 | |
| LarstiQ | Spaz: nah, not as it concers | 20:16 |
| LarstiQ | meh | 20:16 |
| * LarstiQ kicks freezing laptop | 20:17 | |
| Spaz | don't kick it too hard | 20:17 |
| awilkins | markh: Ping? | 20:17 |
| ferrouswheel | hi all, is there any way to pull individual file changes from a revision? | 20:28 |
| ferrouswheel | ahh, dumb question, just found out merge supports that | 20:31 |
| Spaz | bzr help diff | 20:31 |
| Spaz | or that | 20:31 |
| bpierre | hi | 20:40 |
| LarstiQ | bpierre: hey, did you try `bzr add subtree`? | 20:45 |
| LarstiQ | s/hey/hi/ | 20:45 |
| ferrouswheel | looks like i spoke to soon... online some refers to using individual files with merge... but i can't find anything in the help about it | 20:45 |
| ferrouswheel | oh actually it does work... it just doesn't accept wild cards. | 20:46 |
| === kiko-phone is now known as kiko | ||
| bpierre_ | does it work if the directory containing the subtree is added but not yet commited? | 20:51 |
| bpierre_ | LarstiQ: here is what I did: http://www.pastie.org/275241 | 20:58 |
| LarstiQ | bpierre_: I think that should work. The root fileid won't be set yet of ruby, so _possbily_ that could go wrong | 21:02 |
| bpierre_ | I tried to commit, then add, no luck | 21:02 |
| LarstiQ | no luck in what way? | 21:02 |
| bpierre_ | I'm using the right format, right? | 21:02 |
| LarstiQ | bpierre_: yes, old, but alas | 21:03 |
| bpierre_ | add src, commit src, branch ../c src/c, add src/c | 21:03 |
| LarstiQ | bpierre_: what does that give? | 21:03 |
| bpierre_ | nothing, if I do a status, src/c is still unknown | 21:03 |
| LarstiQ | hmm | 21:06 |
| bpierre_ | 0.373 opening working tree '/home/bpierre/projs/test/ptree/ruby/trunk/src/c' | 21:06 |
| bpierre_ | 0.390 skip control directory '.bzr' | 21:06 |
| bpierre_ | in ~/.bzr.log | 21:07 |
| * LarstiQ tries to find a workable machine | 21:07 | |
| === kiko is now known as kiko-phone | ||
| LarstiQ | bpierre_: oh wait, which bzr is that you're using? | 21:13 |
| LarstiQ | bpierre_: path/to/nested-trees/bzr ? | 21:13 |
| bpierre_ | installed http://bazaar.launchpad.net/%7Elarstiq/bzr/nested-trees/ with --prefix=~/progs | 21:14 |
| bpierre_ | bzr --version: Bazaar (bzr) 1.3.0.dev.0 | 21:14 |
| LarstiQ | bpierre_: ok, so bzr in your path is that one? | 21:14 |
| bpierre_ | yep | 21:14 |
| LarstiQ | bpierre_: bah, you're right | 21:16 |
| fm | how do i publish my local bzr repo to an ftp server? | 21:16 |
| bpierre_ | ? | 21:16 |
| LarstiQ | bpierre_: that means I'll have to refamiliarize myself with the code | 21:17 |
| bpierre_ | ok | 21:17 |
| jcomeau | hi all, i can't seem to find the right lines on your webpage to add to /etc/apt/sources.list... any clues? | 21:17 |
| jcomeau | this is on Debian, of course | 21:17 |
| LarstiQ | bpierre_: I'm sorry I don't know currently why that is so :/ | 21:18 |
| LarstiQ | jcomeau: testing or sid should not need anything extra | 21:18 |
| bpierre_ | LarstiQ: how can I execute the test suite? | 21:18 |
| LarstiQ | bpierre_: bzr selftest <pattern> | 21:19 |
| LarstiQ | bpierre_: without the latter it will run the entirety | 21:19 |
| bpierre_ | ok | 21:19 |
| LarstiQ | bpierre_: there are on the order of 10 failures/errors atm | 21:19 |
| bpierre_ | ok, and I don't need to be in a specific directory? | 21:20 |
| LarstiQ | bpierre_: (if you're bored, you can look at `bzr help join`, and see how well that models your components usecase) | 21:20 |
| bpierre_ | ah, ok | 21:20 |
| LarstiQ | bpierre_: join is also in regular bzr fwiw | 21:21 |
| LarstiQ | bpierre_: I believe at least Debian/Ubuntu run the suite after building packages, and not from the source tree, so I expect that to work | 21:21 |
| bpierre_ | really? I noticed split was | 21:21 |
| bpierre_ | (part of the regular bzr) | 21:22 |
| LarstiQ | bpierre_: in development, most people will run it from a bzr source tree | 21:22 |
| bpierre_ | ok | 21:22 |
| LarstiQ | bpierre_: yeah, bzr-svn uses (or used) the same functionality under the hood | 21:22 |
| bpierre_ | the rich root format? | 21:22 |
| LarstiQ | bpierre_: splitting and joining | 21:23 |
| bpierre_ | what are the differences between all those format? rich-root, development-subtree, dirstate-with-subtree? | 21:23 |
| jcomeau | LarstiQ: that's what i gathered, but apt-get -t unstable install bazaar tells me it's already the latest version... and it's 1.4.2 | 21:24 |
| LarstiQ | jcomeau: s/bazaar/bzr/ | 21:24 |
| pl0sh | i have installed the new release and i got this message always i use the bzr command. | 21:24 |
| LarstiQ | jcomeau: the 'bazaar' package is unfortunately named, it is not the bzr Bazaar | 21:24 |
| LarstiQ | bpierre_: different ages basically | 21:25 |
| jcomeau | LarstiQ: thanks! looks like that'll do it... | 21:25 |
| LarstiQ | bpierre_: rich-root is a part of what the nested-trees needed, but that got integrated a while ago | 21:26 |
| LarstiQ | bpierre_: dirstate-with-subtree is the old dirstate format, plus subtrees | 21:26 |
| LarstiQ | bpierre_: and development-subtree I don't know but assume to be current development format plus subtree | 21:26 |
| bpierre_ | ok, and rich-root? | 21:26 |
| LarstiQ | pl0sh: what error? | 21:27 |
| bpierre_ | in the blueprint, rich-root is required, so is rich-root part of subtree format | 21:27 |
| bpierre_ | ? | 21:27 |
| LarstiQ | bpierre_: no, the rich-root feature is necessary but not enough | 21:28 |
| pl0sh | bzr-svn is not up to date with installed bzr version 1.7rc1. | 21:28 |
| pl0sh | There should be a newer version of bzr-svn available. | 21:28 |
| pl0sh | Standalone tree (format: pack-0.92) | 21:28 |
| LarstiQ | bpierre_: rich-root _is_ enough for bzr-svn though, part of the reason why rich-root formats exist in released versions | 21:29 |
| bpierre_ | ok, it's what I understood then | 21:30 |
| bpierre_ | thanks | 21:30 |
| LarstiQ | pl0sh: either update bzr-svn to a version that works with bzr 1.7rc1, downgrade bzr to a version that works with your bzr-svn, or disable the bzr-svn plugin | 21:30 |
| LarstiQ | bpierre_: np | 21:30 |
| * LarstiQ really needs to start going home | 21:30 | |
| pl0sh | ok, so, what version of bzr-svn works with bzr 1.7rc1? | 21:31 |
| LarstiQ | pl0sh: no released versions according to http://bazaar-vcs.org/BzrForeignBranches/Subversion | 21:32 |
| LarstiQ | pl0sh: two other options, run with --no-plugins, or ignore the message. | 21:32 |
| LarstiQ | pl0sh: you do realise bzr 1.7rc1 is a release candidate, and not a released version? :) | 21:33 |
| awilkins | pl0sh: silly question ; do you use it? | 21:33 |
| pl0sh | sure i know it | 21:33 |
| awilkins | (bzr-svn, that is) | 21:33 |
| LarstiQ | pl0sh: if you don't use bzr-svn, disabling it is probably the easiest solution | 21:33 |
| pl0sh | i don't use it i think i'll disable it or anyway just ignore the message | 21:34 |
| awilkins | You can just find it and move it to the parent folder | 21:34 |
| bpierre_ | LarstiQ: mmm, did a join, without --reference, commit, but then noticed --reference, and how it matched more by usecase, so uncommit, revert, add (after renaming src/c/.bzr.retired.0/), and now commit | 21:34 |
| LarstiQ | pl0sh: if you do want to use bzr-svn and 1.7rc1, you could use a non-released bzr-svn version as well | 21:34 |
| bpierre_ | but it fails | 21:34 |
| bpierre_ | :P | 21:34 |
| * LarstiQ slaps self | 21:35 | |
| LarstiQ | bpierre_: reference, that's it! :) | 21:35 |
| bpierre_ | bit I'm not really going gentle with it, what with the uncommit and all | 21:35 |
| pl0sh | alright, thank you | 21:35 |
| bpierre_ | LarstiQ: the error is: bzr: ERROR: already in a write group | 21:35 |
| LarstiQ | pl0sh: which would be lp:bzr-svn/0.4 I think | 21:35 |
| LarstiQ | bpierre_: huuuu | 21:35 |
| bpierre_ | :D | 21:35 |
| bpierre_ | I'm going to try all over again, start from a clean state | 21:36 |
| pl0sh | btw, i'm not very expert using bzr, and i'd want to use it better, where can i start? | 21:36 |
| LarstiQ | bpierre_: I like your abilities as a tester ;) | 21:36 |
| LarstiQ | pl0sh: that depends. Reading the documentation is a start, but imo interacting with other people works best. | 21:37 |
| * LarstiQ really heads home now | 21:37 | |
| LarstiQ | bpierre_: thanks for trying this stuff out btw, I can use the kick under my rear :) | 21:37 |
| pl0sh | i just use the basics of bzr | 21:38 |
| LarstiQ | pl0sh: well, what more do you want to do? | 21:38 |
| LarstiQ | pl0sh: plugins can be fun to write, if you have the time and the inclination | 21:39 |
| LarstiQ | pl0sh: as can reading the mailing list | 21:39 |
| pl0sh | that would be great | 21:39 |
| pl0sh | actually i use bzr to keep tracking my development and as a helper when a make a mistake (i.e. delete a file or something like that..).. | 21:40 |
| pl0sh | but actually i don't know how to use bzr in a team, like merging branches (i think) | 21:41 |
| shawn_1 | I have been using svn for a long time, and I am trying to migrate to bazaar. I have the repository set up on a remote box and I am having trouble checking out from it. | 21:41 |
| bpierre_ | LarstiQ: same error: http://www.pastie.org/275273 | 21:42 |
| shawn_1 | bazaar is not liking my proxy settings | 21:43 |
| VanL | Is there a way to list the available repositories at a URL? For example, I have access to bzr+ssh://username@hostname.com/some/path. | 21:43 |
| VanL | I can push something there | 21:44 |
| VanL | but I want to see what others are doing in the same tree | 21:44 |
| mwh | hmm, seems having a gannotate window open makes bzr pull fail with | 21:44 |
| mwh | bzr: ERROR: Could not acquire lock "[Errno 11] Resource temporarily unavailable" | 21:44 |
| awilkins | Wah, wah, wah | 21:44 |
| VanL | but I don't know the exact path to their repository. | 21:44 |
| awilkins | I built bzr.exe for windows, and it doesn't work | 21:44 |
| awilkins | mwh: Yes, many things I think should be read only use too many locks | 21:45 |
| fullermd | VanL: Not exactly. There's a 'branches' command in bzrtools that will walk around a given location and try to list all the branches there. | 21:46 |
| VanL | fullermd: Does it come with the basic bzr install? | 21:47 |
| fullermd | No, but it's a common plugin. | 21:47 |
| fullermd | There's a package for it on most OSen that I know of [that bzr is packaged for, at least] | 21:48 |
| bpierre_ | part of the windows setup exe too | 21:50 |
| kiko-phone | hey lifeless, are you around? | 21:50 |
| VanL | In bzrlib/plugins? | 21:51 |
| GaryvdM | VanL: qlog from qbzr will find the branches and show the tips form the branches. See http://garyvdm.googlepages.com/qlog-repo.png | 21:51 |
| bpierre_ | any direction on how to rebuild the setup exe for windows? | 21:51 |
| VanL | GaryvdM: thanks | 21:51 |
| VanL | fullermd: thanks, now installed. | 21:52 |
| mwh | is it new that remotebranches support set_stacked_on_url? | 21:56 |
| mwh | i think they do something really weird with relative paths | 21:56 |
| mwh | ah no | 22:10 |
| mwh | it's that RemoteBzrDir.find_branch_format opens the branch | 22:10 |
| lifeless | jam: ping | 22:21 |
| lifeless | jam: do you know, offhand, where Py_ssizet is defined, getting buildfailures of all our extensions on a python2.4 box | 22:21 |
| jam | lifeless: You need a new-ish version of pyrex | 22:22 |
| jam | which will do a proper "if python_version < 2.5: #define Py_ssize_t int" | 22:22 |
| jam | lifeless: looking at the file I have right now: | 22:23 |
| ronny | re | 22:23 |
| jam | http://rafb.net/p/47rI8Y78.html | 22:23 |
| lifeless | this is still running dapper :P | 22:23 |
| jam | Py_ssize_t only exists on python >2.5 | 22:23 |
| jam | sorry, >= 2.5 | 22:23 |
| jam | lifeless: I'm trying to debug why PQM is running into autopack failures | 22:24 |
| jam | And I seem to have run into a *very* strange situation | 22:24 |
| jam | Where I'm seeing a revision text 6 times in the same pack file | 22:24 |
| jam | each time with different content | 22:24 |
| lifeless | just whacking that into _)dirstate_helpers_c.h has helped | 22:24 |
| lifeless | jam: if you're analyzing the pack content, remember that knit hunks only have a revision field | 22:24 |
| lifeless | jam: so you'll see file texts and inventories etc willynilly | 22:25 |
| lifeless | jam: there is a bug open on the autopack issue, its not just pqm (FWIW) | 22:25 |
| jam | lifeless: sure, but how would you get 6 items? | 22:25 |
| jam | ah, just multiple file texts? | 22:26 |
| LarstiQ | bpierre_: same thing here, I'll look at it tomorrow, after some sleep | 22:27 |
| bpierre_ | ok, thanks | 22:27 |
| ronny | lifeless: about that only having a single tip per branch + always having the workdir point to that tip, is there any chance to ever change that? | 22:27 |
| === kiko-phone is now known as kiko-afk | ||
| lifeless | jam: rev, inv, sig, 3 file changes | 22:29 |
| lifeless | ronny: well, everything can be changed, if the community agree its an improvement | 22:31 |
| lifeless | ronny: I'm not quite sure what you mean though, because branch, in every VCS I know of, refers to one of two things: a line of development, or a bifurcation in the revision graph | 22:31 |
| fullermd | Well, the workdir can already point elsewhere than the tip. You just can't do or find out much of anything about it when it is. | 22:31 |
| jam | lifeless: do you know how LP guys are requesting PQM do a cherrypick? I didn't think that was possible | 22:32 |
| mwh | jam: cherrypicks are done by the osas i think | 22:32 |
| lifeless | ronny: in the former, a revision is the definition of an entry point into the graph; I guess you could define multiple revs as all being 'part of branch X' | 22:32 |
| lifeless | jam: manual merges by LOSAs | 22:32 |
| fullermd | Well, mtn can have multiple heads because "on a branch" means "has a given certificate attached"... | 22:33 |
| lifeless | ronny: and in the latter case, its structural rather than user facing | 22:33 |
| jam | I don't know what an OSA or a LOSA is, but it is getting the PQM user-id | 22:33 |
| lifeless | fullermd: indeed; mtn is the exception :) | 22:33 |
| ronny | lifeless: well, git, hg and monotone allow me to go to previous/alternative versions in a branch, i build my workflows around that, bzr really differs there | 22:33 |
| bpierre_ | monotone allows multiple heads for a branch | 22:33 |
| lifeless | jam: 'sudo' :> | 22:33 |
| jam | anyway, I have the feeling that the manual editing is where the problem is happening | 22:33 |
| jam | *why* I'm not sure | 22:33 |
| jam | but that seems to be causing the later problems. | 22:33 |
| lifeless | jam: I don't, because the same thing has happened to beuno on a normal push | 22:33 |
| jam | I'll check another example (I have 2) | 22:33 |
| ronny | bpierre_: not just monotone | 22:34 |
| lifeless | jam: there is a bug open, with tarballs of the branch as it happened live | 22:34 |
| beuno | are we talking about the packs collisions? | 22:34 |
| bpierre_ | can be interrested to go back (maybe using something like bisect), and fix the bug where it was added | 22:34 |
| lifeless | jam: don't get confused by pqm hitting it :P | 22:34 |
| bpierre_ | then merge the multiple heads | 22:34 |
| beuno | if we are, it's happened multiple times already, with different branches | 22:34 |
| lifeless | ronny: AFAIK bzr allows precisely the same workflow, spelt a little differently, but the same overall picture and work | 22:34 |
| bpierre_ | also, you can pull/push with monotone, without having to merge, which can be great (you can always do the merging on one machine) | 22:34 |
| lifeless | ronny: if there is a something you want to do and bzr doesn't help you do it, thats definitely a bug. | 22:35 |
| ronny | lifeless: as far as i got that i have to make a multi-branch repo and create multiple branches on different paths, and thats just not what i want to do | 22:35 |
| LarstiQ | lifeless: I want to find bugs in bzr? :) | 22:35 |
| fullermd | ronny: Well, I think it IS just monotone. The others have multiple branches. | 22:35 |
| LarstiQ | ronny: bzr switch <sibling> ? | 22:36 |
| toytoy | guys how would i resolve the pending merges? or can i also abort that pending merges? this exist when i issue 'bzr status' | 22:36 |
| bpierre_ | wouldn't the -r fix to update fix that? | 22:36 |
| bpierre_ | being able to go back | 22:36 |
| LarstiQ | toytoy: normally, you'd commit them | 22:36 |
| fullermd | Not exactly. | 22:36 |
| ronny | LarstiQ: not really | 22:36 |
| fullermd | update -r fits different uses. | 22:37 |
| ronny | LarstiQ: not nearly as flexible | 22:37 |
| LarstiQ | ronny: then it isn't clear to me what you want to do. | 22:37 |
| bpierre_ | fullermd: ? | 22:37 |
| toytoy | LarstiQ: oh yeah thanks i did and it's lost i thought it will still show :) | 22:37 |
| lifeless | toytoy: after you do a merge, you need to do a commit to action the merge | 22:37 |
| lifeless | toytoy: bzr stops after ocmbining the content, so you can review it | 22:37 |
| ronny | fullermd: well, in monotone multiple heads with the same name are pretty much 2 "branches", too they just happen to have the same name | 22:38 |
| fullermd | bpierre_: update -r lets you flind your WT around easily (and with better semantics for various things than using revert), but it's not the same as jumping among branches at all. | 22:38 |
| lifeless | bpierre_, ronny: perhaps a little detail will help. We have 3 objects: | 22:38 |
| lifeless | WT - your source code unpacked on disk, and some metadata such as the revision bzr set the tree to be | 22:38 |
| toytoy | lifeless: oh i see, thanks for that :) | 22:38 |
| fullermd | ronny: Not really; as far as mtn is concerned, it IS one branch. Leads to some impressively large small differences. | 22:39 |
| lifeless | Branch - a tip in the revision graph, with attached user editable metadata like push-location, tags etc | 22:39 |
| bpierre_ | well, my first concern is being able to switch revision, not branch, and being able commit on the same branch | 22:39 |
| fullermd | Anyway. I do agree that branches being tied to directories makes a number of things more cumbersome. | 22:39 |
| lifeless | Repository - history store | 22:39 |
| bpierre_ | but being able to switch a workspace to another branch could be handy too | 22:39 |
| fullermd | With a lot more support code, a fair bit of that could be papered over, but... | 22:39 |
| ronny | fullermd: well, from a technical point its just 2 heads in the dag with the same name tag, it works exactly the same in hg | 22:40 |
| lifeless | bpierre_: you can switch workspaces easily - the switch command does this. | 22:43 |
| lifeless | a shared history store gives you disk space optimisation, for large projects this is useful | 22:43 |
| lifeless | bpierre_: when you say commit on the same branch, do you mean 'manage branches roughly like mtn' ? | 22:44 |
| lifeless | wife calling, I'll be back in a bit. ronny - look into tags; they may do what you want [though using a single workspace N branches should do it too - I'd like to know the downsides] | 22:45 |
| bpierre_ | well, what happen if I go back, and try to commit? | 22:45 |
| bpierre_ | all on the same branch? | 22:46 |
| ronny | lifeless: i mostly want to deal with stuff like i do with git/hg, im not using mtn these days | 22:46 |
| bpierre_ | isn't switch only part of the loom plugin? | 22:46 |
| GaryvdM | no | 22:47 |
| ronny | bpierre_: well, the dirstate has to be linked to the revision you are at, so you would create a new line of history thats to be merged at a later point | 22:47 |
| bpierre_ | I really liked monotone, but conflicts were a pain, and bzr is so much faster | 22:47 |
| bpierre_ | ronny: ok, that's what I want | 22:47 |
| bpierre_ | how would I merge? | 22:47 |
| bpierre_ | merge . | 22:47 |
| bpierre_ | ? | 22:47 |
| ronny | if you got 2 heads, you would just merge, else yo'd have to refer to the revisions | 22:48 |
| bpierre_ | how would revision number be constructed? | 22:49 |
| lifeless | ronny: well, git gives you a new ref in the same repository, which is equivalent to a separate branch in a shared repo in bzr | 22:50 |
| ronny | well, there are bzr's uuid's and bzr could also infer a local linear numbering (hg does that, works like a charm) | 22:50 |
| bpierre_ | I have revnos 1 2 3 4 5, go back to 3 with update -r 3, commit | 22:50 |
| lifeless | ronny: have you tried this, and of so what didn't it do for you? | 22:50 |
| ronny | lifeless: i disliked the workflows of shared repos | 22:51 |
| lifeless | ronny: local linear numbering conflicts rather badly with concurrency | 22:52 |
| bpierre_ | yeah | 22:53 |
| lifeless | so I think there are ~ 3 discussions going on here at once | 22:53 |
| lifeless | a) how to do what bpierre_ wants | 22:53 |
| lifeless | b) how to do what ronny wants, in a way that works for ronny | 22:54 |
| lifeless | c) some technical stuff about design/scaling etc | 22:54 |
| ronny | lifeless: you mean concurrent multiple writers to the repo? | 22:54 |
| lifeless | bpierre_: in the current design, if you want another line of development, you need a new branch object; branches in bzr are like branches in git in this way - they are not inferred, they are explicit references | 22:54 |
| lifeless | ronny: by concurrency - yes | 22:54 |
| ronny | hmk, nice | 22:55 |
| bpierre_ | mmm | 22:55 |
| lifeless | bpierre_: branches are cheap though; I have a repo with ~12K branches, and it performs fine | 22:55 |
| bpierre_ | the problem is more how a branch is tied to a directory | 22:56 |
| ronny | lifeless: any locks involved for stuff like tags? or completely lockfree? | 22:56 |
| lifeless | bpierre_: what about that gives you problems (damn, I sound like eliza) | 22:56 |
| bpierre_ | I mean in monotone, there is a clear difference between the database, and a workspace | 22:56 |
| lifeless | ronny: tags are per-branch, and as such the branch-lock surrounds mutation to tags | 22:56 |
| ronny | ah, ok | 22:57 |
| bpierre_ | each revision can have multiple branch certs, and monotone just try to follow the DAG for update operation | 22:57 |
| lifeless | ronny: so two branches can be pushed concurrently to the same repo, they don't conflict or collide | 22:57 |
| bpierre_ | an complain if it find a fork | 22:57 |
| bpierre_ | then you can reconcile multiple heads on the branch | 22:58 |
| fullermd | I've hit some ugly corners in mtn on that sort of thing, to be sure. | 22:58 |
| bpierre_ | with bzr, a branch is tied to a directory, no? | 22:58 |
| fullermd | The flexibility is nice to have, though. | 22:58 |
| bpierre_ | fullermd: what corners? | 22:58 |
| lifeless | bpierre_: yes, branches are tied to a directory, but you can consider that a user-accessible database if you like | 22:58 |
| lifeless | bpierre_: try this, just quickly, if you would: | 22:59 |
| fullermd | Well, to take one example, I propogated a change where there was no divergeance. Only the head got the new certificate, so one side of the 'branch' wasn't connected. mtn-viz had a total fit for somebody else. | 22:59 |
| lifeless | bzr init-repo --no-trees /tmp/bzr-db | 22:59 |
| bpierre_ | my only real problem, was how you resolve conflict, with a use case where you have a simplifed project, and you propagate with new/modified files in a directory that don't exists anymory in the target branch | 22:59 |
| bpierre_ | yeah, I could consider a no tree repo has my db | 23:00 |
| bpierre_ | and then I can create has many branches | 23:00 |
| fullermd | (a lot of things about mtn bugged the snot out of me. I don't particularly enjoy working with it. But the multi-head capability makes doing daggy fixes REAL easy, and I miss that) | 23:00 |
| lifeless | bpierre_: right | 23:00 |
| bpierre_ | which might be different revision of the same branch | 23:00 |
| bpierre_ | logical branch | 23:00 |
| lifeless | bpierre_: trunk is one branch, and feature branches a,b,c | 23:00 |
| bpierre_ | but, it's more work | 23:01 |
| bpierre_ | than with monotone | 23:01 |
| lifeless | bpierre_: ok. I take it you've tried working with this? | 23:02 |
| bpierre_ | btw, can you easily add custom certs/properties to a revision? | 23:02 |
| lifeless | there is a revision_properties facility | 23:02 |
| bpierre_ | lifeless: multiple branches for each feature? | 23:02 |
| lifeless | we use it for recording branch nicknames and plugins use it for recording arbitrary things | 23:02 |
| bpierre_ | ok | 23:02 |
| lifeless | bpierre_: multiple branches, switch between them, etc. | 23:03 |
| lifeless | bpierre_: I'm going out on a limb here, but are you trying to do 'daggyfixes' ? | 23:03 |
| bpierre_ | no, but it is one use case | 23:03 |
| bpierre_ | last time, I wanted to use the bisect plugin | 23:03 |
| bpierre_ | to find a bug | 23:04 |
| bpierre_ | which was a waste of time since it was a hardware bug on my project, but I disgrees, anyway, right know, what the plugin does is revert to a revision | 23:04 |
| bpierre_ | so stat, show the differences with the tip of the branch | 23:05 |
| bpierre_ | which is not practical | 23:05 |
| bpierre_ | and might be tempted to fix it in the revision that introduced it, so yes, a daggyfix, no? | 23:06 |
| ronny | well, basically 2 things about branches suck, 1. dirstate is allways bound to the latest rev, 2. there is no way to have more than one head | 23:06 |
| ronny | i want to jump back to rev x, commit a fix, merge with head | 23:06 |
| bpierre_ | also my tree is big, so all those operation take time/space | 23:06 |
| bpierre_ | ronny: exactly | 23:06 |
| lifeless | bpierre_: switch is mostly O(difference), so total tree size and history are not really factors | 23:07 |
| awilkins | I found the dirstate bound to tip thing confusing | 23:07 |
| fullermd | 1. isn't true; there's just no real capability to manage it not being. | 23:07 |
| lifeless | yah, 1. is false, though bzr tries to keep it always the same to allow commit() to work | 23:08 |
| ronny | commit cant commit to revs that already have children? | 23:08 |
| lifeless | ronny: commit commits to the tip of a branch | 23:08 |
| bpierre_ | ;( | 23:08 |
| fullermd | (which is to say, the dirstate can easily point at any rev in the branch history, but there's no way, sans deep hacking, to MOVE it to anywhere but the current tip) | 23:08 |
| lifeless | ronny: branch is defined as 'a tip' | 23:08 |
| ronny | uh, thats well bad | 23:08 |
| awilkins | Commit therefore makes a new tip | 23:08 |
| lifeless | ronny: so its a tautology | 23:09 |
| awilkins | So it should be able to make a new tip from any revision ; it already has done, for every revision before this one... | 23:09 |
| lifeless | oh | 23:09 |
| lifeless | terminology overlap | 23:09 |
| awilkins | You can certainly have multiple tips in a repo | 23:09 |
| lifeless | 'tip' here -> 'tip of the line of development', *NOT* 'a leaf node in the DAG' | 23:10 |
| awilkins | Or heads | 23:10 |
| lifeless | the DAG is unknowable, because its simultaneously distributed and disconnected | 23:10 |
| lifeless | its also O(history) to do anything with it that involves inferring 'unmerged' from the entire dataset. this simply doesn't scale well without complex caches or long critical-lock sections around insertions to the db | 23:11 |
| * mwh waves https://bugs.edge.launchpad.net/bzr/+bug/271924 | 23:11 | |
| ubottu | Ubuntu bug 271924 in bzr "RemoteBzrDir.find_branch_format opens the branch" [Undecided,New] | 23:11 |
| lifeless | ronny: so if you change the branch tip and dirstate rev you can commit against *any* rev in your local database | 23:11 |
| mwh | around | 23:11 |
| bpierre_ | ok | 23:12 |
| lifeless | this just mutates your existing branch - its what commit does, it mutates a branch to add a commit object to it, which is likewise inserted in to the repository | 23:12 |
| lifeless | (actually the ordering is 'new commit object in repo; update branch tip; update dirstate' | 23:12 |
| ronny | hmm, it generaly sounds a __lot__ more complicated to do in bzr, than it is in git/hg/monotone | 23:13 |
| lifeless | ronny: git is the same - create a new commit object (done by linking to the index), update the branch reflog and basis reflog | 23:14 |
| lifeless | ronny: hg is the same - insert content into all the modified revlogs, then the manifest revlog and revision revlog, then update the dirstate | 23:14 |
| lifeless | I haven't read the code for commit in monotone but I bet it is ~= | 23:14 |
| lifeless | we're having a deep technical discussion rather than one about getting you working well, because you seem to want to do that:) | 23:15 |
| ronny | well, bzr doesnt seem to allow me to work like i want | 23:15 |
| ronny | well, in hg i just do hg up -r rev; commit; merge | 23:16 |
| bpierre_ | +1 | 23:16 |
| ronny | in mtn i do the same | 23:16 |
| lifeless | ronny: so, question. | 23:16 |
| lifeless | ronny: if you do the first two commands, and someone clones you, what do they get ? | 23:16 |
| ronny | 2 heads | 23:17 |
| lifeless | ronny: and how do they know which one really represents the branch ? | 23:17 |
| lifeless | (vs being an experiment that failed) | 23:17 |
| ronny | both do | 23:17 |
| bpierre_ | they don't | 23:17 |
| lifeless | bingo, that confusion is exactly my point | 23:18 |
| bpierre_ | know which one is best, an experiment | 23:18 |
| lifeless | in bzr we don't have that, because the branch tip is well defined at all times | 23:18 |
| ronny | well | 23:18 |
| bpierre_ | yeah, but with a process, a common location with a gatekeeper | 23:18 |
| bpierre_ | where is the problem? | 23:19 |
| abadger1999 | There very often isn't a good process or a gatekeeper. | 23:19 |
| ronny | people cant pull my local repos, no problem, i wont push before the merge | 23:19 |
| lifeless | bpierre_: what if the gatekeeper does that ? :P Or more pragmatically, consider shared branches, where there are many gatekeepers | 23:19 |
| bpierre_ | also, a good use case with multiple heads, is being able to commit on one machine, push to another, and do the merge on the second one | 23:19 |
| lifeless | bpierre_: you can do that with bzr just fine | 23:19 |
| ronny | also pushing is pretty much prohibited without explicit force if there are more than 1 heads as a result | 23:20 |
| bpierre_ | you have to create another branch, no? | 23:20 |
| ronny | so remote branches are well-defined | 23:20 |
| bpierre_ | you can't push if you have diverged | 23:20 |
| lifeless | bpierre_: no, though its the simplest way IMO | 23:20 |
| ronny | i just want to do what the heck i want locally | 23:20 |
| * abadger1999 often works on git repos where there's multiple branches with no well defined method of finding which a given piece of work should be done on. | 23:20 | |
| bpierre_ | lifeless: how do you it without a new branch? | 23:20 |
| abadger1999 | I note that it's a social problem though... launchpad makes the same thing happen to collections of bzr branches. | 23:20 |
| lifeless | bpierre_: bzr push, ignore the error about divergence, bzr heads on the other machine, bzr merge . -r <head you want> | 23:21 |
| bpierre_ | wait, push will have pushed the revisions? | 23:22 |
| lifeless | bpierre_: though I prefer to just make a new branch when I have that situation, it remembers it for me then | 23:22 |
| lifeless | bpierre_: yes, the repository will have them, they just aren't reference from the branch | 23:22 |
| bpierre_ | mmm, but you have to remember the revid | 23:22 |
| lifeless | bpierre_: thats what heads will tell you, and heads --dead only lists unmerged heads | 23:23 |
| bpierre_ | ok | 23:23 |
| lifeless | what I like about separate branches is that they are cheap, they are easily managed (I can have arbitrary number of pending-review, pending-merge, in-progress, etc) | 23:23 |
| lifeless | by cheap I mean no workspace | 23:23 |
| lifeless | and no separate history store | 23:23 |
| awilkins | Does uncommit mark revisions? | 23:24 |
| lifeless | as for the use case of 'make a new branch from an arbitrary rev', well - I think bisect can definitely be improved; there already is 'bzr branch -r XXX' to make a branch @ a rev | 23:24 |
| awilkins | Because one thing I found is that "heads" is really fouled by uncommits | 23:24 |
| lifeless | awilkins: If I understand you correctly, no | 23:24 |
| fullermd | Branches being directories does necessarily make them heavier weight than ref-based branches, though. | 23:25 |
| bpierre_ | yeah, but you don't want a new workspace for each revision you try | 23:25 |
| lifeless | awilkins: that would be nice wouldn't it. needs some thought | 23:25 |
| awilkins | It would be nice if uncommit marked a rev as having been uncommitted | 23:25 |
| lifeless | fullermd: yes, but thats the same weight as git and svn and cvs and a few others besides | 23:25 |
| bpierre_ | although, you could cheat with a new branch, cloning the tip, and then pull --overwrite -r ? | 23:26 |
| fullermd | No (well, maybe svn/cvs, but I don't count them) | 23:26 |
| fullermd | I don't mean heavier technically; I mean heavier psychologically. | 23:26 |
| fullermd | You have to switch a lot more gears. | 23:26 |
| fullermd | There needs to be a whole lot more UI magic happening to make dir-based branches seamless in a way that ref-based are naturally. | 23:26 |
| lifeless | fullermd: mmmm, I don't see why; single tree, switch between, branches to list, push-repo, modulo bugs | 23:26 |
| lifeless | fullermd: please define 'ref-based' | 23:26 |
| fullermd | Well, ref-based can be dir-based, but meaning managed entirely by the tool behind your back. | 23:27 |
| lifeless | bpierre_: yes, new branch, pull --overwrite -r X, should be fast | 23:27 |
| awilkins | branch-and-switch would cover a lot of it | 23:27 |
| fullermd | Consider the case: I have my branch of $PROJ. You suggest a branch I should merge in. | 23:27 |
| lifeless | fullermd: ok | 23:27 |
| fullermd | If bzr were ref-based, I could "bzr branch $NEW beblatz ; bzr switch beblatz ; <check stuff> ; bzr switch mine ; bzr merge beblatz ; bzr ci" | 23:28 |
| fullermd | But with dir based, I can't do that directly; I have to switch to knowing about the filesystem, and "bzr branch $NEW /wherever/my/repo/is/beblatz", etc. | 23:28 |
| lifeless | fullermd: but you can do that today, with one change: | 23:28 |
| fullermd | Ditto when I'm done, and can "bzr rm-branch beblatz" instead of "rm -rf /some/where... crap, where is that..." | 23:28 |
| lifeless | "bzr branch $NEW ../beblatz ; bzr switch beblatz ; <check stuff> ; bzr switch mine ; bzr merge ../beblatz ; bzr ci" | 23:29 |
| lifeless | fullermd: have you tried the switch branch-finding heuristic? | 23:29 |
| fullermd | No, because I don't generally work that way. But until it's a branch branch-finding heuristic and a merge branch-finding heuristic and a diff branch-finding heuristic... it means you're switching a lot of gears. | 23:29 |
| LarstiQ | so right now, switch is the only command that has the ref-behind-your-back heuristic, afaik | 23:29 |
| bpierre_ | switch is provided in 1.7? | 23:30 |
| lifeless | fullermd: note that for hg, you have to rollback to decide you didn't like it, which is fugly, for git you need a branch-name, (so its system-managed, and thats nice) | 23:30 |
| fullermd | I don't claim that dir-based branches are _inherently_ psychologically heavier, but there needs to be a lot of UI magic to make them FEEL the same weight. | 23:30 |
| lifeless | fullermd: oh, I agree, the heuristic needs to be pervasive | 23:30 |
| lifeless | fullermd: I was asking if you had tried it | 23:30 |
| lifeless | bpierre_: switch is single, um, 0.92 or something; been in for ages | 23:30 |
| bpierre_ | ah | 23:31 |
| lifeless | bpierre_: what we're talking about here, is a heuristic where switch will look for branches in oldbranch/../, which means less typing for you | 23:31 |
| fullermd | Unfortunately, it's a lot like the performance question, in a way. | 23:31 |
| lifeless | bpierre_: but other commands don't yet do that | 23:31 |
| fullermd | It's not "bzr can't", but "bzr presently doesn't". | 23:31 |
| fullermd | And each side of the question is going to put a very different emphasis on that phrase :| | 23:32 |
| fullermd | Being branch-based we have an inherent [not insoluble, but] problem, in that we HAVE to have that heuristic. | 23:32 |
| lifeless | how many paths does mysql have in it ? | 23:33 |
| fullermd | And it's a lot of places to sprinkle it. Even if we get all the commands, then we have branch: and ancestor: and such revspecs to handle too. And then there are plugins... | 23:33 |
| bpierre_ | I can live with the typing, it's just that the use of checkout can sometime be confusing (at least to me) so I didn't think about using it with a regular (disconnected) branch | 23:33 |
| bpierre_ | (after reading the help for switch) | 23:33 |
| fullermd | Heck, look how long it's taken us (still taking?) just to get all the commands to understand the metadir format, and stop demanding WT's when they don't need them, etc. | 23:33 |
| fullermd | (not that that's in any real way related to the issue, just the same on some level in the amount of distributed assumptions) | 23:34 |
| awilkins | I agree, I keep finding myself wishing that merge had the same sibling-heuristic as switch (and that someone would merge my sibling finding patch for switch) | 23:37 |
| bpierre_ | wait, switch only work for a checkout ... | 23:37 |
| awilkins | bpierre_: Yes, but the sibling heuristic only works on lightweights | 23:37 |
| awilkins | bpierre_: My patch fixes it so it works on eavies too | 23:37 |
| bpierre_ | sibling? | 23:37 |
| awilkins | brother, sister | 23:38 |
| ronny | well, basically the workflow enfocements and the speed issues basically make me avoid bzr for all of my own projects | 23:38 |
| jam | lifeless: so I have an idea of what is causing the auto-pack problem. And it *is* related to the cherrypicking, but only tangentially | 23:38 |
| awilkins | bzr switch sibling == bzr switch <my bound branch>/../sibling | 23:38 |
| LarstiQ | bpierre_: repo/{foo,bar}, cd foo, switch bar == switch ../bar | 23:38 |
| bpierre_ | I guess lightweigts is ok, I think I'm starting to understand how you use it lifeless | 23:38 |
| bpierre_ | LarstiQ: yeah, just syntaxic sugar | 23:39 |
| bpierre_ | :P | 23:39 |
| LarstiQ | bpierre_: exactly | 23:39 |
| jam | lifeless: consider if we have packs of 10*9, and one of 1, and then we fetch another pack of 19. This will trigger an autopack, and try to create a pack of 100, 10. It can fill the 100 one from all the large packs | 23:39 |
| jam | and the size 1 pack gets "promoted" to size 10, but there is nothing else to put in with it | 23:39 |
| jam | Anyway, I'll poke at it more, but I think it is something worth trying out. | 23:39 |
| awilkins | I think BB needs some work. 'tis down again. Does it do many hardworking things? | 23:40 |
| bpierre_ | so you create a repo, with x no tree branches, and then you work with one checkout of those branches, which you can then switch depending on your activity, right? | 23:41 |
| awilkins | bpierre_: That's it | 23:41 |
| bpierre_ | thanks | 23:41 |
| bpierre_ | :D | 23:41 |
| awilkins | bpierre_: Rather the same as git, only the branches are out there in the filesystem for you to look at | 23:41 |
| bpierre_ | yeah | 23:41 |
| awilkins | (can git do hierarchical branch organization by the wa?) | 23:42 |
| fullermd | I don't think as such, but you can mostly fake it via naming. | 23:42 |
| lifeless | jam: ok. | 23:42 |
| lifeless | jam: it may help to simplify things there, I realised a while ago that autopack should be a little simpler. | 23:42 |
| fullermd | We fake naming via hierarchy; they fake hierarchy via naming ;) | 23:42 |
| awilkins | fullermd: You can just move those folders around, right? | 23:43 |
| bpierre_ | and if I want do to a daggyfix, I can just push -r to clone at a revision, and switch to it, than back to where I was, and merge? | 23:43 |
| awilkins | fullermd: As long as they stay in the repo? | 23:43 |
| lifeless | jam: specifically, rather than going for N packs of specific sizes, when we were past a pack boundary, it should (still using the 1, 10, 100 etc logic - thats fine), just calculate the ones it wants to combine, and output one single big pack | 23:43 |
| fullermd | In bzr, you mean? Sure. | 23:43 |
| lifeless | jam: e.g. rather than making a 100, and a 10, it would just make one of 110 | 23:43 |
| jam | lifeless: sure | 23:43 |
| awilkins | Only thing it screws with is the bindings | 23:43 |
| Odd_Bloke | D'oh, poolie's not around. | 23:44 |
| jam | lifeless: triggered it | 23:51 |
| * fullermd scampers off to a meeting. | 23:51 | |
| jam | now I need a simpler test case :) | 23:51 |
| lifeless | bbiab, food | 23:53 |
| poolie | hello | 23:58 |
| Odd_Bloke | poolie: Hey. | 23:58 |
| poolie | hello | 23:58 |
| Verterok | poolie: hi | 23:58 |
| jam | lifeless: instructions on how to get it to fail easily are on bug #242510 | 23:58 |
| ubottu | Launchpad bug 242510 in bzr "Pack already exists when pushing/autopacking" [High,Confirmed] https://launchpad.net/bugs/242510 | 23:58 |
| Odd_Bloke | poolie: I'm afraid I can't really chat now. :( | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
