| awilkins | Hmm... when I view the output of building the "survival" docs locally all I get is a blue page | 00:02 |
|---|---|---|
| awilkins | Title headers are there but the content seems to be missing | 00:02 |
| awilkins | Same for the other pages so I know it's not just me | 00:02 |
| fullermd | awilkins: Sorry, that means you don't get to survive :( | 00:14 |
| awilkins | Bah, pushed it up anyway, the text is still PURE GOLD, I tell you. | 00:15 |
| awilkins | Only someone who hates VSS as much as I do could document how it differs from decent version control systems at all thoroughly. | 00:15 |
| awilkins | Because by definition, anyone who knows a lot about how VSS works, hates it. | 00:16 |
| * mwhudson hasn't used VSS for 9 years, didn't use it much then and still hates it | 00:18 | |
| * fullermd never used VSS, and still hates it :p | 00:19 | |
| awilkins | I used to have to run the "analyze.exe" tool | 00:20 |
| fullermd | I figured the document would look something like "unlike VSS, bzr actually stores your history and can retrieve it later" | 00:20 |
| awilkins | I tried to stay away from making it a "why Bazaar is just Soooooooo much better than VSS" document and stuck to "Why you may find Bazaar, or indeed, any decent VCS, a bit confusing after using VSS" | 00:21 |
| awilkins | But it's far from complete and I need sleep. But slashdot beckons | 00:21 |
| awilkins | Bah | 00:21 |
| awilkins | Is Karmic going to have GNOME Shell? | 00:24 |
| SamB_XP_ | awilkins: why do you care? rxvt-unicode, man! | 00:25 |
| fullermd | Oh, is that what people use who don't have xterm? :p | 00:25 |
| awilkins | Yeah, but it's nice to have a window manager to move your terminals around | 00:25 |
| awilkins | You can fit more on the screen with overlapping windows | 00:26 |
| fullermd | Pfft. Who wants to waste CPU cycles on frills? | 00:26 |
| SamB_XP_ | awilkins: oh, wait, I'm confused with GNOME Terminal | 00:26 |
| SamB_XP_ | I guess I may have been using Windows too much lately? | 00:26 |
| SamB_XP_ | also, some people are liking Xmonad, though it's configuration file be written in a most arcane script ... | 00:26 |
| awilkins | This was prompted by the announcement that Fedora 12 has a preview of it in the distro | 00:27 |
| dash | gnome-shell is available in karmic | 00:27 |
| dash | it's slightly neat | 00:27 |
| SamB_XP_ | who needs a desktop? | 00:27 |
| dash | SamB_XP_: who needs a computer? | 00:27 |
| awilkins | Who needs a computer? | 00:27 |
| * dash hgh fives awilkins | 00:27 | |
| awilkins | :-D | 00:27 |
| fullermd | How else would I heat my house? | 00:28 |
| SamB_XP_ | dash: well, the desktop is a lot less necessary than the WM | 00:28 |
| SamB_XP_ | if you'd seen my homedir, you would understand ;-) | 00:28 |
| awilkins | They replaced my machine at work with one that only drives one monitor | 00:28 |
| fullermd | That sounds like it should be a country song. | 00:28 |
| awilkins | What the *hell* are they smoking in ICT | 00:29 |
| awilkins | I'll just have to get one of those USB graphics adapters | 00:29 |
| SamB_XP_ | huh, my school's ITS is really crappy and I don't think we *have* any computers that can only drive one monitor ... | 00:29 |
| === davidstrauss_ is now known as davidstrauss | ||
| awilkins | Or work at home a lot more... I neeeeeed my dual 22" widescreens | 00:29 |
| awilkins | It's painful enough being trapped in tiny resolutions like 1280x1024 at work... | 00:30 |
| SamB_XP_ | ... of course, none of them are really set up to take advantage of the second output, except some of the ones hooked up to projectors :-( | 00:30 |
| awilkins | Blimey, gnome-shell is going all "Mac" in terms of menu | 00:33 |
| === BasicPRO is now known as BasicOSX | ||
| Peng_ | I'm being pushy here, but: could someone send my branch to PQM? :D https://code.edge.launchpad.net/~mnordhoff/bzr/statictuple-pickling | 01:16 |
| fullermd | Let's just agree too assume I've found the perfect time for the 'sounds like a real pickle' joke, and save me the trouble of coming up with it, and you the trouble of hearing it. | 01:18 |
| spiv | Peng_: hmm, I don't see your name on the list people that have signed contributor agreements... would you mind doing so? http://www.canonical.com/contributors | 01:22 |
| Peng_ | spiv: Yeah, I never did, cuz I don't like copyright assignment. :P I liked being in the grey area of "hasn't written enough code for it to be copyrightable". | 01:28 |
| Peng_ | spiv: Anyway, I'll do it now. | 01:28 |
| Peng_ | Crap, it's a PDF? | 01:28 |
| Peng_ | Google cache++ | 01:28 |
| spiv | Oh, that's a problem? I could have sworn this was 2009, not 1999 ;) | 01:29 |
| fullermd | No way. Then I'd have to stop partying like this. | 01:29 |
| spiv | Haha | 01:29 |
| Peng_ | spiv: Or...I'll do it soonish. My brain isn't up to deciphering legal documents rightn ow. | 01:33 |
| Peng_ | spiv: Who do you want me to CC it to, you or poolie? | 01:33 |
| spiv | Peng_: poolie | 01:34 |
| Peng_ | spiv: 'kay | 01:50 |
| Peng_ | spiv: Is it supposed to be GPG-signed? | 01:53 |
| spiv | Peng_: I don't think it's required (whatever that link says is the rule), but it wouldn't hurt. | 01:54 |
| spiv | Peng_: and I know if I was the sender it would make me feel better ;) | 01:55 |
| jdub | hrm, where do i install plugins such that loggerhead will run them on writes? | 02:29 |
| lifeless | the bzr plugins dir | 02:34 |
| lifeless | how are you running loggerhead? | 02:34 |
| jdub | lifeless: the init script... runs as loggerhead user | 02:37 |
| jdub | lifeless: so ~loggerhead/.bzr/plugins ? | 02:37 |
| * jdub doesn't like the loggerhead package | 02:37 | |
| lifeless | you may also need to be sure you are running 'bzr serve --http', not 'serve-branches' | 02:37 |
| lifeless | the former will load all plugins, the latter *may*, and I'd need to check to be sure. | 02:37 |
| jdub | s/bzr/bazaar/ <- oops ;) | 02:38 |
| jdub | lifeless: hrm, then using loggerhead as a plugin? | 02:39 |
| spiv | lifeless: serve-branches does load plugins | 02:40 |
| lifeless | spiv: good to know | 02:41 |
| lifeless | jdub: I hope to convince beuno to delete serve-branches soon | 02:42 |
| lifeless | only need one 'serve' command. | 02:42 |
| jdub | spiv: so my expectation that it'd load them from ~/.bazaar/plugins of whatever user loggerhead is running as would be right? | 02:42 |
| lifeless | yes | 02:42 |
| lifeless | or the global python install dir | 02:42 |
| lifeless | and you can add paths via BZR_PLUGINS_PATH | 02:43 |
| jdub | whihc makes the loggerhead package SPECIAL | 02:43 |
| Peng_ | It does? | 02:43 |
| jdub | jdub@whitlam:~$ getent passwd loggerhead | 02:43 |
| jdub | loggerhead:x:109:117::/:/bin/false | 02:43 |
| lifeless | \o/ | 02:43 |
| lifeless | jdub: put them in e.g. /var/lib/loggerhead/plugins | 02:43 |
| lifeless | and export BZR_PLUGINS_PATH=/var/lib/loggerhead/plugins | 02:43 |
| jdub | perhaps the best thing to do would be BZR_PLUGINS_PATH=/var/lib/loggerhead or whatever in the init script | 02:44 |
| jdub | ha ha | 02:44 |
| jdub | we are FHS TO THE MAX, man | 02:44 |
| lifeless | submit a package patch to do that ;) | 02:44 |
| jdub | yeah, but now i'm looking more closely at bzr serve | 02:44 |
| jdub | does --http only work when bzr finds loggerhead? | 02:45 |
| lifeless | yes | 02:45 |
| lifeless | loggerhead provides --http | 02:45 |
| jdub | right | 02:45 |
| lifeless | svn should provide --svn, but I don't know if its glued in yet | 02:45 |
| jdub | will other parameters be passed through automagically? ie --use-cdn | 02:46 |
| spiv | It would perhaps be nice to have something simple builtin for --http, but if loggerhead is easy enough to install then it's probably not a big deal. | 02:46 |
| lifeless | spiv: I'm very keen on not building in a non-loggerhead http | 02:46 |
| lifeless | spiv: I think discussions about doing that have been missing the point :) | 02:47 |
| AfC | lifeless: that wold be nice | 02:47 |
| Peng_ | jdub: No. | 02:47 |
| lifeless | AfC: --svn? | 02:47 |
| Peng_ | jdub: That's basically the reason to still keep serve-branches around for now. | 02:47 |
| AfC | lifeless: non loggerhead --http | 02:47 |
| AfC | [battery change | 02:47 |
| lifeless | AfC: why? | 02:47 |
| jdub | Peng_: particularly since the use of libjs-yui doesn't actually work ;-) | 02:48 |
| jdub | Peng_: ah, plus, no way to provide a prefix | 02:49 |
| jdub | jdub@whitlam:~$ bzr serve --http --allow-writes --port 8000 --directory /srv/whitlam.crikey.com.au/code/ | 02:50 |
| jdub | ... | 02:50 |
| jdub | File "/usr/lib/python2.5/site-packages/bzrlib/registry.py", line 183, in get_prefix | 02:50 |
| cszikszoy | Hi, I was wondering if someone could help me with a small bzr problem. I merged 2 branches. There was a conflict in 1 file. I bzr rm'd the folder that contained that file, and now I can't commit (bzr says conflicts still exist). | 02:50 |
| jdub | if fullname.startswith(key): | 02:50 |
| jdub | AttributeError: 'LocalTransport' object has no attribute 'startswith' | 02:50 |
| lifeless | jdub: please file a bug on that | 02:50 |
| cszikszoy | bzr resolve gives an error saying: "bzr: ERROR: The file id "....." is not present in the tree <WorkingTree4 of ...." | 02:51 |
| lifeless | cszikszoy: bzr resolve --all | 02:51 |
| jdub | lifeless: will do | 02:51 |
| lifeless | cszikszoy: and file a bug please | 02:51 |
| jdub | lifeless: against? | 02:51 |
| jdub | bzr itself | 02:51 |
| lifeless | jdub: loggerhead, for now. | 02:51 |
| jdub | ok | 02:52 |
| cszikszoy | lifeless, great, thanks very much! | 02:52 |
| spiv | lifeless: yeah, I'm certainly not keen on bringing yet another underpowered, buggy HTTP server into the world :) | 02:55 |
| spiv | lifeless: I can see how it might be convenient from time to time... but I think I'd rather put effort into making loggerhead smoother. | 02:56 |
| lifeless | same | 02:56 |
| mlh | http://code.google.com/p/magnum-py/ ? | 02:58 |
| lifeless | god no | 02:58 |
| jdub | -1 point, terrible pun name | 02:59 |
| mlh | oh, liux specific :-(, not really embeddable | 02:59 |
| mlh | (I'll get my coat) | 02:59 |
| lifeless | for starters, python 2.6 minimum | 03:00 |
| lifeless | and multiprocessing is *slow* | 03:00 |
| lifeless | (the module) | 03:00 |
| mlh | is it? I was curious about that | 03:00 |
| lifeless | we already have http servers in the code base too, for testing | 03:00 |
| lifeless | there is a tolerable http server in the standard library | 03:00 |
| jdub | lifeless: looked at unicorn? | 03:01 |
| lifeless | nope | 03:01 |
| jdub | lifeless: http://unicorn.bogomips.org/ (ruby, but interesting to read) | 03:01 |
| * mwhudson keeps meaning to investigate spawning seriously for loggerhead | 03:02 | |
| lifeless | mwhudson: please don't, I've seen one have lots of fallout from spawning | 03:04 |
| spiv | lifeless: btw, here's something a bit amusing | 03:05 |
| jdub | yeah, spawning sucks. looking at you, spiv. | 03:05 |
| lifeless | jdub: 'serve fast clients on low-latency, high-bandwidth connections' | 03:06 |
| spiv | lifeless: we recently pointed out an error in the way our mortgage interest was being calculated by our bank (they weren't applying an offset account the way we had asked them to) | 03:06 |
| lifeless | jdub: e.g. 'unsuitable for use on the internet' | 03:06 |
| jdub | lifeless: it also says that. :-) | 03:06 |
| lifeless | spiv: nice catch | 03:06 |
| spiv | lifeless: the bank checked their records and agreed, so they had to fix the history of our account | 03:06 |
| jdub | lifeless: unicorn is designed to sit behind nginx | 03:07 |
| spiv | lifeless: it turns out they don't rebase ;) | 03:07 |
| jdub | (or something else, but they're close cousins) | 03:07 |
| lifeless | spiv: so you got a single adjustment ? | 03:07 |
| spiv | lifeless: so the statement for the mortgage now has all the original interest and payment transactions, plus a bajillion new transactions, backdated, that undo those individually, and individually reapply the right amounts | 03:08 |
| lifeless | jdub: squid won't [without a rather ugly hack I don't think I landed in trunk] buffer full responses | 03:08 |
| spiv | lifeless: on top of the existing history | 03:08 |
| lifeless | jdub: unless they are tiny | 03:08 |
| spiv | lifeless: which certainly makes for a confusing read, but the original history is intact ;) | 03:08 |
| lifeless | spiv: nice | 03:08 |
| lifeless | spiv: they can't rebase, its the law :) | 03:08 |
| spiv | Right. | 03:09 |
| spiv | Still, it would be nice to have a view of the history "as it should be" as well as "how it ended up being recorded" | 03:09 |
| spiv | But they don't provide the tools for that. | 03:09 |
| lifeless | true | 03:10 |
| spiv | jdub: spawning is certainly slow~! | 03:10 |
| lifeless | [======= ] download in progress | 03:11 |
| lifeless | there is a maternity t-shirt with that on it | 03:11 |
| spiv | lifeless: from thinkgeek, yeah :) | 03:11 |
| jdub | spiv: yeah, i think about starting, but "want! now!" impatience gets in the way | 03:11 |
| lifeless | it would rock if they sold three or four versions | 03:12 |
| lifeless | jdub: and thus, Po | 03:12 |
| jdub | lifeless: or a little extendy piece of fabric | 03:12 |
| jdub | hmm. | 03:12 |
| jdub | probably going to have shirt size problems. | 03:12 |
| jdub | separate shirts == better. | 03:12 |
| piem | howdy. i'm trying to "bzr svn-import https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/pd", but it crashes bzr | 03:13 |
| lifeless | yes | 03:13 |
| jdub | lifeless: adult size, puppy brain! | 03:13 |
| jdub | he's 23kg now | 03:13 |
| jdub | 6 when we got him | 03:13 |
| lifeless | jdub: nice | 03:13 |
| spiv | piem: with a memory error, or something else? | 03:13 |
| lifeless | piem: details are needed, my telepathy is broken | 03:13 |
| piem | ok, i'll reproduce again. got than on osx, now back on debian unstable, and got the same | 03:14 |
| jdub | he's currently chasing horse flies in the loungeroom... chaos. | 03:14 |
| piem | $ dpkg -l bzr | tail -1 | awk '{print $3}' | 03:15 |
| piem | 2.0.1-1 | 03:15 |
| piem | $ dpkg -l bzr-svn | tail -1 | awk '{print $3}' | 03:15 |
| piem | 1.0.0-1 | 03:15 |
| piem | now running the import, it will take a while... | 03:16 |
| spiv | piem: a pastebin of the error would be helpful | 03:16 |
| piem | spiv: yep, preparing that... | 03:17 |
| Peng_ | jdub: Waitwaitwait, I just fixed that LocalTransport bug in the trunk a couple days ago. | 03:17 |
| jdub | Peng_: oh! loggerhead trunk? | 03:17 |
| Peng_ | jdub: Yah. | 03:17 |
| jdub | Peng_: win! :-) | 03:17 |
| spiv | jdub: also, loggerhead trunk has my fix from yesterday I think | 03:18 |
| jdub | looks like i'll have to start running loggerhead trunk ;) | 03:18 |
| jdub | yayayay | 03:18 |
| spiv | jdub: (and bzr trunk now has the fix for the other issue I bumped into too) | 03:18 |
| lifeless | spiv: whats a test that will run only_raises | 03:18 |
| Peng_ | spiv: Yes, it does. | 03:18 |
| jdub | not quite so interested in running bzr trunk ;) | 03:18 |
| piem | http://pastebin.com/d47582967 | 03:19 |
| Peng_ | jdub: Why not? | 03:19 |
| jdub | (it appears this loggerhead adventure has been fruitful!) | 03:19 |
| spiv | lifeless: test_decorators has unit tests for it | 03:19 |
| jdub | Peng_: happy to run 2.0 on production machine via ppa, but not quite so keen on bothering with trunk ;) | 03:19 |
| Peng_ | jdub: Bazaar's trunk is just as reliable as the releases. | 03:19 |
| lifeless | piem: either a sf operation issue, or a bzr-svn bug; start by filing a bug on bzr-svn please | 03:19 |
| Peng_ | jdub: Plus, there's a nightly PPA, so you don't even have to build it yourself. | 03:19 |
| spiv | lifeless: or if you mean indirectly, any test that invokes unlock on a Repository or Branch | 03:19 |
| spiv | Peng_: mmm, our trunk is pretty damn good | 03:20 |
| spiv | Peng_: but even so it's not *quite* as reliable as releases | 03:20 |
| piem | lifeless: https://bugs.launchpad.net/bzr-svn/+filebug ? | 03:20 |
| Peng_ | spiv: The only major breakage I remember is all of the fallout back when packs were added, and that made it into the releases. :P | 03:21 |
| spiv | piem: yep | 03:21 |
| Peng_ | spiv: But you're right. Still, it's pretty damn close. | 03:21 |
| Peng_ | spiv: I sent the contributor agreement email, btw | 03:22 |
| spiv | Peng_: there have been a few regressions in trunk from time to time that we've been careful to catch and fix before releases | 03:22 |
| Peng_ | spiv: Hmm. The 2a fallout? | 03:22 |
| spiv | Peng_: and occasionally stuff like hpss verbs in one revision of trunk incompatible with an earlier revision of trunk | 03:22 |
| Peng_ | spiv: Oh, that's a good point. That did bite me once. | 03:23 |
| Peng_ | The main problem with running bzr.dev is keeping all of your plugins compatible. | 03:23 |
| Peng_ | piem: The "bzr init" is pointless. | 03:23 |
| fullermd | All the majorest hiccups I remember ended up happening with releases too. | 03:23 |
| piem | Peng_: why? | 03:24 |
| fullermd | So maybe it's safer to avoid them and stick with .dev ;) | 03:24 |
| spiv | Yeah, plugins are really the main practical issue, much more so than our rare regressions. | 03:24 |
| piem | Peng_: import does init too/ | 03:24 |
| piem | ? | 03:24 |
| jdub | Peng_: i use bzr-svn quite a bit (working with wordpress stuff) | 03:24 |
| piem | just submitted a bug | 03:24 |
| piem | https://bugs.launchpad.net/bzr-svn/+bug/457813 | 03:24 |
| ubottu | Launchpad bug 457813 in bzr-svn "bzr svn import crashes" [Undecided,New] | 03:24 |
| Peng_ | piem: Well, first of all, teh command you were looking for was "bzr init-repo", not "bzr init". And yes, it does create its own repo. | 03:25 |
| Peng_ | jdub: You only have to keep a copy of bzr.dev's bzrlib around for Loggerhead. You don't need to install it globally. Well, you'd have to hack get it into sys.path somehow, but... | 03:25 |
| === Sam__ is now known as SamB_XP | ||
| Peng_ | Just sayin'. | 03:25 |
| jdub | Peng_: wait, loggerhead trunk requires it? | 03:26 |
| Peng_ | jdub: Err, no, not what I meant. I meant that if you wanted to run Loggerhead against bzr.dev, you don't need to install bzr.dev globally. | 03:27 |
| Peng_ | jdub: Loggerhead trunk is supposed to be compatible back to...1.13, I think? | 03:27 |
| Peng_ | jdub: I don't know if anyone tests it regularly, but... | 03:27 |
| jdub | right | 03:29 |
| jdub | yeah, if i don't need to run bzr.dev, i'm not going to bother :) | 03:29 |
| piem | Peng_: right. reproduced, the right way :-) | 03:30 |
| spiv | piem: exact same error? Or does the SVN revision number change? | 03:30 |
| piem | and bug report updated | 03:30 |
| piem | spiv: exact same error it seems | 03:32 |
| Peng_ | jdub: If you want .bzr/smart to work with shared repos, you'll need bzr.dev. Or to backport the patch. | 03:33 |
| spiv | Or use the monkeypatch I gave him yesterday | 03:33 |
| jdub | yeah | 03:34 |
| Peng_ | Or that! | 03:34 |
| Peng_ | Heh. | 03:34 |
| Peng_ | I don't want to add the monkeypatch to Loggerhead; there's not a good way to test if the version of bzr.dev being used has the bug or not. | 03:34 |
| spiv | Peng_: version < 2.1.0b2 would be approximately right | 03:35 |
| mwhudson | lifeless: one as in u1? | 03:35 |
| mwhudson | in any case, good to know | 03:37 |
| Peng_ | spiv: Eh. | 03:39 |
| spiv | Peng_: I'm not for or against adding the monkeypatch to loggerhead anyhow | 03:39 |
| spiv | Peng_: just saying :) | 03:39 |
| Peng_ | spiv: :) | 03:39 |
| Peng_ | I don't _want_ to add it, but I also want Loggerhead to seem less buggy. I'm going with the lazy choice for now. :P | 03:40 |
| spiv | +1 lazy | 03:40 |
| spiv | piem: not that it matters a lot, but I don't see your update to the bug report? | 03:42 |
| Peng_ | Stupid question: does interning objects keep them around forever or can they still be GCed? | 03:45 |
| mwhudson | interning strings doesn't keep them around forever | 03:48 |
| piem | spiv: editing the first entry actually failed, resubmitted now | 03:50 |
| Peng_ | ISTM _static_tuple_py's interning makes them immortal, though. It just does "adict.setdefault(self, self)" | 03:51 |
| spiv | Peng_: hmm, perhaps that should be a weakref dict of some sort. | 03:52 |
| Peng_ | _static_tuple_c OTOH uses a SimpleSet, and does a decref and has a comment about making sure they're not immortal, so I guess it doesn't? | 03:53 |
| mwhudson | static tuple's aren't weakrefable | 03:54 |
| mwhudson | though maybe the python version is | 03:54 |
| spiv | mwhudson: the pure python one is a non __slot__ted subclass of tuple, so it probably is | 03:54 |
| spiv | (Hmm, adding __slots__ to that is probably a good idea though) | 03:54 |
| mwhudson | spiv: i don't think it is actually | 03:54 |
| mwhudson | because you can't weakref subclasses of variable sized types i think | 03:55 |
| mwhudson | (i tried to fix this once) | 03:55 |
| spiv | mwhudson: apparently you're right | 03:55 |
| spiv | That seems like an odd restriction. | 03:55 |
| mwhudson | spiv: it's because the location of the weakref list is stored as an offset into the structure | 03:56 |
| mwhudson | in something like tuples you'd have to interpret a negative offset as an index from the end of the object | 03:56 |
| spiv | Ah, hmm. | 03:56 |
| mwhudson | (which is how dict is done) | 03:57 |
| mwhudson | i can't remember why i didn't fix this, i guess i just ran out of steam | 03:57 |
| spiv | Another reason perhaps to make the pure python StaticTuple not inherit from tuple | 03:57 |
| mwhudson | or make interning a noop | 03:58 |
| spiv | (the other is that you can't make tuple + StaticTuple give you a StaticTuple) | 03:58 |
| spiv | (which is an unfortunate difference in behaviour from the C version) | 03:58 |
| spiv | I don't think it's hugely likely that we'll right code that accidentally depends on "foo = (prefix,) + a_static_tuple; foo = foo.intern()" | 04:00 |
| Peng_ | There are probably other subtle differences, features that tuple doesn't implement but StaticTupleC does. | 04:00 |
| spiv | s/right/write/ | 04:00 |
| lifeless | mwhudson: yes, u1 | 04:00 |
| spiv | (I'm sure if wrote it we'd right it sooner or later ;) | 04:00 |
| mwhudson | lifeless: ugh :( | 04:01 |
| mwhudson | lifeless: oh well, i'm glad i can take advantage of their pain | 04:01 |
| lifeless | mwhudson: they may have gotten all the glitches out by now | 04:02 |
| lifeless | but its got a tonne of too-much-magic in it | 04:03 |
| lifeless | such as watching sys.modules contents, which is a terrible idea (apt-get dist-upgrade FAIL) | 04:03 |
| Peng_ | E.g., StaticTuplePy.from_sequence supports arbitrary iterables; C requires sequences. | 04:03 |
| Peng_ | StaticTuplePy can be subclassed, C cannot . . | 04:03 |
| Peng_ | The very basic issubclass(StaticTuple, tuple). | 04:04 |
| lifeless | AfC: why? | 04:33 |
| AfC | lifeless: you talking about aspiration for a loggerhead-less embedded web server? | 04:34 |
| lifeless | yes | 04:34 |
| lifeless | I said 'we don't want it' and you piped up with 'it would be desirable'... | 04:35 |
| lifeless | so why is it desirable? | 04:35 |
| AfC | lifeless: well (and this is just my subjective experience, but) LoggerHead has been unbearably slow. | 04:36 |
| AfC | lifeless: It's user interface is ghetto. | 04:36 |
| AfC | lifeless: It is almost impossible to find the revisions [and their detailed commit messages] that actually contributed changes as instead presents almost exclusively to the useless left hand edge merges. | 04:36 |
| lifeless | AfC: so, an embedded http server in bzr core would be likely be slower and even more primitive | 04:37 |
| AfC | lifeless: and I am quite embarrassed that my code is presented by it on the branches that launchpad mirrors. | 04:37 |
| AfC | lifeless: as may be | 04:37 |
| lifeless | AfC: these are 'things wrong with loggerhead' not 'why there should be an embedded http server in bzr core' | 04:37 |
| lifeless | AfC: For the former, I encourage bug filing! | 04:38 |
| AfC | lifeless: I've been hacking on a kludgy workaround just using GNU source-highlight locally and then rsyncing up | 04:38 |
| lifeless | for the latter, I'm still at a loss | 04:38 |
| AfC | lifeless: but a straight forward [a la darcsweb, gitweb] branch navigator would have been lovely. | 04:38 |
| lifeless | I _loath_ gitweb | 04:38 |
| lifeless | its terrible | 04:38 |
| AfC | lifeless: or whatever they're running on git.gnome.org — people can effortlessly refer to a branch + revision + file + line number combination. | 04:39 |
| mwhudson | a Transport should expect to get paths that are utf-8 plain strings and urlencoded, right? | 04:39 |
| lifeless | mwhudson: yes | 04:39 |
| lifeless | mwhudson: or rather no | 04:40 |
| lifeless | mwhudson: urls and relative urls | 04:40 |
| mwhudson | lifeless: i mean a transport method like "rename" | 04:40 |
| lifeless | mwhudson: url encoding is not uf8; its a specific defined encoding itself. | 04:40 |
| jfroy | verterok: I got things building, I'll try to package tomorrow | 04:40 |
| lifeless | utf8 is outside the permitted codepoints for urls | 04:40 |
| mwhudson | lifeless: yes, it's a succession of things: unicode --(utf-8)--> str --(urlencode)--> ascii-only str | 04:41 |
| lifeless | AfC: you can do that in loggerhead too | 04:41 |
| lifeless | mwhudson: urls don't imply unicode or utf8 at all | 04:41 |
| lifeless | mwhudson: std66 is sadly clear about it being useless this way. | 04:41 |
| spiv | AfC: I honestly don't see any of that being harder with loggerhead than with what git.gnome.org is running | 04:41 |
| mwhudson | lifeless: i'm not talking about urls, i'm talking about bzrlib.transport.Transport methods | 04:42 |
| lifeless | mwhudson: the generator of a url is responsible for getting it into url form, and noone else is permitted to try to decode it. | 04:42 |
| lifeless | mwhudson: so am I | 04:42 |
| spiv | except *perhaps* the browsing for branches part | 04:42 |
| lifeless | mwhudson: they take relative url references | 04:42 |
| AfC | spiv: I couldn't say why, to be honest. I'm just giving you the result of my experience working with both that cgit is a) not slow and b) way easier to use. | 04:42 |
| spiv | But certainly once you're looking at a branch it's essentially the same, except it takes me one less click with loggerhead | 04:43 |
| lifeless | AfC: its fast, I'll give you that. Thats something loggerhead can improve at - it should be faster with 2a branches anyhow. | 04:43 |
| lifeless | AfC: can you describe /how/ cgit it easier to use? | 04:43 |
| lifeless | I know I find 'blob' links a bit of a mindfuck | 04:44 |
| mwhudson | lifeless: the concrete problem i have is that "bzr push bzr+ssh://bazaar.launchpad.dev/~mark/+junk/bé" causes a server side exception | 04:44 |
| mwhudson | (that was a utf-8 string if irc's unhelpfulness on this topic defeated things) | 04:45 |
| lifeless | mwhudson: ok. So the client should be encoding that, and here is where std66 fucks us, we guess at utf8 for the native encoding of the far end | 04:45 |
| mwhudson | lifeless: right | 04:45 |
| lifeless | so you'll have argv[2].decode(console_encoding).encode('utf8').urlencode() | 04:46 |
| lifeless | and then pushed over the wire | 04:46 |
| lifeless | whats the server side exception? is there a bug? | 04:46 |
| mwhudson | lifeless: the bug is https://bugs.edge.launchpad.net/launchpad-code/+bug/449528 | 04:46 |
| ubottu | Launchpad bug 449528 in launchpad-code "lp: resolution for non-ASCII name oopses" [High,Triaged] | 04:46 |
| mwhudson | well, ish | 04:46 |
| spiv | AfC: hmm. Well, if you figure out why it feels nicer to you at some point then please do file a bug or post about it. From what I can see loggerhead's UI actually is simpler for this, but I realise UI issues can be pretty subtle. | 04:46 |
| mwhudson | the exception in that report is in the lp-resolution | 04:46 |
| lifeless | mwhudson: is there a stock test double for launchpad, for using in code that wants to talk to launchpad | 04:47 |
| mwhudson | lifeless: no | 04:47 |
| mwhudson | it would be hard to make a generically useful test double that was much less complicated than launchpad i think... | 04:47 |
| lifeless | a fixed definition of apis would allow that to be programmtically generated | 04:48 |
| mwhudson | lifeless: the exception is actually in the implementation of the xml-rpc method that we call to interpret paths | 04:49 |
| AfC | spiv: I don't know. I've just spent the last 5 minutes trying to find loggerhead of bzr on launchpad. I really don't have any more time, so I'm sure you'll dismiss this feedback as whinging. Pity I can't be more specific. At least my objection to Bazaar Explorer is simpler to articulate. | 04:49 |
| lifeless | mwhudson: it would help to have a backtrace in the bug | 04:49 |
| mwhudson | lifeless: basically, i think there's a lack of understanding of unicode paths all through the code, so i want to figure things out starting at the beginning | 04:49 |
| spiv | AfC: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/ | 04:49 |
| lifeless | mwhudson: we try for crunchy shell there | 04:50 |
| AfC | spiv: [thanks; that wasn't anywhere obvious on the bling new website] | 04:50 |
| spiv | AfC: now, if your problem is with Launchpad's UI for browsing branches rather than loggerheads, that makes more sense to me :) | 04:50 |
| AfC | spiv: aren't they the same? | 04:51 |
| lifeless | AfC: bzr lp-open lp:bzr, and click on 'view the branch content' | 04:51 |
| mwhudson | lifeless: i'm implementing a transport, i'm part of the shell, surely? | 04:51 |
| lifeless | AfC: god no. | 04:51 |
| spiv | AfC: I mean, for browsing through the set of branches that are available | 04:51 |
| lifeless | mwhudson: gimme a backtrace, I'll try to help :) | 04:51 |
| AfC | really? Well, launchpad is what everyone I talk to thinks loggerhead is | 04:51 |
| AfC | s/launchpad/launchpad's pathetic attempt at branch, revision, and code browsing/ | 04:52 |
| lifeless | AfC: the url spiv gave you is loggerhead | 04:52 |
| mwhudson | lifeless: you've already answered my question enough i think | 04:52 |
| spiv | AfC: as opposed to what loggerhead provides to Launchpad, which I just gave you a link to | 04:52 |
| spiv | AfC: (And is where the "browse the source code" link on https://code.launchpad.net/bzr will take you) | 04:52 |
| lifeless | mwhudson: ok, well I'm happy to look more closely if you like. | 04:52 |
| lifeless | it would be a pleasant distraction from deciding how untested I can bear this ppa watcher to be | 04:52 |
| mwhudson | lifeless: thanks, i'll come back if i have more questions | 04:53 |
| Peng_ | Crap, I just let a traceback get word-wrapped by my email client. :( Should I resend a fixed version, or do you guys usually just suffer through mangled tracebacks? | 04:53 |
| spiv | AfC: so if the difficulty you have is with finding a branch in the first place, that's purely Launchpad. | 04:53 |
| AfC | So here I am, trying to find the revisions that led to revno 4753. Click on the expander, and all I get is more details about some guy named "Canonical.com Patch Queue Manager" who write some code | 04:53 |
| spiv | Peng_: they are generally decipherable anyway | 04:53 |
| mwhudson | oooh | 04:54 |
| mwhudson | bleeping xmlrpclib strikes again | 04:54 |
| mwhudson | i expect | 04:55 |
| spiv | AfC: ah, fair enough. The link "(4752.2.1 integration)" with the crossed arrows icon takes you to the other parent revision | 04:55 |
| AfC | Four pages later I finally find my way to a page that has a link that turns out to be http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/4752.1.1 that finally has the commit message that Vincent wrote. | 04:55 |
| spiv | AfC: but I think a way to see all the revisions that were merged into mainline at that point is lacking | 04:56 |
| emmajane | abentley, I see you're away and stuff... but I'll be in Toronto this weekend for OLF. We're going out for dinner on Friday if you're interested. | 04:56 |
| AfC | in little itty bitty type | 04:56 |
| * spiv takes some notes | 04:56 | |
| emmajane | (Everyone else is invited too... if you can make it up to Canada) | 04:56 |
| AfC | spiv: yeah, you know, like, say, `bzr viz` | 04:56 |
| mwhudson | aaaaaaaaaaa | 04:56 |
| * spiv nods | 04:57 | |
| AfC | oh, that's brilliant... from that page, click on "view branch changes" which is http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes/4752.1.1?start_revid=4752.1.1 and then get another useless left hand edge history. Squint hard, and we'll see our revision at the top. | 04:59 |
| * emmajane chuckles. | 04:59 | |
| AfC | spiv: so... here I am, having spent about 4 times longer on evaluating this than most people, [and lord knows I'm predisposed to at least try and figure it out] only to be frustrated, puzzled, and then ultimately profoundly depressed. | 04:59 |
| AfC | spiv: maybe this makes perfect sense to someone who understands the Zen Of LoggerHead | 05:00 |
| spiv | AfC: Thanks, this is useful feedback. | 05:00 |
| spiv | So, I think Loggerhead currently does a very good job with the left-hand history. | 05:01 |
| AfC | spiv: but I've got to admit as someone who has a reasonably sophisticated (if outsider) knowledge of Bazaar and it's culture [and more to the point, basis] that I have absolutely no idea what that tool is presenting, other than knowing that it's | 05:01 |
| AfC | not giving me anything I can readily show to a new developer saying "yeah, here! that's the code" | 05:01 |
| spiv | And a pretty weak job with the rest. | 05:01 |
| AfC | [and yes, I've tried this extensively on [mirrors of] my branches] | 05:01 |
| jdub | spiv: you would have received more points if you started that with, "so, on the one hand..." | 05:02 |
| AfC | spiv: which, actually, is my primary interest: people toddle along to one of my projects, ask a question, | 05:02 |
| AfC | spiv: and I want to show them a {file snippet | branch that is working on that feature} in as seemless and impressive a way as possible. | 05:02 |
| AfC | spiv: in order to suck them in, have them think that Bazaar is smoking hot & sexy cool | 05:03 |
| AfC | spiv: while being blown away and in need of CPR to get over how impressed they are at my code :) | 05:03 |
| spiv | So I think loggerhead does a pretty good job of that. Wanting to interrogate the non-lefthand history isn't usually something I'd want to do with a project I'm new to. | 05:03 |
| spiv | It would be good to make it easy to do so, of course. | 05:04 |
| AfC | spiv: in the projects I'm working on, the left hand edge is almost meaningless. It's the people who contributed the actual work in the [non merge] revisions & their commit messages that I'm interested in. That's where the credit needs to be focused. | 05:04 |
| AfC | spiv: and that's what the left hand edge bias comprehensively works against. | 05:04 |
| AfC | [as I write about frequently] | 05:05 |
| spiv | Sure. There are multiple use cases here. | 05:05 |
| AfC | spiv: (and, just to close the topic, annotate does NOT show left hand edges. It shows the revisions that change things. Merges are transparent there, as they should be) | 05:05 |
| spiv | And some of them aren't being well catered for. I just wanted to point out that some are, and I think actually fixing the presentation non-lefthand history is not fundamentally that hard. | 05:06 |
| spiv | ...and, to bring the conversation back to the start: I'd rather fix this in loggerhead than try to do it from scratch in some sort of minimal serve --http :) | 05:06 |
| mwhudson | spiv: do you have any good tips for running pdb inside a smart server process? | 05:07 |
| spiv | mwhudson: "import pdb; pdb.set_trace()" works well in a TCP server | 05:07 |
| spiv | Other than that, not really. | 05:07 |
| AfC | spiv: not sure; as I've just alluded to, those of you who work to the patch queue manager and have it committing your left hand edge seem awfully happy with that workflow, | 05:08 |
| mwhudson | hm, i can probably get a TCP server to work | 05:08 |
| AfC | spiv: but certainly no one else I know is using that model, and thus the culture expressed by the bzr tool (and its left hand edge loving ecosystem) doesn't seem to be that well suited to "their" needs. [using that sloppily, of course]... | 05:08 |
| AfC | spiv: and since I have a somewhat vested interest in Bazaar looking appealing to [new contributors] people, this is a very exposed issue for me. | 05:08 |
| AfC | spiv: back to start... fair enough | 05:08 |
| spiv | AfC: well, I think for heavy lifting you really want something richer than a web UI (which is not an argument for neglecting the web UI) | 05:09 |
| AfC | spiv: perhaps, but at this point anyone coming from another system has glorious [pun intended] web experiences, and we look lame & cumbersome in comparison. | 05:10 |
| spiv | AfC: but "when did this line of this file change", and "show me what's been happening lately" the sorts of things a casual users tend to want and loggerhead already caters for quite well. | 05:10 |
| mwhudson | huh, pushing to bzr://localhost/<non ascii path> says "bzr: ERROR: Unsupported protocol for url "bzr://localhost/~mark/+junk/bé"" | 05:10 |
| spiv | mwhudson: weird | 05:11 |
| spiv | AfC: I'll file some bugs with this feedback, it's good to have some concrete "user tried to do X, got lost" stories. | 05:12 |
| mwhudson | oh hang onnnnnnnnnnn | 05:13 |
| spiv | AfC: oh, and I'll note we keep getting git users in this channel wanting to rebase because they don't want to deal with non-linear history in any VCS ;) | 05:14 |
| mwhudson | the unicode characters in my test case are getting past the checks in get_transport because of the directory service? | 05:14 |
| mwhudson | well sort of | 05:14 |
| spiv | mwhudson: whee? | 05:14 |
| * spiv -> late lunch | 05:14 | |
| mwhudson | the directory service is accidentally quoting them | 05:14 |
| lifeless | 'accidentally' ? | 05:15 |
| mwhudson | well maybe not that | 05:16 |
| mwhudson | but it is | 05:16 |
| AfC | spiv: yeah, well, there is that :) | 05:16 |
| AfC | spiv: I have a suspicion that if we did a concerted push on making the workflow [that I don't have a cunning handle for, but that John blogged about at http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html ] | 05:17 |
| AfC | spiv: be *ultra* smooth and sexy | 05:17 |
| mwhudson | lifeless: basically you can say bzr push lp:<unicode> and it will go off and talk to the server | 05:17 |
| AfC | spiv: [ie, the use of revert there, and the need to not unrevert a second time] | 05:17 |
| mwhudson | lifeless: but the client will barf on bzr push sftp://<unicode> | 05:17 |
| mwhudson | (actually you can't say the former, the directory service will oops) | 05:18 |
| AfC | [when "revert" as in blow away is NOT what you're actually doing overall, even if in that branch at that instantaneous moment it is indeed the operation you are performing] | 05:18 |
| AfC | spiv: cross product | 05:18 |
| AfC | spiv: somehow making the `bzr diff -r submit:` UI a bit more first class | 05:18 |
| AfC | would suddenly make the outward goal that people are trying to achieve ["here's my patch, here are the revisions (sic) that led to it" be über clean] | 05:19 |
| AfC | and suddenly merge vs rebase would go away entirely (with bzr winning, because the workflow would be easy, and the history would be preserved... TRANSPARENTLY | 05:19 |
| AfC | anyway, that's what I'm ultimately after. There's no doubt in my mind that Bazaar's infrastructure is a better foundation, but equally the ... effect ... that people are presently rebasing to achieve isn't going to go away. | 05:21 |
| AfC | It is, indeed, [IMHO] the primary open source workflow, and we don't support it very well. | 05:21 |
| AfC | ... which was the point that Havoc & Martin made all those years ago when contemplating what a next gen distributed version control system ought to be if it was going to be of value to open source communities. | 05:22 |
| Peng_ | Ohh! I left out my name in the contributor agreement email. Oops. | 05:27 |
| mwhudson | lifeless: fwiw, i think i found the (or a, at least) problem in codehosting: in say def get(relpath) going self.base + relpath isn't valid | 05:35 |
| mwhudson | because the escaping is different on the two sides | 05:35 |
| lifeless | mwhudson: thats correct | 05:37 |
| lifeless | mwhudson: don't you wish we used haskell/erlang/ocaml? | 05:37 |
| mwhudson | lifeless: heck, python3k would be a lot better for this | 05:37 |
| lifeless | mwhudson: I don't think it would catch this as they are both going to be bytestrings | 05:38 |
| lifeless | unless relpath is unicode, in which case your caller is broken | 05:38 |
| mwhudson | lifeless: although launchpad implemented in haskell would be an interesting idea | 05:38 |
| mwhudson | lifeless: yeah, true in this case, but it would be better for other things | 05:38 |
| jelmer | moin | 06:00 |
| lifeless | hi jelmer | 06:01 |
| jdub | lifeless: writing post commit stuff is kinda hard for a sysadmin not familiar with the bazaar codebase | 06:03 |
| lifeless | jdub: I'd like to have a library of common needs | 06:04 |
| lifeless | jdub: the svn stuff is also strange | 06:04 |
| jdub | lifeless: ever thought of a runparts adapter? | 06:04 |
| lifeless | jdub: mmmm, not having stuff on disk ... | 06:04 |
| jdub | lifeless: hmm? | 06:05 |
| lifeless | I may be confused | 06:05 |
| jdub | lifeless: i was just thinking of a bazaar plugin which let you throw shell scripts into runparts style directories | 06:07 |
| jdub | and passed useful parameters | 06:08 |
| lifeless | jdub: see jelmers shell hooks plugin | 06:08 |
| * jdub currently trying to figure out params, as passed to post_change_branch_tip | 06:08 | |
| jdub | lifeless: ooer, wher eis this? | 06:08 |
| lifeless | jdub: somewhere around | 06:08 |
| lifeless | anyhow, write the hook, and import pdb;pdb.set_trace() as teh first line of it | 06:09 |
| lifeless | you can explore very effectively | 06:09 |
| lifeless | what do you want your hook to check | 06:09 |
| jdub | first thing appears to be "is this the branch i should be running this hook on?" | 06:09 |
| jdub | ahr: http://people.samba.org/bzr/jelmer/bzr-shell-hooks/trunk | 06:10 |
| lifeless | right, you can use the branch.get_config() to read a config key | 06:10 |
| lifeless | johnf has done some stuff for finding the public url too, for similar reasons | 06:10 |
| abentley | emmajane: I'm rock-climbing on Friday after work, but maybe I can meet up later? | 06:11 |
| emmajane | oooooo | 06:11 |
| emmajane | jealous | 06:11 |
| emmajane | I havne't been climbing in ages. | 06:11 |
| spiv | jdub: http://doc.bazaar-vcs.org/latest/en/user-reference/index.html#post-change-branch-tip http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.branch.ChangeBranchTipParams.html | 06:11 |
| emmajane | abentley, we'll be up at the end of the world for the pre-party. it'd be great if you could make it. | 06:11 |
| jdub | spiv: aha, it's that second url i have been looking for -- thanks! | 06:12 |
| jdub | hrm, suspect i can't really use the shell hooks stuff... not sure i want something in .bzr/branch/branch.conf -> i only want server-side hooks | 06:13 |
| lifeless | jdub: that should be referenced (as ChangeBranchTipParams) from the hook docs | 06:13 |
| lifeless | and pydoc bzrlib.branch.ChangeBranchTipParams | 06:13 |
| lifeless | will work | 06:13 |
| abentley | emmajane: Sure, can you mail me details? aaron@aaronbentley.com | 06:13 |
| emmajane | abentley, sure. | 06:13 |
| lifeless | jdub: .bzr/branch/branch.conf is fine for configuring a plugin that is only installed on the server :) | 06:13 |
| lifeless | jdub: as for the shell hooks - yes, security and containment are big reasons we didn't include them in core | 06:14 |
| jdub | lifeless: but if someone has the plugin on their client, won't it attempt to run the shell script? | 06:14 |
| lifeless | "jdub: as for the shell hooks - yes, security and containment are big reasons we didn't include them in core" | 06:14 |
| lifeless | :P | 06:14 |
| jdub | heh | 06:15 |
| jdub | lifeless: pdb during commit = win ;) | 06:16 |
| jdub | well | 06:16 |
| jdub | post commit ;) | 06:16 |
| lifeless | james_w: please upgrade bzr-builder to 2a | 06:18 |
| bialix | hi bzr universe | 06:45 |
| jdub | can't quite seem to get loggerhead to run a commit hook plugin | 07:01 |
| jdub | i've got a py file in /var/lib/loggerhead/plugins | 07:01 |
| jdub | set the BZR_PLUGIN_PATH env var in the init script (both exported and ahead of the daemon just in case) | 07:01 |
| jdub | BZR_PLUGIN_PATH=/var/lib/loggerhead/plugins bzr plugins | 07:02 |
| jdub | lists the plugin | 07:02 |
| jdub | it's world readable | 07:02 |
| jdub | i've set up a non-interactive way to see if it runs | 07:03 |
| jdub | (touch /tmp/touchable ;) | 07:03 |
| spiv | jdub: your plugin touches when loaded, or when the hook is run? | 07:03 |
| jdub | spiv: oh, within the hook | 07:04 |
| jdub | spiv: good point, check if it's loaded at all | 07:04 |
| spiv | Yeah | 07:04 |
| jdub | aha | 07:07 |
| spiv | It might be nice if loggerhead had an option to turn on a magic diagnostic URL, e.g. /plugins to list plugins. | 07:07 |
| jdub | loaded and running | 07:07 |
| jdub | maybe one of my checks is bad... | 07:07 |
| jdub | (also, must remember to restart loggerhead on plugin changes) | 07:07 |
| vila | hi all | 07:17 |
| vila | spiv: revno 4762 put babune in the red, 16 errors about TypeError: __init__() takes exactly 5 arguments (4 given) | 07:18 |
| bialix | hi vila | 07:18 |
| vila | hi bialix ! | 07:18 |
| bialix | :-) | 07:18 |
| bialix | babune -- what is funny name. what it means? a monkey? | 07:19 |
| vila | spiv: certainly trivial, but I'm worried that PQM let it pass... | 07:19 |
| vila | spiv: http://paste.ubuntu.com/298840/ | 07:21 |
| vila | spiv: I need to apply updates all over the place so babune (and I :) may well be unreachable in the coming hour, see the paste above for the various call sites | 07:21 |
| jdub | spiv: *lightbulb* ... plugins run in bzr serve's handy chroot | 07:22 |
| lifeless | jdub: :) | 07:23 |
| jdub | spiv: well, no, more that branch locations have special chroot names | 07:23 |
| jdub | (params.branch.base) | 07:23 |
| lifeless | this is why I mentioned johnf's work | 07:24 |
| igc | hi vila, bialix | 07:24 |
| bialix | hi igc | 07:24 |
| * igc back online after a day nursing my 6 year old | 07:25 | |
| mneptok | igc: you've started lactating?! | 07:30 |
| igc | mneptok: no, that's well beyond my talents! | 07:31 |
| mneptok | igc: damn. it's always been a secret desire of mine, and i was going to ask about your current pharmaceutical regimen. | 07:31 |
| igc | mneptok: :-) | 07:32 |
| lifeless | mneptok: I hear simple stimulation can be enough | 07:43 |
| * spiv puzzles over the test failures that PQM didn't catch | 07:47 | |
| spiv | lifeless: Oh!! | 07:47 |
| spiv | lifeless: selftest --subunit gives exit code 0 even when a test fails. | 07:48 |
| * spiv fixes the immediate failures first. | 07:48 | |
| === mthaddon` is now known as mthaddon | ||
| mneptok | lifeless: if you're going to be at UDS, i'll take you up on that offer | 08:05 |
| * vila back after rebootS | 08:07 | |
| vila | spiv: ping | 08:08 |
| spiv | vila: so | 08:09 |
| spiv | vila: 1) fix for the test failures is with PQM | 08:09 |
| spiv | vila: 2) selftest --subunit has exit code of 0 even when test fail | 08:10 |
| vila | argh, I ws so afraid about 2) :-( | 08:10 |
| vila | spiv: is that related to the progress reportting ? | 08:10 |
| spiv | vila: well, in bzr.dev make check uses --subunit now | 08:11 |
| spiv | To give the progress reporting | 08:11 |
| spiv | But it looks like subunit's TestProtocolClient has a bug in wasSuccessful | 08:11 |
| spiv | In certainly doesn't have a unit test for it... | 08:11 |
| vila | spiv: ok, thanks for checking that so quickly | 08:11 |
| spiv | vila: this explains both recent cases of buildbot breakage I think | 08:12 |
| vila | I was about to say that :) | 08:12 |
| vila | It certainly sounds like jam's breakage that we attributed to some extension building related problem wasn't related to extensions :) | 08:12 |
| vila | It's a good thing I don't use 'make check' in babune (as I considered at one point, but I think lifeless disagree :) | 08:13 |
| vila | disagreed | 08:13 |
| lifeless | spiv: subunit command gives non-0 though | 08:14 |
| lifeless | spiv: oh, you've found the bug? | 08:14 |
| spiv | lifeless: yes | 08:14 |
| lifeless | cool | 08:15 |
| spiv | lifeless: here's a failing unit test for you http://pastebin.com/m72a5a3bf | 08:15 |
| spiv | lifeless: feel like writing the fix? :) | 08:16 |
| spiv | lifeless: (I need to go to the shops and grab some dinner stuff) | 08:16 |
| lifeless | spiv: not tnoight; can you file a bug with that? | 08:16 |
| spiv | lifeless: sure | 08:17 |
| spiv | lifeless: https://bugs.edge.launchpad.net/bzr/+bug/457952 | 08:23 |
| ubottu | Launchpad bug 457952 in bzr "TestProtocolClient.wasSuccessful is always True" [Critical,Confirmed] | 08:23 |
| spiv | Pfft, I filed that on subunit originally, but somehow the bzr task seems to have taken precedence. | 08:23 |
| spiv | Anyway, food. | 08:24 |
| Peng_ | Crapcrapcrap, jailbreak errors. | 08:29 |
| Peng_ | Ah, I accidentally reverted the fix. | 08:31 |
| lifeless | spiv: thats not the bug | 08:36 |
| garyvdm | Hi bialix | 08:46 |
| garyvdm | I don't often get annoyed, but I'm realy piss now... </vent> | 08:47 |
| bialix | Hi Gary | 08:48 |
| bialix | garyvdm: I don't understand | 08:48 |
| bialix | am I say something wrong (again)? | 08:48 |
| garyvdm | No not you | 08:49 |
| === weigon_ is now known as jan | ||
| garyvdm | Craig | 08:49 |
| vila | garyvdm: me ? I said nothing ! Maybe I should have ? :-D | 08:49 |
| === jan is now known as Guest67699 | ||
| garyvdm | lol | 08:50 |
| * vila is always happy when he can make an angry people laughs :) | 08:50 | |
| bialix | garyvdm: that custom rendering was always issue for me | 08:51 |
| bialix | garyvdm: take easy, Craig is not python developer as I know | 08:52 |
| garyvdm | bialix: Me to. The qt api is not very good, it that it does not allow you to reuses the bits that you need. | 08:52 |
| bialix | heh | 08:53 |
| === Guest67699 is now known as weigon | ||
| Peng_ | jam: ping | 09:00 |
| vila | Peng_: Don't wake up the beast yet... | 09:00 |
| vila | Peng: it's 3:00AM in Chicago... | 09:01 |
| Peng_ | vila: A real beast never sleeps anyway! | 09:01 |
| vila | Peng: oh, you're talking about fullermd now... | 09:01 |
| Peng_ | jam: There's a little oddness in StaticTuple_New: if (size < 0), it throws a TypeError with PyErr_BadInternalCall(). Then it has a check, if (size < 0 || size > 255), it throws a ValueError. | 09:02 |
| Peng_ | I should probably file a bug or something instead of IRC-poking. | 09:03 |
| vila | Peng: exactly, throw a mail to the ML or better, file a bug | 09:03 |
| Peng_ | vila: Then I have to think of a title and stuff. I hate that. :P | 09:04 |
| Peng_ | (Will do.) | 09:05 |
| vila | Peng: title == 'little oddness in StaticTuple_New' | 09:05 |
| Peng_ | vila: I hate undescriptive bug tiles like that, or "bzr crash" or whatever. | 09:07 |
| spiv | lifeless: oh? | 09:07 |
| spiv | lifeless: hmm | 09:08 |
| spiv | lifeless: so, in that case, I still think you want a test for the behaviour of wasSuccessful :) | 09:08 |
| vila | Peng: that one should be short-lived so it doesn't matter that much, what you want is catch jam attention, if you don't want to file a bug, send a mail :) | 09:08 |
| Peng_ | vila & jam: Well, I filed https://bugs.edge.launchpad.net/bzr/+bug/457979 about it. | 09:12 |
| ubottu | Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/457979) | 09:12 |
| Peng_ | C'mon, ubottu, you can do it! ...Darn. | 09:12 |
| vila | Peng: hmm, looks like today will be a good day for you :) | 09:13 |
| Peng_ | I just edited the bug description right after filing it. I *always* do that. | 09:14 |
| igc | vila: do you have time today to look at the review queue? There's a few small changes there from community folk that I'd like to get a second reviewer on | 09:35 |
| vila | igc: not really, but I'm tweaking the terminal_width one right now | 09:35 |
| vila | igc: also I'd really like if we can do *something* about the dwim revspec one to get it moving forward | 09:36 |
| vila | lifeless: would you be really sad if we land it as is ? I agree we want *something* to be done for svn:, git:, thread:, etc, but we don't have that today so I think it's not a valid reason to block the landing... thoughts ? | 09:42 |
| vila | spiv: babune starting its comeback in green (jaunty almost there, I'll start the others now), thanks | 09:44 |
| igc | vila: ok. Thanks for working on the terminal width one. I think we need to help pilot a few of these patches through rather than let them sit there in semi-limbo for weeks/months | 09:50 |
| vila | igc: you're preaching the choir :) | 09:50 |
| igc | vila: ? as in you agree? | 09:51 |
| vila | igc: as in: I fully agree for years :-D | 09:51 |
| vila | igc: as in: I'm a dog more than a owl (at least that's what everybody is telling me :) bark bark | 09:52 |
| igc | vila: I've been flat out on 2.0-related stuff like packaging and docs for a few months now but ... | 09:53 |
| igc | vila: I'd *love* to get back to the BundleBuggy days of just a few patches in the queue - not 20 | 09:53 |
| vila | igc: sure, I think we have more submissions right now though... | 09:54 |
| igc | vila: we probably do. It will only increase though if we're successful :-) | 09:55 |
| vila | igc: hehe, I think the actual increase *is* already a sign of success :) | 09:55 |
| igc | vila: and I want the community folk to enjoy the experience of submitting patches (again) rather than being frustrated as some have been lately | 09:56 |
| igc | vila: anyhow, enough philosophy. Here are the simple patches I'm looking for a reviewer on ... | 09:57 |
| igc | https://code.edge.launchpad.net/~mathepic/bzr/mkdir-recursive/+merge/13380 | 09:57 |
| igc | https://code.edge.launchpad.net/~mathepic/bzr/remove-tree-multi/+merge/13451 | 09:57 |
| igc | plus the terminal one | 09:58 |
| lifeless | vila: I think that landing the proposed patch makes things less clear/obvious for someone wanting to work inthat area | 09:59 |
| lifeless | vila: that fails the 'dont make things worse' tenant | 09:59 |
| lifeless | bah, spelling. | 09:59 |
| lifeless | vila: I'm not -1 on it, but I'm certainly not for it. | 10:00 |
| vila | lifeless: worse ? It *adds* new semantics for unqualified rev specs. It *doesn't* provides an easy way to add *more* dwim semantics, but there wasn't any before that. What is worse ? | 10:03 |
| vila | lifeless: I'm really trying to understand here, I've looked at addressing [y]our concerns but didn't find a trivial way in less than an hour, hence my desire to land as is | 10:05 |
| spiv | I'm inclined to agree with vila. I haven't looked at the patch closely, but I don't see that adding that extensibility later is going to be hard enough that it justifies landing the incremental improvement. It doesn't feel like a step backwards to me. | 10:07 |
| spiv | Er, | 10:07 |
| spiv | That is justifies *not* landing. | 10:07 |
| spiv | memo to self: long run on sentences with double negatives on irc are a bad idea :) | 10:08 |
| * igc dinner | 10:12 | |
| Kamping_Kaiser | suppose I bugger up a commit without noticing and want to fix it. is the best thing to branch at that point, fix and merge? | 10:15 |
| === loxs_wrk is now known as loxs | ||
| Kamping_Kaiser | I have commited since the change in question | 10:15 |
| Peng_ | Kamping_Kaiser: Daggy Fixes are really cool (IMO), but not necessary. You can just "bzr commit" a fix. | 10:16 |
| Peng_ | Kamping_Kaiser: Daggy Fixes are useful if you want to do something like merge it into a release branch, though. | 10:16 |
| Kamping_Kaiser | Peng_: ok, thanks. | 10:17 |
| === davidstrauss_ is now known as davidstrauss | ||
| lifeless | spiv: vila: it adds a long case statement which needs to be teased apart and put back into the existing registry | 11:33 |
| vila | lifeless: right, looking at the code, I think we don't want to inherit from RevisionSpec but put the code back into a static method, and from there, right (apart from rewriting the tests), there should be a way to come back to a registry but I'm not sure we want to reuse the existing one or create a new one | 11:38 |
| vila | but that isn't indeed trivial | 11:39 |
| vila | pff, not even ! the dwim revspec is used to delay the _match_on call so that the actual revspec can be created lazily from the dwim_revspec created in from_string :-/ | 11:41 |
| === deryck is now known as deryck[afk] | ||
| vila | hmm, jam just walked on his laptop that he mistakenly left near his bed... | 11:54 |
| === mrevell is now known as mrevell-lunch | ||
| RenatoSilva | Is there a way to unmerge an ancient merge? | 12:59 |
| === mrevell-lunch is now known as mrevell | ||
| === vila is now known as vila-afk | ||
| garyvdm | Any opions on Bug 444862? | 13:42 |
| ubottu | Launchpad bug 444862 in qbzr ""bzr qlog" displays revision when searching in revids, but not when searching in messages" [Undecided,New] https://launchpad.net/bugs/444862 | 13:42 |
| === weigon_ is now known as weigon | ||
| === vila-afk is now known as vila | ||
| vila | garyvdm: you mean apart from the fact that 52 clicks is too much ? :) | 14:15 |
| vila | garyvdm: oh wait, you ask that question before guilhem replied tight ? | 14:16 |
| guilhembi | vila: garyvdm: | 14:16 |
| guilhembi | hello, yes I just replied, and it has to do with 52 clicks indeed (more details in my reply). | 14:17 |
| guilhembi | and I attached a screenshot to clarify more. | 14:17 |
| garyvdm | guilhembi: Ok - so you want it to expand to the found revision. | 14:20 |
| garyvdm | *revisions | 14:20 |
| guilhembi | garyvdm: yes, 52 clicks is tedious. On the other hand, there is not one found revision, all found revisions are interesting, | 14:21 |
| guilhembi | so I guess it could expand to all found revisions. On the yet other hand, if the search found 10000 revisions, | 14:21 |
| guilhembi | this expanding will kill qlog I guess. | 14:21 |
| guilhembi | Which is why I thought - don't expand, but offer an "expand all" button (if user sees 1000 unexpanded revisions he may not click on the button). Just an idea. | 14:22 |
| garyvdm | Yes - if you start typing 'apple' and you just get to 'a' - it will show lots. | 14:22 |
| garyvdm | hmm - intresting problem | 14:23 |
| === deryck[afk] is now known as deryck | ||
| igc | night | 15:09 |
| === MTecknology is now known as MTeck-ricer | ||
| jam | night igc | 16:04 |
| jam | morning vila, did you see my response to your 'isatty' change | 16:04 |
| jam | I think you 'broke' the original intent with your update | 16:04 |
| vila | jam: not yet, :-/ | 16:05 |
| vila | jam: morning | 16:05 |
| jam | basically, you now set the terminal width based on whether there is an 'isatty' attribute | 16:06 |
| jam | rather than whether isatty() returns True/False | 16:06 |
| jam | and doing "bzr log | less" has an object with 'isatty' but it returns False | 16:06 |
| vila | oh, I see, you mean I should *add* 'and not sys.stdout.isatty()' ? | 16:08 |
| vila | rhaaaa 'or not sys.stdout.isatty()' | 16:09 |
| vila | jam: ^ | 16:10 |
| vila | jam: ok, found your mail finally, I agree (as said above...) and will fix | 16:18 |
| vila | jam: did you read the IRC logs, especially the part about PQM not failing on errors ? (for bzr.dev, not 2.0.x) | 16:22 |
| === GaryvdM_ is now known as GaryvdM | ||
| === beuno is now known as beuno-lunch | ||
| jam | vila: I did not see the irc logs, I did see Andrew's post about it. | 16:38 |
| vila | jam: good, I didn;t see your comment on the bug until now | 16:42 |
| jam | Peng_: btw, I replied to the bug and the merge proposal | 16:43 |
| jam | wow GaryvdM is going banaza on the bugtracker... | 16:45 |
| fullermd | vila: I warned you that registrifying the DWIM wasn't trivial :p | 16:58 |
| vila | fullermd: I have a working patch except it fails one test that seems so unrelated I'm a bit puzzled... | 16:59 |
| fullermd | 's either a lot of grumpy hand-fitting so it works with The Way Things Are, or a lot of grumpy work changing The Way Things Are... | 16:59 |
| vila | fullermd: not that much, let me push that so you can see | 16:59 |
| fullermd | Oh, my eyes won't help you. I hit my capability limit just writing it as-is. | 17:00 |
| vila | fullermd: pff :) | 17:00 |
| fullermd | And I'm in crunch, so I won't have time to do more than glance at much for weeks... | 17:00 |
| fullermd | And actually, if the concensus is toward stopping on non-revno revno-looking things, that adds more magic in registrification, unless that check is left out of the reg, and... | 17:04 |
| maxb | igc: Hi! What's your initial reaction to the idea of having bzr-fastimport store git refs as bzr branch nicks? | 17:04 |
| vila | fullermd: look at lp:~bzr/bzr/revspec-dwim if/when you can | 17:04 |
| vila | fullermd: that's not as bad as many tought | 17:04 |
| fullermd | vila: What's with the pulling of wants_revision_history in 4586? | 17:06 |
| vila | fullermd: nobody uses that since we create new revspecs objects | 17:06 |
| fullermd | Are you sure? I needed it so that it didn't try to build the history when it looked into revnos, but DID for other stuff. | 17:07 |
| vila | fullermd: no I'm not sure :) | 17:07 |
| larsemil | i have created a project for wich i am the maintainer on launchpad. but i dont understand how to upload my code there? | 17:08 |
| fullermd | (and without at least setting it False, it ended up building the history just for revnos, which is a big regression) | 17:08 |
| vila | fullermd: you rock ! | 17:09 |
| vila | setting to false is enough | 17:09 |
| vila | Indeed, I deleted that after running only -s bt.test_revisio, but the failing one was not there... | 17:09 |
| vila | I need to EOD just now, but I'll update the submission probably later tonight ~21h00 my time (it's 18h10) | 17:10 |
| fullermd | I recall that I needed to reset it for later because something failed if I didn't, but that may be faulty memory. | 17:11 |
| jam | larsemil: you may want to create a group for the project | 17:19 |
| jam | otherwise just "bzr push lp:~USERNAME/PROJECT/trunk" or some similar branch name. | 17:19 |
| jam | you can then edit your project settings to declare that location as the 'development focus' | 17:19 |
| jam | so that people doing "bzr branch lp:PROJECT" will get the code from that branch. | 17:20 |
| jam | Peng_: if you could help me understand the issue with 'merge' it would be appreciated | 17:21 |
| jam | testing it locally doesn't seem to trigger the problem | 17:21 |
| larsemil | so now the project came under USERNAME/PROJECT so noone else will be able to commit to it+ | 17:22 |
| jam | larsemil: so anyone can push their own branch to "~myuser/project/branch-name", however yes, if you don't create a group for the project | 17:23 |
| jam | only you will be able to push to the trunk branch | 17:23 |
| jam | note that you can create a group later | 17:23 |
| jam | and move the development focus to that branch later, etc. | 17:23 |
| larsemil | jam: i did a push but still it says no revision? | 17:24 |
| larsemil | jam: and with group you mean team= | 17:24 |
| larsemil | ? | 17:24 |
| jam | larsemil: yeah, probably team | 17:25 |
| larsemil | thanks | 17:26 |
| jam | larsemil: did you commit locally before pushing? | 17:26 |
| larsemil | jammaybe not? | 17:26 |
| larsemil | before pushing i did bzr init | 17:26 |
| jam | larsemil: 'bzr init; bzr add; bzr commit; bzr push' is the general steps | 17:29 |
| === beuno-lunch is now known as beuno | ||
| jam | note that you may want "bzr init; bzr st; bzr ignore; bzr add" etc | 17:29 |
| larsemil | jam: thanks i got the files now | 17:32 |
| jam | Peng_: for example, are you sure that you recompiled all extensions before doing the 'bzr merge' ? | 17:38 |
| RenatoSilva | I want your feedback about the following workflow. I have trunk and feature branches. I focus on testing all of them together, so I have a branch all-features that basically is a merge of trunk and the otehr branches. | 18:48 |
| RenatoSilva | Hi. | 19:01 |
| RenatoSilva | I want your feedback about the following workflow. I have trunk and feature branches. I focus on testing all of them together, so I have a branch all-features that basically is a merge of trunk and the other branches. | 19:01 |
| dash | RenatoSilva: why do you do that? | 19:01 |
| break_ | hey. I was hoping someone could help me. I need to import the files from just the latest revision of an svn repo into a newly created bzr branch. I don't need any of the revision information, just the files themselves. how do i do this? | 19:49 |
| vila | fullermd: so, we were both half-right, wants_revision_history should be set to False at the class level BUT there is no need to set it to True after that. | 19:56 |
| vila | fullermd: presumably you needed it in some intermediate implementation ? | 19:57 |
| fullermd | Possible. | 19:57 |
| fullermd | Remember, I don't know python or bzrlib, so my patches are all just shotgunned until they work :p | 19:57 |
| fullermd | You can def. see the performance impact of not False'ifying it. | 19:58 |
| === Adys is now known as Cogwillie | ||
| Tak | break_: svn export, then bzr add? | 19:58 |
| vila | fullermd: EPARSE(can def. see) | 19:59 |
| fullermd | Goes from ~.21s to ~.60s for 'stat -c-1' without it, since it builds the full tree before it gets to trying the revno. | 19:59 |
| === Cogwillie is now known as Adys | ||
| fullermd | "can definitely see" | 19:59 |
| vila | ha, funny you say that, the failing tests was a effort one :-) | 19:59 |
| vila | bzrlib.tests.blackbox.test_pull.TestPull.test_pull_smart_stacked_streaming_acceptance | 20:00 |
| * fullermd blinks. | 20:00 | |
| fullermd | Wow, that must be some WEIRD indirect kinda effect :p | 20:00 |
| fullermd | But I guess it did its job, in a roundabout way. | 20:00 |
| vila | the test checks how many calls are done to the remote server, getting the rev history add calls | 20:01 |
| fullermd | I can only imagine the performance impact it would have on trees with more history than bzr.dev, but I knew if I submitted a patch that made -r123 more expensive, I'd get lynched... | 20:01 |
| vila | the good thing is that the test was well tought and caught a related bug, the bad thing is that it was the only test to catch it | 20:01 |
| fullermd | Yeah, but who expects something like that to be doing a -rSOMETHING? Wacky. | 20:02 |
| vila | fullermd: look at it now that you know it fails and why, you'll see it's obivous | 20:02 |
| vila | even more when knowing that replacing '-r 1' by '-r revno:1' made it pass | 20:02 |
| fullermd | Probably. I never looked at it before I kniew it failed :p | 20:02 |
| fullermd | ('cuz it never failed for ME. I can't help it if YOU break my perfect code ;) | 20:03 |
| sjamaan | Is there any sane documentation for scmproj? The official docs are thoroughly confusing | 20:03 |
| vila | fullermd: me neither, but it prompted me to ask for your fresh eye 5 mins before my EOD :) | 20:03 |
| vila | sjamaan: your input will certainly help, the main autho native language is not english | 20:04 |
| vila | s/autho/author/ | 20:04 |
| break_ | Tak: thank you, that looks like just what i need | 20:04 |
| sjamaan | vila: sure, but in order to be able to provide input I have to understand it first :) | 20:04 |
| sjamaan | I was able to initialize a project, but I can't find docs on how to actually start adding subprojects to the project | 20:05 |
| vila | I don't use it myself so I can't answer that | 20:06 |
| vila | fullermd: so, should I propose merging lp:~bzr/bzr/revspec-dwim or do you want to pull that in your branch and press the resubmit button ? | 20:08 |
| vila | I think the later will provide a better tracking,,, | 20:08 |
| fullermd | Either way. | 20:09 |
| vila | then pull/push/resubmit , I'll aprove, add some comments | 20:12 |
| vila | s/approve,/approve and/ | 20:12 |
| vila | fullermd: the 'resubmit proposal' button is in the upper right area | 20:13 |
| * fullermd waits in LP to update it. | 20:15 | |
| vila | ok | 20:15 |
| fullermd | I don't see a... oh, on the merge page, not the branch. | 20:16 |
| fullermd | 'k, wending its way around. | 20:20 |
| vila | fullermd: did you explicitly request reviews from Ian and Robert or did lp did that on its own ? | 20:21 |
| fullermd | I didn't do anything to add them, so I guess LP slapped 'em on. | 20:21 |
| vila | wow, I thought I approved that one.... but I'm not even in the comments 8-) | 20:22 |
| fullermd | You answered the email I sent on to the list, not the MP mail. | 20:22 |
| * fullermd goes on another epic bitch session about the two being divorced. | 20:22 | |
| vila | hmm, yeah, both arrive in the same mailbox here so I may have been confused, especially if you used the same subject... | 20:23 |
| fullermd | jelmer and spiv also commented, but on the list, so they didn't make it into the tracker either. | 20:23 |
| vila | I think we are progressing anyway :-) | 20:24 |
| phoenixz | Hi all, Im new on Bazaar... Long time SVK / SVN user, but since SVK effectively is dead, I need to switch to something new.. Could anybody here tell me if bazaar has these options? - Offline working, automated merges (not needed to track which changes where, etc, just plain merge and it works)... | 20:25 |
| vila | We have nearly all the needed pieces in place: 1) You put an url to the merge proposal in the commit mesage when you land on trunk, 2) You put url to the mailing list archive in your merge proposal, 3) You teach qbzr/bzr-gtk to open urls in commit messages.... | 20:25 |
| fullermd | phoenixz: Both of those are pretty much inherent qualities in DVCS's, so bzr does them naturally. | 20:26 |
| phoenixz | fullermd: well, I'd think so too, but AFAIK, SVN doesn't.. :) which was the reason for me to use SVK, which does.. | 20:26 |
| fullermd | That's 'cuz SVN isn't a _D_VCS ;) | 20:27 |
| phoenixz | fullermd: sounds good.. is it possible to for BZR to connect to an SVN repository? | 20:27 |
| nyu | hi | 20:27 |
| phoenixz | fullermd: Just for the record, I'm just walking out on SVK / SVN here.. :) I know VCS, but what is a DVCS? | 20:27 |
| fullermd | phoenixz: Yes, there's a bzr-svn plugin for that. | 20:27 |
| nyu | I notice branching from svn (via bzr-svn plugin) is awfully slow. is this because of the branching or because of the svn->bzr conversion? | 20:28 |
| fullermd | phoenixz: 'Distributed' | 20:28 |
| dash | phoenixz: yes, i use bzr with several svn repos | 20:28 |
| nyu | I guess it's downloading the whole thing? | 20:28 |
| * fullermd has to dash off and take care of some things. | 20:28 | |
| dash | phoenixz: I hear it can even read SVK merge data but I haven't tried that :) | 20:28 |
| dash | nyu: yes, the first time it has to download the whole thing | 20:28 |
| phoenixz | dash: so it makes a complete local mirror of a repository, like SVK does? | 20:29 |
| dash | right | 20:29 |
| nyu | dash: once I created the first branch, will I be able to create further branches from it quickly? | 20:29 |
| dash | yes | 20:29 |
| nyu | I mean, remotely | 20:29 |
| dash | a shared repo can also help with that | 20:29 |
| phoenixz | fullermd: another question.. svn has the very FRIGGIN nasty habbit of dumping .svn directories all over the place.. bzr doesnt do this either? | 20:29 |
| dash | phoenixz: nope, just one .bzr dir at the top level of your branch | 20:29 |
| nyu | dash: so even if the repo is huge, I can branch a remote bzr URL into another remote bzr URL with small cost? | 20:30 |
| phoenixz | dash: mmm, I think I can live with that.. | 20:30 |
| nyu | i.e. without downloading the whole thing | 20:30 |
| dash | nyu: right, because it will use the revisions stored locally before downloading any | 20:30 |
| dash | if you use a shared repo then the branches will use it for the revisions they have in common | 20:31 |
| nyu | in that case I guess I should setup a bzr mirror of svn trunk, then branch off it, rather than branching directly from svn? | 20:31 |
| nyu | I need branching to be cheap | 20:31 |
| dash | nyu: that's what we did | 20:31 |
| nyu | ok, thanks | 20:31 |
| phoenixz | fullermd: so, it also tracks all changes and merges? So, say if I have tree B, with subdirectory lib in there.. I copy tree A to B, I make changes in some files in A/lib and some changes in similar and other files in B/lib.. then can I easily merge the changes from A/lib to B/lib and also vice-versa? | 20:32 |
| phoenixz | fullermd: I realize, I may be asking if ice is cold here, but with SVK.. well, it worked, but thats about all.. I have a migraine from using it and I need something that just plainly works.. | 20:32 |
| fullermd | phoenixz: Sorta. There'll be some realigning of your thinking to fit with bzr, though. | 20:32 |
| phoenixz | fullermd: howso? | 20:33 |
| fullermd | phoenixz: You don't work with repositories in bzr, you don't work with branches. And they're real branches, not 'copies'. | 20:33 |
| phoenixz | fullermd: okay.. trying to fit that in... | 20:33 |
| fullermd | phoenixz: And revisions are the first-class entities you ship around. So when you merge, you're merging one set of revisions with another. Your history has all the revisions you've ever pulled in, so it tracks based on that. | 20:34 |
| fullermd | phoenixz: I really need to run off right now, but I'll be back in an hour or so. Or somebody else can help you fill that in. | 20:34 |
| sjamaan | fullermd: Is there a way to fetch an entire repository with bzr? Or can you only fetch branches? | 20:34 |
| fullermd | sjamaan: Only branches, currently. There may never be a way to fetch a _repository_ per se, but there will probably be ways to fetch a _group of branches_. | 20:35 |
| sjamaan | (I'm a little concerned that if I have two very big branches and I clone both, they won't share data on my machine) | 20:35 |
| phoenixz | fullermd: okay, thanks for all the info anyway! Im going to give this one a good try | 20:36 |
| sjamaan | Having repositories be second-class citizens as it were, you undermine the distributed nature of bzr, no? | 20:36 |
| dash | sjamaan: create a repo, fetch branches into it, they'll share revisions | 20:36 |
| sjamaan | dash: Ah, that works? | 20:36 |
| dash | sjamaan: yep | 20:36 |
| sjamaan | cool! | 20:36 |
| sjamaan | I take it it picks up the sha1 hashes and uses that to determine two files are the same? | 20:37 |
| dash | sjamaan: this is why they're second class citizens, they're mostly an optimization rather than something affecting the contents of your branch :) | 20:37 |
| dash | sjamaan: revision IDs | 20:37 |
| sjamaan | Ah, I understand now | 20:37 |
| sjamaan | It does make sense | 20:37 |
| asac | how can i configure bzr branches so that noone can push merges that make the bzr revision move backward? | 20:38 |
| sjamaan | Is there a way to create repositories later on, after you checked out a branch? | 20:38 |
| sjamaan | (say I have branch a as a regular branch, but then decide I also want branch b, and want them to share data) | 20:38 |
| dash | sjamaan: sure. just do the same thing :) | 20:38 |
| dash | create a repo, create a branch in it from your existing non-repo branch | 20:38 |
| sjamaan | I need to re-clone the branch? | 20:38 |
| sjamaan | Or can I just move the existing branch into the repo dir? | 20:39 |
| dash | the former | 20:39 |
| * sjamaan nods | 20:39 | |
| sjamaan | I could probably clone it locally and then make it point at the original upstream branch, right? | 20:40 |
| sjamaan | (to avoid downloading a lot of data) | 20:40 |
| lifeless | asac: bzr help configuration, look for append_only | 20:42 |
| lifeless | moin | 20:54 |
| sjamaan | Where can I find more info on nested branches? | 21:04 |
| nyu | dash: uhm, the "bzr push" part of the mirroring just takes 5 steps in progress bar, is this normal? | 21:04 |
| nyu | it looks scaringly fast in comparison ;-) | 21:05 |
| nyu | I hope it *does* indeed upload the whole thing | 21:05 |
| Solarion | is there an easy-to-read guide to using bzr in emacs? | 21:21 |
| dash | Solarion: well, both vc (builtin to emacs) and DVC (available separately) support it | 21:22 |
| dash | DVC does more | 21:22 |
| sjamaan | dvc is fancy | 21:22 |
| dash | yeah and its bzr support is pretty good these days | 21:23 |
| Solarion | vc is (hopefully) fine for now | 21:23 |
| dash | Solarion: well, i'd just look at the manual for that | 21:23 |
| Solarion | I may be stupid, but I'm having trouble figuring out how to do a basic pull and update the buffers | 21:24 |
| dash | vc doesn't support pull | 21:24 |
| Solarion | ah, well, that'd explain it. :) | 21:24 |
| dash | vc was written when CVS was the hot new thing :) | 21:24 |
| Solarion | yeah | 21:25 |
| Solarion | it seems to quasi-support bzr, though, so it had me fooled | 21:25 |
| Solarion | is there an ubuntu package? | 21:25 |
| dash | sure | 21:25 |
| sjamaan | Solarion: I guess it would work if you only use bound branches? | 21:25 |
| dash | the operations that vc _does_ support, it supports on bzr | 21:25 |
| dash | (where they make sense) | 21:25 |
| sjamaan | (ie "centralised mode") | 21:25 |
| Solarion | sjamaan: I don't think so | 21:26 |
| Solarion | maybe I fail to distinguish between bound and checkout | 21:26 |
| sjamaan | no, that's the same | 21:26 |
| Solarion | then no. :) | 21:26 |
| Solarion | at least, not that I can tell | 21:26 |
| sjamaan | clone creates an unbound copy, checkout creates a bound copy of a branch | 21:27 |
| sjamaan | VC has all the main concepts then, no? commit, update, log | 21:27 |
| sjamaan | Those work when operating on a bound branch | 21:27 |
| sjamaan | (not that I've tried this though :) ) | 21:28 |
| Solarion | C-x v m? | 21:28 |
| Solarion | to just "Picku p any recent changes from the repository without trying to commit your own chagnes" | 21:28 |
| Solarion | "Sorry, merge-news is not implemented on Bzr" | 21:29 |
| sjamaan | ic | 21:31 |
| sjamaan | Well, too bad :) | 21:31 |
| Solarion | y8eah | 21:31 |
| Solarion | DVC it is | 21:32 |
| * Solarion doesn't want to manually update all the buffers | 21:32 | |
| sjamaan | yeah, that sucks too | 21:33 |
| nyu | is it possible to organize repositories using a directory structure? | 21:33 |
| sjamaan | I always hated that about vc-mode | 21:33 |
| nyu | bzr seems to want them all in the top dir | 21:33 |
| sjamaan | Even with svn I use psvn or dsvn | 21:33 |
| sjamaan | (but vc-mode is a nice way to do a "quick commit") | 21:33 |
| sjamaan | (and then afterwards finding out you forgot to commit the other file and need to do it all again) | 21:34 |
| sjamaan | :P | 21:34 |
| LarstiQ | nyu: euh? you can use directory hierarchies just fine | 21:34 |
| nyu | it complains that "parent of foo does not exist". and --create-prefix doesn't seem to be accepted in branch command | 21:35 |
| nyu | maybe I should branch locally, then push with --create-prefix ? | 21:36 |
| LarstiQ | what is it you are trying to do? | 21:36 |
| nyu | or perhaps just create the directory by hand | 21:36 |
| nyu | LarstiQ: branch from . to a remote location | 21:36 |
| nyu | . is a pull from svn, which I just pushed | 21:37 |
| nyu | (to a remote bzr location) | 21:37 |
| LarstiQ | nyu: `bzr push --create-prefix remote/location` | 21:38 |
| nyu | LarstiQ: but then it's not a branch? | 21:38 |
| nyu | or is it | 21:38 |
| LarstiQ | it is | 21:39 |
| * LarstiQ goes to bed | 21:40 | |
| nyu | but this uploads the whole thing? | 21:40 |
| lifeless | if the branch is new, yes | 21:41 |
| nyu | but I'm branching from something which is already in the server | 21:41 |
| lifeless | server? | 21:41 |
| nyu | I guess "branch <remote URL 1> <remote URL 2>" is what I'd like to do, but it complains about missing directory | 21:42 |
| nyu | may I create that dir by hand? | 21:42 |
| lifeless | nyu: is this an svn server? | 21:43 |
| lifeless | or a bzr server? | 21:43 |
| * lifeless is totally without context | 21:43 | |
| nyu | bzr | 21:44 |
| lifeless | then branching locally and push --overwrite newoath is equivalent | 21:44 |
| lifeless | uhm | 21:44 |
| lifeless | if you're worried that it will upload a lot of data - it won't (unless you don't have a shared repo) | 21:45 |
| lifeless | and if you don't have a shared repo, branching on the server would still have to do the same amount of work | 21:45 |
| nyu | I was using the local tree I use for the svn->bzr transition, is that ok? | 21:45 |
| lifeless | thats fine | 21:45 |
| nyu | do I have a shared repo? ;-) | 21:45 |
| lifeless | do you have any branches on the server yet? | 21:46 |
| nyu | well, I'm trying to create the first one. then I interrupted it mid-way because it seemed like it was uploading the whole thing | 21:46 |
| lifeless | it has to :) | 21:47 |
| nyu | but why? | 21:47 |
| nyu | it's already there | 21:47 |
| lifeless | you just said you don't have any branches on the server... | 21:48 |
| nyu | oh, sorry | 21:48 |
| nyu | I have something I would've called a 'trunk' | 21:48 |
| lifeless | and its a bzr branch ? | 21:48 |
| nyu | it's the result of bzr pull from svn && bzr push to bzr | 21:48 |
| lifeless | ok | 21:48 |
| lifeless | 'bzr info <url to trunk>' | 21:49 |
| lifeless | pastebin that somewhere, and I can show you if you have a shared repo | 21:49 |
| nyu | it says that's the "branch root". svn one is in "related branches" | 21:50 |
| lifeless | It should have provided several lines of output | 21:51 |
| lifeless | you can anonymise the urls if you like, but I need to see the otuput | 21:52 |
| nyu | nah, just these two | 21:52 |
| nyu | wait | 21:53 |
| nyu | lifeless: http://pastebin.com/m3a9c5661 | 21:53 |
| phoenixz | Hi, just started to test a little with BZR.. made a project, pushed it to a remote place, branched it to another computer.. Now I have the same project on 2 locations, I made changes on both places, now I want to merge the changes from both locations so that both locations have the same changes but how do I do that? bzr send seems to support only email?! cant I send the changes directly? | 21:54 |
| lifeless | phoenixz: bzr merge OTHER_URL; bzr commit | 22:12 |
| lifeless | nyu: 'Standalone branch ' is the bit that matters | 22:13 |
| lifeless | nyu: it means you don't have a shared repo | 22:13 |
| lifeless | nyu: if you do this: | 22:13 |
| lifeless | 'bzr init-repo --rich-root-pack sftp://robertmh@bzr.savannah.gnu.org/srv/bzr/grub/trunk' | 22:13 |
| lifeless | then you'll have a shared repo | 22:14 |
| lifeless | you'll need to push up the contents once more, because the previous push is in a standalone branhc | 22:14 |
| lifeless | so | 22:14 |
| lifeless | bzr push sftp://robertmh@bzr.savannah.gnu.org/srv/bzr/grub/temp | 22:14 |
| lifeless | and after that pushing new branches will be fast | 22:15 |
| fullermd | You probably don't want to actually init-repo at trunk/... | 22:15 |
| lifeless | oh yes, bad cp | 22:16 |
| lifeless | 'bzr init-repo --rich-root-pack sftp://robertmh@bzr.savannah.gnu.org/srv/bzr/grub' | 22:16 |
| lifeless | I'll note that sftp is fairly slow compared to our dedicated server, but savannah still see to be confused/limited | 22:16 |
| lifeless | kfogel: ^ | 22:16 |
| asac | thx | 22:17 |
| nyu | lifeless: ok, now I need to push again? the old tree is still there | 22:17 |
| kfogel | lifeless: reding | 22:18 |
| kfogel | lifeless: savannah problem? | 22:18 |
| lifeless | nyu: you need to push to a branch that isn't trunk, within the shared repo, to seed it with the content. | 22:19 |
| lifeless | kfogel: last I heard they only support sftp for bzr | 22:20 |
| lifeless | kfogel: which is really really inefficient compared to a client-server protocol | 22:20 |
| nyu | lifeless: ok. how do I replace the old trunk afterwards? | 22:21 |
| lifeless | delete it, e.g. with lftp | 22:21 |
| lifeless | then push to it again | 22:21 |
| nyu | ah. can't I just delete trunk already? | 22:22 |
| lifeless | sure | 22:22 |
| kfogel | lifeless: https://savannah.gnu.org/support/?106612#comment10 indicates they have smart server | 22:22 |
| lifeless | they need a root signed ssl cert too | 22:22 |
| lifeless | or we should ship their root cert | 22:22 |
| nyu | lifeless: btw, when setting up a svn mirror, am I supposed to checkout or branch from it? | 22:22 |
| nyu | I guess commits aren't going to be pushed back, so branch would be the way? | 22:23 |
| lifeless | nyu: its up to you | 22:23 |
| lifeless | nyu: if you want a mirror, I'd use checkout + update myself | 22:23 |
| lifeless | as you shouldn't be committing in a mirror | 22:23 |
| lifeless | kfogel: "Using the latest version of bzr with a ssh + smart server access requires a change in the current installation and a migration of existing bzr projects. This looks like the way to go in the long run but this will take more time than using the existing infrastructure. " | 22:24 |
| lifeless | kfogel: I think you got the sense inverted | 22:24 |
| nyu | lifeless: yeah, I don't want anyone to commit in the mirror. they should branch instead | 22:25 |
| kfogel | lifeless: oh, no I just read the first line. but they are doing commit emails with inotify | 22:25 |
| lifeless | nyu: exactly | 22:25 |
| lifeless | nyu: what I'd do is maintaint he mirror as a checkout+update; and branch from the mirror to do work | 22:25 |
| phoenixz | bzr does not support file copy? | 22:28 |
| fullermd | phoenixz: Not as something that makes any notations in history, no. | 22:28 |
| phoenixz | fullermd: so basically, a copied file is just a new file, as far as bzr is concerned? | 22:29 |
| fullermd | Right. | 22:29 |
| phoenixz | fullermd: okay... and just so that I get it.. I created tree A, added some files and dirs, committed, then pushed that to another server.. on the same computer in another directory, I bzr branch "serverpushurl", and had a branch of A, which I called B.. so far, so good, right? | 22:31 |
| phoenixz | fullermd: then I made changes in A and in B, and to merge them, I basically would have to do cd A, merge ../B, correct? | 22:31 |
| fullermd | Right. So now you [technically] have 3 branches; one at A, one at B, one at SERVER. | 22:31 |
| phoenixz | and then cd ../B, bzr merge ../A | 22:31 |
| phoenixz | fullermd: ah, so bzr push also branches? | 22:32 |
| fullermd | (note that you could have done 'cd .. ; bzr branch A B' instead of routing through SERVER there too) | 22:32 |
| phoenixz | fullermd: but so, technically, how could I merge my changes back to the pushed branch? because that didnt work, somehow.. | 22:32 |
| fullermd | Well, you'll have to quantify "didn't work" a little more ;) | 22:32 |
| fullermd | Because that looks reasonably correct. | 22:33 |
| phoenixz | fullermd: heheh, well, so I had A, pushed it to server (which is branching too, right?), lets call that C, then I bzr branch C on another location in my laptop, called that B | 22:34 |
| * fullermd glares at his ringing phone. | 22:34 | |
| phoenixz | fullermd: so I have A, B and C (on the server) | 22:34 |
| nyu | lifeless: btw, the example in http://doc.bazaar-vcs.org/latest/en/user-guide/svn_plugin.html recommends --default-rich-root rather than --rich-root-pack. I guess it needs updating? | 22:34 |
| lifeless | nyu: no | 22:34 |
| phoenixz | yeah, take that call :) I'll keep on writing.. | 22:35 |
| lifeless | nyu: you did the conversion with an older bzr | 22:35 |
| nyu | lifeless: ah, ok | 22:35 |
| phoenixz | fullermd: now, I make changes to A and B.. I can merge changes from A to B and from B to A.. but how do I send those changes to C?? | 22:35 |
| lifeless | nyu: I used the exact matching format that 'bzr info' told me you have your trunk in | 22:35 |
| nyu | lifeless++ | 22:35 |
| lifeless | nyu: otherwise bzr would have had to do data conversion - and while converting to 2a (which is what default-rich-root is now) is a good thing, I sense you're just getting started | 22:35 |
| nyu | pretty obvious that I am ;-) | 22:36 |
| fullermd | phoenixz: 'k, sorry. You'd use 'push' to push them up. | 22:39 |
| fullermd | push is almost the complement to pull, except that (as in your first steps) push also creates the target branch if it doesn't already exist. | 22:39 |
| phoenixz | fullermd: and if I Im in B and I send changes from A to C and I want to receive those changes in B.. ? how would I do that then? | 22:40 |
| lifeless | vila: jam: spiv: - on tripit? | 22:40 |
| phoenixz | fullermd: sorry for all the bothering :) just trying to gettit | 22:40 |
| fullermd | phoenixz: Grr. You people are going to make me actually dig all that up... | 22:42 |
| fullermd | phoenixz: Lemme dig through my logs. I had a long discussion about roughly that with another guy some weeks ago... I've been threatening to put it up somewhere for reference. | 22:43 |
| phoenixz | fullermd: Hehehe, sorry.. Its just that bzr does seem to do things a bit different than SVN.. its not hard to grasp, its hard to change learnt stuff... | 22:43 |
| fullermd | Yeah, the basic units you work with are a bit different. | 22:43 |
| phoenixz | fullermd: exactly, thats my difficulty now, Im looking though pink svn glasses... | 22:44 |
| fullermd | phoenixz: Editing... will take me some minutes. | 22:48 |
| phoenixz | fullermd: sure, thanks! | 22:48 |
| fullermd | phoenixz: http://bazaar-vcs.org/MatthewFuller/AboutPushPullMerge | 23:03 |
| fullermd | phoenixz: There was followup discussion to that about Repositories. I'm editing that now. | 23:09 |
| nyu | lifeless: ok, finished with the re-push. still complains about non-existant parent dir though | 23:15 |
| nyu | I guess I can mkdir it by hand? | 23:15 |
| nyu | (within the shared-repo directory, of course) | 23:15 |
| sven_oostenbrink | fullermd: thanks for the document, reading it now! | 23:19 |
| sven_oostenbrink | fullermd: sorry for the late reply, had some network problems here | 23:19 |
| fullermd | Hey! No nick changing on me! 10 minutes in the penalty box! | 23:20 |
| RenatoSilva | my question : http://pastie.org/665423 | 23:22 |
| RenatoSilva | sorry http://pastie.org/665941 | 23:23 |
| sven_oostenbrink | fullermd: just a question... the .bzr directory basically is the repository? and then the files along side it the working tree? | 23:25 |
| fullermd | The .bzr/ directory is all the bzr meta-data. Any given .bzr/ dir may have a Repository, or a Branch, or [the internal tracking files for] a Working Tree. | 23:26 |
| fullermd | Or any combination of the above. | 23:26 |
| fullermd | In SVN terms, it can be the repo, or the equivalent of the stuff in .svn/ dirs in a checkout, or both. | 23:26 |
| sven_oostenbrink | fullermd: gottit.. | 23:26 |
| sven_oostenbrink | fullermd: other question.. | 23:27 |
| sven_oostenbrink | fullermd: There is A, pushed to B, branched to C | 23:28 |
| sven_oostenbrink | fullermd: So I could say.. B is the trunk, A is my working copy, C is working copy for person C.. | 23:28 |
| sven_oostenbrink | now, A makes changes, C makes changes.. | 23:28 |
| sven_oostenbrink | fullermd: to move those changes to B, A does bzr push | 23:28 |
| sven_oostenbrink | When C does a push, A's changes will NOT be overwritten, right? | 23:29 |
| rockstar | sven_oostenbrink, no. In fact, C can't commit unless they are up to date. | 23:29 |
| sven_oostenbrink | fullermd: thats to say... when I push to a location, All revisions (each revision being a collection of changes) will be pushed to that location.. If that location contains nothing yet, it will practically be a copy of my local stuff, right? | 23:30 |
| fullermd | rockstar: No, they're branches, not checkouts. | 23:30 |
| fullermd | sven_oostenbrink: When C tries to push, it will tell him he's out of date. And he'd have to merge before he could push. | 23:30 |
| rockstar | fullermd, yeah, I think there's some confusion there. | 23:30 |
| sven_oostenbrink | fullermd: so C first would have to do a pull, right? | 23:31 |
| fullermd | (this also then leads into a discussion about how you'd actually probably NOT wnat to work that way, since it destroys the mainline. But let me edit ONE big thread at once!) | 23:31 |
| rockstar | fullermd, sven_oostenbrink, he won't be able to just push if A has pushed already. | 23:31 |
| sven_oostenbrink | fullermd: C would have to do bzr pull or bzr merge? | 23:31 |
| rockstar | He'll have to do a merge -> push, because the branches are diverged. | 23:31 |
| fullermd | sven_oostenbrink: No, he'd have to merge. He couldn't pull since he has changes the far side doesn't. See the merge discussion about halfway down that page. | 23:31 |
| fullermd | You can imagine that instead of that guy working on both Linux and Windows, there are just two people, one on each. | 23:31 |
| sven_oostenbrink | fullermd: so if C would do either push or pull, he'd get a message he'd have to merge first.. | 23:32 |
| rockstar | sven_oostenbrink, yes. | 23:32 |
| sven_oostenbrink | ok, perfect.. | 23:33 |
| sven_oostenbrink | fullermd: rockstar: another question.. I did a push to another server over sftp:// I checked the destination, and it was a directory with a .bzr directory in it. This means that, bzr push basically sends all revisions to the remote location that the remote location doesn't have yet, and if the remote location has nothing yet, it will just send all revisions I have.. is this correct? | 23:34 |
| rockstar | sven_oostenbrink, correct. | 23:35 |
| sven_oostenbrink | ok, and when I have changes to merge, I can also send them by email (bzr send) and then another person receiving htat mail, can apply then with bzr patch ? | 23:35 |
| fullermd | 'bzr merge' more like. | 23:36 |
| fullermd | You could also just put your branch somewhere they can see, and they can merge directly from it. | 23:36 |
| sven_oostenbrink | ah, gottit.. | 23:37 |
| sven_oostenbrink | fullermd: now just one other thing.. What, in bzr, is the difference between a checkout and a branch? I mean, in SVN / SVK, a branch basically is a copy. period. A checkout is creating a working tree.. but here, I bzr branch or bzr checkout, both create a WT.. | 23:39 |
| sven_oostenbrink | fullermd: if I get it correctly | 23:39 |
| sven_oostenbrink | fullermd: then if I have A in bzr, I push that to B.. Then if I work on location C, if I bzr branch it, I have branch C.. if I just checkout it, I will be on location C but working on branch B... ? irght? | 23:40 |
| mwhudson | argh | 23:40 |
| dash | sven_oostenbrink: the difference is just that a checkout is bound to a remote branch | 23:40 |
| fullermd | sven_oostenbrink: Roughly the same, actually. Just think of 'branch' as making a branch and then checking it out. | 23:40 |
| mwhudson | lifeless: hi | 23:40 |
| * fullermd stabs dash until he stops saying 'bound branch'. | 23:40 | |
| dash | sven_oostenbrink: meaning that checkins will first make sure the changes can be applied to the remote branch before applying them locally | 23:40 |
| dash | fullermd: I didn't say "bound branch"! | 23:41 |
| fullermd | You said half of it. That's at least 75% as bad :p | 23:41 |
| sven_oostenbrink | fullermd: understood.. but then, if I checkout from a branch on another computer.. when committing, I then MUST have network access to that computer, no? while bzr branch would just place everything locally on my computer.. right? | 23:41 |
| dash | sven_oostenbrink: if you don't have network access you can do 'bzr commit --local' | 23:42 |
| fullermd | Right. | 23:42 |
| dash | and then push/merge later | 23:42 |
| fullermd | And never commit --local. 'cuz then we'll have another giant fooforah when it screws you. | 23:42 |
| dash | fullermd: What | 23:42 |
| dash | fullermd: Where is this documented | 23:42 |
| * sven_oostenbrink hates deez pink SVN glasses.. its easy, but so hard to get it.. | 23:43 | |
| dash | sven_oostenbrink: the third mode is a lightweight checkout, you get one via "bzr co --lightweight" | 23:43 |
| dash | sven_oostenbrink: this doesn't store any local revisions, it's like an svn checkout in that regard | 23:44 |
| fullermd | dash: In a whole lot of mailing list threads and long IRC discussions. | 23:44 |
| dash | fullermd: so what's wrong with it | 23:44 |
| sven_oostenbrink | dash: Id prefer just bzr branch.. just work on my own branch, all alone, nobody bothering me.. when I'm finished, I merge my changes to a trunk | 23:44 |
| dash | sven_oostenbrink: that works | 23:45 |
| fullermd | For one thing, various bugs cause it to totally hork you when you have local commits and uncommited changes and update. | 23:45 |
| fullermd | sven_oostenbrink: It's very common to use checkouts for the trunk. | 23:45 |
| dash | fullermd: Oh. :( | 23:45 |
| dash | yeah I switched to a checkout for my local copy of trunk | 23:45 |
| fullermd | In a broader sense, local commits in a _checkout_ make no sense. That's more a 'bound branch' thing. | 23:45 |
| dash | fullermd: what's the difference | 23:45 |
| dash | I never knew those were distinct | 23:45 |
| fullermd | sven_oostenbrink: So instead of merging trunk and pushing your branch over, you merge your branch into trunk and commit. That way you don't disturb the mainline. | 23:45 |
| fullermd | Well, they're not, in bzr. That's kinda the problem :p | 23:46 |
| dash | fullermd: I am utterly confused | 23:46 |
| dash | fullermd: what is the problem? | 23:46 |
| fullermd | The difference is that in a _checkout_, you have one branch, and a WT for it. In a _bound branch_, you have TWO branches, that you generally want to keep in sync. | 23:46 |
| dash | Er | 23:46 |
| fullermd | The desired semantics of the two cases are subtly different in many ways. | 23:46 |
| dash | i thought that's what a lightweight checkout was? | 23:46 |
| sven_oostenbrink | fullermd: sorry, didn't get that last one.. merging trunk and pushing branch over, or merge branch into trunk.. whats the difference? | 23:46 |
| fullermd | Right now, bzr has _neither_. It has a chimera that's some of both. | 23:46 |
| dash | Okay | 23:47 |
| sven_oostenbrink | fullermd: probably totally logical, but not seeing it for a second here.. :) | 23:47 |
| fullermd | sven_oostenbrink: It has to do with the way revisions are arranged in history. Ask me later. | 23:47 |
| sven_oostenbrink | ok | 23:47 |
| dash | I think I'm going to stop thinking about this and go back to being ignorant | 23:47 |
| * sven_oostenbrink welcomes dash... | 23:47 | |
| fullermd | Light and heavy checkouts _should_ act exactly the same, just with heavies having a local cache. Bound branches should act differently from either. | 23:47 |
| fullermd | But as-is, we have heavy checkouts sometimes acting like bound branches (and sometimes acting in ways more like a checkout) | 23:48 |
| fullermd | The two cases are so MUCH alike, that it's easy and natural (and what happened) to conflate them. But it's troublesome because they're not really the same thing. | 23:48 |
| lifeless | nyu: push --create-prefix | 23:48 |
| lifeless | mwhudson: hi | 23:48 |
| lifeless | mwhudson: are you on tripit? | 23:48 |
| mwhudson | lifeless: i don't think i know what tripit is, so probably not | 23:49 |
| lifeless | mwhudson: social flight tracking | 23:49 |
| spiv | lifeless: I'm not on it | 23:50 |
| * mwhudson is once again horrifically confused by non-ascii characters in urls | 23:50 | |
| lifeless | spiv: does your -suffix@puzzling.org work dynamically? | 23:51 |
| lifeless | or do you need to set them up? | 23:51 |
| sven_oostenbrink | dash: another one, does bzr also do binary files, like (small) images | 23:51 |
| sven_oostenbrink | ? | 23:51 |
| fullermd | sven_oostenbrink: http://bazaar-vcs.org/MatthewFuller/AboutUsingRepositories is a followon to that previous discussion, talking about using shared repos (and some other stuff mixed in I didn't bother cleaning out) | 23:51 |
| dash | sven_oostenbrink: sure, files are files :) | 23:51 |
| fullermd | It's hard to get a diff of them, of course ;) | 23:51 |
| lifeless | fullermd: I don't really get the differences you postulate for bound/heave | 23:52 |
| fullermd | lifeless: Yeah, I'm gonna make a wiki page of it in, like, 20 years when I recover from making them today :p | 23:52 |
| lifeless | spiv: mwhudson: you should both have tripit invites | 23:53 |
| mwhudson | it seems if i do bzr push bzr://localhost/b%C3%A9 the server raises an exception and the client blows up translating it :( | 23:53 |
| lifeless | mwhudson: would you like to go through whats happening in more detail? | 23:54 |
| fullermd | lifeless: Bound branches can have different nicks, checkouts can't (doesn't make sense). Bound branches can diverge, checkouts can't (doesn't make sense). Checkouts should be sync'd to the remote with update, bound branches should use pull. etc etc etc. | 23:54 |
| lifeless | fullermd: are you listing bugs or conceptual expectations? | 23:54 |
| fullermd | Well, the latter, which means them showing up is the former ;) | 23:55 |
| lifeless | fullermd: I wouldn't expect pull on a bound branch to sync it to the master | 23:55 |
| lifeless | fullermd: I'd expect that to change the master | 23:55 |
| mwhudson | oops, now i have two tripit accounts it seems... | 23:56 |
| lifeless | mwhudson: heh, you can combine them I think | 23:56 |
| mwhudson | yeah, i'm sure | 23:56 |
| fullermd | sven_oostenbrink: (that discussion of usage of repositories may be good for you coming from svn) | 23:56 |
| mwhudson | lifeless: yes i would like to talk about what's going on, but first i think i'm going to have lunch | 23:56 |
| mwhudson | lifeless: talk to you in a bit? | 23:56 |
| spiv | lifeless: yes, the suffix is automatic, although I prefer @bemusement.org these days. | 23:57 |
| fullermd | lifeless: Maybe. But 'update' shouldn't updating the local branch to the other branch. Update is for WT<-Branch, not Branch<-OtherBranch. | 23:57 |
| lifeless | mwhudson: ok | 23:58 |
| lifeless | spiv: puzzling/bemusement :P | 23:58 |
| lifeless | fullermd: as the author of update, I take some exception to your definition | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!