| mtaylor | abentley: so, I spoke with a friend of mine who runs email at uc berkeley... they just recently did some turbogears email integration work, so I wanted to see what they did for addresses | 00:00 |
|---|---|---|
| mtaylor | turns out, they analyzed a bunch of addresses they had in the system (about 1.5 million) | 00:00 |
| mtaylor | (you are right - there is no specced length limit) | 00:01 |
| mtaylor | but _most_ of the email addresses were in the 30 char length and the really long ones were about 60 | 00:02 |
| mtaylor | so they set it at about 150 chars and decided that if anyone with a longer address wanted to do anything they would just laugh at them | 00:03 |
| === spiv_ is now known as spiv | ||
| mtaylor | the link to the bzr repos on http://bazaar-vcs.org/QBzr is wrong - it should be either http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk/ or lp:qbzr | 01:42 |
| mtaylor | bzr branch https://launchpad.net/qbzr | 01:42 |
| mtaylor | doesn't even partially work | 01:42 |
| === jamesh__ is now known as jamesh | ||
| * igc lunch | 02:23 | |
| sechastain | there are coding standards for bzr, right? | 02:34 |
| Peng_ | They're in the HACKING document. | 02:35 |
| Peng_ | http://doc.bazaar-vcs.org/bzr.dev/en/developer-guide/HACKING.html | 02:35 |
| Peng_ | Or doc/developers/HACKING.txt in the source, I think. | 02:35 |
| sechastain | that's it | 02:35 |
| sechastain | thanks | 02:35 |
| lifeless | spiv: ping; can I nag you to review my breadth first search patch; its a dependency on 'more-find-ghosts' that you already tweaked. | 03:01 |
| lifeless | spiv: piong | 03:56 |
| poolie | hi lifeless | 03:57 |
| cr3 | how can I revert a commit on many files? | 04:01 |
| poolie | bzr revert FILE ... | 04:01 |
| sechastain | uncommit | 04:01 |
| poolie | or bzr revert DIR | 04:01 |
| poolie | unless maybe you want uncommit instead? | 04:01 |
| cr3 | poolie: yeah, uncommit would be awesome... checking manpage | 04:02 |
| spiv | lifeless: ok, I'll do that now | 04:02 |
| cr3 | first time I use this feature, absolutively cool! | 04:02 |
| Peng_ | cr3: If you've already pushed, don't uncommit. | 04:10 |
| cr3 | Peng_: thanks for the warning, but I was safe | 04:12 |
| Peng_ | :) | 04:12 |
| lifeless | I poolie | 04:18 |
| hacklberry | if i want to use bzrsvn against svn 1.4.6 do i still need to apply the patch to the svn python bindings as described on the bzr homepage wiki? (i know i can look at the diff myself and figure that out, so just in case someone knows from top of their head...) | 04:20 |
| fullermd | No, you lifeless. | 04:20 |
| mtaylor | hacklberry: well, it'll work without the patch, but the memory leak may hit you if the svn repos is really big | 04:20 |
| mtaylor | hacklberry: but I've been using it against svn for a while without problems (except for the memory leak) | 04:21 |
| fullermd | Er, AFAIK, the stock 1.4.x bindings won't work at all without the patch. | 04:21 |
| Odd_Bloke | I poolie? | 04:21 |
| mtaylor | oh | 04:21 |
| mtaylor | nevermind then... don't listen to me | 04:21 |
| hacklberry | mtaylor: thanks for the info, does the mem leak depend on the size of the whole svn repo or the size of a module one want's to work with? | 04:23 |
| mtaylor | hacklberry: depends on how you are branching it | 04:23 |
| mtaylor | hacklberry: I, most of the time, do bzr svn-import to get a bzr repos of the svn repos | 04:24 |
| mtaylor | hacklberry: at times, this takes a very, very, very long time | 04:24 |
| hacklberry | mtaylor: thanks | 04:26 |
| mtaylor | hacklberry: sure. but also fullermd is probably right about the patch - he's smarter than I am | 04:26 |
| mtaylor | :) | 04:26 |
| mtaylor | so ignore me about that | 04:26 |
| fullermd | Oh, great, now my ego is gonna strut around all day.... | 04:27 |
| fullermd | We may be talking about different patches. | 04:27 |
| fullermd | There IS a memory leak patch that prevents it from going out the window and down the road on big things. | 04:27 |
| fullermd | That's not strictly _necessary_, especially if you have a small repo, but it's still a good idea. | 04:27 |
| fullermd | But there's also a giant mega-patch that you _need_ with 1.4.x bindings, because they're useless, which I think basically updates them to 1.5.x bindinds. | 04:28 |
| hacklberry | fullermd: just for reference i was gibbering about this patch: http://samba.org/~metze/subversion-1.4.0-metze-python-bindings.patch | 04:34 |
| jelmer | hacklberry: yes, you will still need to update the patch if you are on subversion 1.4.x | 04:35 |
| jelmer | unless your distributions ships its packages with it | 04:35 |
| jelmer | Debian and Ubuntu do | 04:35 |
| mtaylor | ah | 04:37 |
| mtaylor | that's why I'm working fine "without" the patch | 04:37 |
| * mtaylor doesn't understand people who don't use debian/ubuntu | 04:38 | |
| fullermd | Linux? That thing is still around? :p | 04:38 |
| mtaylor | hehe | 04:38 |
| * TFKyle doesn't understand people who do use ubuntu :P | 04:38 | |
| jelmer | The memory leak fix is not included in the Debian/Ubuntu packages yet | 04:39 |
| * mtaylor stabs TFKyle in the eye | 04:39 | |
| hacklberry | jelmer: thanks. OT:(huh distirbution - what's that :-) ? slack base here, the rest rolled from sources... | 04:39 |
| jelmer | but will be included in the next upload to sid (and first import from sid from ubuntu) | 04:39 |
| TFKyle | ubuntu's good though, they applied one of my patches for a while | 04:39 |
| * mtaylor would be happier if he could figure out how to go through the dev process on either debian or ubuntu... | 04:39 | |
| mtaylor | but I guess I haven't sacrificed goats in the right places yet | 04:40 |
| * TFKyle typically uses gentoo, have ubuntu and a few BSD's installed in vmware though | 04:41 | |
| mtaylor | there are some times when it seems that after a branch I don't have a pull location set automatically | 04:42 |
| mtaylor | is that just me being wrong, or are there times when that's true? | 04:42 |
| jelmer | mtaylor: it'll only remember the branch location if there was none set previously or if you specify --remember | 05:03 |
| mtaylor | jelmer: so when I make a fresh clean branch, it _should_ remember the pull location, right? | 05:03 |
| jelmer | it may actually be set to the location you branched from by default | 05:04 |
| jelmer | cat .bzr/branch/branch.conf | 05:04 |
| lifeless | ok, Repository.get_parent_map is working | 05:06 |
| lifeless | shoud gzip the content I think though | 05:06 |
| hacklberry | jelmer: i installed svn 1.5.0 (dev build), but when i run 'bzr selftest svn' i got: bash-3.1$ bzr selftest svn | 05:40 |
| hacklberry | testing: /usr/bin/bzr | 05:40 |
| hacklberry | /usr/lib/python2.5/site-packages/bzrlib (1.0.0 python2.5.1.final.0) | 05:40 |
| hacklberry | ERROR: bzrlib.plugins.svn.tests.test_branch.WorkingSubversionBranch.test_create_checkout | 05:40 |
| hacklberry | _get_global_config() takes exactly 1 argument (4 given) | 05:40 |
| hacklberry | [10/722 in 4s, 1 errors] bzrlib.plugins.svn.tests.test_branch.WorkingSubversionBranch.test_create_checkout_lightweight Segmentation fault | 05:40 |
| abentley | lifeless: Perhaps even bzip? Probably lots of redundancy in revision ids. | 06:18 |
| spiv | abentley: bzip is a pretty large leap in processing cost, IIRC. | 06:27 |
| abentley | spiv: Sure, but on today's hardware, it could still be very cheap. | 06:30 |
| spiv | Yeah. Worth experimenting with. | 06:30 |
| spiv | I'm guessing in the context of ~64k of graph data it won't be worth it, but that's purely a guess :) | 06:31 |
| abentley | Is it going to be 64K compressed or uncompressed? | 06:32 |
| spiv | abentley: good question ;) | 06:33 |
| spiv | abentley: lifeless just posted (and I just reviewed) a smart method that just does 64k uncompressed. | 06:34 |
| fullermd | bzip2 is awful slow. zlib's a lot faster, and will probably get you enough of a saving to not notice the difference on less than a couple megs... | 06:39 |
| brilliantnut | hi anybody knows about 1.1? | 07:27 |
| AfC | brilliantnut: are you subscribed to the bazaar project mailing list? | 07:27 |
| brilliantnut | no, only to announce | 07:28 |
| brilliantnut | but I keep browsing thru those archives for info on 1.1, did I miuss something? | 07:30 |
| AfC | brilliantnut: Martin wrote a ... oh, damn. Well, whatever | 07:33 |
| lifeless | abentley: 64 on the wire is my current 'sweet spot' for requests | 07:48 |
| lifeless | abentley: so if we compress it, ~64k compressed | 07:48 |
| lifeless | with 64k uncompressed we do 4 round trips to get those 100 commits | 07:49 |
| lifeless | spiv: thanks for the reviews; I'll reply to the tomorrow morning. Some stuff I agree with, some I don't :) | 07:49 |
| lifeless | spiv: in particular, I want the tests for the two variants of the searcher protocol to be single units; to avoid skew being added by one-or-other tests; | 07:50 |
| * igc dinner | 08:05 | |
| rjek | Is there a place I can branch the current release version from? | 10:07 |
| rjek | (ie, not http://www.bazaar-vcs.org/bzr/bzr.1.0/ but something like http://www.bazaar-vcs.org/bzr/bzr.current/) | 10:08 |
| Lo-lan-do | If you do that, then you'll be left out with a diverged branch when a new version is published. | 10:09 |
| rjek | (pref. one I can fetch with 0.90 :) | 10:09 |
| rjek | Which is the issue I'm wanting to solve. | 10:09 |
| rjek | ie, when a new release is made, I can just bzr pull. | 10:09 |
| Lo-lan-do | You can't do that, since each release comes from a different branch. | 10:10 |
| dato | rjek: s/current/dev/, but you need 0.92 for that | 10:10 |
| fullermd | Releases aren't cut from the trunk, they're cut from their own branches. | 10:10 |
| dato | ah | 10:10 |
| dato | I misunderstood rjek | 10:10 |
| rjek | That's a shame. OK. | 10:10 |
| fullermd | Well, I imagine he misunderstands himself too ;) | 10:10 |
| * dato releases his stuff from $project.stable | 10:10 | |
| fullermd | Why do you want a release branch instead of trunk? | 10:10 |
| lifeless | rjek: http://bazaar-vcs.org/bzr/bzr.0.92/ | 10:10 |
| rjek | lifeless: I'm fetching bzr.dev.knits atm. | 10:11 |
| rjek | (which 0.90 can grock.) | 10:11 |
| lifeless | rjek: the url I gave will give you 0.92, and 0.92 can grok it | 10:11 |
| lifeless | sorry, 0.90 can grok it | 10:11 |
| rjek | I know. | 10:11 |
| Odd_Bloke | bzr.dev is normally pretty solid, so I run from that in most places. | 10:12 |
| rjek | But if it's suggested that I go for bzr.dev, is bzr.dev.knits not just bzr.dev except in the older format that pre-0.92 versions can read? | 10:12 |
| fullermd | Yes, it is. | 10:12 |
| Odd_Bloke | And possibly a few hours out of date. | 10:12 |
| rjek | Right, I'll get that then. Going via an intermediate version is a faff. :) | 10:12 |
| * fullermd is still pulling the .knits variant. | 10:12 | |
| lifeless | rjek: yeah, we try to allow reasonable overlap for folk | 10:13 |
| lifeless | but we do keep finding things we can do better | 10:13 |
| fullermd | Aw, bzr.dev.as.weaves isn't around anymore? Shucks... | 10:13 |
| lifeless | fullermd: we're not masochists | 10:14 |
| fullermd | I'm sure there's evidence to the contrary in the code still :p | 10:14 |
| brilliantnut | poolie: would you have any idea of what happened to the 1.1 release of bazaar that was scheduled on 11th Jan? | 10:21 |
| poolie | brilliantnut, yes, i've just been delayed in making it | 10:22 |
| poolie | should be out tonight | 10:22 |
| poolie | it will have no substantial changes from 1.1rc1 | 10:22 |
| dato | poolie: it is very minor, but 1.1 still claims pack-0.92 is experimental. http://bundlebuggy.aaronbentley.com/request/<20080114093341.GA6173%40chistera.yi.org> | 10:22 |
| * rjek wishes to upgrade as 0.90 is painfully slow for even the most trivial of tasks. | 10:22 | |
| brilliantnut | ok. Thanks :) I've been waiting for 1.1 since ages. | 10:23 |
| dato | well | 10:23 |
| dato | poolie: er, well, never mind really, because with pack-0.92 being default, it won't show under "experimental formats" in `bzr help formats`, I just realized of that. | 10:24 |
| dato | (so it only affects rich-root pack) | 10:24 |
| poolie | brilliantnut, do you mean since december? | 10:24 |
| poolie | or were you waiting for 1.1 because you don't use 1.0 releases? :) | 10:24 |
| brilliantnut | yeah, | 10:24 |
| brilliantnut | no, we tried out 1.0, and found that it was missing something for our particular situation | 10:25 |
| fullermd | I don't trust 0.9x releases. I've been waiting for 0.19 forever :| | 10:25 |
| poolie | but it's fixed in 1.1? | 10:25 |
| poolie | that's good | 10:25 |
| brilliantnut | talking to jelmer here helped us understand that there was a patch going in which would solve our problem.. spiv was making that patch. | 10:26 |
| brilliantnut | so, we have been waiting for 1.1 since then.. | 10:26 |
| Odd_Bloke | spiv: No pressure. :p | 10:26 |
| brilliantnut | We had scheduled time on Saturday to migrate from CVS to bzr 1.1 :( | 10:26 |
| brilliantnut | yeah, spiv, no pressure. | 10:26 |
| awilkins | Are we discussing the reason that the replay branch doesn't work with a 1.0 client (KnitRepository error?) | 10:26 |
| awilkins | Is KnitRepository the bit that handles branches of differing format versions? | 10:27 |
| poolie | KnitRepository is a set of imprementations | 10:28 |
| poolie | um, i'd have to see the bug or error msg | 10:28 |
| awilkins | Japanese implementations :-) ? | 10:28 |
| awilkins | https://bugs.launchpad.net/bzr/+bug/182803 | 10:28 |
| ubotu | Launchpad bug 182803 in bzr "Replay branch appears broken" [Undecided,New] | 10:28 |
| ubotu | New bug: #182803 in bzr "Replay branch appears broken" [Undecided,New] https://launchpad.net/bugs/182803 | 10:30 |
| rjek | What does "bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>. Does not support rich root data." mean when doing bzr upgrade? | 10:35 |
| Peng_ | rjek: What format are you currently using (bzr info)? | 10:39 |
| rjek | bzr info doesn't say, but I believe it's knits. | 10:40 |
| fullermd | Check the first line of output. | 10:41 |
| Peng_ | rjek: You're using a rich-root or subtree format, which includes metadata that non-rich-root formats like pack-0.92 don't support. Try upgrading to rich-root-pack. | 10:41 |
| rjek | Ah, yes: dirstate-with-subtree | 10:41 |
| rjek | What is a rich root, anyway? | 10:42 |
| Peng_ | rjek: Try rich-root-pack, then. | 10:42 |
| rjek | bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack4>. Does not support nested trees | 10:43 |
| rjek | :) | 10:43 |
| Peng_ | rjek: pack-0.92-subtree then. | 10:43 |
| Peng_ | rjek: Older formats didn't store any information about the root directory of the branch. Rich root formats do. | 10:43 |
| rjek | OK, pack-0.92-subtree works, although I have no idea what it means, and the option appears to be undocumented in "bzr help upgrade" | 10:44 |
| Peng_ | rjek: Yeah. Subtrees are kind of experimental, so they're hidden. | 10:45 |
| Peng_ | rjek: Rich roots were invented as something between the regular formats and subtree formats that wasn't experimental. | 10:45 |
| rjek | And what is a subtree? | 10:46 |
| Peng_ | rjek: With rich roots, you can use bzr split and join (make a directory in a branch into its own branch, and vice versa). | 10:46 |
| Peng_ | rjek: No idea. :) Something more advanced than that I guess. | 10:46 |
| dato | Peng_: no, split/join are with *subtree, not with rich-root alone | 10:46 |
| Peng_ | Bah. | 10:47 |
| Peng_ | What's the point of rich roots then? | 10:47 |
| Peng_ | They're enough for bzr-svn. | 10:47 |
| Peng_ | Why? | 10:47 |
| fullermd | Because they store the root identity, which (AIUI) bzr-svn uses to keep from going nutbar coping with svn's soi-disant branching schemes. | 10:48 |
| Peng_ | Heh, ok. | 10:48 |
| awilkins | Anyone using the eclipse bzr support? Any good? | 10:53 |
| brilliantnut | awilkins: not yet. | 10:54 |
| brilliantnut | awilkins: I tried it out, but it doesn't support the full range of eclipse team tasks that cvs/svn does. | 10:55 |
| jelmer | I thought split/join worked with rich-root too | 11:22 |
| jelmer | subtree is for by-reference nested tree | 11:22 |
| dato | oh | 11:25 |
| dato | Peng_: ^ | 11:25 |
| Peng_ | :D | 11:28 |
| Peng_ | So subtrees are like svn externals? | 11:28 |
| jelmer | Peng_: Yep | 11:30 |
| Peng_ | Ok. | 11:31 |
| Peng_ | I think I finally understand the whole mess. | 11:31 |
| Peng_ | Shouldn't rich-root-pack be named pack-0.92-rich-root? | 11:32 |
| fullermd | That would blow our 2-dash budget... | 11:32 |
| jelmer | fullermd: (-: | 11:33 |
| === asac_ is now known as asac | ||
| fullermd | Hm. added seems to be b0rked... | 12:25 |
| Odd_Bloke | fullermd: !testcase ;) | 12:28 |
| fullermd | I'm more of an idea rat... | 12:28 |
| glyph | Hello bazaarians ... what do you call bazaar users? bzrkers? Anyway, I've got bzr 1.0 and bzr-svn installed from debs, and I just checked out a pretty massive svn project. It seems to be working great (although I haven't tried a "push" yet), but I'd really like to use a shared repository locally | 12:51 |
| glyph | unfortunately shared repositories seem to be incompatible with bzr-svn | 12:51 |
| glyph | can someone explain how this could work to me? I think I'm not understanding the vocabulary around how init-repository and formats work | 12:52 |
| jelmer | glyph: Shared repositories work | 12:52 |
| glyph | jelmer: Cool. How do I do it? :) | 12:52 |
| jelmer | use the format bzr-svn needs: bzr init-repo --rich-root-pack | 12:52 |
| Odd_Bloke | glyph: How did you create the sha... oh, jelmer will save the day. :) | 12:52 |
| glyph | jelmer: also, may I say, you are a god among men | 12:53 |
| Odd_Bloke | +1 | 12:53 |
| glyph | jelmer: Any chance you could make the error messages a bit more explanitory? The fact that it talks about SubversionRepository and KnitRepository is a bit confusing - it made me think that the right thing to do was bzr init-repository --format subversion, which does... something else :) | 12:54 |
| rjek | heh | 12:55 |
| jelmer | glyph: The error is from bzr, not from bzr-svn unfortunately | 12:55 |
| glyph | oh, and also - I just spent like 3 hours checking out all 110MB of history; how can I convert this branch to use a shared repository without repeating that? | 12:55 |
| glyph | jelmer: sure, but I was assuming you could write patches for either :) | 12:55 |
| Peng_ | glyph: bzr branch into the shared repo. | 12:55 |
| jelmer | glyph: Create the shared repository, then use "bzr branch" to clone that data into the shared repo | 12:55 |
| jelmer | glyph: True :-) | 12:55 |
| glyph | jelmer: OK, I was going to try that next | 12:56 |
| glyph | jelmer: also, I'm a little concerned about actually using "bzr push" to put stuff into the svn repository. Should I be? It seems to be working fabulously so far, but, uh | 12:57 |
| jelmer | glyph: Concerned about what specifically? | 12:58 |
| Lo-lan-do | I usually keep a bound branch for that | 12:58 |
| glyph | as far as I can tell it uses heuristics to determine what a "branch" is, and I'm not sure what the different URLs really mean to bzr. Can I, for example, pull from an svn+ssh URL to a branch (a copy of /trunk, in /branches), then merge from that locally, then push to trunk, and get something in svn that looks about right? | 12:59 |
| Lo-lan-do | "bzr commit" commits both to bzr and svn, "bzr pull" from another branch does the right thing, etc. | 12:59 |
| glyph | Lo-lan-do: "the right thing" seems a little scary. For example, if you merge trunk into a branch, can svn still tell what's going on? :) | 13:01 |
| === mrevell is now known as mrevell-lunch | ||
| Lo-lan-do | Actually, the bzr "merge" operation does strange things. I usually keep to pull and push. | 13:02 |
| glyph | are you using bzr-svn for read-only operation? | 13:03 |
| Lo-lan-do | No | 13:03 |
| glyph | presumably "pull" won't work sometimes, if you have conflicts | 13:03 |
| Lo-lan-do | But I don't do advanced branch stuff in bzr. | 13:03 |
| Lo-lan-do | For the few non-svn branches I have, I usually rebase before pulling into svn. | 13:03 |
| glyph | rebase? | 13:04 |
| glyph | Pardon, I'm still a bit of a bzr newb | 13:04 |
| Lo-lan-do | It's another plugin | 13:04 |
| glyph | I'm playing with bzr-svn because it looks like it's finally getting to the point where I can do real development in bzr without actually disturbing any of the projects I work with (in svn) | 13:04 |
| Lo-lan-do | (Still one of jelmer's though :-) | 13:04 |
| * glyph reads the package description | 13:05 | |
| glyph | I have no idea what this means :) | 13:05 |
| Lo-lan-do | It takes all the revisions you've committed since your branch diverged, then applies them on top of the tip of the remote branch and commits them back. | 13:05 |
| Lo-lan-do | So the history stays linear, and you can pull your branch into the svn one | 13:05 |
| glyph | hmm | 13:06 |
| glyph | Lo-lan-do: I *think* I know what you just said | 13:07 |
| glyph | actually no I don't. | 13:07 |
| Lo-lan-do | It's still not optimal, but that's what you get for using SVN :-) | 13:07 |
| glyph | "applies them on top of the tip" | 13:07 |
| glyph | diverged from ... what? | 13:07 |
| Lo-lan-do | Okay. Assume a branch, that we'll call trunk, with revisions A, B, C and D. | 13:07 |
| Odd_Bloke | glyph: If you diverge from trunk, rebase takes your fork of the branch and reapplies it to HEAD. | 13:07 |
| Lo-lan-do | Assume another branch, called foo, started from trunk at point C. | 13:08 |
| glyph | Odd_Bloke: I think I like where Lo-lan-do's explanation is going ;) | 13:08 |
| Lo-lan-do | You commit E and F on top of foo. | 13:08 |
| Odd_Bloke | glyph: ^_^ | 13:08 |
| Lo-lan-do | C is the last common ancestor for the branches, right? | 13:08 |
| glyph | Lo-lan-do: Yes, this makes sense | 13:08 |
| glyph | Lo-lan-do: It's helpful to use letters rather than numbers, because svn has given me nearly irreparable brain damage in this regard ;-) | 13:09 |
| Lo-lan-do | But you can't pull foo into trunk, because there's one rev on trunk not in foo (D) | 13:09 |
| glyph | (I have to keep repeating to myself, "directed graph of revisions" over and over again just so I don't start hemmorhaging blood out of my brain when I type "bzr branch") | 13:09 |
| Lo-lan-do | So what you do is rebase foo on trunk. | 13:09 |
| Lo-lan-do | What "bzr rebase ../trunk" does is this: it uncommits E and F, then pulls D, then re-applies E and F on top of D. | 13:10 |
| glyph | Lo-lan-do: OOoooooohhh... | 13:10 |
| Lo-lan-do | Of course, since D changed the tree, what it actually commits is E' and F', with slight changes. | 13:10 |
| Odd_Bloke | http://paste.pocoo.org/show/21271/ is my attempt to outdo Lo-lan-do. :D | 13:10 |
| glyph | Lo-lan-do: So this is trunk in SVN and foo in bzr | 13:10 |
| Lo-lan-do | Odd_Bloke: I think you got it wrong | 13:11 |
| Odd_Bloke | Lo-lan-do: How so? | 13:11 |
| glyph | Lo-lan-do: this is _seriously_ awesome. | 13:11 |
| glyph | Lo-lan-do: Does this, or can this work with branches in svn as well? | 13:11 |
| Lo-lan-do | glyph: Note you can get conflicts during rebasing, obviously, if D conflicts with E and/or F | 13:11 |
| spiv | glyph: the downside of rebase is that it throws away history | 13:12 |
| glyph | Lo-lan-do: for reference, here is what we do right now, without bzr, to do what would be in a bzr repository a straightforward merge from trunk: http://www.divmod.org/trac/wiki/MergedForward | 13:12 |
| glyph | spiv: you know me. | 13:12 |
| glyph | spiv: I _LOVE_ throwing away history. So much. | 13:12 |
| Lo-lan-do | I use trunk as a branch bound to SVN | 13:12 |
| spiv | glyph: it generates a new history, but anyone who branched off your branch will be in a bit of a mess. | 13:12 |
| Lo-lan-do | Odd_Bloke: Missing primes, and/or wrong ordering | 13:12 |
| glyph | spiv: Oh. That is unfortunate. I guess they could rebase as well but it would cause them some pretty severe suffering. | 13:12 |
| spiv | glyph: no worse than keeping the same sort of branches-of-branches in plain SVN (which keeps no history in this sense at all, at least not in any useful way) | 13:13 |
| glyph | branches-of-branches in SVN is just not worth the trouble | 13:13 |
| glyph | the math required to not kill yourself is too hard for any human being to od | 13:13 |
| Odd_Bloke | Lo-lan-do: OK, you win. :p | 13:14 |
| glyph | spiv: I am starting to think of experimentally developing a few Twisted or Divmod branches in bzr | 13:14 |
| glyph | spiv: Trying to think about the best way to go about that so as not to be overly disruptive. I am very excited right now because it looks like as of 1.0 and the matched release of bzr-svn, it's actually up to the task | 13:15 |
| spiv | basically, if you have a branch off F with revision G, and do the rebase Lo-lan-do described, you suddenly have two branches with different revisions making very similar changes. | 13:15 |
| glyph | spiv: It seems like the best way might just be to keep trunk in SVN, and push bzr branches elsewhere | 13:15 |
| spiv | So you're risking messy conflicts, as I'm sure you can imagine. | 13:15 |
| glyph | spiv: yes | 13:15 |
| Lo-lan-do | glyph: I've documented a setup I have on http://mail.gnome.org/archives/f-spot-list/2008-January/msg00035.html | 13:15 |
| Lo-lan-do | I don't do any rebasing in there, only merges, but that's not a problem since I don't have commit access to SVn anyway :-) | 13:16 |
| spiv | Lo-lan-do: ooh, you do f-spot dev with bzr? I made a checkout of that with bzr-svn to start hacking on a bug I found, but never played with it much... | 13:16 |
| glyph | Lo-lan-do: *perfect*! | 13:16 |
| glyph | OK now I'm getting too excited. | 13:16 |
| spiv | Lo-lan-do: but I still want to fix that bug :) | 13:16 |
| Lo-lan-do | spiv: I do, but only locally. | 13:16 |
| * spiv reads | 13:16 | |
| Lo-lan-do | spiv: Fix the bug, submit a patch to Bugzilla, and tell me the number so I'll create a new branch with it, and merge it into my superpatch branch | 13:17 |
| glyph | Squeeeeeeeee | 13:17 |
| glyph | OK I guess I need to propose this on the mailing list | 13:17 |
| Lo-lan-do | (I'm currently tracking 14 patches :-) | 13:18 |
| glyph | Hmm | 13:20 |
| glyph | The main reason I need to push to svn branches is to avoid disrupting our review process | 13:20 |
| glyph | oh right, now I remember other problem with using bzr here - when I push to trunk in svn, I want to destroy as much history as possible :) | 13:24 |
| glyph | Lo-lan-do: let's say I do | 13:24 |
| glyph | bzr get svn+ssh://.../trunk; bzr branch trunk foo; cd foo; bzr commit; bzr commit; bzr commit; bzr push ../trunk; cd ../trunk; bzr push | 13:25 |
| glyph | am I going to get 3 revisions in trunk, or 1? It's important to me to be able to reduce that to 1 somehow | 13:25 |
| glyph | in the absence of SVN being able to understand that this is a single logical "merge" operation, our release manager is going to want to look at a log of trunk and see only one revision for each merge | 13:26 |
| luks | if you merge foo to trunk, instead of pushing foo to trunk, you will get only one | 13:26 |
| Lo-lan-do | What luks said | 13:27 |
| glyph | luks: Interesting | 13:27 |
| glyph | luks: That is pretty much exactly what I want | 13:27 |
| luks | bzr will still all of them, but svn only the merge | 13:27 |
| luks | er, still see | 13:27 |
| glyph | luks: "(08:02:51 AM) Lo-lan-do: Actually, the bzr "merge" operation does strange things. I usually keep to pull and push." | 13:27 |
| glyph | luks: That worries me though ;) | 13:27 |
| Lo-lan-do | I think it does strange stuff when you merge from svn into bzr, then pull(or push) the result into svn. | 13:28 |
| luks | Lo-lan-do: what kind of strange things? | 13:28 |
| luks | I practically use bzr-svn only for merging svn branches, and it always worked fine for me | 13:29 |
| Lo-lan-do | svn sees a series of commits based not on D but on C (from my earlier scheme) | 13:29 |
| luks | if you merge, it sees only one commit | 13:30 |
| luks | as it pushes only the mainline | 13:30 |
| glyph | luks: is this documented somewhere? | 13:30 |
| luks | not sure, but bzr-svn will push always only the mainline commits | 13:31 |
| Lo-lan-do | Yeah, but if you merge from svn into bzr and then pull the result into svn again... you get surprises. | 13:31 |
| luks | that is, the non-indented ones from bzr log | 13:31 |
| luks | Lo-lan-do: pull into svn? | 13:31 |
| luks | you mean push? | 13:31 |
| Lo-lan-do | Whichever | 13:32 |
| Lo-lan-do | (I pull into a branch bound to svn) | 13:33 |
| luks | oh, I can see how that causes problems | 13:34 |
| luks | because pull can change the mainline | 13:34 |
| luks | but I personally wouldn't pull to a svn checkout | 13:34 |
| bialix | hi guys | 13:34 |
| bialix | I can't find 1.1 branch. Is it not public (yet)? | 13:35 |
| glyph | luks: hmm | 13:35 |
| luks | Lo-lan-do: push to the svn branch would complain about diverged branches | 13:35 |
| glyph | luks: what if I'm working in a bzr branch, and I want to merge in the svn trunk? | 13:35 |
| glyph | here's what I would think would not give me any surprises | 13:36 |
| luks | bzr branch svn+ssh:// trunk; cd ..; bzr branch trunk foo; cd foo; bzr ci; cd ../trunk; bzr merge ../foo; bzr ci -m 'Merged foo'; bzr push | 13:37 |
| luks | this should work without any surprises | 13:37 |
| luks | oh, you might want to add 'bzr pull' before the merge, to avoid the need for rebasing | 13:37 |
| glyph | bzr branch svn+ssh://.../trunk; bzr branch trunk foo; cd trunk; bzr pull; cd ../foo; bzr merge ../trunk; bzr ci; edit stuff; bzr ci; cd ../trunk; bzr merge ../foo; bar ci; bzr push; | 13:37 |
| glyph | hah, cool | 13:38 |
| glyph | I *think* we said the exact same thing | 13:38 |
| luks | you usually don't need the 'bzr merge ../trunk' step | 13:39 |
| luks | unless you have a long lived branch and you want to sync it with trunk | 13:39 |
| glyph | luks: that's exactly the case I'm thinking about | 13:39 |
| Peng_ | bialix: It may not be on Launchpad, but http://bazaar-vcs.org/bzr/bzr.1.1/ | 13:39 |
| === Peng_ is now known as Peng | ||
| luks | but either way, this should work fine | 13:39 |
| luks | just don't do: cd trunk; bzr pull ../foo; bzr push svn+ssh://... | 13:40 |
| luks | or the other way around: cd foo: bzr push --overwrite ../trunk | 13:41 |
| glyph | luks: OK. *That*, I definitely don't want to do :) | 13:41 |
| glyph | luks: as I understand it, pulling and pushing generate multiple mainline revisions, which is exactly the case I don't want | 13:41 |
| luks | yes | 13:41 |
| glyph | luks: am I phrasing that properly? | 13:41 |
| luks | I think it's better to think of it in terms of mirrors | 13:42 |
| luks | bzr push/pull will mirror a branch | 13:42 |
| spiv | glyph: "generate" is a misleading verb for that, I think | 13:42 |
| licorna | hi | 13:43 |
| glyph | I really need a version of bzr-gtk that works with 1.0 so I can visualize this :( | 13:43 |
| spiv | glyph: the "new" revisions already exist in another branch, no new revisions are made. | 13:43 |
| brilliantnut | glyph: bzr-gtk dos work with 1.0 | 13:43 |
| glyph | brilliantnut: Oh? | 13:43 |
| * glyph looks at a webpage | 13:43 | |
| glyph | oh, so it does | 13:43 |
| glyph | I guess I'm just waiting for debs then | 13:44 |
| Lo-lan-do | They are in sid | 13:46 |
| bialix | Peng_: thanks | 13:46 |
| glyph | Lo-lan-do: I'm using gutsy | 13:46 |
| glyph | (and and bazaar-vcs.org's gutsy repository, and jelmer's personal unstable repository) | 13:46 |
| luks | https://launchpad.net/~bzr/+archive | 13:47 |
| luks | it seems to have 0.93 for gutsy | 13:48 |
| glyph | huh | 13:48 |
| glyph | good to know | 13:48 |
| === mrevell-lunch is now known as mrevell | ||
| glyph | luks: should I get rid of those other two repositories I just mentioned and go from PPA instead? | 14:03 |
| jelmer | afaik the ppa is not actively maintained | 14:05 |
| glyph | I guess I'll just download the one deb I want :) | 14:07 |
| glyph | hmm | 14:08 |
| glyph | man, I love gdebi | 14:08 |
| glyph | the experience of clicking on a web page and getting an "install" button is just awesome | 14:09 |
| licorna | if I want to make a local branch and push it to a central location, in this 'central location' is not necesary that bzr is installed, right= | 14:28 |
| licorna | ? | 14:28 |
| licorna | just need a ftp server? | 14:28 |
| LeoNerd | Indeed; anything that can host files in some way is sufficient. | 14:29 |
| LeoNerd | sftp and http work well | 14:29 |
| rjek | You can push to http? | 14:29 |
| rjek | Actually, I meant to ask that: can bzr use HTTP PUT to push to http:// URLs? | 14:29 |
| licorna | don't know. i'm new | 14:30 |
| ubotu | New bug: #182849 in bzr "bzr bind to unknown host causes internal error" [Undecided,New] https://launchpad.net/bugs/182849 | 14:30 |
| licorna | how to use a non standard port in sftp (I'm using port 21 for firewall issues) | 14:34 |
| licorna | ?? | 14:34 |
| licorna | I mean, bzr push sftp://... | 14:34 |
| Lo-lan-do | Declare it in your .ssh/options file? | 14:34 |
| Lo-lan-do | Or maybe sftp://foo:21/path | 14:34 |
| === cprov is now known as cprov-lunch | ||
| licorna | Oh, you're right, thanks | 14:35 |
| Odd_Bloke | licorna: For reference, which suggestion was correct? | 14:47 |
| Lo-lan-do | Both, I suppose :-) | 14:55 |
| arne^ | hello, I'm trying to use bzrlib in a python script. I was able to figure out how to do things like bzr init, add, commit but I'm stuck with a way to do bzr cat for old revisions (working on a local workingtree). Can anybody give a pointer where to look? | 14:55 |
| rjek | Oooh, that reminds me: are there C bindings to bzrlib so I can call it from C programs, and easily bind it to other languages? | 14:59 |
| ubotu | New bug: #182856 in bzr "Error 2 during merge resulting in many conflicts" [Undecided,New] https://launchpad.net/bugs/182856 | 15:01 |
| luks | arne^: tree.get_file_text(file_id) | 15:07 |
| luks | and tree.path2id(path) to get the file_id | 15:07 |
| wingo | congrats on 1.0 :) | 15:19 |
| wingo | question. | 15:19 |
| === abadger1991 is now known as abadger1999 | ||
| wingo | do by-reference nested branches work yet? | 15:20 |
| jelmer | wingo: They're still an experimental feature | 15:21 |
| jelmer | and will only work with the various -subtree formats | 15:21 |
| wingo | ok | 15:21 |
| === cprov-lunch is now known as cprov | ||
| rjek | Other than the speed issue, there's only been one issue I've had with my migration to bzr, and that's the apparent constant changing of the on-disc format. :-/ | 15:26 |
| rjek | Oh, and the lack of ability to do what I want authentication-wise, but Kinni's looking into that for me :) | 15:26 |
| luks | why is changing of the format bad? | 15:28 |
| jelmer | maybe bzr should just do as some other vcs'es do and upgrade silently between on-disc like some other VCS' do :-) | 15:29 |
| luks | *cough*git*cough*? :) | 15:30 |
| rjek | luks: Because it's a ballache when you don't have a smart server to abstract the differences. | 15:30 |
| arne^ | luks: thx, but I'm having problems to get a tree which represents the correct revision ... | 15:34 |
| luks | repository.revision_tree(revision_id) | 15:34 |
| arne^ | repository can be a local working copy? | 15:35 |
| luks | no, tree.branch.repository | 15:35 |
| luks | if 'tree' is a working tree | 15:36 |
| arne^ | ah, ok, I will try it. thank you | 15:36 |
| === mw__ is now known as mw|brb | ||
| ubotu | New bug: #182899 in bzr "reconcile must be run in a branch root" [Undecided,New] https://launchpad.net/bugs/182899 | 16:36 |
| === mw|brb is now known as mw | ||
| arne^ | luks: my code is working now, thanks for your help! | 17:11 |
| luks | you're welcome :) | 17:13 |
| === brilliantnu1 is now known as brilliantnut | ||
| ekimus | hmm can I somehow place Revision Identifiers in the source (looking for a substitute of subversions $Date$ $Author$... - svn:keywords) - or do I want something completely different like a custom plugin or hook? | 18:34 |
| ekimus | ok I just found the specs about KeywordExpansion, sadly "Implementation branch: none yet" - well I'll wait :) | 18:44 |
| fullermd | ekimus: The current solution is using 'version-info' in your build script to stuff the version somewhere. | 18:44 |
| fullermd | (or some similar mechanism; I do some sed'ery in one project to stick bits in a header file) | 18:45 |
| ekimus | well I guess we can live without that, since I carefully set up trac with hooks to react on commit messages a year ago so far they haven't used it. guess they can than live without svn:keywords too... | 18:54 |
| fullermd | Of course, now that you've said that, there'll be a peasant uprising tomorrow demanding keywords. | 19:00 |
| * brilliantnut wants keyword expansion | 19:02 | |
| * fullermd does too. And a pony. | 19:04 | |
| * beuno points to Canonical's owned pony, Woody | 19:05 | |
| beuno | (yes, the secret is out) | 19:06 |
| brilliantnut | Canonical has a pony? | 19:11 |
| brilliantnut | which project? | 19:11 |
| beuno | brilliantnut, they sponsor an actual pony | 19:12 |
| fullermd | Sponsor? What does it do, figure skate? | 19:12 |
| beuno | but I'm not a Canonical person, so I don't know much more then that and a some picture I got and used in slides as a "Why use Ubuntu" | 19:13 |
| fullermd | Come to think of it, I would *totally* pay to see a donkey do a double axel. | 19:13 |
| beuno | lol, interesting, now we know where Canonical gets all that funding... :p | 19:13 |
| deepjoy | fullermd: or a monkey do bzr checkout http://en.wikipedia.org/wiki/Infinite_monkey_theorem | 19:14 |
| beuno | "figure skating ponies" | 19:14 |
| deepjoy | :-) | 19:14 |
| beuno | btw, has anyone seen this: http://juliank.wordpress.com/2008/01/13/a-small-benchmark-bazaar-git-mercurial/ | 19:16 |
| beuno | bzr seems to loose on all tests | 19:16 |
| beuno | which contradicts http://bazaar-vcs.org/Benchmarks/SpaceEfficiency | 19:17 |
| luks | well, you know how benchmarks work | 19:18 |
| fullermd | You pick up the computer, hold it at a carefully-chosen angle, let it fall, then measure the mark on the bench? | 19:19 |
| brilliantnut | speaking of peasant uprisings, demanding stuff, rumour had it that 1.1 was about to be released today? *cough*poolie*cough* | 19:19 |
| lamont | is it possible to edit the commit message on the most-recent commit? | 19:21 |
| luks | bzr uncommit, bzr commit | 19:21 |
| beuno | well, I just added a comment, but maybe someone a bit more knowledgable should contact the guy | 19:21 |
| minghua | How to undo a merge? I can revert all the files that are changed, but the "bzr status" still shows "pending merges". | 19:38 |
| dato | bzr revert | 19:38 |
| minghua | dato: Ah, that works. I must did something stupid last time I tried. Thanks! | 19:42 |
| abentley | minghua: reverting specific files won't clear pending merges. You should do "bzr revert" with no arguments to clear pending merges. | 19:51 |
| minghua | abentley: Yes, dato gave the same (although less elaborated) answer. And it works, thanks! | 19:52 |
| abentley | minghua: I saw, I just wanted to make it really clear. | 19:53 |
| mtaylor | statik: where was it you were saying did the save-commit-messages already? | 20:56 |
| statik | mtaylor: qbzr | 20:56 |
| mtaylor | statik: I looked in qbzr and didn't see it | 20:56 |
| mtaylor | statik: I also didn't see a "save message and don't commit" button | 20:56 |
| statik | mtaylor: save_message() in commit.py. There is no button, it just works if you hit cancel | 20:57 |
| mtaylor | statik: ahhh | 20:58 |
| mtaylor | statik: ok. that's what I was missing. thanks | 20:58 |
| elmo | how fragile is bzr nested tree support right now? | 21:04 |
| elmo | I know there's a subtree format, but it (or publicizing it) seems relatively controversial | 21:04 |
| elmo | I don't care about performance, and I'm only dealing with local non-distributed branches | 21:04 |
| mtaylor | elmo: I don't believe nested tree support is ready-for-prime-time yet | 21:05 |
| elmo | mtaylor: may-eat-my-data not ready? | 21:05 |
| lifeless | elmo: with larstiqs patch it might work | 21:05 |
| mtaylor | elmo: not-even-pushed-into-trunk not ready | 21:05 |
| elmo | bother | 21:05 |
| lifeless | hi statik, guess what I'm going to ask you :) | 21:06 |
| statik | lifeless: :) sorry, don't have it yet, but it's still on the top of my todo list staring at me | 21:07 |
| * lifeless adds an i to it | 21:08 | |
| mtaylor | statik: ok, found the code. thanks | 21:14 |
| jam | poolie: ping | 22:09 |
| lifeless | jam: hi | 22:13 |
| lifeless | jam: poolie is on some sort of call | 22:13 |
| jam | lifeless: yeah, I'm supposed to be on it with him | 22:13 |
| poolie | that's why he was pinging... | 22:13 |
| jam | he wasn't there yet :) | 22:13 |
| lifeless | poolie: lol | 22:13 |
| elmo | LarstiQ: ping? | 22:34 |
| LarstiQ | elmo: just-before-sleep pong | 22:34 |
| elmo | LarstiQ: can-wait-till-tomorrow-then | 22:34 |
| LarstiQ | elmo: well, I'll hang around for a couple more minutes | 22:35 |
| LarstiQ | elmo: ah hmm | 22:36 |
| LarstiQ | elmo: depends on how actively you want to exercise it | 22:36 |
| * LarstiQ hasn't spent time on it for too long though | 22:37 | |
| elmo | LarstiQ: I'd just like to try it :) | 22:38 |
| elmo | LarstiQ: is there an easy way to get a patch that I might slap onto bzr 1.0? | 22:38 |
| elmo | or should I just suck it up and force your branch onto current bzr.dev? | 22:38 |
| LarstiQ | elmo: I think there will be quite a lot of conflict resolving you'd have to do | 22:39 |
| elmo | LarstiQ: either way? | 22:39 |
| LarstiQ | elmo: either way. You _could_ try playing with split/join as they are in 1.0, but in that case be sure to, in a given hierarchy, not have subtrees with the same name. | 22:40 |
| LarstiQ | ie, root/sub and root/sub/sub will give you problems. | 22:40 |
| elmo | ok, that shouldn't be a problem | 22:40 |
| elmo | LarstiQ: but, FWIW, if you cooked up a current bzr.dev or bzr 1.0 patch, I'd be happy to run on a bunch of servers and give you some real world testing | 22:41 |
| elmo | (if that'd be useful, if not, I'm happy to try just 1.0) | 22:41 |
| LarstiQ | elmo: how early on would you want to do testing? | 22:42 |
| elmo | LarstiQ: how do you mean? | 22:42 |
| LarstiQ | elmo: well, you could be comfortable with testing something I'd submit for bzr.dev inclusion but like some real world usage, but not earlier on when there are still bugs to iron out. | 22:43 |
| elmo | LarstiQ: if you're relatively confident bugs will be 'explode' bugs rather, than insidious non-obvious data corruption bugs, I'd be happy enough to test pretty early on | 22:44 |
| LarstiQ | cool | 22:44 |
| elmo | 'cos I can reset to last night's .bzr trivially enough | 22:44 |
| LarstiQ | elmo: I'll certainly take you up on that then. | 22:44 |
| elmo | LarstiQ: neato | 22:45 |
| elmo | tgabjs | 22:45 |
| elmo | err, thanks | 22:45 |
| * LarstiQ goes to bed now | 22:45 | |
| dato | 23:34 <elmo> LarstiQ: can-wait-till-tomorrow-then | 22:57 |
| dato | 23:35 <LarstiQ> elmo: well, I'll hang around for a couple more minutes | 22:57 |
| dato | 23:36 <LarstiQ> elmo: ah hmm | 22:57 |
| dato | 23:36 <LarstiQ> elmo: depends on how actively you want to exercise it | 22:57 |
| dato | I think my ctrlproxy lost a line there. | 22:58 |
| elmo | dato: nah, larstiq just read scrollback to divine my intent | 22:58 |
| elmo | dato: (we're talking about his nested trees++ branch) | 22:59 |
| lifeless | spiv: I have replied to your reviews, there is one open question about the value of _returning; I propose 'next' and 'next_with_ghosts' | 23:04 |
| spiv | lifeless: that sounds fine to me | 23:05 |
| === jamesh_ is now known as jamesh | ||
| lifeless | poolie: jam: when do you want this call | 23:33 |
| * igc breakfast - bbiab | 23:46 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!