[00:00] <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:01] <mtaylor> (you are right - there is no specced length limit)
[00:02] <mtaylor> but _most_ of the email addresses were in the 30 char length and the really long ones were about 60
[00:03] <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
[01:42] <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
[02:23]  * igc lunch
[02:34] <sechastain> there are coding standards for bzr, right?
[02:35] <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
[03:01] <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:56] <lifeless> spiv: piong
[03:57] <poolie> hi lifeless
[04:01] <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:02] <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:10] <Peng_> cr3: If you've already pushed, don't uncommit.
[04:12] <cr3> Peng_: thanks for the warning, but I was safe
[04:12] <Peng_> :)
[04:18] <lifeless> I poolie
[04:20] <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:21] <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:23] <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:24] <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:26] <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:27] <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:28] <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:34] <hacklberry> fullermd: just for reference i was gibbering about this patch: http://samba.org/~metze/subversion-1.4.0-metze-python-bindings.patch
[04:35] <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:37] <mtaylor> ah
[04:37] <mtaylor> that's why I'm working fine "without" the patch
[04:38]  * 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:39] <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:40] <mtaylor> but I guess I haven't sacrificed goats in the right places yet
[04:41]  * TFKyle typically uses gentoo, have ubuntu and a few BSD's installed in vmware though
[04:42] <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?
[05:03] <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:04] <jelmer> it may actually be set to the location you branched from by default
[05:04] <jelmer> cat .bzr/branch/branch.conf
[05:06] <lifeless> ok, Repository.get_parent_map is working
[05:06] <lifeless> shoud gzip the content I think though
[05:40] <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
[06:18] <abentley> lifeless: Perhaps even bzip?  Probably lots of redundancy in revision ids.
[06:27] <spiv> abentley: bzip is a pretty large leap in processing cost, IIRC.
[06:30] <abentley> spiv: Sure, but on today's hardware, it could still be very cheap.
[06:30] <spiv> Yeah.  Worth experimenting with.
[06:31] <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:32] <abentley> Is it going to be 64K compressed or uncompressed?
[06:33] <spiv> abentley: good question ;)
[06:34] <spiv> abentley: lifeless just posted (and I just reviewed) a smart method that just does 64k uncompressed.
[06:39] <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...
[07:27] <brilliantnut> hi anybody knows about 1.1?
[07:27] <AfC> brilliantnut: are you subscribed to the bazaar project mailing list?
[07:28] <brilliantnut> no, only to announce
[07:30] <brilliantnut> but I keep browsing thru  those archives for info on 1.1, did I miuss something?
[07:33] <AfC> brilliantnut: Martin wrote a ... oh, damn. Well, whatever
[07:48] <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:49] <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:50] <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;
[08:05]  * igc dinner
[10:07] <rjek> Is there a place I can branch the current release version from?
[10:08] <rjek> (ie, not http://www.bazaar-vcs.org/bzr/bzr.1.0/ but something like http://www.bazaar-vcs.org/bzr/bzr.current/)
[10:09] <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:10] <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:11] <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:12] <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:13] <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:14] <lifeless> fullermd: we're not masochists
[10:14] <fullermd> I'm sure there's evidence to the contrary in the code still   :p
[10:21] <brilliantnut> poolie: would you have any idea of what happened to the 1.1 release of bazaar that was scheduled on 11th Jan?
[10:22] <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:23] <brilliantnut> ok. Thanks :) I've been waiting for 1.1 since ages.
[10:23] <dato> well
[10:24] <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:25] <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:26] <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:27] <awilkins> Is KnitRepository the bit that handles branches of differing format versions?
[10:28] <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:30] <ubotu> New bug: #182803 in bzr "Replay branch appears broken" [Undecided,New] https://launchpad.net/bugs/182803
[10:35] <rjek> What does "bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>.  Does not support rich root data." mean when doing bzr upgrade?
[10:39] <Peng_> rjek: What format are you currently using (bzr info)?
[10:40] <rjek> bzr info doesn't say, but I believe it's knits.
[10:41] <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:42] <rjek> What is a rich root, anyway?
[10:42] <Peng_> rjek: Try rich-root-pack, then.
[10:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:53] <awilkins> Anyone using the eclipse bzr support? Any good?
[10:54] <brilliantnut> awilkins: not yet.
[10:55] <brilliantnut> awilkins: I tried it out, but it doesn't support the full range of eclipse team tasks that cvs/svn does.
[11:22] <jelmer> I thought split/join worked with rich-root too
[11:22] <jelmer> subtree is for by-reference nested tree
[11:25] <dato> oh
[11:25] <dato> Peng_: ^
[11:28] <Peng_> :D
[11:28] <Peng_> So subtrees are like svn externals?
[11:30] <jelmer> Peng_: Yep
[11:31] <Peng_> Ok.
[11:31] <Peng_> I think I finally understand the whole mess.
[11:32] <Peng_> Shouldn't rich-root-pack be named pack-0.92-rich-root?
[11:32] <fullermd> That would blow our 2-dash budget...
[11:33] <jelmer> fullermd: (-:
[12:25] <fullermd> Hm.  added seems to be b0rked...
[12:28] <Odd_Bloke> fullermd: !testcase ;)
[12:28] <fullermd> I'm more of an idea rat...
[12:51] <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:52] <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:53] <glyph> jelmer: also, may I say, you are a god among men
[12:53] <Odd_Bloke> +1
[12:54] <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:55] <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:56] <glyph> jelmer: OK, I was going to try that next
[12:57] <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:58] <jelmer> glyph: Concerned about what specifically?
[12:58] <Lo-lan-do> I usually keep a bound branch for that
[12:59] <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.
[13:01] <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:02] <Lo-lan-do> Actually, the bzr "merge" operation does strange things.  I usually keep to pull and push.
[13:03] <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:04] <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:05]  * 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:06] <glyph> hmm
[13:07] <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:08] <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:09] <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:10] <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:11] <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:12] <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:13] <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:14] <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:15] <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:16] <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:17] <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:18] <Lo-lan-do> (I'm currently tracking 14 patches :-)
[13:20] <glyph> Hmm
[13:20] <glyph> The main reason I need to push to svn branches is to avoid disrupting our review process
[13:24] <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:25] <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:26] <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:27] <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:28] <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:29] <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:30] <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:31] <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:32] <Lo-lan-do> Whichever
[13:33] <Lo-lan-do> (I pull into a branch bound to svn)
[13:34] <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:35] <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:36] <glyph> here's what I would think would not give me any surprises
[13:37] <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:38] <glyph> hah, cool
[13:38] <glyph> I *think* we said the exact same thing
[13:39] <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] <luks> but either way, this should work fine
[13:40] <luks> just don't do: cd trunk; bzr pull ../foo; bzr push svn+ssh://...
[13:41] <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:42] <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:43] <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:44] <glyph> I guess I'm just waiting for debs then
[13:46] <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:47] <luks> https://launchpad.net/~bzr/+archive
[13:48] <luks> it seems to have 0.93 for gutsy
[13:48] <glyph> huh
[13:48] <glyph> good to know
[14:03] <glyph> luks: should I get rid of those other two repositories I just mentioned and go from PPA instead?
[14:05] <jelmer> afaik the ppa is not actively maintained
[14:07] <glyph> I guess I'll just download the one deb I want :)
[14:08] <glyph> hmm
[14:08] <glyph> man, I love gdebi
[14:09] <glyph> the experience of clicking on a web page and getting an "install" button is just awesome
[14:28] <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:29] <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:30] <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:34] <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:35] <licorna> Oh, you're right, thanks
[14:47] <Odd_Bloke> licorna: For reference, which suggestion was correct?
[14:55] <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:59] <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?
[15:01] <ubotu> New bug: #182856 in bzr "Error 2 during merge resulting in many conflicts" [Undecided,New] https://launchpad.net/bugs/182856
[15:07] <luks> arne^: tree.get_file_text(file_id)
[15:07] <luks> and tree.path2id(path) to get the file_id
[15:19] <wingo> congrats on 1.0 :)
[15:19] <wingo> question.
[15:20] <wingo> do by-reference nested branches work yet?
[15:21] <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:26] <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:28] <luks> why is changing of the format bad?
[15:29] <jelmer> maybe bzr should just do as some other vcs'es do and upgrade silently between on-disc like some other VCS' do :-)
[15:30] <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:34] <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:35] <arne^> repository can be a local working copy?
[15:35] <luks> no, tree.branch.repository
[15:36] <luks> if 'tree' is a working tree
[15:36] <arne^> ah, ok, I will try it. thank you
[16:36] <ubotu> New bug: #182899 in bzr "reconcile must be run in a branch root" [Undecided,New] https://launchpad.net/bugs/182899
[17:11] <arne^> luks: my code is working now, thanks for your help!
[17:13] <luks> you're welcome :)
[18:34] <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:44] <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:45] <fullermd> (or some similar mechanism; I do some sed'ery in one project to stick bits in a header file)
[18:54] <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...
[19:00] <fullermd> Of course, now that you've said that, there'll be a peasant uprising tomorrow demanding keywords.
[19:02]  * brilliantnut wants keyword expansion
[19:04]  * fullermd does too.  And a pony.
[19:05]  * beuno points to Canonical's owned pony, Woody
[19:06] <beuno> (yes, the secret is out)
[19:11] <brilliantnut> Canonical has a pony?
[19:11] <brilliantnut> which project?
[19:12] <beuno> brilliantnut, they sponsor an actual pony
[19:12] <fullermd> Sponsor?  What does it do, figure skate?
[19:13] <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:14] <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:16] <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:17] <beuno> which contradicts http://bazaar-vcs.org/Benchmarks/SpaceEfficiency
[19:18] <luks> well, you know how benchmarks work
[19:19] <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:21] <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:38] <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:42] <minghua> dato: Ah, that works.  I must did something stupid last time I tried.  Thanks!
[19:51] <abentley> minghua: reverting specific files won't clear pending merges.  You should do "bzr revert" with no arguments to clear pending merges.
[19:52] <minghua> abentley: Yes, dato gave the same (although less elaborated) answer.  And it works, thanks!
[19:53] <abentley> minghua: I saw, I just wanted to make it really clear.
[20:56] <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:57] <statik> mtaylor: save_message() in commit.py. There is no button, it just works if you hit cancel
[20:58] <mtaylor> statik: ahhh
[20:58] <mtaylor> statik: ok. that's what I was missing. thanks
[21:04] <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:05] <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:06] <lifeless> hi statik, guess what I'm going to ask you :)
[21:07] <statik> lifeless: :) sorry, don't have it yet, but it's still on the top of my todo list staring at me
[21:08]  * lifeless adds an i to it
[21:14] <mtaylor> statik: ok, found the code. thanks
[22:09] <jam> poolie: ping
[22:13] <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:34] <elmo> LarstiQ: ping?
[22:34] <LarstiQ> elmo: just-before-sleep pong
[22:34] <elmo> LarstiQ: can-wait-till-tomorrow-then
[22:35] <LarstiQ> elmo: well, I'll hang around for a couple more minutes
[22:36] <LarstiQ> elmo: ah hmm
[22:36] <LarstiQ> elmo: depends on how actively you want to exercise it
[22:37]  * LarstiQ hasn't spent time on it for too long though
[22:38] <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:39] <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:40] <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:41] <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:42] <LarstiQ> elmo: how early on would you want to do testing?
[22:42] <elmo> LarstiQ: how do you mean?
[22:43] <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:44] <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:45] <elmo> LarstiQ: neato
[22:45] <elmo> tgabjs
[22:45] <elmo> err, thanks
[22:45]  * LarstiQ goes to bed now 
[22:57] <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:58] <dato> I think my ctrlproxy lost a line there.
[22:58] <elmo> dato: nah, larstiq just read scrollback to divine my intent
[22:59] <elmo> dato: (we're talking about his nested trees++ branch)
[23:04] <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:05] <spiv> lifeless: that sounds fine to me
[23:33] <lifeless> poolie: jam: when do you want this call
[23:46]  * igc breakfast - bbiab