#bzr 2008-01-14
<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
<mtaylor> turns out, they analyzed a bunch of addresses they had in the system (about 1.5 million)
<mtaylor> (you are right - there is no specced length limit)
<mtaylor> but _most_ of the email addresses were in the 30 char length and the really long ones were about 60
<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
<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
<mtaylor> bzr branch https://launchpad.net/qbzr
<mtaylor> doesn't even partially work
 * igc lunch
<sechastain> there are coding standards for bzr, right?
<Peng_> They're in the HACKING document.
<Peng_> http://doc.bazaar-vcs.org/bzr.dev/en/developer-guide/HACKING.html
<Peng_> Or doc/developers/HACKING.txt in the source, I think.
<sechastain> that's it
<sechastain> thanks
<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.
<lifeless> spiv: piong
<poolie> hi lifeless
<cr3> how can I revert a commit on many files?
<poolie> bzr revert FILE ...
<sechastain> uncommit
<poolie> or bzr revert DIR
<poolie> unless maybe you want uncommit instead?
<cr3> poolie: yeah, uncommit would be awesome... checking manpage
<spiv> lifeless: ok, I'll do that now
<cr3> first time I use this feature, absolutively cool!
<Peng_> cr3: If you've already pushed, don't uncommit.
<cr3> Peng_: thanks for the warning, but I was safe
<Peng_> :)
<lifeless> I poolie
<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...)
<fullermd> No, you lifeless.
<mtaylor> hacklberry: well, it'll work without the patch, but the memory leak may hit you if the svn repos is really big
<mtaylor> hacklberry: but I've been using it against svn for a while without problems (except for the memory leak)
<fullermd> Er, AFAIK, the stock 1.4.x bindings won't work at all without the patch.
<Odd_Bloke> I poolie?
<mtaylor> oh
<mtaylor> nevermind then... don't listen to me
<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?
<mtaylor> hacklberry: depends on how you are branching it
<mtaylor> hacklberry: I, most of the time, do bzr svn-import to get a bzr repos of the svn repos
<mtaylor> hacklberry: at times, this takes a very, very, very long time
<hacklberry> mtaylor: thanks
<mtaylor> hacklberry: sure. but also fullermd is probably right about the patch - he's smarter than I am
<mtaylor> :)
<mtaylor> so ignore me about that
<fullermd> Oh, great, now my ego is gonna strut around all day....
<fullermd> We may be talking about different patches.
<fullermd> There IS a memory leak patch that prevents it from going out the window and down the road on big things.
<fullermd> That's not strictly _necessary_, especially if you have a small repo, but it's still a good idea.
<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.
<hacklberry> fullermd: just for reference i was gibbering about this patch: http://samba.org/~metze/subversion-1.4.0-metze-python-bindings.patch
<jelmer> hacklberry: yes, you will still need to update the patch if you are on subversion 1.4.x
<jelmer> unless your distributions ships its packages with it
<jelmer> Debian and Ubuntu do
<mtaylor> ah
<mtaylor> that's why I'm working fine "without" the patch
 * mtaylor doesn't understand people who don't use debian/ubuntu
<fullermd> Linux?  That thing is still around?   :p
<mtaylor> hehe
 * TFKyle doesn't understand people who do use ubuntu :P
<jelmer> The memory leak fix is not included in the Debian/Ubuntu packages yet
 * mtaylor stabs TFKyle in the eye
<hacklberry> jelmer: thanks. OT:(huh distirbution - what's that :-) ? slack base here, the rest rolled from sources...
<jelmer> but will be included in the next upload to sid (and first import from sid from ubuntu)
<TFKyle> ubuntu's good though, they applied one of my patches for a while
 * mtaylor would be happier if he could figure out how to go through the dev process on either debian or ubuntu... 
<mtaylor> but I guess I haven't sacrificed goats in the right places yet
 * TFKyle typically uses gentoo, have ubuntu and a few BSD's installed in vmware though
<mtaylor> there are some times when it seems that after a branch I don't have a pull location set automatically
<mtaylor> is that just me being wrong, or are there times when that's true?
<jelmer> mtaylor: it'll only remember the branch location if there was none set previously or if you specify --remember
<mtaylor> jelmer: so when I make a fresh clean branch, it _should_ remember the pull location, right?
<jelmer> it may actually be set to the location you branched from by default
<jelmer> cat .bzr/branch/branch.conf
<lifeless> ok, Repository.get_parent_map is working
<lifeless> shoud gzip the content I think though
<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
<hacklberry> testing: /usr/bin/bzr
<hacklberry>    /usr/lib/python2.5/site-packages/bzrlib (1.0.0 python2.5.1.final.0)
<hacklberry> ERROR: bzrlib.plugins.svn.tests.test_branch.WorkingSubversionBranch.test_create_checkout
<hacklberry>     _get_global_config() takes exactly 1 argument (4 given)
<hacklberry> [10/722 in 4s, 1 errors] bzrlib.plugins.svn.tests.test_branch.WorkingSubversionBranch.test_create_checkout_lightweight                                                                Segmentation fault
<abentley> lifeless: Perhaps even bzip?  Probably lots of redundancy in revision ids.
<spiv> abentley: bzip is a pretty large leap in processing cost, IIRC.
<abentley> spiv: Sure, but on today's hardware, it could still be very cheap.
<spiv> Yeah.  Worth experimenting with.
<spiv> I'm guessing in the context of ~64k of graph data it won't be worth it, but that's purely a guess :)
<abentley> Is it going to be 64K compressed or uncompressed?
<spiv> abentley: good question ;)
<spiv> abentley: lifeless just posted (and I just reviewed) a smart method that just does 64k uncompressed.
<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...
<brilliantnut> hi anybody knows about 1.1?
<AfC> brilliantnut: are you subscribed to the bazaar project mailing list?
<brilliantnut> no, only to announce
<brilliantnut> but I keep browsing thru  those archives for info on 1.1, did I miuss something?
<AfC> brilliantnut: Martin wrote a ... oh, damn. Well, whatever
<lifeless> abentley: 64 on the wire is my current 'sweet spot' for requests
<lifeless> abentley: so if we compress it, ~64k compressed
<lifeless> with 64k uncompressed we do 4 round trips to get those 100 commits
<lifeless> spiv: thanks for the reviews; I'll reply to the tomorrow morning. Some stuff I agree with, some I don't :)
<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;
 * igc dinner
<rjek> Is there a place I can branch the current release version from?
<rjek> (ie, not http://www.bazaar-vcs.org/bzr/bzr.1.0/ but something like http://www.bazaar-vcs.org/bzr/bzr.current/)
<Lo-lan-do> If you do that, then you'll be left out with a diverged branch when a new version is published.
<rjek> (pref. one I can fetch with 0.90 :)
<rjek> Which is the issue I'm wanting to solve.
<rjek> ie, when a new release is made, I can just bzr pull.
<Lo-lan-do> You can't do that, since each release comes from a different branch.
<dato> rjek: s/current/dev/, but you need 0.92 for that
<fullermd> Releases aren't cut from the trunk, they're cut from their own branches.
<dato> ah
<dato> I misunderstood rjek
<rjek> That's a shame.  OK.
<fullermd> Well, I imagine he misunderstands himself too   ;)
 * dato releases his stuff from $project.stable
<fullermd> Why do you want a release branch instead of trunk?
<lifeless> rjek: http://bazaar-vcs.org/bzr/bzr.0.92/
<rjek> lifeless: I'm fetching bzr.dev.knits atm.
<rjek> (which 0.90 can grock.)
<lifeless> rjek: the url I gave will give you 0.92, and 0.92 can grok it
<lifeless> sorry, 0.90 can grok it
<rjek> I know.
<Odd_Bloke> bzr.dev is normally pretty solid, so I run from that in most places.
<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?
<fullermd> Yes, it is.
<Odd_Bloke> And possibly a few hours out of date.
<rjek> Right, I'll get that then.  Going via an intermediate version is a faff. :)
 * fullermd is still pulling the .knits variant.
<lifeless> rjek: yeah, we try to allow reasonable overlap for folk
<lifeless> but we do keep finding things we can do better
<fullermd> Aw, bzr.dev.as.weaves isn't around anymore?  Shucks...
<lifeless> fullermd: we're not masochists
<fullermd> I'm sure there's evidence to the contrary in the code still   :p
<brilliantnut> poolie: would you have any idea of what happened to the 1.1 release of bazaar that was scheduled on 11th Jan?
<poolie> brilliantnut, yes, i've just been delayed in making it
<poolie> should be out tonight
<poolie> it will have no substantial changes from 1.1rc1
<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>
 * rjek wishes to upgrade as 0.90 is painfully slow for even the most trivial of tasks.
<brilliantnut> ok. Thanks :) I've been waiting for 1.1 since ages.
<dato> well
<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.
<dato> (so it only affects rich-root pack)
<poolie> brilliantnut, do you mean since december?
<poolie> or were you waiting for 1.1 because you don't use 1.0 releases? :)
<brilliantnut> yeah,
<brilliantnut> no, we tried out 1.0, and found that it was missing something for our particular situation
<fullermd> I don't trust 0.9x releases.  I've been waiting for 0.19 forever   :|
<poolie> but it's fixed in 1.1?
<poolie> that's good
<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.
<brilliantnut> so, we have been waiting for 1.1 since then..
<Odd_Bloke> spiv: No pressure. :p
<brilliantnut> We had scheduled time on Saturday to migrate from CVS to bzr 1.1 :(
<brilliantnut> yeah, spiv, no pressure.
<awilkins> Are we discussing the reason that the replay branch doesn't work with a 1.0 client (KnitRepository error?)
<awilkins> Is KnitRepository the bit that handles branches of differing format versions?
<poolie> KnitRepository is a set of imprementations
<poolie> um, i'd have to see the bug or error msg
<awilkins> Japanese implementations :-) ?
<awilkins> https://bugs.launchpad.net/bzr/+bug/182803
<ubotu> Launchpad bug 182803 in bzr "Replay branch appears broken" [Undecided,New]
<ubotu> New bug: #182803 in bzr "Replay branch appears broken" [Undecided,New] https://launchpad.net/bugs/182803
<rjek> What does "bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>.  Does not support rich root data." mean when doing bzr upgrade?
<Peng_> rjek: What format are you currently using (bzr info)?
<rjek> bzr info doesn't say, but I believe it's knits.
<fullermd> Check the first line of output.
<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.
<rjek> Ah, yes: dirstate-with-subtree
<rjek> What is a rich root, anyway?
<Peng_> rjek: Try rich-root-pack, then.
<rjek> bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack4>.  Does not support nested trees
<rjek> :)
<Peng_> rjek: pack-0.92-subtree then.
<Peng_> rjek: Older formats didn't store any information about the root directory of the branch. Rich root formats do.
<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"
<Peng_> rjek: Yeah. Subtrees are kind of experimental, so they're hidden.
<Peng_> rjek: Rich roots were invented as something between the regular formats and subtree formats that wasn't experimental.
<rjek> And what is a subtree?
<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).
<Peng_> rjek: No idea. :) Something more advanced than that I guess.
<dato> Peng_: no, split/join are with *subtree, not with rich-root alone
<Peng_> Bah.
<Peng_> What's the point of rich roots then?
<Peng_> They're enough for bzr-svn.
<Peng_> Why?
<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.
<Peng_> Heh, ok.
<awilkins> Anyone using the eclipse bzr support? Any good?
<brilliantnut> awilkins: not yet.
<brilliantnut> awilkins: I tried it out, but it doesn't support the full range of eclipse team tasks that cvs/svn does.
<jelmer> I thought split/join worked with rich-root too
<jelmer> subtree is for by-reference nested tree
<dato> oh
<dato> Peng_: ^
<Peng_> :D
<Peng_> So subtrees are like svn externals?
<jelmer> Peng_: Yep
<Peng_> Ok.
<Peng_> I think I finally understand the whole mess.
<Peng_> Shouldn't rich-root-pack be named pack-0.92-rich-root?
<fullermd> That would blow our 2-dash budget...
<jelmer> fullermd: (-:
<fullermd> Hm.  added seems to be b0rked...
<Odd_Bloke> fullermd: !testcase ;)
<fullermd> I'm more of an idea rat...
<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
<glyph> unfortunately shared repositories seem to be incompatible with bzr-svn
<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
<jelmer> glyph: Shared repositories work
<glyph> jelmer: Cool.  How do I do it? :)
<jelmer> use the format bzr-svn needs: bzr init-repo --rich-root-pack
<Odd_Bloke> glyph: How did you create the sha... oh, jelmer will save the day. :)
<glyph> jelmer: also, may I say, you are a god among men
<Odd_Bloke> +1
<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 :)
<rjek> heh
<jelmer> glyph: The error is from bzr, not from bzr-svn unfortunately
<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?
<glyph> jelmer: sure, but I was assuming you could write patches for either :)
<Peng_> glyph: bzr branch into the shared repo.
<jelmer> glyph: Create the shared repository, then use "bzr branch" to clone that data into the shared repo
<jelmer> glyph: True :-)
<glyph> jelmer: OK, I was going to try that next
<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
<jelmer> glyph: Concerned about what specifically?
<Lo-lan-do> I usually keep a bound branch for that
<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?
<Lo-lan-do> "bzr commit" commits both to bzr and svn, "bzr pull" from another branch does the right thing, etc.
<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? :)
<Lo-lan-do> Actually, the bzr "merge" operation does strange things.  I usually keep to pull and push.
<glyph> are you using bzr-svn for read-only operation?
<Lo-lan-do> No
<glyph> presumably "pull" won't work sometimes, if you have conflicts
<Lo-lan-do> But I don't do advanced branch stuff in bzr.
<Lo-lan-do> For the few non-svn branches I have, I usually rebase before pulling into svn.
<glyph> rebase?
<glyph> Pardon, I'm still a bit of a bzr newb
<Lo-lan-do> It's another plugin
<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)
<Lo-lan-do> (Still one of jelmer's though :-)
 * glyph reads the package description
<glyph> I have no idea what this means :)
<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.
<Lo-lan-do> So the history stays linear, and you can pull your branch into the svn one
<glyph> hmm
<glyph> Lo-lan-do: I *think* I know what you just said
<glyph> actually no I don't.
<Lo-lan-do> It's still not optimal, but that's what you get for using SVN :-)
<glyph> "applies them on top of the tip"
<glyph> diverged from ... what?
<Lo-lan-do> Okay.  Assume a branch, that we'll call trunk, with revisions A, B, C and D.
<Odd_Bloke> glyph: If you diverge from trunk, rebase takes your fork of the branch and reapplies it to HEAD.
<Lo-lan-do> Assume another branch, called foo, started from trunk at point C.
<glyph> Odd_Bloke: I think I like where Lo-lan-do's explanation is going ;)
<Lo-lan-do> You commit E and F on top of foo.
<Odd_Bloke> glyph: ^_^
<Lo-lan-do> C is the last common ancestor for the branches, right?
<glyph> Lo-lan-do: Yes, this makes sense
<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 ;-)
<Lo-lan-do> But you can't pull foo into trunk, because there's one rev on trunk not in foo (D)
<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")
<Lo-lan-do> So what you do is rebase foo on trunk.
<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.
<glyph> Lo-lan-do: OOoooooohhh...
<Lo-lan-do> Of course, since D changed the tree, what it actually commits is E' and F', with slight changes.
<Odd_Bloke> http://paste.pocoo.org/show/21271/ is my attempt to outdo Lo-lan-do. :D
<glyph> Lo-lan-do: So this is trunk in SVN and foo in bzr
<Lo-lan-do> Odd_Bloke: I think you got it wrong
<Odd_Bloke> Lo-lan-do: How so?
<glyph> Lo-lan-do: this is _seriously_ awesome.
<glyph> Lo-lan-do: Does this, or can this work with branches in svn as well?
<Lo-lan-do> glyph: Note you can get conflicts during rebasing, obviously, if D conflicts with E and/or F
<spiv> glyph: the downside of rebase is that it throws away history
<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
<glyph> spiv: you know me.
<glyph> spiv: I _LOVE_ throwing away history.  So much.
<Lo-lan-do> I use trunk as a branch bound to SVN
<spiv> glyph: it generates a new history, but anyone who branched off your branch will be in a bit of a mess.
<Lo-lan-do> Odd_Bloke: Missing primes, and/or wrong ordering
<glyph> spiv: Oh.  That is unfortunate.  I guess they could rebase as well but it would cause them some pretty severe suffering.
<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)
<glyph> branches-of-branches in SVN is just not worth the trouble
<glyph> the math required to not kill yourself is too hard for any human being to od
<Odd_Bloke> Lo-lan-do: OK, you win. :p
<glyph> spiv: I am starting to think of experimentally developing a few Twisted or Divmod branches in bzr
<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
<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.
<glyph> spiv: It seems like the best way might just be to keep trunk in SVN, and push bzr branches elsewhere
<spiv> So you're risking messy conflicts, as I'm sure you can imagine.
<glyph> spiv: yes
<Lo-lan-do> glyph: I've documented a setup I have on http://mail.gnome.org/archives/f-spot-list/2008-January/msg00035.html
<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 :-)
<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...
<glyph> Lo-lan-do: *perfect*!
<glyph> OK now I'm getting too excited.
<spiv> Lo-lan-do: but I still want to fix that bug :)
<Lo-lan-do> spiv: I do, but only locally.
 * spiv reads
<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
<glyph> Squeeeeeeeee
<glyph> OK I guess I need to propose this on the mailing list
<Lo-lan-do> (I'm currently tracking 14 patches :-)
<glyph> Hmm
<glyph> The main reason I need to push to svn branches is to avoid disrupting our review process
<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 :)
<glyph> Lo-lan-do: let's say I do
<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
<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
<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
<luks> if you merge foo to trunk, instead of pushing foo to trunk, you will get only one
<Lo-lan-do> What luks said
<glyph> luks: Interesting
<glyph> luks: That is pretty much exactly what I want
<luks> bzr will still all of them, but svn only the merge
<luks> er, still see
<glyph> luks: "(08:02:51 AM) Lo-lan-do: Actually, the bzr "merge" operation does strange things.  I usually keep to pull and push."
<glyph> luks: That worries me though ;)
<Lo-lan-do> I think it does strange stuff when you merge from svn into bzr, then pull(or push) the result into svn.
<luks> Lo-lan-do: what kind of strange things?
<luks> I practically use bzr-svn only for merging svn branches, and it always worked fine for me
<Lo-lan-do> svn sees a series of commits based not on D but on C (from my earlier scheme)
<luks> if you merge, it sees only one commit
<luks> as it pushes only the mainline
<glyph> luks: is this documented somewhere?
<luks> not sure, but bzr-svn will push always only the mainline commits
<Lo-lan-do> Yeah, but if you merge from svn into bzr and then pull the result into svn again... you get surprises.
<luks> that is, the non-indented ones from bzr log
<luks> Lo-lan-do: pull into svn?
<luks> you mean push?
<Lo-lan-do> Whichever
<Lo-lan-do> (I pull into a branch bound to svn)
<luks> oh, I can see how that causes problems
<luks> because pull can change the mainline
<luks> but I personally wouldn't pull to a svn checkout
<bialix> hi guys
<bialix> I can't find 1.1 branch. Is it not public (yet)?
<glyph> luks: hmm
<luks> Lo-lan-do: push to the svn branch would complain about diverged branches
<glyph> luks: what if I'm working in a bzr branch, and I want to merge in the svn trunk?
<glyph> here's what I would think would not give me any surprises
<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
<luks> this should work without any surprises
<luks> oh, you might want to add 'bzr pull' before the merge, to avoid the need for rebasing
<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;
<glyph> hah, cool
<glyph> I *think* we said the exact same thing
<luks> you usually don't need the 'bzr merge ../trunk' step
<luks> unless you have a long lived branch and you want to sync it with trunk
<glyph> luks: that's exactly the case I'm thinking about
<Peng_> bialix: It may not be on Launchpad, but http://bazaar-vcs.org/bzr/bzr.1.1/
<luks> but either way, this should work fine
<luks> just don't do: cd trunk; bzr pull ../foo; bzr push svn+ssh://...
<luks> or the other way around: cd foo: bzr push --overwrite ../trunk
<glyph> luks: OK.  *That*, I definitely don't want to do :)
<glyph> luks: as I understand it, pulling and pushing generate multiple mainline revisions, which is exactly the case I don't want
<luks> yes
<glyph> luks: am I phrasing that properly?
<luks> I think it's better to think of it in terms of mirrors
<luks> bzr push/pull will mirror a branch
<spiv> glyph: "generate" is a misleading verb for that, I think
<licorna> hi
<glyph> I really need a version of bzr-gtk that works with 1.0 so I can visualize this :(
<spiv> glyph: the "new" revisions already exist in another branch, no new revisions are made.
<brilliantnut> glyph: bzr-gtk dos work with 1.0
<glyph> brilliantnut: Oh?
 * glyph looks at a webpage
<glyph> oh, so it does
<glyph> I guess I'm just waiting for debs then
<Lo-lan-do> They are in sid
<bialix> Peng_: thanks
<glyph> Lo-lan-do: I'm using gutsy
<glyph> (and and bazaar-vcs.org's gutsy repository, and jelmer's personal unstable repository)
<luks> https://launchpad.net/~bzr/+archive
<luks> it seems to have 0.93 for gutsy
<glyph> huh
<glyph> good to know
<glyph> luks: should I get rid of those other two repositories I just mentioned and go from PPA instead?
<jelmer> afaik the ppa is not actively maintained
<glyph> I guess I'll just download the one deb I want :)
<glyph> hmm
<glyph> man, I love gdebi
<glyph> the experience of clicking on a web page and getting an "install" button is just awesome
<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=
<licorna> ?
<licorna> just need a ftp server?
<LeoNerd> Indeed; anything that can host files in some way is sufficient.
<LeoNerd> sftp and http work well
<rjek> You can push to http?
<rjek> Actually, I meant to ask that: can bzr use HTTP PUT to push to http:// URLs?
<licorna> don't know. i'm new
<ubotu> New bug: #182849 in bzr "bzr bind to unknown host causes internal error" [Undecided,New] https://launchpad.net/bugs/182849
<licorna> how to use a non standard port in sftp (I'm using port 21 for firewall issues)
<licorna> ??
<licorna> I mean, bzr push sftp://...
<Lo-lan-do> Declare it in your .ssh/options file?
<Lo-lan-do> Or maybe sftp://foo:21/path
<licorna> Oh, you're right, thanks
<Odd_Bloke> licorna: For reference, which suggestion was correct?
<Lo-lan-do> Both, I suppose :-)
<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?
<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?
<ubotu> New bug: #182856 in bzr "Error 2 during merge resulting in many conflicts" [Undecided,New] https://launchpad.net/bugs/182856
<luks> arne^: tree.get_file_text(file_id)
<luks> and tree.path2id(path) to get the file_id
<wingo> congrats on 1.0 :)
<wingo> question.
<wingo> do by-reference nested branches work yet?
<jelmer> wingo: They're still an experimental feature
<jelmer> and will only work with the various -subtree formats
<wingo> ok
<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. :-/
<rjek> Oh, and the lack of ability to do what I want authentication-wise, but Kinni's looking into that for me :)
<luks> why is changing of the format bad?
<jelmer> maybe bzr should just do as some other vcs'es do and upgrade silently between on-disc like some other VCS' do :-)
<luks> *cough*git*cough*? :)
<rjek> luks: Because it's a ballache when you don't have a smart server to abstract the differences.
<arne^> luks: thx, but I'm having problems to get a tree which represents the correct revision ...
<luks> repository.revision_tree(revision_id)
<arne^> repository can be a local working copy?
<luks> no, tree.branch.repository
<luks> if 'tree' is a working tree
<arne^> ah, ok, I will try it. thank you
<ubotu> New bug: #182899 in bzr "reconcile must be run in a branch root" [Undecided,New] https://launchpad.net/bugs/182899
<arne^> luks: my code is working now, thanks for your help!
<luks> you're welcome :)
<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?
<ekimus> ok I just found the specs about KeywordExpansion, sadly "Implementation branch: none yet" - well I'll wait :)
<fullermd> ekimus: The current solution is using 'version-info' in your build script to stuff the version somewhere.
<fullermd> (or some similar mechanism; I do some sed'ery in one project to stick bits in a header file)
<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...
<fullermd> Of course, now that you've said that, there'll be a peasant uprising tomorrow demanding keywords.
 * brilliantnut wants keyword expansion
 * fullermd does too.  And a pony.
 * beuno points to Canonical's owned pony, Woody
<beuno> (yes, the secret is out)
<brilliantnut> Canonical has a pony?
<brilliantnut> which project?
<beuno> brilliantnut, they sponsor an actual pony
<fullermd> Sponsor?  What does it do, figure skate?
<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"
<fullermd> Come to think of it, I would *totally* pay to see a donkey do a double axel.
<beuno> lol, interesting, now we know where Canonical gets all that funding...   :p
<deepjoy> fullermd: or a monkey do bzr checkout http://en.wikipedia.org/wiki/Infinite_monkey_theorem
<beuno> "figure skating ponies"
<deepjoy> :-)
<beuno> btw, has anyone seen this: http://juliank.wordpress.com/2008/01/13/a-small-benchmark-bazaar-git-mercurial/
<beuno> bzr seems to loose on all tests
<beuno> which contradicts http://bazaar-vcs.org/Benchmarks/SpaceEfficiency
<luks> well, you know how benchmarks work
<fullermd> You pick up the computer, hold it at a carefully-chosen angle, let it fall, then measure the mark on the bench?
<brilliantnut> speaking of peasant uprisings, demanding stuff, rumour had it that 1.1 was about to be released today? *cough*poolie*cough*
<lamont> is it possible to edit the commit message on the most-recent commit?
<luks> bzr uncommit, bzr commit
<beuno> well, I just added a comment, but maybe someone a bit more knowledgable should contact the guy
<minghua> How to undo a merge?  I can revert all the files that are changed, but the "bzr status" still shows "pending merges".
<dato> bzr revert
<minghua> dato: Ah, that works.  I must did something stupid last time I tried.  Thanks!
<abentley> minghua: reverting specific files won't clear pending merges.  You should do "bzr revert" with no arguments to clear pending merges.
<minghua> abentley: Yes, dato gave the same (although less elaborated) answer.  And it works, thanks!
<abentley> minghua: I saw, I just wanted to make it really clear.
<mtaylor> statik: where was it you were saying did the save-commit-messages already?
<statik> mtaylor: qbzr
<mtaylor> statik: I looked in qbzr and didn't see it
<mtaylor> statik: I also didn't see a "save message and don't commit" button
<statik> mtaylor: save_message() in commit.py. There is no button, it just works if you hit cancel
<mtaylor> statik: ahhh
<mtaylor> statik: ok. that's what I was missing. thanks
<elmo> how fragile is bzr nested tree support right now?
<elmo> I know there's a subtree format, but it (or publicizing it) seems relatively controversial
<elmo> I don't care about performance, and I'm only dealing with local non-distributed branches
<mtaylor> elmo: I don't believe nested tree support is ready-for-prime-time yet
<elmo> mtaylor: may-eat-my-data not ready?
<lifeless> elmo: with larstiqs patch it might work
<mtaylor> elmo: not-even-pushed-into-trunk not ready
<elmo> bother
<lifeless> hi statik, guess what I'm going to ask you :)
<statik> lifeless: :) sorry, don't have it yet, but it's still on the top of my todo list staring at me
 * lifeless adds an i to it
<mtaylor> statik: ok, found the code. thanks
<jam> poolie: ping
<lifeless> jam: hi
<lifeless> jam: poolie is on some sort of call
<jam> lifeless: yeah, I'm supposed to be on it with him
<poolie> that's why he was pinging...
<jam> he wasn't there yet :)
<lifeless> poolie: lol
<elmo> LarstiQ: ping?
<LarstiQ> elmo: just-before-sleep pong
<elmo> LarstiQ: can-wait-till-tomorrow-then
<LarstiQ> elmo: well, I'll hang around for a couple more minutes
<LarstiQ> elmo: ah hmm
<LarstiQ> elmo: depends on how actively you want to exercise it
 * LarstiQ hasn't spent time on it for too long though
<elmo> LarstiQ: I'd just like to try it :)
<elmo> LarstiQ: is there an easy way to get a patch that I might slap onto bzr 1.0?
<elmo> or should I just suck it up and force your branch onto current bzr.dev?
<LarstiQ> elmo: I think there will be quite a lot of conflict resolving you'd have to do
<elmo> LarstiQ: either way?
<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.
<LarstiQ> ie, root/sub and root/sub/sub will give you problems.
<elmo> ok, that shouldn't be a problem
<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
<elmo> (if that'd be useful, if not, I'm happy to try just 1.0)
<LarstiQ> elmo: how early on would you want to do testing?
<elmo> LarstiQ: how do you mean?
<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.
<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
<LarstiQ> cool
<elmo> 'cos I can reset to last night's .bzr trivially enough
<LarstiQ> elmo: I'll certainly take you up on that then.
<elmo> LarstiQ: neato
<elmo> tgabjs
<elmo> err, thanks
 * LarstiQ goes to bed now 
<dato> 23:34 <elmo> LarstiQ: can-wait-till-tomorrow-then
<dato> 23:35 <LarstiQ> elmo: well, I'll hang around for a couple more minutes
<dato> 23:36 <LarstiQ> elmo: ah hmm
<dato> 23:36 <LarstiQ> elmo: depends on how actively you want to exercise it
<dato> I think my ctrlproxy lost a line there.
<elmo> dato: nah, larstiq just read scrollback to divine my intent
<elmo> dato: (we're talking about his nested trees++ branch)
<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'
<spiv> lifeless: that sounds fine to me
<lifeless> poolie: jam: when do you want this call
 * igc breakfast - bbiab
#bzr 2008-01-15
<lockheartmac> hello
<lockheartmac> im new to bzr, but can it be used for Flash or Photoshop files?
<rjek> Sure, but the diffs won't be very readable. :)
<rjek> I don't know how efficent it is at storing binary files, but it certainly can.
<lockheartmac> cool
<lockheartmac> do you know of something else that might be better for tose types of files?
<lifeless> bzr should be fine
<lifeless> I have heard of people versioning iso's in bzr
<lockheartmac> nice! im gonna give it a try, thanks!
<rjek> lifeless: Why are they versioning ISOs rather than the files and the scripts to create the ISO from them?
<lifeless> rjek: congenital insanity ?
<rjek> I see. :)
<Kinnison> night all
<lifeless> spiv: ping
<spiv> lifeless: pong
<lifeless> can I slip that patch in with the single large test ?
<spiv> lifeless: yes
<spiv> lifeless: sorry, I should have said so explicitly
<spiv> lifeless: I'd love to find a nice way to deal with that situation, because I have tests that would be improved too :)
<edencane> Hi. Ive updated a library file in the tree; did a bzr remove <oldfile>; bzr add <newfile>; then bzr commit;
<edencane> then bzr push;
<edencane> THe files are not in the tree though? Why would that be?
<edencane> anyone able to help?
<bob2> what method are you using to push?
<bob2> not all of them update the remote working tree
<edencane> just bzr push
<bob2> e.g. bzr+ssh, sftp, ...
<edencane> sftp
<bob2> I don't think sftp updates the tree (which seems reasonable, since it's not executing bzr on the other end)
<bob2> does "bzr up" in the remote tree make the files appear?
<edencane> how would I do that? bzr up sftp:<foo>?
<bob2> "ssh remotehost '(cd /to/remote/dir ; bzr up)"
<AfC> edencane: I think he meant ssh'ing to the machine in question and running `bzr update` in the branch
<edencane> hmmm
<AfC> (because I know that's what I do in the one external branch that I keep an up to date tree in)
<edencane> maybe... bzr push  seems to push the changes Ive made to local files
<lifeless> edencane: if you want the files to be visible there you need to run bzr at the far end; but other bzr users can pull from it already
<lifeless> edencane: .bzr is a database
<edencane> this is a replacement of a library...
<AfC> eg the difference between http://research.operationaldynamics.com/bzr/java-gnome/mainline/ and say http://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/missing/
<edencane> normally if I do a bzr add <file> or bzr remove <file> do I need to do bzr commit on <file> as well?
<AfC> lifeless: sometimes I wonder if push shouldn't have updated when run locally. Of course, that's the confusing badness that most other systems force their users to deal with, but we sure do run into people not understanding the "remote push usually can't update remote working tree" thing.
<bob2> edencane: yes, or just a commit of the whole tree
<AfC> ... but maybe it would have taught people the difference between push and update (and the fact that push locally _does_ an update). Perhaps we should make that more explicit locally?
<edencane> bob2: ohkay, I didnt do the bzr commit on both the old file (removed) and new file (added)
<spiv> edencane: until you "bzr commit", no changes you've made will be recorded in the branch.  "bzr add <file>" is a change, just like editing a versioned file.
<edencane> Ahhhh
<edencane> Okay...
<edencane> Thanks ever so much...
<bob2> edencane: if it's a new version of some file, you could just copy it over and commit the modification of the file rather than its' replacement
<AfC> edencane: [you threw us off when you said you'd committed]
<AfC> edencane: [as commit without args commits all pending changes]
<AfC> bob2: indeed. Far better to do that
<edencane> hmmmm I see your point, but in many cases I have a lot of crud files kicking around that I dont want to commit...
<TFKyle> edencane: if they're new files that you don't want to add just don't add them, for modifications to existing files possibly have a look at bzr shelve (part of bzrtools)
<edencane> bob2: it wasnt a new version, it was a replacement library like: somelib1.3.3 replaced with someLib2.0.7
<TFKyle> (well, shelve/unshelve)
<lifeless> AfC: thats a good idea; just a printline would help
<edencane> AfC: yea, I always commit specific files, sorry
<AfC> lifeless: you want a bug for that, or is that a "just do it"
<AfC> edencane: which would have been find had you committed all the files relevant to the change you were trying to capture
<poolie> hm something odd is happening trying to get the .sig file...
<lifeless> AfC: mail to the list
<poolie> hm. the incorrect mime types make firefox pretty unhappy....
<igc> ping spiv
<igc> spiv: on a typical project, what sort of performance gain do you expect using the smart server vs plain http?
<lifeless> igc: you'll need to benchmark it ;)
<lifeless> igc: its probably marginally faster than sftp for packs today
<igc> my benchmarks overnight are showing plain http is now quite quick with packs
<igc> whereas bzr+ssh is a fair bit slower
<lifeless> good
<lifeless> ;)
<igc> lifeless: downloading 33 projects on a LAN over plain http is 708 seconds
<AfC> bzr:// use the same packs (and realizes the same efficiencies) as http://, right?
<igc> lifeless: using bzr+ssh, it's taking 1908 secs
<igc> so I'm wondering whether I'm doing something wrong :-)
<TFKyle> igc: what version of openssh are you using?
<lifeless> AfC: not quite; but due to bugs not design
<lifeless> TFKyle: its not that
<TFKyle> (probably not that, but you never know)
<igc> whatever version comes with gutsy :-)
<lifeless> igc: you are using bzr.dev on this end and 1.0 on the other
<lifeless> igc: or something similar
<igc> yep
<AfC> lifeless: oh. That's discouraging
<lifeless> igc: so you are not getting a streaming pull, you are falling back to VFS, and the bzr VFS does not do readv expansion so the index reads will be bisecting in 200 byte ranges, rather than 64K ones
<igc> the remote machine is running bzr 1.0 on Leopard
<lifeless> AfC: they are being fixed right now
<igc> the local machine is bzr.dev on gutsy
<lifeless> igc: yes, this fits my prediction
<lifeless> igc: for benchmarks always have the server be a >= bzr than the client
<AfC> lifeless: sweet [We invested considerable effort circa 0.91 to get the server running and to get everyone converted to bzr:// URLs, so I was hoping that all that hadn't been deprecated]
<lifeless> AfC: heck no
<lifeless> AfC: just teething problems between VFS changes and smart server changes not lining up quite right
<igc> lifeless: fwiw, we whip hg now on plain http serving: 708 secs vs 2200 secs
<lifeless> what latency are you benching with?
<lifeless> ratchet it up to 150ms or so
<AfC> lifeless: (I came across this question more as an offshoot when I was researching what would be involved in switching people to packs)
<igc> it's a 100Mb LAN
<AfC> igc: that's excellent news.
<igc> lifeless: I'm looking at netem today
<AfC> igc: (we should publish that somewhere)
<lifeless> AfC: if you have a server version that is >= your bzr client version you'll get a streaming pull which should be faster than packs; or at least close to
<lifeless> we're working on making it faster
<igc> AfC: it's nice to know. The smart server comparison is more meaningful though I suspect
<AfC> igc: yeah
<AfC> igc: they did after all go there from the very beginning.
<AfC> lifeless: [both are 1.0 atm]
<igc> and configuring Hg is more painful than I expected so my main focus is our benchmarks, not theirs
<AfC> sure
<AfC> "configuring Hg is more painful" ... that's the sort of critique that while subjective nevertheless resonates widely. I would encourage you to put that into a blog post with some details.
<AfC> (which people like me could link to)
<igc> AfC: coming from someone that works at Canonical, people expect me to say that
<igc> AfC: better if you blog that I think :-)
<AfC> igc: I didn't do the tests, I didn't have the experience. You did. You're the one that found hg cumbersome to use. I'd be interesting in hearing why (and why you think bzr takes a better approach to $whatever). You are more than eminently qualified to report on such things
<igc> AfC: in the end, I gave up trying to find out how to push over sftp with Hg, particularly initial push
<AfC> And more to the point, if you guys don't blow your own horn, no one else will.
<igc> so I went with scp to just get the files pushed across
 * AfC laments that he has several tens of draft blog posts of this sort of critique/experience across many projects that he hasn't quite gotten around to tying together into a cohesive point yet
<igc> it really is sweet how Bazaar doesn't require anything on the server bar ssh access
<AfC> CafÃ©
<lifeless> igc: hg wants a smart server always unless you do speciall stuff
<igc> lifeless: yeah - it's really annoying
<lifeless> poolie: jam: ping?
<poolie> ready when you are
<jam> hi lifeless, poolie  are we doing a conference call?
<lifeless> conf centre?
<jam> sure, dialing now
<jam> waiting for the "leader"
<lifeless> standing by
<jam> poolie: you coming?
<poolie> sure
 * igc lunch
<fullermd> lifeless: How much of that streaming SS capability is making 1.1?
<lifeless> fullermd: none
<fullermd> Oh.  Well, that makes it easy to quantify   :)
<abentley> jelmer: ping
<abentley> Or anyone-who-groks-pygtk: ping
<spiv> jamesh: I hear you know a little about pygtk ;)
<jamesh> I've heard that rumour too
<abentley> jamesh: I'm using a VBox to add a toolbar to a diff window, and I'm getting some strange sizing issues.
<abentley> It seems like pack_start isn't honoring the expand parameter.
<abentley> I do self.vbox.pack_start(scrollwin, expand=True, fill=True)
<abentley>         self.vbox.pack_start(merge_button, expand=False, fill=False)
<abentley> And the button and the scrollwin take equal amounts of space.
<jamesh> that should make scrollwin take any space above the requested minimum
<jamesh> what's the vbox packed inside of?
<abentley> That's what I thought, but it's not what I'm seeing.
<jamesh> (i.e. what is its sizing policy?)
<abentley> The vbox is in a subclass of Window.  That subclass has set_default_size invoked to set it to 66% of screen width, 66% of screen height.
<jamesh> is the code available somewhere?
<abentley> I'll put it up.
<abentley> Also strange is that the fill parameter has an effect even when expand=False.
<jamesh> well, fill would generally affect only the horizontal space used by the child in a vbox
<abentley> Okay, it's up at http://code.aaronbentley.com/bzr/bzrrepo/bzr-gtk-meld
<abentley> Right, but the docs say it has no effect when expand=False.
<jamesh> that doesn't sound correct
<abentley> Or do I have it backwards?
<poolie> spiv, i guess i'm not coming up today...
<abentley> "The fill argument to the pack methods control whether the extra space is allocated to the objects themselves (True), or as extra padding in the box around these objects (False). It only has an effect if the expand argument is also True."
<abentley> The branch I put up is bzr-gtk.
<lifeless> whee that was a call
<jamesh> abentley: http://developer.gnome.org/doc/GGAD/sec-containers.html <- it's a bit old, but it is a good description of box packing
<jamesh> abentley: if expand=False for a child of a vbox, it won't be allocated any more height than it requested
<jamesh> abentley: but the width of the vbox may be wider than what the child requested -- the fill setting comes into play here
<abentley> jamesh: That's what I would expect.
<abentley> jamesh: What I am seeing is that the button is always full-width.
<jamesh> found it:
<jamesh>         self.vbox = gtk.VBox(True)
<spiv> poolie: not a problem
<jamesh> you've created a homogeneous vbox, where each child is allocated equal size
<jamesh> change that to self.vbox = gtk.VBox() and you should be set
<abentley> Thanks.
<abentley> I must have copied-and-pasted without realizing I was breaking myself.
<abentley> I confirm that fixes it.
<lifeless> this carpet install is driving me bats
<abentley> My mind is sufficiently warped that I wondered whether that was a derogatory term for apt-get dist-upgrade.
<abentley> Installation as carpet-bombing
<lifeless> lol
<lifeless> no the apartment above is being renovated
<lifeless> bastards
<lifeless> next week would have been fine
<bob2> for you!
<spiv> lifeless: any ideas on how to test the socket connection error handling?
<spiv> lifeless: the obvious thing is to just try connecting to "bzr://unknown.local/" or something.
<spiv> lifeless: But I fear sufficiently badly configured systems will manage to resolve it, leading to spurious test failures...
<spiv> lifeless: I suppose I coudl write Feature that checks that some impossible host name really does fail to resolve...
<fullermd> It's not spurious.  It points to a real problem   ;)
<spiv> fullermd: it's a real problem, but not the one the test is trying to catch :P
<spiv> fullermd: I think probably the user in that case would be better served by a "missing feature" message telling them not to have crazy wildcard resolvers
<fullermd> Well, it's not like you're often going to get random people running selftest and watching their system nail itself to the wall for 45 minutes...   selftest is mostly a dev tool.
<fullermd> I'd use "nonexistent.invalid" or something like that, since .invalid is spec'd to not exist.
<spiv> Hmm, I think a Feature is probably right for it.
<dysinger> Hey
<spiv> Given that it's a property of the environment running the tests that is needed to run a particular test.
<dysinger> Congrats on the 1.1
<spiv> But it's also something that doesn't make bzr itself behave incorrectly.
<fullermd> Reasonable enough, I s'pose.
<fullermd> Just my Long-Suffering Sysadmin hat makes me want to inflict immediate pain on people with b0rked setups   :p
<spiv> fullermd: thanks for the "nonexistent.invalid" suggestion.
<jamesh> spiv: you could try something under example.com
<spiv> jamesh: is that likely to be any better than something under .invalid?
<fullermd> Well, ICANN _could_ make hosts under example.com.  The .invalid TLD is specifically for nonexistence.
<jamesh> fullermd: ... and so is available for local host names
<spiv> http://www.rfc-editor.org/rfc/rfc2606.txt seems to suggest that .invalid is a better fit than .example or example.com
<jamesh> the machines on my local network have .henstridge.invalid hostnames
<lifeless> lol, rather than .local ?
<jamesh> lifeless: the ones with zeroconf setup also have .local names asserted via mDNS
<lifeless> I think fullermd is right
<lifeless> a feature that depends on an unresolvable hostname
<fullermd> Surely you can't be implying that there are people in the world who don't own their own vanity domain already?   ;)
<jamesh> spiv: you could also try picking a syntactically invalid domain name, I guess
<jamesh> e.g. one with underscores
<spiv> jamesh: I could even do both!
<fullermd> An implementation could conceptually throw a different error for that...
<dysinger> so does anyone have bzr-svn working on the mac ?
<jamesh> spiv: http://www.rfc-editor.org/rfc/rfc2606.txt <- that's the relevant RFC
<dysinger> I couldn't get it to work on leopard
<spiv> jamesh: I know, I gave that link 6 minutes ago ;)
<jamesh> garr
<spiv> lifeless: thanks
 * spiv writes the test + feature
<jamesh> hah.  Microsoft has a knowledge base article stating "Make sure if you choose not to register a name that you choose a name that is unique. You can review existing names at http://www.networksolutions.com (http://www.networksolutions.com)."
<jamesh> maybe you could do the same for your test, and pick a .com that is not currently registered
<fullermd> Well, if we're going that way, we could just set up invalid.bazaar-vcs.org.
<fullermd> (well, or not set up, depending on your semantics ;)
<jamesh> then we could monitor who is running the Bazaar test suite by tracking nameserver logs
<fullermd> Going to .invalid should finish in just a query to the roots, though.  Elsewhere might take several steps, wasting a bit of time and a bit more load on various servers along the way.
<fullermd> Oh, well, you want monitoring, then you want ${bzrlib_vesion}.invalid.b-v.o.
<jamesh> or ${username}.${bzrlib_version}.invalid.b-v.o
<fullermd> % bzr selftest
<fullermd> Please enter your credit card number: _
<spiv> lifeless: http://rafb.net/p/svj9Hw22.html
<dysinger> So this no-way-to-import-svn and no-way-to-work-on-top of svn is keeping me on Git.  I sure wish there was a way to get it working on OS X Leopard.  It probably works fine with Tiger (becasue SVN & svn-python doesn't come pre-installed)
<spiv> lifeless: does that test + feature look ok?
<spiv> lifeless: should I move the feature to bzrlib/tests/__init__.py?
<spiv> fullermd: it could be "Please enter your licence key: _" ;)
<keir> i want to have a make (ok, scons) rule which bakes the bzr version into a header file, so that gets baked into every binary. is there a 'best practice' way to do this with bzr?
<spiv> keir: how about "bzr revision-info"?
<lifeless> I think the feature is fine in place
<keir> spiv, great, thanks.
<bob2> should that command be hidden?
<keir> spiv, hmm; i want to also reflect if there are local changes. something like revision-info with '+local mods'
<lifeless> spiv: +1
<dysinger> ok thanks for the help.  Talk to you later.
<spiv> lifeless: thanks!
<lifeless> keir: also, consider bzr version-info
<lifeless> keir: which is more comprehensive, can output C etc etc
<keir> ah, cool; almost perfect
<keir> --clean requires no unknown files?
* spiv changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.1 is out! woo! | http://bazaar-vcs.org/releases/src/bzr-1.1.tar.gz
<keir> wow, 1.1! congrats
 * spiv figures if the website announces it, the IRC topic might as well announce it too :)
 * fullermd blinks.
<fullermd> Did I miss an announcement?
<spiv> fullermd: I haven't seen an email yet, but the website has been linking to it for a couple of hours now
<AfC> Gentoo rev bump filed.
<ubotu> New bug: #183079 in bzr "added fails when not run in tree root" [Undecided,New] https://launchpad.net/bugs/183079
<fullermd> FreeBSD port update, ditto.
<poolie> thanks
<poolie> i did send an announcement mail
<poolie> might be held?
 * igc dinner
<matkor> Hi ! How to perform such task. How to uncommit changes to one given file back to given revision ?
<matkor> I during commit I commited mostly valid changes except one file, later a did a lot of commits, now I would like to revert changes introduced by that old commit but only intoruduced to one specific file ?
<matkor> I short, hot to say in bzr: bzr want-now-that-file-as-it-was-than <filename> -r <revno> ?
<fullermd> bzr revert -rwhatever $FILE
<lifeless> spiv: ping
<lifeless> a = [('call_expecting_body',
<lifeless>   'Repository.get_parent_map',
<lifeless>   ('///quack/', '\xe0\xb6\xab'))]
<lifeless> b = [('call_expecting_body',
<lifeless>   'Repository.get_parent_map',
<lifeless>   ('quack/', '\xe0\xb6\xab'))]
<lifeless> after your most recent commit to bzr.dev.
<lifeless> (you reviewed myy patch with this test in it; is it sane to replace /// with '' in my test and thats all ?
<matkor> fullermd: Yah. So simple ... Thank you very much.  As far bzr has highest question to answer size ratio for me ;)
<Peng> Omgyay! The bzr+http path issue really was fixed!
 * Peng hugs spiv.
<Peng> Hm, now that the pack format exists, I guess it's not so useful..
<Peng> I do still have one project in dirstate though.
<AfC> bzr 1.1 now in Gentoo
<Peng> Hmmm.
<Peng> What the heck? .bzr/smart for one branch gives a 404.
<Peng> It works fine for every other one.
<Peng> .htaccess issue. Apparently "RewriteEngine on" in a child .htaccess negates rewrites in parents?
<Peng> Or any mod_rewrite stuff at all, I guess.
<Peng> RewriteOptions inherit. Okies.
<Peng> I know, it was never on-topic, but I'm afraid of #apache and wanted somewhere to think out loud. :P
<spiv> lifeless: right
<Peng> spiv: You rock!
<spiv> Peng: it's not totally fixed yet
<Peng> What's still wrong?
<spiv> Peng: but the client part of it was a pretty big part.
<Peng> It's fixed enough that it works for me.
<spiv> Peng: http://bundlebuggy.aaronbentley.com/request/%3C20071214015112.GC14963@steerpike.home.puzzling.org%3E
<spiv> Peng: yeah
<spiv> Peng: that's the main thing :)
 * Peng watches hundreds of POSTs scroll by during a "bzr branch".
<Peng> All the recent ones are for 680-690 bytes.
<Peng> Oh, good, two 60 KB ones were thrown in.
<fullermd> I can just see the paper...  "bzr smart requests as a PMTU discovery tool"
<spiv> Peng: yeah, the readv stuff with the smart protocol isn't particular, um, smart for some reason.
<Peng> So I've noticed.
<Peng> Oh, good, it finished in 8m36.343s.
<Peng> Dumb http only took 1m14.493s.
<spiv> Yeah, that's mainly the readv borkage I belive.
<spiv> Especially now that lifeless has starting improving the remote graph stuff.
<Peng> The remote graph stuff is making it better or worse?
<spiv> Better.
<Peng> Oh, good.
<Peng> That's a client-side thing?
<spiv> Both.
<spiv> New smart verbs to more efficiently fetch graph info to find graph differences.
<Peng> Ok.
<spiv> If you have the latest bzr.dev on both ends you shouldn't get much readv borkage, I think.
<spiv> (because it'll get the info it needs using other methods, rather than because readv has been fixed in bzr.dev)
<Peng> I do have the latest bzr.dev on both ends.
<spiv> Oh.  Hmm.
<Peng> And it took 450 mostly-sub-KB requests to make a branch of a smallish project of 150 revisions.
<spiv> Ah well, more to do then :)
<Peng> (pytz).
<spiv> Peng: those requests were readv, I presume?
 * spiv is just double-checking
<Peng> Using FastCGI definitely speeds it up.
<Peng> spiv: I dunno. They read a few hundred bytes.
<Peng> I ran locally with lots of -D options so I can probably figure it out.
<spiv> -Dhpss should give you plenty of info
<Peng> I used -Dhpss -Dhttp.
<Peng> It appears to have recorded the full request and response headers of every request.
<Peng> You want to sort through it? :D
<spiv> Heh.
<spiv> Just -Dhpss is probably a better bet in this case :)
<Peng> Yeah. I did both because I was testing both http and bzr+http and wanted to use the same args for both of them.
 * spiv nods
 * Peng wonders how much the debug data contributed to those times.
<spiv> Peng: probably a bit  :)
<Peng> http on a dirstate branch took 392 requests. bzr+http took 422.
<spiv> Peng: what took up the bulk of the bzr+http requests?  Was this a push or pull?
<Peng> spiv: "bzr branch".
<Peng> http://bzr.mattnordhoff.com/bzr/pytz/pytz-current/ , FWIW.
<spiv> Ta
<fullermd> Every time I look at the bzr+http setup, I get skeered   :|
<spiv> Peng: you don't seem to have the most recent bzr.dev on the server
<Peng> Eeerrrr.
<spiv> Peng: if you did, you'd see the number of requests drop dramatically
<Peng> You know what?
<Peng> bzr.dev isn't in my PYTHONPATH.
<Peng> That's 1.1.
<spiv> Right :)
<Peng> I knew that would bite me eventually.
<spiv> Peng: The "   result:    0.666s  'error', "Generic bzr smart protocol error: bad request 'Repository.stream_revisions_chunked'"
<spiv> "
<spiv> gave it away
<Peng> Humm.
<spiv> That verb is in bzr.dev, but not 1.1
<Peng> How do you think I should solve this?
<spiv> Apache?
<Peng> Add the path to bzr.dev to sys.path? "setup.py install" bzr.dev and remember to rerun it every time I update?
<spiv> Peng: you're using FastCGI, IIRC?
<Peng> spiv: Yessir.
<spiv> Peng: you could put some sys.path hackery in the little glue script.
<Peng> That's what I was thinking.
<Peng> Will do.
<spiv> Or build nightly debs of bzr.dev for us ;)
<fullermd> I s'pose someday I should apply some of my CFT to seeing if it's setupable...
<spiv> fullermd: wait till bug 129089 is fully fixed first
<ubotu> Launchpad bug 129089 in gnome-system-tools "Modified user not listed" [Low,Invalid] https://launchpad.net/bugs/129089
<spiv> Er
<spiv> 124089
<spiv> Ahem, bug 124089
<ubotu> Launchpad bug 124089 in bzr "wsgi smart server chrooting does not manage additional paths" [High,In progress] https://launchpad.net/bugs/124089
<spiv> Thanks ubotu
 * spiv wishes IRC bots were telepathic
<dato> just live long enough ;)
<Peng> Ok, fixed.
<fullermd> Well, it just seems like it would be painful to do well enough.  Glancing over the doc, it's full of hardcoded paths.
<Peng> spiv: How do I check if it's using bzr.dev?
<fullermd> I don't think that bug would change that...
<spiv> Peng: judging by my -Dhpss output, it is :)
<spiv> Peng: also,
<spiv> andrew@steerpike:/tmp$ time bzr -Dhpss branch bzr+http://bzr.mattnordhoff.com/bzr/pytz/pytz-current/
<spiv> Branched 151 revision(s).
<spiv> real    0m39.611s
<Peng> Lucky low-latency/high-speed Internet connection bastard.
<spiv> I'm in .au
<Peng> Wait, it took 27 seconds for me.
<spiv> I don't think the latency is low :)
<Peng> 27 seconds is awesome.
<spiv> I think it's the new smart verbs doing what they're supposed to do :)
<fullermd> Branched 151 revision(s).
<fullermd> 2.262u 0.571s 0:21.20 13.3%     113+146k 0+0io 0pf+0w
<fullermd> Looks like ~93ms latency from here.
<Peng> Blahg, 2 or 3 of us did things at once. Now I can't mentally parse my access.log.
<spiv> Heh.
<dato> bzr: ERROR: Not a branch: "bzr+http://bzr.mattnordhoff.com/bzr/pytz/pytz-current/".
<spiv> Peng: FWIW, I'm done hitting your branch
<spiv> dato: Are you using bzr.dev?
<fullermd> Of course, .bzr/ has less than a meg and a half in it.  I should be able to move that much data in about 3 seconds   :p
<spiv> dato: I think you probably need a fix that landed earlier today.
<dato> spiv: ah, I didn't pull today
<spiv> fullermd: yeah, there's still a heap of unnecessary roundtrips in there
<dato> spiv: btw, do you plan to make http (as opposed to bzr+http) look if there's a smart server available?
<dato> or is that done already?
<spiv> dato: I think that would probably be nice
<spiv> dato: Although I'm a bit scared to do that until bzr+http is a little more mature.
<dato> spiv: yeah, "at some point in the future"
<spiv> Right.
<dato> ok
<fullermd> Would it be a fair bet that we couldn't really dump some of those absolute paths in the config until we could turn off VFS methods altogether in the SS?
<Peng> What about making bzr+http fall back to http?
<fullermd> Or maybe there's some way to get Apache to pass down paths for the chrooting?  Seems like it would dig deep into FCGI messes real quick, though   :|
<Peng> FWIW, I put up a copy of that branch in packs at http://bzr.mattnordhoff.com/bzr/pytz/pytz-current.packs/
<Peng> Took 13.7 seconds to branch.
<Peng> That is, over http.
<Peng> 22 over bzr+http.
<Peng> Fewer requests over http too.
<spiv> Peng: yeah, there's still plenty of dumb things to fix in the smart server.
<Peng> Those times count building the working tree too.
 * spiv nods
<Peng> So bzr+http is a huge win for dirstate with bzr.dev, but not so much for packs.
 * Peng notices that the developer of the project is using dirstate while I am using dirstate-tags.
<Peng> Um, did any of you poke my site from t-ipconnect.de, or do I have a bot on my hands?
<fullermd> I'm a long way from anything .de...
 * dato too
<spiv> Not me.
<Peng> Also, the user-agent was "CFNetwork/220", some library or something.
<Peng> Huh.
<Peng> How can I switch a branch from dirstate-tags to dirstate?
<dato> Peng: b init --dirstate foo; cd foo; b pull /path/to/dirstate-tags
<spiv> Peng: http://rafb.net/p/LS6bB821.html may make bzr+http with packs faster
<Peng> Hm, what would Launchpad think if I did that?
<spiv> Peng: launchpad will cope just fine
<Peng> Will it change the format of the mirrored branch
<Peng> ?
<spiv> Yep.
<Peng> Ok.
<fullermd> Are you sure you need to, though?
<Peng> Of course I don't need to.
<fullermd> I mean, they won't be able to get your tags, but the repo format is still the same and all, so...
<Peng> I don't use any tags.
<Peng> Upstream uses dirstate and I want to use the same format.
<fullermd> And going down to branch5 means your locations.conf gets all polluted again.
<Peng> It's just the remote branch. Locally I use packs.
<spiv> Peng: FWIW, with that patch, time to branch pytz-current.packs with bzr+http drops to 29.7s from 38.3s.
<spiv> Peng: (vs 15.2s for plain http)
 * fullermd is very glad to see all the SS work lately.
<spiv> Me too!
<spiv> :)
<Peng> spiv: Send the patch in, then? :)
<fullermd> Yeah, we'll alibi you   ;)
<fullermd> "No sir, he couldn't have sent anything to PQM.  He was sitting with us waiting for the smart server to finish branching a pack repo, see..."
<spiv> Peng: I am :)
<Peng> Cool.
<Peng> Well, this has been a fun and bandwidth-wasting night. :)
<spiv> Peng: thanks for the feedback!
<dato> Peng: oh, I thought you were in Europe?
<Peng> dato: No, I'm just a bat.
<fullermd> If you can hear this, you're a bat:
<poolie> night...
<lifeless> spiv: is the client path change compatible with older servers?
<ubotu> New bug: #183156 in bzr "bzr branch uses too much RAM when not using a shared repository" [Undecided,New] https://launchpad.net/bugs/183156
<fullermd> Well, I've pushed over bzr+ssh to a 1.0 server once or twice since I pulled down the change...
<beuno> anyone know where I can get a bzr 1.0 .deb for feisty?
<beuno> http://rafb.net/p/yPNFTT74.html
<beuno> hmmmm, I'm having a recurring problem with a packs repository, anyone know why this might be happening:  http://rafb.net/p/yPNFTT74.html
<luks> https://launchpad.net/~bzr/+archive
<beuno> luks, thanks!  (that should be added on the /Downloads page, shouldn't it?
<luks> I don't know, for some reason everybody keeps talking how unofficial PPA is, but it's the only place with actually updated packages
<beuno> alright, let's take this to the mailing list then
<mdz_> I need to create some diagrams to explain how a set of branches are arranged.  Can anyone offer advice regarding suitable tools?
<Kinnison> inkscape?
<beuno> mdz_, related branches?   bzr-gtk has a neat tool, "visualize"
<Kinnison> inkscape can do 'attachment' lines
<Kinnison> otherwise I'd suggest something like visio
<Kinnison> I think OO's draw thingy can do flowchart type stuff too
<mdz_> these happen to be branches I haven't created yet, so I was thinking diagramming tools, but I suppose I could create them and try "visualize"
<mdz_> what does the output look like?
<Kinnison> of visualise?
<mdz_> yes
<luks> I think bzrtools has something to produce a graphviz sources?
<Kinnison> http://users.pepperfish.net/dsilvers/vis-example.png
<mdz> thanks
<mdz> I think bzr visualize would do what I want
<mdz> I can just set up some dummy branches and do it that way
<mdz> thanks
<Kinnison> no problem
<beuno> mdz, the branches have to be related, make sure you explicitly branch from each other and merge back into the parent so you get that kind of output
<beuno> (eg. don't "cp" the repositories)
 * Kinnison ponders screenshotting the bit of aranha's history where unrelated branches are merged together :-)
<mdz> beuno: will do, thanks
<jdahlin> How can I set the default branch bzr push will use if I don't provide a branch argument?
<Kinnison> jdahlin: pardon?
<mtaylor> hey guys... in cmd_commit(), there's a bit near the end where it calls tree.commit()
<beuno> jdahlin, you can do an empty push with --remember
<mtaylor> but I can't seem to find the definition of the commit method that takes a callback object as a param
<jdahlin> beuno, excellent, thanks!
<beuno> :D
<mdz> will bzr visualize show tags?
<jelmer> mdz: it will show them once you've selected a revision
<jelmer> mdz: it doesn't put them in the tree view yet
<mdz> oh
<jelmer> and there'
<jelmer> s a menu item for going to a specific tag
<rjek> Today's questions: 1) Can you export a SVG or similar from bzr vis?  2) Can bzr use HTTP PUT to push to http:// URLs?  3) Is there a C interface to bzr such that you can drive it from C or another language that can bind to C?
<mdz> jelmer: would be great to see them in the tree view, but I can fake it for my purposes
<beuno> rjek, you *can* use http to push AFAIK, but I know it's not recommended (not ideal way to transport that amount of data)
<rjek> Why is it not ideal?
<rjek> I'm beginning to get bored with having asymetrical respository access URLs.
<beuno> rjek, I'm not that familiar with it, but I think it's just not what it's built for
<Kinnison> it'd be fine if bzr smart server over http worked sanely
<beuno> rjek, why not use sftp/ssh instead?
<rjek> beuno: Because they don't allow for public access to a subset of my branches.
<beuno> rjek, and how does http solve that?
 * rjek idly wonders for a moment if HTTP PUT supports byte ranges.
<rjek> beuno: Err, it trivially provides unauthenticated access to a subset of my branches for reading.
<rjek> Where sftp and ssh cannot possibly
<mtaylor> rjek: yeah - but you can push using ssh to a location that people can HTTP get from to branch
<rjek> mtaylor: That's what I'm doing at the moment.
<rjek> (well, read via HTTP, write via sftp)
<beuno> rjek, well, anonymous read-only sftp could work, couldn't it?
<rjek> beuno: Not that I know of, given sftp is based on top of ssh.
<fullermd> Well, of course it _could_.  But it's not trivial.
<beuno> and plain old ftp?
<beuno> you can give read/write access to different users trivially
<rjek> That'd involve me wanting to use ftp. :)
 * fullermd takes FTP out back behind the woodshed.
<mtaylor> fullermd: do you happen to know what the status is of adding a commit hook to inject or modify commit messages?
<rjek> I suppose the issue will be solved when the smart server works.
<mtaylor> fullermd: I see a TODO in the source...
<fullermd> Not really, though I don't recall anybody mentioning working on or thinking heavily about it.
<mtaylor> ok... so if I did some hacking on it, I wouldn't be stepping on anyone's toes that you know of?
<fullermd> Wouldn't expect so.
<jdahlin> Is there support for something like svn:externals in bzr?
<Peng> Not yet.
<jdahlin> When is it planned to be included?
<Peng> In the fyooture.
<Peng> I dunno.
<mw> when was 1.1 released?  i don't see the announcement on the mialing list
<jdahlin> today, it seems
<mw> yeah
<mw> maybe mail's just taking a while to come through
<mw> it wouldn't be the first time :)
<Peng> Yeah, I've seen it on the list.
<Peng> The announce list, at least.
<ubotu> New bug: #183244 in bzr "push aftp crash,  socket.error: (10054," [Undecided,New] https://launchpad.net/bugs/183244
<vagrantc> is there a way to add the --append-revisions-only flag to a branch after it's been created ?
<vagrantc> and is there a way to set it globally ?
<vagrantc> i tried adding "append_revisions_only = True" to ~/.bazaar/bazaar.conf, but that didn't seem to work
<dato> for the former, add it to foo/.bzr/branch/branch.cof
<dato> branch.conf
<vagrantc> dato: is there a way to add it to a remote branch using bzr itself? or do i need shell access to do so?
<fullermd> There's no way to do it via bzr, no.
<vagrantc> gah.
<fullermd> You don't necessarily need shell access; you can just copy down the file, edit it, and copy back up, using sftp or however you're pushing.
<vagrantc> pusshing using bzr+ssh
<fullermd> Well, so you probably have sftp and scp available.
 * vagrantc is trying to work with branches on launchpad
<fullermd> Launchpad supports sftp.
<Peng> In Soviet Launchpad, branches work with you.
<Peng> I'm sorry.
<vagrantc> supports it, but do i have any idea where any of the branches paths are?
<fullermd> Well, if you're pushing to them, I should hope so   :)
<vagrantc> well, it wasn't clear to me that the http/bzr+ssh/sftp URLs were basically the same paths
<fullermd> AFAIK, the sftp and bzr+ssh paths are exactly the same, just with the different protocol specifier.
<vagrantc> thanks for help regarding append_revisions_only
<vagrantc> so there's no global way to make this the default for a given user?
<hendrixski> :-( I'm having some trouble pulling from an svn repository... I have bzr-svn installed... and I've tried a few things in the ~/.bazaar/subversion.conf file... though I'm not sure it's the right thing
<hendrixski> It keeps saying that it's not a valid subversion branching scheme... I'm totally lost
<hendrixski> oh... heh, I just deleted the damn file and it seems to have worked
<abentley> vagrantc: Sounds like a bug to me.  I certainly intended it to work in bazaar.conf and locations.conf
<vagrantc> abentley: i'll test it a little more just to make sure, then. i'm using 1.0-1~bpo40+1 from backports.org on debian etch
<abentley> Make sure you're using a branch format that supports it.
<vagrantc> ah.
<abentley> dirstate-tags and later support it.
<abentley> dirstate and knit do not.
<vagrantc> cat .bzr/branch-format
<vagrantc> Bazaar-NG meta directory, format 1
<vagrantc>  ?
<vagrantc> bzr info seems to think it's dirstate-tags
<dato> cat .bzr/branch/format fwiw
<vagrantc> cat .bzr/branch/format
<vagrantc> Bazaar Branch Format 6 (bzr 0.15)
<dato> right, dirstate-tags
<vagrantc> it's a little hard to keep up with all the branch formats
<Odd_Bloke> Wow, I'm just updating bzr.dev with packs and knits, and the difference is astounding.
<Odd_Bloke> Until now I'd never really seen them side-by-side.
<hendrixski_> GGGGRRRRRRRRRRRrr
<hendrixski_> ok, this really sucks.  I've been trying to get a branch from an svn repo
<hendrixski_> I've pulled off of there before
<hendrixski_> svn.asdf.org/svn/branches/release-##/directory   and the error message is "not a branch: trunk/asdf"  EVEN THOUGH NOWHERE in there am I trying to get anything from trunk, I'm trying to pull from tags
<hendrixski_> what the hell is going on?  Where is it getting the "trunk" b.s. from????
<lifeless> hendrixski_: have you changed bzr versions on the way?
<lifeless> hendrixski_: was the branch copied from trunk?
<lifeless> Odd_Bloke: we do try to improve things :)
<hendrixski_> lifeless,  nope... it's still version .90
<hendrixski_> and I cleaned out ~/.bazaar/subversion.conf, so it shouldn't be looking for trunk anywhere in there
<hendrixski_> this is infuriating
<Odd_Bloke> hendrixski_: Nothing funky rewrite-wise happening on the server?
<radix> hendrixski_: This is just speculation, but maybe it needs to read trunk if the branch has ancestry there. Not that I know anything about bzr-svn.
<hendrixski_> Sooo. the tags on svn used to at one point have been called trunk/ and that's screwing up bzr-svn from reading it????
<Odd_Bloke> jelmer might save us.
<Odd_Bloke> (SUBTLE PING)
<poolie> spiv, did you fix, or have a fix in progress, for bug 82634?
<ubotu> Launchpad bug 82634 in bzr "smart server gives traceback on connection errors" [High,Confirmed] https://launchpad.net/bugs/82634
<poolie> otherwise i might tackle it today
<jelmer> Odd_Bloke: hi
<jelmer> hendrixski_: tags was at one point named trunk?
<fullermd> Man, what a great technique.  You sacrifice a goat on the proper altar, and jelmer appears.
<jelmer> fullermd: I know sir, I should spend less time on IRC... :-P
<hendrixski_> jelmer, I have no idea.  I'm asking if I understood the problem correctly.  That before it became tags, it was at one point trunk.  Is that where this "trunk" thing is coming from?
<jelmer> hendrixski_: Yes, I think so.
<jelmer> hendrixski_: is this repository public?
<hendrixski_> jelmer, yeah.... lemme copy and paste that link
<hendrixski_> http://svn.mythtv.org/svn/branches/release-0-20-fixes/mythtv/
<hendrixski_> somebody else did something cool with that a while back, so I want to find the release that happened closest to the date they pulled from svn, then copy over their changes, then update to the latest... and then make a .deb package... but I can't even get started for some reason
<jelmer> hendrixski_: At least I can confirm it doesn't work
 * hendrixski_ slams head on keyboard
<hendrixski_> jelmer, thanks :-)
<jelmer> hendrixski_: any chance you can file a bug about this?
<hendrixski_> now at least I know to try a different strategy
<jelmer> I don't have time to fix this bug at the moment, but I may have time later this week
<hendrixski_> jelmer, I have the time to file one, yes
<jelmer> thanks, that would be much appreciated
<hendrixski_> !bugs
<ubotu> If you find a bug in Ubuntu or any of its derivatives, please file a bug report at: http://bugs.launchpad.net/ubuntu  -  Bugs in/wishes for the bots can be filed at http://launchpad.net/ubuntu-bots
<jelmer> https://bugs.launchpad.net/bzr-svn/+filebug is the link you want
<hendrixski_> lol, I was about to say, this doesn't look like an ubuntu bug :-p
<hendrixski_> jelmer, is it like this one that you're already assigned on? https://bugs.launchpad.net/bzr-svn/+bug/67010
<ubotu> Launchpad bug 67010 in bzr-svn "Branch copies from non-branches don't work" [Medium,Fix released]
<hendrixski_> or would it be best to file a new one, and submit a log message or two?
<jelmer> hendrixski_: no, bug 67010 is a different issue
<jelmer> hendrixski_: please file a new one, and mention the URL
<hendrixski_> will do :-)
<hendrixski_> jelmer, https://bugs.launchpad.net/bzr-svn/+bug/183361   :-)  is there any other info that would help?
<ubotu> Launchpad bug 183361 in bzr-svn "bzr-svn on a branches not working" [Undecided,New]
<jelmer> thanks!
<jelmer> looks complete
<hendrixski_> cool
<hendrixski_> well, now I have to reformat my strategy of how I'm going to do this... well, vendor drop essentially
<hendrixski_> jelmer, good luck
<jelmer> thanks
<igc> morning
<foom> hendrixski_: perhaps branching from http://svn.mythtv.org/svn/branches/release-0-20-fixes/ instead would work?
<spiv> poolie: no, I don't think I have started on 82634
<poolie> thx
<spiv> poolie: I thought I remembered abentley had a patch for it that got rejected, but I can't find it now.  It might have been a good starting point.
<foom> hey um, i'm looking at the bazaar-vcs.org site and I can't find any links to what changed in 1.1
<poolie> http://doc.bazaar-vcs.org/bzr.1.1/en/release-notes/NEWS.html#bzr-1-1-2008-01-15
<hendrixski_> foom, lemme try that
<hendrixski_> foom, that's ridiculous... that seems to be branching
<hendrixski_> and  that's a TON of extra files
<hendrixski_> way, more of the project than I need
<foom> hendrixski_: in that case, you can probably do bzr svn-branching-scheme --set http://svn.mythtv.org/svn and then in the editor, put two lines: "trunk/*" and "branches/*/*"
<foom> then use your original command
 * hendrixski_ tilts head
<poolie> spiv, re that patch
<poolie> is it necessary to use bzr+http at all?
<spiv> poolie: I don't quite understand the question.  You mean instead of http?
<Peng> bzr+http is great for a dirstate branch.
<Peng> s/dirstate/knit/
<Peng> Not so great for a pack branch.
<Peng> s/branch/repo/g
<spiv> poolie: Hmm,
<spiv> poolie: there are a few significant speed improvements to the smart server in bzr.dev that aren't in 1.1
<poolie> i'm asking: in what way is 1.1 broken without this fix?
<hendrixski_> foom, son of a gun.  That seems to have done it
<spiv> bzr+http:// URLs don't work (except in very unlikely circumstances, where the URL paths correspond directly to filesystem paths IIRC).
<hendrixski_> I'm gonna go read about this branching scheme stuff... see what I missed,  but something about having to set up all that stuff doesn't seem right.
<poolie> foom, i added a link to the changelog from the download page
<poolie> do you think it should be anywhere else?
<foom> poolie: I'd like to see a (much shorter) list of what changed on the main page with the release announcement.
<spiv> poolie: so one thought that just occurred to me is that without the speed improvements in bzr.dev, perhaps there's not much practical benefit to bzr+http over http (assuming the webserver supports Range requests).
<spiv> poolie: e.g. Peng last night reported that with a bzr.dev client and 1.1 on a bzr+http server that branching a knit branch was a bit slower (~10% IIRC) than plain http.
<spiv> poolie: (with bzr.dev both ends, bzr+http was much faster)
<spiv> poolie: (and for packs, plain http always won, but bzr.dev on the server was still a large improvement over 1.1)
<jam> igc: ping, do you want to give me a call so we can make sure ssh is working?
<igc> shall do in a few minutes if that's ok - family on phone currently
<poolie> spiv, ok, so iiuc, this patch enables a feature that is not itself very useful yet?
<poolie> therefor making a new release with this patch would not be a priority?
<igc> poolie: I think x.y.1 releases ought to be kept for critical bug fixes
<spiv> poolie: yeah, I think so
<igc> if the feature wasn't working previously, I don't think a 1.1.1 should be released to enable it
<igc> with a 4 week cycle, 1.2rc isn't far away
<igc> if someone needs the fix before then, they can run on bzr.dev right
<igc> ?
<spiv> Right.
<jam> igc: I sent you the details in an email. Try them out first, and then call me if you need to
<jam> I'm going to be AFK
<igc> jam:ok
<lifeless> spiv: packs FTW huh ? :)
<spiv> lifeless: yep!
<poolie> igc, i agree, i was just trying to determine if this was
<lifeless> spiv: just wait till I get time to do the next index design
<spiv> lifeless: hmm, I seem to be getting worse performance with get_parent_map on an initial branch of bzr.dev, compared to using bzr.dev + recommended_page_size fix for RemoteTransport.
<lifeless> spiv: bet you the remote end is 1.0 or so and the chunked stream is falling back to manual get_data_stream
<spiv> lifeless: -Dtimes -Dhpss says 187s to get up to Repository.stream_revisions_chunked, vs. 72s.
<spiv> lifeless: no, remote is bzr.dev
<lifeless> ok
#bzr 2008-01-16
<lifeless> that would be about right
<lifeless> raw index reads - dictionary compressed
<lifeless> get_parents as is in .dev - no compression at all
<lifeless> I bet slapping a gzip around it and doing 64K of compressed data will more than compensate
<lifeless> also we could add a sliding window
<lifeless> 64K first response
<lifeless> 128K second response
<lifeless> 192K third response
<lifeless> another possibility is history shortcuts causing existing revisions to be retransmitted
<lifeless> but I'm not at all sure about a good way to avoid that without excessive server work (have to read the entire search from scratch each time, to generate the seen-and-do-not-transmit-list)
<lifeless> instrumenting the client to report on duplicate revision receipt with -Dhpss would be a good way to analyse this
 * spiv tries
<spiv> lifeless: wow, yes, lots of retransmitted revisions.
<lifeless> right
<lifeless> I'll get this patch finished, which will give infrastructure for handling this cleanly
<lifeless> the other two things are still good things to do
<lifeless> whats happening is that the path (say) 5 deep along mainline gets us deep history slowly
<lifeless> but the path 5 deep along long lived but rarely committed to branches takes us deep very quickly
<lifeless> so that the first request gets us two different pointers in the mainline
<lifeless> and the server doesn't know when the slower pointer advances up to where the faster pointer jumped to; so it does not filter out the results.
<spiv> lifeless: http://rafb.net/p/dv4ApB92.html
<lifeless> the client knows, so it only asks for what it does not have, but when the server expands the results, this occurs.
<spiv> lifeless: so by the looks more than half the data is wasted.
<lifeless> spiv: thats ok, all the duplicates will be in data we're sending to counteract round trips
<lifeless> spiv: so its not a huge failure; just expected
<spiv> Right, but at the expensive of other data we could be sending to counteract round trips :)
<spiv> s/expensive/expense/
<lifeless> spiv: no
<lifeless> spiv: thats where you are wrong; the server could choose not to send this data, but its not at the expense of the data needed to walk :)
<lifeless> possibly we could sensible advance past those pointers to choose up to 64K of additional data
<spiv> lifeless: I meant in an impossibly optimal world, the server would know what the client has already seen
 * spiv blinks
<spiv> 150.440 retransmitted revisions: 0 of 0
<spiv> I guess those must be ghosts.
<lifeless> so I think the biggest immediate problem is the lack of gzip on the content
 * spiv nods
<lifeless> that will increase the payload of 64K to == or > than packs achieve
<lifeless> which will reduce the maximum iterations to traverse all history
<lifeless> and thus the amount of retransmits too
<poolie> lifeless, do you remember the url of your progress bar branch?
<poolie> if you don't offhand it's not a big deal
<ubotu> New bug: #183380 in bzr "init-repo using hpss on remote host should use format remote host	understands" [Undecided,New] https://launchpad.net/bugs/183380
<lifeless> revno 3034 is pushing now to http://people.ubuntu.com/~robertc/baz2.0/nested-pb
<lifeless> poolie: ^
<poolie> thanxs
<spiv> lifeless: FWIW, in 111 get_parent_map calls, 38427 of 53606 items received were already transmitted.
<lifeless> spiv: thanks
<poolie> lifeless, heh, looms :)
<poolie> foom, I added a summary of the release to the front page
 * igc dentist appointment - bbl
<ubotu> New bug: #183391 in bzr "setup.py should have project metadata" [High,Confirmed] https://launchpad.net/bugs/183391
<lifeless> poolie: ping
<poolie> pong iddle i po
<lifeless> I'd like a teddy bear that asks questions
<poolie> urgently?
<lifeless> yeah, I think
<poolie> ok
<poolie> call
<lifeless> thanks
<lifeless> poolie: I don't understand your comment in bzrlib.tests.interrepository_implementations.test_interrepository.TestInterRepository.test_interrepository_get_returns_correct_optimiser
<poolie> lifeless, the point of the comment is that the relation is not necessarily two-way
<poolie> IR1 may wish to be tested with Rx, Ry
<poolie> but that does not guarantee that IR1 is the preferred interrepo for Rx,Ry
<lifeless> so with that disabled the tests for IR1 may not execute
<lifeless> as the tests are all written on the assumption that it is the preferred interrepo
<lifeless> as the interrepo paramerisation chooses the Rx and Ry, we can guarantee that IR1 is the preferred interrepo for that combination if we wish
<poolie> well
<poolie> as i recall, i disabled that test because there were some repos that were not parameterized correctly
<poolie> and therefore appeared to be being tested,but they actually were not
<lifeless> I'll look at it later; I think it explains some of the problems I encountered with the journalled inventory stuff
<poolie> it does seem like it'd be useful to reenable it and see whether it fails, or at least what class causes it to fail
<Verterok> abentley: hi, I was about to send a bug/error report regarding bundlebuggy.
<Verterok> it's throwing a KeyError when I try to do a search
<Verterok> http://rafb.net/p/VYvot846.html
<igc> poolie: how is 1.1 more efficient than 1.0 in storage?
<poolie> igc, better ordering when packing
<poolie> that was my summary of one of the improvements
<abentley> Verterok: Okay, thanks.
<igc> poolie, lifeless: I thought that just made log faster? Does it reduce storage as well?
<poolie> i meant efficient in time, i guess...
<poolie> maybe it implies space, and i don't think that has changed
<abentley> What  were you searching for?
<Verterok> abentley: np, I tried to debug it locally, but no TG, etc installed in my laptop
<igc> poolie: cool. Just the wording "efficient storage" on the Welcome page confused me
<poolie> feel free to edit
<igc> shall do :-)
<Verterok> abentley: my email: guillo.gonzo, to check if and old merge request is still there
<abentley> Okay, so the issue is that Bundle Buggy contains some merge directives with an invalid format string.
<abentley> And when it's parsing those merge directives, the whole thing breaks.
<poolie> ok, out for a bit
<Verterok> ok, so it's only need a cleanup. (great it's not a bug :D )
<lifeless> well it is a bug I think; because people may send bad directives anytime
<lifeless> so it needs to either ignore them on input, or filter them later
<Verterok> I assumed the old directive isn't a recently submitted one, but you right
<AfC> lifeless: (I asked the other day about packs and bzr://, but I assume that if I switch both server and client+ repositories & branches to the new format it at least wont hurt, right?)
<abentley> lifeless: I agree it's a bug.  I can patch around it in BB, but really bzrlib should never raise KeyErrors.
<lifeless> abentley: I think letting KeyError though sometimes is ok
<lifeless> abentley: but yeah BzrError stuff is usually nicer to work with
<abentley> "Never" may be a bit strong, but I think it should be, pardon the pun, "the exception".
<lifeless> :)
<abentley> Our public APIs are generally higher-level than that.
<lifeless> I think deliberately exposing KeyError is ugly, but I think trying to catch every possible underlying error is a timewaste
<abentley> Sure.  I just think that cases where you can get KeyError are pretty obvious, and if you're surprised by them, it's probably programming error.
<Odd_Bloke> I'm currently using bzr-svn to avoid SVN.  However, if I want to get a patch which looks like the one SVN would generate (to send upstream), what should I do?
<lifeless> bzr diff --old svn://thing
<lifeless> ?
<lifeless> I'm packing it in today; I'm a little under the weather (trying to avoid catching the lurgy Lynne has had for a bit(
<lifeless> [not to mention I started early ;))
<Odd_Bloke> No '--old' option, apparently.
<lifeless> diff svn:// .
<lifeless> then
<lifeless> because you have bzr < 1.0
<Odd_Bloke> Thanks. :)
<Odd_Bloke> You may now go off-duty. ;)
<igc> abentley: is lca going to become the default merge algorithm?
<abentley> I would like that.
<igc> I'm thinking we should switch it early in a cycle to maximise testing
<abentley> I'm already aware of at least one bug.
<abentley> And it can't actually be LCA merge, because there are a few cases that LCA merge doesn't handle.
<igc> ah - ok
<abentley> So it needs to be "AutoSelectMerge", which would generally select LCA.
<igc> understood
<abentley> So it's not just flipping a switch.
<abentley> But maybe I should get hacking on AutoSelectMerge.
<igc> abentley: lca sounds pretty sweet to me
<igc> just wanted to make sure we got more people benefiting from it by default
<igc> once it is fully ready that is
<abentley> It is pretty nice, and I'm using it as my default.
<igc> via an alias?
<abentley> Yeah.
<abentley> I think it's the best in its class for handling criss-cross.
<abentley> But there are other classes of history-based mergers that may handle certain cases better.
<abentley> They are quite expensive for us to use, though.
<abentley> And they rely on data that's typically hidden from the user, so where they go wrong, they're completely impenetrable.
<igc> abentley: sounds like the basis for a conference talk later this year say :-)
<abentley> Sure, that would be fun.
<AfC> [Sorry for asking a question then dropping off; had an X crasher here]
<pattern> is there any way to tell bazaar to exclude certain files/directories when doing a "bzr export" ?
<AfC> What does the (native) prefix on each line on `bzr help formats` mean?
<AfC> pattern: not that I've noticed. Technique we've used quite successfully across darcs, git, and now bzr is to do the export and then to trim the stuff that's unwanted and then create the tarball from there (... all in the `make dist` target)
<AfC> pattern: [among other things, getting the name of the top directory being tarred up corresponding to the standard release version number pattern]
<AfC> pattern: [for example, the dist target in http://research.operationaldynamics.com/bzr/java-gnome/mainline/Makefile (third target up from the bottom)]
<AfC> pattern: [though yesterday I learnt there was a slicker way to determine the no changes state]
<spiv> AfC: I believe (native) signifies that the format is not from a plugin.
<AfC> spiv: that was my guess.
<spiv> AfC: in my bzr install, subversion isn't native, and the rest are.
<spiv> Which is right; only the subversion format in that list is from a plugin.
<pattern> thanks, AfC
<pattern> nice makefile you got there :)
<pattern> AfC, tell me one thing... how do you populate that $(VERSION) in your makefile?
<pattern> do you get if from bazaar?  or do you set it by hand?
<AfC> pattern: our top level ./configure extracts it with a regex from a file called src/bindings/org/gnome/gtk/Version.java - it's a constant in the sources
<AfC> which we then
<AfC> write to an intermediate file.
<AfC> Back up:
<AfC> (context):
<AfC> So my approach to the configuration problem (called "Equivalence", ie, it's equivalent to configure) is a few steps:
<AfC> [and note that this is a Java specific discussion; Java is a funny beast and has specific requirements and opportunities]
<AfC> A. In Java, you only need to to 3 things: 1. Locate prerequisite libraries and form a CLASSPATH env variable | -classpath VM argument.
<AfC> 2. locate and qualify [test] Java compilers and then choose one
<AfC> 3. locate and qualify [test] Java runtimes and then choose one
<AfC> (that may be installed; I'm a Free Java hacker and I play in the Classpath community, so switching between runtimes to test compatibility etc is a big deal for me; note that most people just think in terms of "is Java installed"
<pattern> how does the version constant get in to the source?
<AfC> but given the lack of redistributability of Sun's Java for so so long (until about 18 months ago, only 6 months before Sun switched to announcing that Java 7 will be open source)
<AfC> pattern: manually
<AfC> pattern: that's the origin of the data
<AfC> (ie, not data in configure.ac being pumped into a source file)
<AfC> even people with Java installed often have it in some wacky place. Total nightmare. Getting better, but still)
<pattern> ok
<AfC> B. If you know what operating system you're on, you know *exactly* where to look for things. Debian policy says gtk.h is in exactly this spot. Fedora packages put their .jar files in exactly that directory. Etc.
<AfC> So, figure out the OS, then probe specific locations. And if not found, you can tell the user exactly what package to install in order to to do something about it.
<AfC> Anyway. That all takes place in what is (at present) a Perl file
<AfC> [gotta hate prototypes. They never die. This is a > 1800 line Perl script. YEEETCH
<AfC> totally not normalized, been meaning to refactor it for now 4+ years, etc
<AfC> as it happens, at this point, I intend to fold this experience into Robert's fabricate. So this whole discussion is somewhat academic. But I will now answer your question]
<AfC> I used to use Make entirely for the actual build.
<AfC> (as it turns out, after ~20 years of happily and successfully using Make I hit, in the space of single week, two show stopping limitations. But anyway)
<AfC> So what the top level ./configure spits out is
<AfC> a Makefile fragment
<AfC> [which we stash in .config]
<AfC> with nothing but the variable definitions
<AfC> the Makefile then simply does
<AfC> -include .config
<pattern> ah, i see
<AfC> and ta-da is fully configured and instructed with options paths and variables
<AfC> (anyway, the fact that the actual build is now a Python script is irrelevant - it sources the same data)
<AfC> so to answer your question,
<AfC> ./configure grabs the version number out that source file, and then puts it in a line like
<AfC> VERSION=4.0.5
<AfC> in .config
<AfC> which is then available to the `make dist` target.
<AfC> That's it
<pattern> right
<pattern> makes sense
<pattern> thanks for taking the time to explain that to me, afc
<AfC> Thanks. It's been a powerful design. I'm rather bitter I haven't had the time to refactor it. I have some pretty nice ideas about syntax for expressing prerequisite data  and configurations, (after all, I come from the Infrastructure Management world) but doing domain specific language parsers is sorta beyond my programming skill set at the moment.
<AfC> I'm hoping that I'll be able to plug some of the conceptual aspects into lifeless's build system as it comes to fruition. Having had to write even an ad-hoc build engine I know how complex that work is - but how awesome it will be finally have something that's going to get it right.
<pattern> sounds like you're on the right track
 * igc dinner
<AfC> bug 164288
<ubotu> Launchpad bug 164288 in bzr "bzr serve leaves connections in CLOSE_WAIT a *long* time" [Medium,Confirmed] https://launchpad.net/bugs/164288
<AfC> It's worse than I thought.
<fullermd> It usually is.
<AfC> heh
<spiv> AfC: great blog post about open source
<AfC> spiv: thanks mate
<ubotu> New bug: #183504 in bzr "'bzr status' crash if .bzrignore containts  Latin-2 chars" [Undecided,New] https://launchpad.net/bugs/183504
<abentley> ubotu: paste
<ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<Odd_Bloke> Hmm, I currently have my bzr-svn branch checked out at the root (i.e. with trunk, branches, tags).  Is there a way I can transfer the changes I've made to a new checkout of just 'trunk' without losing history?
<jelmer> Odd_Bloke: No
<jelmer> sorry
<Odd_Bloke> jelmer: Not your fault, I suck. :)
<ubotu> New bug: #183539 in bzr-log-rss "Malformed XML" [Undecided,New] https://launchpad.net/bugs/183539
<Odd_Bloke> I'm just going to end up submitting a single patch upstream anyways. :p
<Odd_Bloke> jelmer: I've just got http://paste.pocoo.org/show/21677/ .  Any idea what I'm doing wrong?
<jelmer> yes, the version of bzr-svn you're using is too old for the version of bzr
<Odd_Bloke> Oh wait, I put the new one in the wrong place. Â¬.Â¬
<Odd_Bloke> There we go.
<Odd_Bloke> All is well with the world.
<Odd_Bloke> jelmer: Thanks. :)
<Odd_Bloke> Am I right in thinking that a branch of an SVN repo is resumable?
<jelmer> Odd_Bloke: only if it's being run inside a shared repository
<Odd_Bloke> \o/
<Odd_Bloke> I did it right! :D
<Odd_Bloke> jelmer: Thanks again.
<dlee> Anyone know if the Windows version of Bzr is supposed to handle gracefully the problem of having file name case change at random?  I'm working with an app that has the annoying habit of saving files with semi-random case for characters in the file extension.  This generated a conflict on a pull while ago.
<ubotu> New bug: #183559 in bzr "bzr switch should have a -r option" [Undecided,New] https://launchpad.net/bugs/183559
<Solarion> is there a way to make bzr-svn not push a bunch of commits but instead just one, final commit?
<Solarion> i.e. when I have made a lot of small changes ('cause that's my style), and then push it back to the svn server, bzr-svn commits each commit I made instead of just bringing the svn server up to the current version in one single commit.
<luks> commit to a feature branch, merge to trunk when it's ready, push to svn only from trunk
<Solarion> "feature branch" is what?
<luks> bzr branch trunk foo
<Solarion> one I'm actively developing
<Solarion> right
<luks> a branch dedicated to a feature
<Solarion> sounds complicated, but it's better than the insanity of keeping bzr and svn from stomping on each other in the same directory
<rjek> I am routinely amazed by the number of people on the Subversion mailing list who can't operate a mail client.
<Solarion> luks: so I geuss the answer is "no"; I'll have to maintain my own separate repo if I want to stay sane.
<fullermd> rjek: I'd like to think I would be, but I think the N other mailing lists I follow have inured me to being amazed by such   :p
<luks> branch, not repository
<Solarion> luks: what is difference?
<jelmer> Solarion: it would be possible to provide a plugin that automates what luks describes
<Solarion> jelmer: I'd rather just not commit each commit
<luks> Solarion: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#branch
<luks> Solarion: then don't commit each commit :)
<fullermd> Commit to not commiting each commit?
<Solarion> luks: I thought committing small changes was good
<rjek> fullermd: I suppose so.  I like to still have some hope for the human race.
<Solarion> luks: ah, thanks for the link
<jelmer> Solarion: combining those commits would mean changing them
<jelmer> Solarion, that breaks the basic model of bzr-svn
<fullermd> rjeck: Hope for...   dude.  Myspace exists.  It's too late to hope.
<rjek> Why would you not want all the smaller individual changes pushed to the upstream subversion?
<Solarion> jelmer: but it sounds like the commits are already combined when merging into another bzr branch
<rjek> fullermd: You make a depressing but good point.
<rjek> ie, why would you want to lose history?
<fullermd> The thing to hope for now is "Maybe the asteroid will hit closer to them than me, so I can enjoy their demise before embracing mine   ;)
<rjek> :)
<Solarion> rjek: apparently my boss wants each individual commit to build, not just HEAD
<Solarion> I don't want to guarantee that each commit will build; I want to keep a finer-grained history
<Solarion> only make sure that what I push to svn actually builds
<jelmer> Solarion: You have to commit a merge - that creates a new commit
<luks> merging branches to trunk is really the best solution for this
<jelmer> Solarion: "bzr push" is meant to just propagate changes, not change them in any way
<jelmer> Solarion: furthermore, if you combined revisions, you would have to have push change your local branch
<Solarion> so I'm just failing to use the tool properly.  :)
<luks> Solarion: just have two branches, "trunk" and "work"
<luks> commit small changes to work
<luks> and then you are ready, merge to trunk, push to svn
<rjek> Solarion: The usual way of doing that is to push to a branch in svn, and then merge that branch.
<luks> (that's if you don't want to deal with feature branches)
<Solarion> but I'm already maintaining a feature branch, my local copy.
<luks> then you need also a mirror of svn trunk
<Solarion> luks: why do I need a mirror?
<rjek> If you're just using bzr as a method of doing disconnected subversion, and you want your branches pushed as one big change, svk may be a better solution.
<luks> to merge your feature branch to it
<Solarion> rjek: I'm using bzr as a method of staying sane.  :)
 * rjek wonders if you can do some evil by having an svn checkout also be a bzr branch :)
<rjek> add .bzr to the svn ignore list. :)
<Solarion> rjek: I've done that.  It kinda sucks.
<rjek> I'm not surprised.
<Solarion> the suckage is maintainable when you just have a copy on your workstaion, but keeping workstation and notebook in sync gives you the full suckage
<rjek> Keep a checkout of svn to one side, and then get bzr to give you a patch that you apply to the svn checkout?
<rjek> Personally, I'd push to a branch on the svn server, and then merge to trunk: that way revisions on the trunk always build and you don't lose history.
<Solarion> rjek: what do you mean precisely?
<Solarion> 3 branches: svn repo, bzr trunk, bzr feature.  Merge between repo and trunk to maintain sync, push/pull between feature and trunk?
<fullermd> Other way around, I'd think.
<lucky> there was a command, at least back in the 0.11 version, that would show me the size of my repository in KB and so on, has it been removed?
<Solarion> merge between feature and trunk; push/pull between trunk and svn?
<fullermd> Yeah.  Or better, automate the second part by making the trunk a checkout of the svn tree.
<fullermd> Then you can just 'update ; merge ../feature ; commit' to bring stuff in.
<Solarion> I need trunk to be centralized
<abentley> Solarion: by "centralized", you mean you want it to be located on a central server?
<Solarion> abentley: yeah
<Solarion> I think I've figured out a good system
<Solarion> plus, whenever it is I leave, my bzr branch can migrate with me without any loss of history or increase in annoyance
<abentley> Solarion: you know about checkouts, right?
<Solarion> abentley: "know about" in what sense?
<abentley> That they allow you to keep your branch in one place and your working directory somewhere else.
<Solarion> "they" who?
<abentley> checkouts
<Solarion> you mean checkouts from svn
<abentley> I mean Bazaar checkouts
<Solarion> there's no such thing as a bzr checkout
<abentley> I use them daily and was involved in their implementation.
<dato> lucky: bzr info -v
<abentley> See "bzr help checkouts"
<Solarion> my impression is that the two branches are on equal footing, aside from policy decisions
<dato> lucky: giving the size needed a bit of time, so it was moved from `bzr info` to `bzr info -v`
<abentley> Solarion: I'm not talking about branches, I'm talking about checkouts.
<abentley> Branches, are indeed equal.
<Solarion> abentley: ah, I wasn't aware of this then
<abentley> If you want to maintain a branch on a central server, checkouts are a useful tool for that.
<Solarion> indeedy
<hendrixski> I'm going to have to pull an earlier revision of something from an svn that happened before a certain date which I can easily find by doing bzr log
 * Solarion reads up on checkouts
<hendrixski> now I've tried this before, and I remember it's not just the revision number I need to get that from svn
<hendrixski> but forgot what... I was hoping someone can tell me what I'm supposed to be looking for?
<lucky> dato: ah, okay, thank you
<lucky> dato: thats what i was looking for
<dato> lucky: you're welcome
<jelmer> dato: any chance you can sponsor an upload of bzr-pqm?
<dato> jelmer: yeah, send me a mail with the dsc url, and I can do it tomorrow
<hendrixski> like, I think I need a revision ID, but I can't seem to find a parameter for bzr log in the man pages that would also show me the reivision id
<dato> hendrixski: --show-ids?
<jelmer> dato: Cool, thanks
<hendrixski> dato, that did it
<hendrixski> alrighty, now let's use that revid to pull from svn :-p
 * hendrixski crosses fingers
<Solarion> abentley: interesting thing
<dysinger> So anyone in here using bzr-svn on OS X Leopard ? :D I can't get it to work.
<rjek> Bah, I want to put over 100MB of test case data into version control.  That's not going to be comfortable.
<foom> well, with svn it's no problem. dunno about bzr. :)
<rjek> In svn, I'd just bung it in with the source, and choose not to check it out when I'm at the wrong end of a wet string.
<rjek> But that's not really an option in bzr.
<LeoNerd> Put it in its own branch?
<rjek> I could do.
<LeoNerd> It's a result of different world views. bzr has revisions. Within a revision, there are files
<rjek> But it kinda breaks my neat hierachy. :)
<LeoNerd> CVS/SVN have files. Within files there are revisions
<LeoNerd> These are very basic and different ways to look at the world; one can't easily fit the other
<rjek> Indeed.
<foom> svn stores files within revisions.
<LeoNerd> Not really.. SVN is a versioned filesystem
<foom> it's just that it lets you mix and match in your working directory
<foom> the repository structure is completely revision-based
 * rjek nods.
<LeoNerd> It's a versioned filesystem, where a commit on a directory atomically references all files witihn it
<lifeless> dysinger: I know some folk have
<dysinger> lifeless:  I have been dying to get off of git-svn if you could direct me it would be awesome.  I have been banging my head with svn and patches on leopard with no luck.  Leopard comes with SVN/Python and SVN/Python SWIG pre-installed and prefers it's own install over /usr/local
<lifeless> dysinger: you can probably control that with PYTHONPATH, which prepends to the path python looks for such libraries
<foom> dysinger: why dying to get off of git-svn?
<lifeless> foom: to use bzr ? :)
<foom> lifeless: obviously, but I thought maybe there was a reason. :)
<dysinger> Yeah I don't mind git-svn so much as the rest of my team wouldn't use it because of the learning curve.
<dysinger> bzr is easier to wrap your mind around.
<lifeless> why did the chicken cross the road?
<Manfre> so i could eat it
<dysinger> and you don't have to do things like git push dev :refs/head/my-branch
<dysinger> and other BS
<foom> i mean, I have a reason why I don't want to use git-svn: it doesn't seem to store enough data in svn to allow cross merging with other git-svn users and pulling the same changes from svn to work
<dysinger> I cross merge with other git-svn users
<foom> last time I tried it was 6 months ago or so I think
<dysinger> But it's a PITA - basically it means pull and pushing to SVN & also pulling and pushing to a server with a clone of your git-svn
<dysinger> so you can share your local branches with someone else
<dysinger> git is way to complex for the average user IMO
<lifeless> dysinger: I have noticed you popping in and out on IRC... if I can make a suggestion; open a 'question' on bzr-svn - https://answers.launchpad.net/bzr-svn
<dysinger> I could only sway my top dev to try it with me.  Everyone else on the team is lost with Git.
<foom> yes, it really does have a poor UI.
<lifeless> dysinger: this is a support forum, and will mean you don't have to be online at the same time as the bzr-svn developer[s]
<foom> i'm sure it makes sense if you're linus. other than that, no, not really. :P
<dysinger> lifeless: sure.
<dysinger> thanks - I just am used to using IRC
<lifeless> IRC is great but it can be lossy; and this is dragging on for you :)
<dysinger> I already spoke to the bzr-svn maintainer about it a couple weeks back with no luck.
<dysinger> I'll just keep using bzr for private projects for now.
<foom> you could do the bzr-svn bit on a different machine. :)
<jelmer> 'evening folks
<fullermd> Jeez, didn't even have to say his name that time...
<dysinger> I added the OS X Leopard bzr-svn to questions at launchpad.  Hopefully I can help and we can get to the bottom of the problem so that all OS X users can use it.  DVCS is only useful to a lot of people if they can still interact with SVN.
<dysinger> https://answers.launchpad.net/bzr-svn/+question/22326
<jelmer> dysinger: You may also have to run 'make install'
<dysinger> That's right there in the script
<dysinger> ...
<dysinger> make check
<dysinger> sudo make install
<dysinger> make swig-py
<dysinger> make check-swig-py
<dysinger> It puts everything in the right place
<dysinger> and
<dysinger> # Check it ---
<dysinger> python -c "import svn.delta; print svn.delta.__file__"
<dysinger> finds the right python script
<dysinger> but python -c "from svn.delta import svn_delta_invoke_txdelta_window_handler" doesn't work
<jelmer> what does the following print
<jelmer> python -c "import svn.delta; print svn.delta.__file__"
<jelmer> also, is LD_LIBRARY_PATH portable to Mac OS X?
<jelmer> it looks like that should be DYLD_LIBRARY_PATH
<dysinger>  OK I'll try that
<dysinger> one sec
<dysinger> ok sorry I got distracted on work.  Before patching svn I get /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/svn/delta.pyc as expect for python -c "import svn.delta; print svn.delta.__file__" ...
<dysinger> After I got /usr/local/lib/svn-python/svn/delta.pyc
<jelmer> and it still doesn't work?
<dysinger> no
<dysinger> I tried both LD_LIB... and DYLD_LIBRARY_PATH
<dysinger> set to /usr/local
<dysinger>  python -c "import svn.delta; print svn.delta.__file__"
<dysinger> Duece:subversion-1.4.6 tim$
<dysinger> Duece:subversion-1.4.6 tim$ python -c "from svn.delta import svn_delta_invoke_txdelta_window_handler"
<dysinger> Traceback (most recent call last):
<dysinger>   File "<string>", line 1, in <module>
<dysinger> ImportError: cannot import name svn_delta_invoke_txdelta_window_handler
<jelmer> does grepping for svn_delta_invoke_txdelta_window_handler in /usr/local/lib/svn-python/svn/delta.py return anything?
<dysinger> no
<jelmer> are you sure the patch applied ok?
<dysinger> The patch for svn applied cleanly
<jelmer> Did Subversion rerun swig?
<dysinger> one sec
<dysinger> Patch seems to have applied ok
<dysinger> patching file subversion/bindings/swig/include/apr.swg
<dysinger> patching file subversion/bindings/swig/include/proxy_apr.swg
<dysinger> patching file subversion/bindings/swig/include/svn_types.swg
<dysinger> patching file subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.c
<dysinger> Hunk #4 succeeded at 533 (offset 3 lines).
<dysinger> Hunk #5 succeeded at 640 (offset 3 lines).
<dysinger> Hunk #6 succeeded at 1534 (offset -1 lines).
<dysinger> Hunk #7 succeeded at 1552 (offset -1 lines).
<dysinger> Hunk #8 succeeded at 1603 (offset -1 lines).
<dysinger> Hunk #9 succeeded at 2272 (offset -1 lines).
<dysinger> patching file subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.h
<dysinger> Hunk #2 succeeded at 202 (offset 1 line).
<dysinger> Hunk #3 succeeded at 319 (offset 1 line).
<dysinger> patching file subversion/bindings/swig/svn_client.i
<dysinger> patching file subversion/bindings/swig/svn_delta.i
<dysinger> Hunk #2 succeeded at 152 (offset 3 lines).
<dysinger> patching file subversion/bindings/swig/svn_ra.i
<dysinger> patching file subversion/bindings/swig/svn_wc.i
<dysinger> Duece:subversion-1.4.6 tim$
<dysinger> grepping in the source dir now returns
<dysinger> Duece:subversion-1.4.6 tim$ grep -r svn_delta_invoke_txdelta_window_handler *subversion/bindings/swig/svn_delta.i:svn_error_t *svn_delta_invoke_txdelta_window_handler (
<dysinger> Duece:subversion-1.4.6 tim$
<jelmer> yes, but was SWIG rerun?
<dysinger> I did make swig-py after i built iit
<dysinger> it
<dysinger> and make check-swig-py and make install-swig-py
<jelmer> if you grep for svn_delta_invoke_txdelta_window_handler after that, does it return anything?
<jelmer> anything but the .i file, I mean
<dysinger> not in /usr/local but let me check again in the build dir.  I wouldn't think it would be in the build dir and not in /usr/local - one sec.
<jelmer> then it didn't run SWIG
<dysinger> should I be doing make swig and not make swig-py ?
<dysinger> Sorry I am a ruby/java guy and novice python
<jelmer> do you have SWIG installed?
<dysinger> y
<jelmer> can you try running extraclean-swig and building it again?
<jelmer> make extraclean-swig, that is
<dysinger> srue
<dysinger> sure one min
<dysinger> IF we can figure this out and it works I am going to go get some Champagne right now and spray it everywhere and put it on my blog with instructions.  :)  (still compiling)
<ubotu> New bug: #183636 in bzr "Internal error when switching an anonymous svn checkout to an authenticated one" [Undecided,New] https://launchpad.net/bugs/183636
<jelmer> :-) Any luck?
<dysinger> not yet still working on it
<dysinger> make extraclean wiped out my ./configure I think it wouldn't compile
<jelmer> just extraclean-swig should be sufficient rather than extraclean
<dysinger> y that's what I meant
<dysinger> but now I get  make swig-py
<dysinger> make: *** No rule to make target `subversion/bindings/swig/python/svn_client.c', needed by `subversion/bindings/swig/python/svn_client.lo'.  Stop.
<dysinger> re configure and re make doesn't fix
<dysinger> :/
<dysinger> should I even need extraclean if I am applying the patch to a fresh checkout?
<dysinger> I wouldn't think so
<jelmer> dysinger: did configure find swig?
<dysinger> Let me check - I would think so make swig-py and check-swig-py works.
<jelmer> dysinger: swig isn't necessarily used for those targets
<dysinger> oh ok - will check
<dysinger> That may be the problem
<dysinger>  ./configure   --without-apache   --without-apxs   --with-ssl   --prefix=/tmp   --libdir=/usr/local/lib | grep swig
<dysinger> checking for swig... /usr/bin/swig
<dysinger> configure: WARNING: Detected SWIG version 1.3.31
<dysinger> checking swig version... 1.3.31
<dysinger> configure: WARNING: Subversion requires 1.3.24 or later, and is known to work
<dysinger> configure: WARNING: with versions up to 1.3.29
<dysinger> configure: Configuring python swig binding
<dysinger> I wish Apple wouldn't try to Jam on bunch of dev tools in the default system.
<dysinger> OS X comes with everything Python / Ruby / Java / Perl and every lateral tool you can think of by default. :/
<dysinger> I like /usr/local and from scratch
<lifeless> you could use ubuntu on that hardware :)
<dysinger> I have tried it - it's cool on the MBP
<fullermd> OS X comes with ubuntu by default?   ;)
<dysinger> no you have to install it.
<dysinger> I tried it when I had to reinstall OS X anyway a couple months ago on my MBP
<dysinger> Everything works.
<dysinger> I doubt it would "just work" on my Mac Pro 8-core Xeon though
<dysinger> Who knows
<dysinger> I am a die hard Linux/BSD fan too - not just a mac nerd - I just like the mac desktop
<dysinger> It's still better than Gnome IMO
<dysinger> I use all Xen servers though
<dysinger> I wish OS X had virtualization like that
<dysinger> jelmer - thanks for helping again - I am done banging my head.
<jelmer> dysinger: it works now?
<dysinger> no
<dato> heh
<dysinger> I'll keep trying
<dysinger> If you know of anyone else trying on OS X Leopard - i have that question open
<dysinger> and my address is tim@dysinger.net
<fullermd> Well, I like my environment better than Gnome too, but it's kinda the opposite direction from Mac   :p
<dysinger> KDE ?
<fullermd> ctwm
<dysinger> wow
<dysinger> I use to only ever use blackbox and xterm
<dysinger> 10 years ago
<jelmer> dysinger: what fails now?
<fullermd> It does what I want it to, and otherwise stays the heck out of my way and doesn't burden me with icons and inferior icon managers and trays and docks and all that crud.  Perfection   :)
<jelmer> dysinger: are you using GNU make?
<dysinger> Jelmer - well after I re-downloaded subversion 1.4.x source again, applied the svn patch, configure, make && make swig-py and grep svn_delta_invoke_txdelta_window_handler I get only the subversion/bindings/swig/svn_delta.i file
<fullermd> Looks like a gmake message.
<dysinger> GNU Make 3.81
<jelmer> dysinger: you really need to run extraclean-swig
<jelmer> before check-swig-py
<dysinger> ok one sec
<dysinger> Same as last time.  As soon as I run extraclean-swig it won't compile any longer
<dysinger> make: *** No rule to make target `subversion/bindings/swig/python/svn_client.c', needed by `subversion/bindings/swig/python/svn_client.lo'.  Stop.
<jelmer> does that change if you run autogen.sh without the --release argument?
<dysinger> ok there we go
<jelmer> actually, did you run with --release earlier?
<dysinger> OMG it works
<dysinger> party time
<dysinger> I will write it up in my blog and on the wiki
<dysinger> thanks jelmer
<jelmer> it's already on the wiki...
<lifeless> dysinger: great
<dysinger> OS X is on the wiki?
<jelmer> dysinger: The installation instructions for python-subversion on the wiki page already included "autogen.sh --release"
<lifeless> jelmer: perhaps a script people can run?
<dysinger> Yeah copying that straight to mac didn't work and the subversion version is old
<jelmer> lifeless, it's a copy-n-pastable at the moment
<jam> spiv: ping
<lifeless> abentley: ping
<abentley> lifeless: pong
<lifeless> abentley: I have a little design thing I want to talk about before coding; because its likely that if I have it wrong you'll bb:reject me :)
<abentley> Fire away.
<lifeless> abentley: here is the context, I want to change 'missing_revision_ids' to return a SearchResult (which I sent a patch to introduce that object yesterday)
<lifeless> but missing_revision_ids _currently_ is defined as returning in topological order
<lifeless> the reason to do this is that the search result has both all the keys (for local data pulling), and the recipe to recreate the search (for hand off over RPC to get a data stream)
<lifeless> currently on initial pull of e.g. python you upload 50K revision ids. This takes a while ;)
<abentley> Okay, makes sense so far.
<lifeless> now, I'm going to deprecate and rename missing_revision_ids for api versioning, but thats not what this discussion is about :)
<lifeless> the question is about the impact...
<lifeless> SearchResult doesn't know about topological ordering, and I've given it a few hours thought and it seems hard to really guarantee good results
<lifeless> pretty trivial searches can start unordered; we can only really order by accumulating all the parent data (e.g. the graph) and then doing a topo_sort at the end
<lifeless> (e.g. A:[B], B:[C], C[NULL], make_breadth_first_search(A, C)
<abentley> If you're defining a new API, I don't think you need to require topo ordering.
<lifeless> goodo. the corollary is that fetchers that want topological ordering will need to do that post-getting-the-list-of-keys
<igc> morning
<lifeless> anyhow, sweet. I'll make it so.
<lifeless> hi igc
<igc> hi lifeless
<abentley> I think topological ordering is nice if cheap, but frequently the callers don't need it.
<jam> morning igc
<abentley> So not worth paying a big price for in the general case.
<abentley> As long as there's no backwards compatibility issue, I'm quite happy to drop it.
<lifeless> abentley: its actually really hard to reliably generate due to history shortcuts
<spiv> jam: pong
<jam> spiv: I'll just mention it in the phone call
<lifeless> hi, I'm joining in today, not in the zone atm
<spiv> ok
<jam> spiv: getting some weird results from your new chunked streaming api
<jam> ... why doesn't gvim get an entry in the Applications menu
<spiv> jam: do you have a -Dhpss -Dtimes log for the slow pull?
<abentley> jam: I think gvim should go under "games".  It's been described as using a video game to edit files, and that fits for me.
<poolie> spiv, i thought -Dtimes was going to always be on?
<poolie> jam, i think you can turn it on in 'edit menus'
<poolie> i agree it's weird
#bzr 2008-01-17
<poolie> igc, do you want to talk about benchmarking some time?
<igc> poolie: sure
<igc> you call me?
<poolie> ok
<dysinger> Noob Q : So will bzr rewind my local commits when I rebase and then apply them again?
<dysinger> like git ?
<dysinger> Er sorry I should RTFM http://bazaar-vcs.org/Rebase
<lifeless> dysinger: you can do that if you want yes
<dysinger> what RTFM ? :)
<lifeless> dysinger: our community rarely uses rebase because its very bad for collaboration
<dysinger> Well it's useful when your team uses SVN IMO
<lifeless> why?
<dysinger> I guess because I have some of the team on SVN and some on DVCS
<dysinger> so the we could all just pull from each other except some people are only commiting to SVN
<lifeless> I still don't get what rebase does for you; just merge and commit and away you go
<lifeless> you don't need rebase for that at all
<dysinger> I guess my mind is polluted with git-svn
<dysinger> :)
<dysinger> BZR will be a fun new (hopefully simpler) experience
<lifeless> when someone commits to svn, you 'bzr merge' to get their stuff into your branch
<lifeless> when you want to commit to svn, you do 'bzr checkout svn:///' merge and commit
<dysinger> Git treats SVN as a whole separate add on side-car which sucks.
<lifeless> indeed
 * AfC just read the URL about rebase above and *still* doesn't get what it's for. {sigh}
<lifeless> it would be extremly hard to do other with gits design
<lifeless> AfC: rebase is for folk that care about having a 'pretty revision graph'
<AfC> I guess
<lifeless> AfC: more than having effective collaboration
<dysinger> Well rebase is awesome for things like:  Fore example I am tracking bazaar but I don't have commit access - so I can rebase and re-apply my commits on top of the latest head.
<lifeless> dysinger: or you can just merge.
<dysinger> ko
<dysinger> ok
<dysinger> So I guess yeah - why would you have rebase then ?
<lifeless> dysinger: your commits are preserved and if you have shared your commits with other people they don't have to resync specially when you merge, like people have to with rebase
<lifeless> dysinger: as I say above, rebase is about 'revision graph prettiness'
<dysinger> I see
<lifeless> some people care intensely about that; for them we have rebase ;)
<AfC> lifeless: huh. Thanks. [I'll admit that there some ... concerns ... that I have about the human usefulness of the revision graph as presented by log and viz UIs at present, but it doesn't seem to be a rebase related thing]
<dysinger> that would be me
<lifeless> rebase can /also/ be used for some internal trickiness related to changing translations between bzr and svn and other such systems, but thats more using the core logic than using the commands
<lifeless> dysinger: well, you may find you care less with bzr's log layout :)
<dysinger> i am looking forward to playing with it.
<dysinger> So the pastable install script for OS - X, BZR 1.1, SVN w/ patch, bzr-svn is different than http://bazaar-vcs.org/BzrForeignBranches/Subversion says to do it.  http://bazaar-vcs.org/BzrForeignBranches/Subversion does NOT work on OS X.
<dysinger> Should I put it somewhere for others?
<lifeless> dysinger: cool, edit that page and add a version for os X
<dysinger> K
<Peng> "Bazaar-NG branch format 5" is dirstate, right? Why is it listed as "unnamed" in bzr info?
<lifeless> Peng: the format name reporting is bogus, there is a bug on it
<lifeless> Peng: format 5 with knits and dirstate is 'dirstate'
<lifeless> Peng: format 5 with packs is 'unnamed'
<Peng> Ahhh, ok.
<Peng> Yeah, I'm using packs.
<Peng> Ok.
<Peng> Thanks for the explanation. :)
<dysinger> ok I updated bzr-svn wiki with the right install info for OS X
<dysinger> jelmer thanks for hanging in there - it's working now!  I am off to play with some svn repos
<poolie> dysinger, thanks!
<dysinger> So who's an expert on light-weight branching?
<lifeless> fsvo expert many people
<lifeless> just ask :)
<dysinger> So I need a plugin? https://launchpad.net/bzr-lightweight-branch
<dysinger> I want to checkout from svn once and then branch off that for topics - but I don't want to copy the whole branch everytime - that would be rudundant and huge.  Git does this with the --shared and --references flags.
<dysinger> I also heard you can have many branches within the same directory like Git
<dysinger> Maybe that would be better
<bob2> create a repository (need to use init-repo --rich-root) and branch into that
<bob2> er, from svn into that
<dysinger> So instead of branching right from svn with bzr branch svn:///..... I do it this way?
<bob2> well, you make the repository, then use "bzr branch svn..." to branch into that repository
<dysinger> mkdir project ; cd project ; bzr init-repo --rich-root ; bzr branch svn:///some/url ./
<bob2> you can't really have multiple branches "within the same directory like Git"
<bob2> you can have a repository, which contains branches (each is a dir), and it efficiently shares data between them, so you're not using N times as much space for N branches
<bob2> "bzr init-repo --rich-root ~/repository/ ; bzr branch svnL//blah ~/repository/trunk/ ; bzr branch ~/repository/trunk/ ~/repository/the-feature-I-am-working-on"
<dysinger> So if I already branched off of svn directly do i have to do it again this way?
<bob2> --no-trees is optional for init-repo, and means it does not include checkouts of the branches along with the branches
<foom> bob2: sure you can; bzr switch will let you do exactly that.
<dysinger> I thought I read you could
<bob2> you should be able to branch from the existing checkout into the repository
<dysinger> In the bzr vs git page
<bob2> foom: that was the next bit
<foom> bob2: oh okay. :)
<bob2> dysinger: you can, though, quickly switch between branches in a checkout using bzr switch, like foom says
<dysinger> that's what I need
<dysinger> I don't want new IDE setup on every branch
<dysinger> I just want to switch between branches fast.
<bob2> that's what I use switch for, works well
<lifeless> dysinger: if you already branched from svn into dir FOO
<lifeless> dysinger: then this:
<lifeless> bzr init --rich-root myrepo
<lifeless> bzr branch $FOO myrepo/svntrunk
<dysinger> awesome that's what I want then - though I am glad about the light-weight branch-to-another dir option too - I like how flexible bzr is
<lifeless> dysinger: will transfer the data into the repo
<bob2> not init-repo?
<AfC> dysinger: When I started working with bzr, the `bzr switch` command was ... unavailable ... and so we developed an alternate approach to dealing with the "and I sure as hell don't want to have to reconfigure my IDE every time I branch" meme
<AfC> dysinger: we have the source code in .../project/mainline .../project/branch1 .../project/branh2, etc
<AfC> dysinger: where .../project is created with `bzr init-repository`
<lifeless> bob2: oh yeah, I meant to type init-repo
<AfC> dysinger: and the first branch was `bzr init mainline`
<dysinger> AFC: lemme guess - symlinks?
<AfC> dysinger: all subsequent branches were, of course, created with the `bzr branch` aka `bzr clone` command
<AfC> dysinger: yes, that's where I'm heading
<AfC> dysinger:
<dysinger> OK
<dysinger> I like the switch option - I'll try that.
<AfC> dysinger: then (this is Eclipse, but whatever), in
<dysinger> I am using eclipse too
<AfC> Eclipse's ~/workspace we have
<AfC> ~/workspace/projectname ->.../project/whicheverbranch
<dysinger> With eclipse and maven it's easier - mvn eclipse:eclipse can generate project files on the fly then you can import them with the mult-project import plugin.
<AfC> and we just move the symlink.
<dysinger> ok thanks AfC
<AfC> You don't need maven, but whatever.
<dysinger> I Do - but that's not related to this.
<dysinger> So do I need the --rich-root to work with switch ?
<dysinger> Does the lightweight branching occur automatically when you are within a rich root ?
<AfC> Also, be aware that `bzr switch` evolved from a different concept that Git's. The Bazaar hackers are working on it, but it wasn't a high priority until recently, and the current implementation is somewhat specific.
<abentley> AfC: The switch command is quite similar to its bzrtools incarnation, so a bug report on the data loss you encountered would still be welcome.
<dysinger> Heh yeah - I am just coming over from Git so I am wanting that switch thing
<lifeless> dysinger: no, lightweight always requires the option
<AfC> abentley: did I mention your name? Was a talking to you? Did I say data loss?
<lifeless> lol!
<dysinger> whoa
<abentley> AfC: No, though you hinted at something to do with the bzrtools incarnation.
<dysinger> When I branch from svn and then branch again somewhere else (like into a rich repo as suggested above) can I commit back to svn directly?
<lifeless> dysinger: yes, just push
<abentley> AfC: But in general, I feel free to join in conversations on public fora like IRC.
<lifeless> dysinger: or simply bind/do a a checkout from svn (using bzr checkout) again.
<lifeless> dysinger: the shared repository will mean that only new data is copied, so it will be nice and fast
<AfC> dysinger: for what it's worth, you're getting on into the area where experience will fill in the blanks. Bazaar is *very* powerful, you can trust it implicitly, but it does work a wee bit differently that Git and you'll probably need to work with it a bit before you catch on to the differences.
<dysinger> ok
<dysinger> Just getting my feet wet today
<AfC> dysinger: that's obviously from my own experience, but beware that it doesn't quite do things Gits way. That's neither good nor bad, but if you think in purely Git terms you may beat your head a bit.
<AfC> dysinger: yeah, so just try stuff a bit.
<dysinger> Is the --lightweight plugin needed to do light-weight branching ? You guys didn't mention it above but it's on the plugin page.
<AfC> dysinger: even creating a full branch or two for a moment to try stuff (including commits and merges) lthen throwing them away won't cost you anything.
<lifeless> dysinger: no
<lifeless> dysinger: I have no idea about that plugin
 * AfC watches another new user flail with the question of what the heck is "lightweight"
<dysinger> AfC - I have already done that - I have pushed and pulled and merged like nuts over the last week.  Today I just got bzr-svn working and now I want to use it for real.
<AfC> dysinger: sweet.
<AfC> dysinger: guess what I'm saying is that you can keep at the experimentation for sure (at least on the Bazaar side)
<AfC> dysinger: and if you have access to create dummy repos on the svn side you're really set
<dysinger> But "for real" means checking out a real very large svn project.  I didn't want to copy it everytime I made a branch.
<lifeless> dysinger: you don't have to; init-repo and you're done
<AfC> The other guys will want to know: how large is large?
<AfC> [The Bazaar hackers, of which I am not one, are especially interested in Bazaar performance and usability on huge projects]
<dysinger> It's probably not large by your guys standards sorry.  Only about 5000 commits but it's about 500MB
<AfC> The svn repo is 500MB, a clean checkout is 500MB, or the release tarball is 500MB?
<lifeless> spiv/abentley if you feel like doing a review SearchResult would love one
<abentley> Sorry, I have to go rock out.
<spiv> lifeless: ok, I'll take a look sometime this afternoon
<lifeless> abentley: enjoy!
<lifeless> spiv: thanks; I have fetch converted to use SearchResult now
<lifeless> making sure all tests pass and that branch will go up; then onto hpss integration
<foom> AfC: unfortunately it's still really bad. :P
<foom> but at least it's gone from really *really* bad to only really bad. :)
<AfC> foom: progress! :)
<AfC> Abstractly, I wonder where the break point is. Number of revisions? Size of repository? Size of code:revision ratio?
<spiv> lifeless: sweet
<lifeless> dysinger: the lightweight /branching/ plugin gives you 'partial history'; its reduces the data the repository stores rather than having no repository (which is what lightweight checkouts do)
<foom> from my understanding, the current speed issues are related to loading the index, which I guess is related to number of revisions
<lifeless> dysinger: erm, no I'm wrong
<foom> but I don't actually know, all I know is that it's still pretty slow. :)
<lifeless> dysinger: its the same as 'bzr cbranch' which is a bzrtools plugin, AFAICT
<foom> (for a 60krev repo)
<lifeless> foom: speed issues in what operations?
<foom> say, log.
<lifeless> thats due to log doing a global sort on the revisions
<AfC> (ie, where does Bazaar go from being a wonderful experience to choking? I imagine that most people working on or evaluating Bazaar, except possibly lifeless, haven't seen the cumulative effect of a marginal one-more-wafer-thin revision; most try to import some huge 20 year old project and something isn't cool and so they give up)
<lifeless> and yes index speed matters there; the current indices are good at partial loads but not so hot at full loads
<dysinger> Sorry guys - all / most of this is already plain as day over in http://doc.bazaar-vcs.org/latest/en/user-guide/index.html - you guys should tell me to RTFM ! :)
<lifeless> dysinger: we're a friendly lot :]
<lifeless> 50% done no failures
 * AfC goes for coffee. dysinger, I hope bzr goes well for you. Good luck.
<lifeless> patch sent
<lifeless> spiv: ping
<lifeless> spiv: what is the current verb for 'pull revisions' that I should be replacing ?
<lifeless> spiv: and why are there two verbs for it ? SmartServerRepositoryStreamKnitDataForRevisions
<spiv> lifeless: there's two, because one buffers everything, and the other sends the response in chunks
<lifeless> I see two for the same request object
<spiv> Oh, ugh, I see.
<spiv> I wonder how that happened...
<lifeless> Repository.stream_knit_data_for_revisions SmartServerRepositoryStreamKnitDataForRevisions and  Repository.chunked_stream_knit_data_for_revisions SmartServerRepositoryStreamKnitDataForRevisions
<lifeless> I iz confused
<spiv> stream_knit_data_for_revisions is the original, buffering one.
<lifeless> ok
<lifeless> is there one that is not in a release yet ?
<spiv> stream_revisions_chunked is the right verb for the better, chunking one.
<lifeless> spiv: is stream_revisions_chunked in 1.1 ?
<spiv> chunked_stream_knit_data_for_revisions should not exist.
<spiv> stream_revisions_chunked has not been in a release.
<spiv> (and neither has chunked_stream_knit_data_for_revisions, thankfully)
<lifeless> k
<lifeless> I'll delete one and alter the other
<spiv> lifeless: thanks
<spiv> lifeless: and thanks for spotting it!
<pattern> can bazaar version symbolic links?
<Manfre> how do I tell bzr to use an SSH key while doing bzr push bzr+ssh?
<pattern> looks like bazaar can version symbolic links  :)
<pattern> aya
<pattern> yay even :)
<bob2> Manfre: just does it for me
<Manfre> i'm on windows
<bob2> ah, dunno then
<bob2> http://bazaar-vcs.org/Bzr_and_SSH
<Manfre> thanks
<Manfre> cool...it's working
<Manfre> i successfully pushed a branch up to launchpad
<lifeless> spiv: I'm running more and more into 'RemoteRepository has duplicate code cause its not a subclass'
<lostylost> Hey, does anyone know if there would be compatibility issues commiting to a remote repo with bzr1 from a local bzr1.1 client?
<lifeless> lostylost: there should not be, but we recommend that bzr servers run the latest release for best performance
<lostylost> that makes sense
<lostylost> I have had a few errors with bzr lately and it's getting me nervous
<spiv> lostylost: what sort of errors?
<lostylost> I lost a complete revision, I think due to my rashness. I was committing locally to a repo. When I tried to commit it said to update, so I did. It gave an error message.
<lostylost> I can't recall exactly what it said
<spiv> lostylost: your ~/.bzr.log may still have the error in it
<lostylost> something about to check the .bzr/checkout/pending-deletes
<lostylost> anyway, it said to delete the ones in there, I foolishly manually deleted them thinking everything would still be in the repo
<lostylost> somehow I lost a whole revision
<lostylost> Check the bzr log hey
<lostylost> I would like to understand what happened for next time
<lostylost> all that was in the directory was files with numerical names...
<lifeless> lostylost: if you ever have to look inside .bzr there is a bug of some sort; ask a question here or on launchpad
<lostylost> cheers
<lostylost> ImmortalPendingDeletion: Unable to delete transform temporary directory D:/invoice/trunk/.bzr/checkout/pending-deletion.  Please examine D:/invoice/trunk/.bzr/checkout/pending-deletion to see if it contains any files you wish to keep, and delete it when you are done.
<lostylost> that is the error message I got
<lostylost> I just deleted all the stuff in there, thinking it was "temporary" working directory stuff
<lifeless> its things that are to be deleted
<lifeless> during the application of a merge/update/pull
<lostylost> so if I actually deleted them they wouldn't have been then?
<lostylost> ?
<lostylost> or are they all moved there temporarily?
<lostylost> hrmm
<lostylost> just the actual working tree files?
<bob2> how do files end up there rather than just conflicting?
<lostylost> how come a whole local commit disappeared, along with it's message?
<lostylost> I shouldn't have been so rash, damn it :(
<lostylost> bob2: it was an "ERROR:"
<lifeless> lostylost: the update should have left your local commit as a pending merge
<lifeless> lostylost: the bug that caused the update to fail probably left the tree unupdated; the commit is still in your repository
<lostylost> I don't see it by running bzr log --forward
<lostylost> I have only 19, should be 20
<lifeless> lostylost: if you install the bzr heads plugin, you can do 'bzr heads' to find it
<lostylost> thank you!
<lostylost> hope yet
<Solarion> so, when you merge, you merge into the working directory?
<Solarion> you can't merge up?
<bob2> merge doesn't commit, so no
<Solarion> merge doesn't commit?
<bob2> merge merges changes into your working tree
<lifeless> merge generates a tree with the combination of two existing commits
<lifeless> this gives you the ability to review what you are merging
<lifeless> and then do 'bzr commit' to save it
<Solarion> right
<Solarion> that makes sense.
<Solarion> I really like that the log has all of the previous logs in it.
<bob2> do git hg etc do the nested log thing?
<Solarion> no idea
<Solarion> I found bzr and it was tasty crack, so here I am.
<lifeless> bob2: hg doesn't
<lifeless> bob2: AFAIR git doesn't
<Solarion> how does one manage a remote bzr branch?
<Solarion> (without logging in, cd'ing to the dir, and then running commands there)
<Solarion> in fact, I'm now doing the 3-branch interface between svn and bzr so that I can stay sane and keep my collaborator happy.  :)
<bob2> push to it and/or checking it out and commiting to it
<Solarion> :(
<lifeless> Solarion: define manage
<Solarion> lifeless: I have 2 branches (+ the one in SVN)--a working branch and the trunk.  Trunk is kept synchronized with the svn repo and merges in changes from the working branch, but otherwise I don't really directly access it.
<Solarion> lifeless: the two branches are on my server, so that I can keep synchronized between workstation and laptop (and whatever else).
<lostylost> no luck with bzr heads
<lifeless> lostylost: you get only one head ?
<lostylost> no I was jumping the gun
<Solarion> lifeless: I can bzr push/pull to/from the working branch from my workstation to keep it up to date.  However, it seems that I have to be in (a branch of) the trunk branch or (a branch of) the working branch to sync between them, or to sync to/from the svn server.
<lostylost> I think I am inluck
<lostylost> bzr head --all shows it
<lostylost> sweet
<Solarion> lifeless: Thus, I either have to pull a copy of whatever branch I'm actively working on, do the changes, and push it up, or else ssh in to the server to do the operations.
<Solarion> lifeless: Ideally, I'd like to just, say, run bzr --root=sftp://server/path operation
<lostylost> ok so it's in there, how do  retrieve it?  it says it's a (dead) revision?
<lifeless> lostylost: bzr merge . -r revid:THEREVISIONID
<Solarion> lifeless: in which case, instead of looking at the current directory, bzr acts like sftp://server/path is the current working directory (or root of the branch)
<lostylost> thank you very much lifeless, your a godsend
<lifeless> Solarion: we don't generally do working tree operations over teh network because things like 'stat' are really not reliable, and they are needed
<lifeless> Solarion: why don't you just have both branches on your laptop and work there
<Solarion> lifeless: I have a workstation I work on about the same amount of the time
<lifeless> Solarion: then whenever you feel like it bzr push to the server (e.g. when you are about to switch to another machine)
<Solarion> I suppose that'll work
<Solarion> still, I like the --root option idea better.  :)
<lifeless> what I'd do is different
<Solarion> Also, I'd like a pony.
<Solarion> bzr --pony
<lifeless> I'd just work on the laptop and workstation as separate branches
<lifeless> 60% tests passed, looks like this patch is done
<Solarion> lifeless: still not help when I need to sync the changes over to trunk.
<Solarion> I like "micro-checkins" as my boss calls it, while he likes larger changes.
<Solarion> having trunk helps put all of my little changes into one big one.  Keeps both of us happy.  :)
<lifeless> Solarion: sure; so have a checkout of trunk on both laptop and workstation
<lifeless> Solarion: then you just merge to that checkout and 'bzr commit'
<Solarion> lifeless: then I'd have to care about keeping them synchronized.
<lifeless> Solarion: no, bzr will manage that for you
<Solarion> The management of it that I've seen thus far from bzr consists of telling me I need to merge the changes manually.  :(
<lifeless> checkouts won't commit if the master is newer than the local tree; just like 'svn'
<Solarion> anyhow, ssh'ing over to the server isn't a big deal; it's just annoying
<lifeless> so you'll get 'cannot commit, run bzr update' if you haven't run bzr update before merging, but thats all
<Solarion> lifeless: unless your changes + their changes require a manual merge
<lifeless> 'bzr checkout's workflow really is designed for 'trunk' situations
<Solarion> conflict
<lifeless> Solarion: then you'll get a tree you can resolve the conflict it, and when you do that and ocmmit it will be all synced
<Solarion> yeah, I ran checkout for a while, but it took a while whenever I wanted to commit.
<Solarion> lifeless: I'd rather just not have to deal with keeping multiple branches in sync and ssh to the server.
<lifeless> Solarion: ah, interesting
<Solarion> or, use the --root option (in combination with --pony)  :)
<Solarion> trunk is really just for combining commits so my boss is happy.
<Solarion> the less annoying it is, the better
<Solarion> though keeping multiple branches in sync is still less annoying than having to use svn
<Solarion> interesting.  pushing the merged changes just kept my overall message, not the sub-messages.
<Solarion> (according to svn log)
<codeslinger> hi, pardon me for barging in. New user, quick question.   I cant get the authentication.conf file to work.  have read and re-read the docs till my eyeballs are spiing but just dont get what the problem is. can somebody please give me a hint.
<codeslinger> Im am trying to set up automatice password so I dont have to keep typing it.  everything else is working far as I can tell
<lifeless> Solarion: thats svn's failure to track merges AIUI
<Solarion> svn seems to fail quite a bit
<lifeless> Solarion: yes :)
<Solarion> ah well, I can put it somewhere where it'll be found in the next merge.
<Solarion> lifeless: thanks for the help, but it is bedtime for bonzo
 * Solarion heads to bed
<lifeless> codeslinger: I have no idea sorry; I haven't used that feature
<dysinger> hmm I was all excited to use bzr-svn today.   However after trying it - it's unusable slow.  Am I doing something wrong?  I branched from svn.  I did a "lightweight" checkout which took a couple of minutes.  I open a file a put one line of whitespace in and committed locally.  Then I did a push parent.   It's been going 5 minutes now with 4 ===
<lifeless> dysinger: there is a first time startup cost which is pretty high AIUI
<codeslinger> how many megs of files??   speed is good for me with about 40megs of files.
<dysinger> I put one line of whitespace in a file and made a commit comment - then I am trying to get that back into sv.
<dysinger> svn.
<lifeless> dysinger: so you're pushing to svn:// ? from bzr?
<dysinger> It's been twirling for 5 minutes now.
<foom> dysinger: the first time you do "anything" it loads a bunch of stuff into a cache
<codeslinger> lifeless -- are you saying that you type the password after every command???  or just run everything local?   I find the password prompt tedious real fast.
<dysinger> trying to push that one commit up
<lifeless> dysinger: like I say though, AIUI there is a first time cost where it maps a bunch of data
<lifeless> codeslinger: I use ssh with ssh-agent
<dysinger> didn't it map that on the way when I branched it?
<foom> probably not since you did a lightweight branch
<dysinger> No the test commit to svn I did on the branch I took from svn
<lifeless> dysinger: I've seen jelmer explain this to other people;
<lifeless> dysinger: if you allow it to finish and try again I understand it to be much much faster
<dysinger> I branched my trunk svn project with bzr-svn, made one line of whitespace and then tried to push that back to svn
<dysinger> lifeless - ok
<codeslinger> lifeless -- ssh-agent -- oh, okay, I see a vague reference to it, but did not yet find/read that section.    if that works well then I guess I better give it a shot
<foom> btw, is your home directory on a local disk?
<dysinger> It's taken forever so it's scared me.
<dysinger> It's never taken this long with file:// or sftp://
<foom> i ran into the issue where it was taking *extra* forever due to it putting the cache on NFS.
<codeslinger> could be the speed issue is related to the hybyrd interface to svn.  I create a clean repository from scratch and was satisfied with the speed.  its not a mamoth project, but it's not lightweight either.
<dysinger> I am hoping this is just some one time cost.
<dysinger> it's been committing my one line of whitespace for 10 minutes now.  It's churning through things like it's evaluating all 5000 commits 1st though
<foom> it is
<codeslinger> does anybody else have any ideas about authentication.conf ???   is there a trick to getting it to work???  maybe its a bug???
<lifeless> spiv: ping
<lifeless> spiv: I'd like a quick chat
<lostylost> thanks again lifesaver
<lostylost> lifeless
<lifeless> lostylost: np
<dysinger> How do I manipulate the "parent" branch - say I branched and then the parent is gone now.
<poolie> dysinger, i believe it's set by pull --remember
<poolie> um
<poolie> there might be a more direct way?
<dysinger> So let me ask another question - is there some benefit to setting up a rich root and the branching a svn repository into it a subdirectory vs just branching a svn directory somewhere else?  When I do a bzr info on both of them the both say rich-root type.
<dysinger> "as a subdirectory"
<codeslinger> lifeless -- Im trying to find the docs for ssh agent.  the manual refers to it in several places.  but nowhere do  I find a section on setting it up???
<dysinger> I don't see the benefit of the creating a bzr init-repo --rich-root repostitory and then going into that directory and bzr branch http://my/svn/repo
<dysinger> I can just  bzr branch http://my/svn/repo directly
<dysinger> both ways I can checkout --lightweight from it.
<dysinger> maybe I am missing something.
<foom> you can have a heavyweight checkout for "free" inside the repo
<foom> instead of just a lightweight one
<dysinger> oh you mean I don't have to specify the --lightweight ?
<foom> not only don't you have to specify it, you get all the revision data immediately there
<codeslinger> from reading the manual, it says that the main advantage of the repro is when you have multiple branches.   Lightweight is basically for when you want just the files and nothing else.  for instance the example give is that you are publishing to a website.  otherwise heavywieght is usually what you want.
<codeslinger> when you have multiple branches the shared repro is able to avoid duplication.  if you only have one branch you won't see any savings.
<codeslinger> question: I have multiple projects that use some of the same files.  I can keep all of these shared files in their own directory.  what is the best way to share them amoung multiple unrelated projects?
<Peng> You'd put them in another branch, and include them with subtrees (something akin to svn:externals). Unfortunately, that's not exactly supported yet. :P
<Peng> s/include them/include that branch/
<dysinger> ok Let's take the case of using a subversion "trunk" repository as the parent:  If I create a shared repo and then branch svn trunk into it as "trunk" and then I have another branch from svn called "branch-x" that I clone and then I branch locally from trunk.  You are saying that the shared repository is aware of the commits so that it doesn't duplicate data ?
<codeslinger> its not clear to me how to do subtrees, but some of what Ive read cause me to think that it is still being developed.
<bob2> dysinger: for branches within the repository, yes
<dysinger> ok I see the benefit then.  Thanks.
<dysinger> So I am going to create a shared repo with bzr init-repo --rich-root myrepo then branch a remote svn "trunk" and remote "branch-x" into the repo.  THen I can go into the repo and "checkout trunk my-topic" and make commits to that.
<Peng> codeslinger: Yeah, subtrees are experimental.
<bob2> well, "branch trunk my-topic"
<dysinger> checkout is not recommended?
<codeslinger> ok, thanks, I will avoid that for now.   any ideas where I can find the docs to config ssh agent?
<dysinger> branch would give me a clone
<dysinger> right?
<bob2> well, you'd need to make a my-topic a branch in the repository, then check that out
<codeslinger> yes, branch is a connected clone
<dysinger> That would make 3 layers there - 1 branch svn, 1 more branch "my-topic" and then one checkout?
<lifeless> dysinger: checkout is recomment just fine
<bob2> three steps, yes
<dysinger> I don't see the benefit ...  In git I clone, then branch, work, commit, merge, push etc.  Then delete the branch and move on.
<codeslinger> the checkout is your working set of files where you make you changes. the svn branch would be your base
<dysinger> Couldn't I just branch from svn and then branch off that for topics, commit and then push  ?
<bob2> you can
<dysinger> oh codeslinger says I _can_ checkout off the svn branch
 * dysinger needs to learn the diff between branch and checkout.
<Silktrader> Hello.
<bob2> yes, using a repository is just an organisational/efficiency thing
<bob2> sorry if I confused you by suggesting it
<dysinger> It's fine - I am drinking from the firehose
<dysinger> :)
<dysinger> No better way to drink if you ask me.  -  just get it over with
<Silktrader> I had a glance at Bazaar's container formats, and I see dirstate and knit ...
<Silktrader> Is there a way to have plain files stored?
<Peng> Silktrader: Plain files? What do you mean? Why?
<Silktrader> I am using bzr to track changes on Word documents.
<Silktrader> Though I would like to index them.
<Silktrader> So I can search within those.
<Silktrader> Right now bzr stores revisions as .packs.
<Peng> For a mirrored bzr branch on Launchpad, would bzr+http be better than http? Does "bzr pull" or whatever LP uses perform better in some way with bzr+http?
<dysinger> When you guys checkout from svn - I am sure some of you do in here - just to deal with other projects that use svn.  When you do that do you checkout the repository root or do you checkout individual branches, trunk and tags ?
<Peng> FWIW, 99% of the time, LP will find no new changes.
<Peng> Silktrader: Why do you want to index the repository instead of the working tree?
<Silktrader> Because I may delete content from the working tree.
<Silktrader> I have document X, which I edit and commit.
<Silktrader> Then I reedit document X, take off stuff, recommit.
<dysinger> Sorry to ask so many questions - I promise to help out with other noobs when I get done.
<Silktrader> I would like to be able to search through what has been deleted, for instance.
<Silktrader> That is - through old revisions.
<Peng> Silktrader: Ooh, that's pretty neat.
<bob2> dysinger: latter, doing the former on big svn repositories would be huge
<foom> checking out the repository root is a good way to use up your whole hard drive. :)
<dysinger> OK so you make a shared bzr repo and then checkout trunk and checkout branch-a etc.
<codeslinger> dysinger -- okay, say you start out with the svn in the shared repository.  you leave that prestine as your base.  then you make a branch in the repository and that becomes your target for any changes.  these both are living on the server.   now you do a branch on your local computer from the branch that you made of the svn.  this thrid branch is your working set, where you make your changes.  when you do a checkout you are connecting your 
<codeslinger> branch to the servers branch such that any commits are made immediatly to the server as well as local.  this is refered to as lock-step mode and is probably closest to how you are used to working with svn.   but you do not actually have to do a checkout, you can skip that process and work with the local branch in dristubited mode.
<Peng> Silktrader: Anyway, bzr currently does not have a format that stores a bunch of plain files. That would be horribly inefficient.
<Peng> Silktrader: You could always develop one if you wanted to . . . :D
<Silktrader> Peng: I understand. But given small repos ... space efficiency is not so important, is it.
<foom> Peng: you'd be surprised: some VCSes only store full files, no diffs.
<Peng> Silktrader: True.
<bob2> Peng: hardlinking identical files...
<foom> Peng: "hard disk space is cheap" is the theory
<bob2> you could call it a "revision library"
<Silktrader> Foom: which ones?
<Peng> foom: What, svn working copies (ughhh, that was a bad design decision) and git? With git, you're supposed to pack occasionally.
<foom> Silktrader: accurev is one
<Silktrader> Proprietary, right?
<foom> yes
<bob2> doesn't svn gzip pristines now?
<Silktrader> Gzip is already decent ...
<foom> not in the last released version...dunno about the next version
<Silktrader> As content can be easily indexed within archives.
<dysinger> codeslinger - If I didn't want to go that complex and keep it distributed like git - I could just create a shared repo, branch svn there and then branch again from that - commit, commit and then push back to svn.  Correct?
<codeslinger> I dunno....  but frankly I'd be pretty nervous about it.  plenty of opportunity for bugs to byte yea in the interface/conversions to/from svn
<dysinger> really?  so bzr-svn isn't ready for prime-time?  I have to work with others that aren't on bzr - they are on svn.
<codeslinger> did you figure out how to get it to not ask you for a pasword?
<dysinger> y
<codeslinger> whats the secret???   to the password?  I've been thrashing it for a couple of hours now with no luck.
<dysinger> I mean I would be all for fully distrubuted mode with git or bzr for me team but I have to get them to take baby-steps
<dysinger> I just cloned (branched) from subverison with http://myuser:mypassword:server/repo
<dysinger> I mean http://myuser:mypassword@server/repo
<dysinger> http basic style
<codeslinger> awww  thats too simple :-)    thanks.
<dysinger> Maybe it doesn't remember my password though - I need to use it more to make sure.
<dysinger> It does at least keep the username - I can see that in the bzr info
<lifeless> foom: disk space is cheap; disk cache is not
<lifeless> Silktrader: I suggest you index by writing a small amount of glue for your indexer
<lifeless> Silktrader: so that it can extract all the historical versions during initial indexing
<foom> lifeless: yeah but who ever accesses old revisions, anyways!
<codeslinger> as fro svn, I'm a bzr noob.  I only know what Ive read in the docs so far.   but my overall impression is that bzr is still a little young.  plus just general experience says that a hybyrd interface is asking for trouble.  I'd be very conservative if I was you, last thing you need happening is corruypting either of the stores.  won't make a good impression on your team.
<Silktrader> I do, foom. Very often.
<Silktrader> Perhaps not when writing software.
<Silktrader> lifeless: thanks, but can't code a plugin for the indexer ...
<Silktrader> ... I'd rather use the filesystem and that's it.
<lifeless> Silktrader: write it in fuse then :)
<lifeless> Silktrader: but that said, sounds like the indexer is pretty primitive
<Silktrader> Come on, write a fuse plugin to deal with that? :-)
<lifeless> Silktrader: sure; expose the historical trees over fuse
<Silktrader> Lucene, Google Search, etc.
<foom> hey now, a fuse plugin for bzr would be nifty
<Silktrader> They can't deal with bzr's packs.
<foom> someone was just telling me the other day how awesome it was in ClearCase how you could just use normal unix utilities to navigate history
<lifeless> Silktrader: they wouldn't need do; you can generate any flat namespace you like;
<lifeless> foom: yah; I wrote a fuse plugin using pyfuse and pybaz
<Silktrader> lifeless: It's great to be spurred to write code ... but I don't have the time nor the skill to :-)
<Silktrader> Besides ...
<Silktrader> I work on Windows machines ...
<Silktrader> So no fuse I suppose.
<codeslinger> there is a reference in the manual with pointers to an article about using word revision tracking in conjunction with bzr
<foom> there's fuse for windows now I believe
<Silktrader> codeslinger: searching, thanks.
<Silktrader> codeslinger: I see a DocDiff plugin.
<codeslinger> that could be it, I didn't read it since I dont need it.   be careful of word revisions though they are not that reliable.
<Silktrader> They suck.
<Silktrader> Both Word and OO.
<codeslinger> it's hard to do it right, the complexities of the documents is huge.  I don't know what OO's track record is for revisions, but I have a lot of experience with word revisions and know that they are not something you would want to use with complex docs, as long as you stick to text with no tables or art objects you should be fine.
<lifeless> with oo you can get diffs from bzr, using bzr to track the revisions
<codeslinger> that sounds great.  I was guessing/hoping that OO had done it better.
<Silktrader> lifeless: Yes. I assume OO's format is also more portable than MS.
<Silktrader> But it still doesn't solve the searching issue ...
<Silktrader> I should probably be looking for DMS.
<Silktrader> Document Management Systems ...
<Silktrader> But bzr is so simple and easy ...
<Silktrader> Software like Alfresco and whatnot puts me off.
<codeslinger> well, good luck.  I gotta get back to my bzr slugfest.
<lifeless> spiv: ping
<spiv> pong
<lifeless>   File "/home/robertc/source/baz/search-results/bzrlib/smart/client.py", line 77, in call_with_body_bytes_expecting_body
<lifeless>     request = self.get_smart_medium().get_request()
<lifeless>   File "/home/robertc/source/baz/search-results/bzrlib/smart/client.py", line 33, in get_smart_medium
<lifeless>     return self._shared_connection.connection
<lifeless> AttributeError: 'FakeMedium' object has no attribute 'connection'
<lifeless> and I'm seeing an error about read_streamed_body
<spiv> Hmm.
<lifeless> so I was pinging you about the fake medium error
<lifeless> where is the voodoo to fit that in
<spiv> lifeless: See FakeClient
<lifeless> the second one comes from
<lifeless>   File "/home/robertc/source/baz/search-results/bzrlib/repository.py", line 832, in insert_data_stream
<lifeless>     for item_key, bytes in stream:
<lifeless>   File "/home/robertc/source/baz/search-results/bzrlib/remote.py", line 996, in _deserialise_stream
<spiv> lifeless: I think you want to override call_with_body_bytes_expecting_body in that.
<lifeless>     stream = protocol.read_streamed_body()
<lifeless> AttributeError: 'SmartClientRequestProtocolOne' object has no attribute 'read_streamed_body'
<lifeless> ah
<Silktrader> Well fellows, thanks for the help. Have a good day, cheers.
<spiv> The second error is correct, in that there is intentionally no read_streamed_body on SmartClientRequestProtocolOne.  It's implemented only on SmartClientRequestProtocolOne
<spiv> Er,
<spiv> It's implemented only on SmartClientRequestProtocol*Two*
<lifeless> err, ROTFL> L> L>
<spiv> A laugh with a stutter?
<lifeless> yah
<lifeless> so why am I getting the old protocol?
<spiv> You'll have to demonstrate that one in person for me sometime ;)
<spiv> Good question.
<lifeless> laugh repeatedly tailing off a little slowly
<lifeless> ok, first one fixed
<spiv> Can you give me a little more context?
<lifeless> yes
<lifeless> I'm testing a modified streaming revisions pull
<lifeless> that I upload a body to
<lifeless> that contains start_keys\nstop_keys\ncount
<lifeless> I'll defer this till tomorrow now, too many hours working :)
<spiv> lifeless: that's odd
<spiv> lifeless: I don't know why you'd get a ProtocolOne there
<lifeless> oh
<lifeless> callwithbodybytes
<lifeless> uses One not Two
<lifeless> is it safe to change that ?
<Peng> Cool, with dirstate-tags, pulling with no new revisions only downloads the format files and last-revision.
<spiv> Oh, huh.
<Peng> Oh, and tags.
<Peng> With bzr+http, it still makes 24 requests.
<spiv> lifeless: I guess so, it seems wrong that it's hard-coded either way in that class though.
<Peng> Same as when there is 1 new revision.
<spiv> lifeless: but it should at least be hard-coded consistently :)
<lifeless> spiv: righto, well I'll change it in the new method I add
<lifeless> spiv: and let you worry about consistency
<lifeless> :)
<spiv> lifeless: sounds good :)
<lifeless> woo passes
 * lifeless runs a full suite and organises food
<Peng> Ooh! I upgraded all of my local branches recently but forgot about my remote ones!
<Peng> Err, wait, I don't know.
<Peng> Right, I don't want to upgrade that branch.
<Peng> Apparently on one project still using dirstate, some of my remote branches are dirstate and some are dirstate-tags.
<Peng> I guess it depends on whether they were created before or after I upgraded my local stuff to packs.
<abentley> bob2: revision library?  For shame!
<poolie> ok, out for a bit
<poolie> good night, abentley, or morning
<abentley> poolie: good night
<dysinger> What does --rich-root really do ?  the help doesn't really explain it and the online manual doesn't mention it.
<lifeless> it adds a versioned / to the disk format
<lifeless> which is needed to handle svn branches as they are made via copies
<dysinger> ok don't quite get that but ok
<lifeless> it will eventually be the default format
<dysinger> the manual just says bzr init-repo X-repo (without the rich-root).
<dysinger> ok cause when I do a branch from a svn repo it does the rich-root by default - I can see it in the info
<dysinger> Is the --no-trees usually used with checkout ?  And is checkout mostly used with the centralized workflow only?
<dysinger> that seems to be the pattern in the examples in the manual
<fullermd> dysinger: It Depends(tm)   :)
<dysinger> heh
<lifeless> checkout is most often a tool for centralised workflows
<dysinger> I am just trying to figure out the best setup for working with a team that mostly uses svn.  I could init-repo and "checkout" the remote svn repo and then make branches off of that for work.  Or I could "branch" the svn repo and then make branches off of that for work.
<lifeless> --no-trees in init-repo is used when you expect to have your working areas elsewhere yes
<dysinger> lifeless gotcha
<lifeless> dysinger: so there are two dimensions here
<lifeless> 1) init-repo or not
<lifeless> 2) checkouts or branches
<fullermd> Well, you _can_ do it either way, or probably a dozen others.  If it were me, *I* would make a checkout of the svn branch, then branch off that.
<dysinger> OK so --no-trees would be like git clone --bare
<dysinger> It's for history only then.
<dysinger> no work
<lifeless> init-repo is *simply* for sharing .bzr/repository amongst many branches
<fullermd> That way I could use that checkout just like it were a svn checkout; update, commit, etc.
<lifeless> thats all
<dysinger> checkout would be if I wanted a tracking branch
<fullermd> And it wouldn't let me commit and diverge from upstream.
<lifeless> so you can init-repo, then branch into the repo, and make branches from that etc
<dysinger> where commits are immediate.
<fullermd> Then I could merge ; commit into it when I wanted to land my other branches.
<lifeless> or you can init-repo, and use checkouts, its all reasonable
<fullermd> (or just edit ; commit directly in it if I just wanted to make one rev right on trunk, like if I were just using svn itself)
<dysinger> ok I am getting it.
<fullermd> Right.  That checkout would then explicitly always be "whatever's in svn [mod getting behind and having to 'update' of course]"
<dysinger> There's some parallels to git (and some to svn)
<lifeless> rule of thumb is 'if your history is large, or you will have many branches, you should use init-repo'
<dysinger> What is --rich-root-pack all about?
<dysinger> Does it make a diff vs --rich-root  really ?
<fullermd> --rich-root is a variant of knits (the older repo format).  --rich-root-pack is a variant of packs (the newer repo format)
<dysinger> should I go with the newer one? Is that where everything is headed ?  I read how you guys are using packs to speed up transfers.
<ubotu> New bug: #183704 in bzr "bzr clean-tree should not remove .shelve directory" [Undecided,New] https://launchpad.net/bugs/183704
<fullermd> Well, packs ARE intended to replace knits.  It's the direction we're going.  There are some reasons to use knits; compatibility with older versions of bzr, for instance.
<fullermd> But lacking those reasons, you probably want packs.
<dysinger> ok I have no other bzr interaction on my project
<dysinger> (no older versions)
<fullermd> packs are the default now, if you just 'bzr init'.
<dysinger> oh really
<dysinger> so I could just bzr init-repo myrepo ?
<fullermd> Yeah, as of 1.0 [I think].  They were introduced on 0.92.
<fullermd> Well, not if you want to use bzr-svn   ;)
<fullermd> It needs the rich-root variant.
<fullermd> (which isn't default)
<dysinger> oh ok so if I want to branch off of svn I MUST use the knits format
<fullermd> No, you need to use a rich-root capable format.  There's one of those for knits AND one for packs.
<fullermd> --rich-root is the knit version; --rich-root-pack is the pack version.
<dysinger> ok
<fullermd> Unless you know a reason you want to go knit, you probably want the pack.
<fullermd> (if the choice turns out to be wrong later, there are ways to convert yourself down, so it's not a lock-in decision)
<fullermd> rich-root is, though, which is the main reason it's not default; you can convert data from packs into knits, (or from rich-packs into rich-knits), but you can't convert from rich to non-rich.
<dysinger> so just so I am understanding - in order to use svn I must use a rich _variant_ which is either rich-root or rich-root-pack - either one.  Packs are the default bet are not rich right?
<dysinger> s/bet/but
<fullermd> Right.
<dysinger> so I could bzr init-repo --rich-root-pack myrepo and the branch svn off into it
<fullermd> Bingo.
<dysinger> ok thanks for your help
<dysinger> I am getting it.
<dysinger> I promise I'll help others once I do
<lifeless> you want rich-root-pack
<dysinger> someone told be just rich-root earlier
<dysinger> but I want to go with the newest format
<dysinger> if I have no legacy to deal with
<lifeless> yeah I forgot there were two variants
<fullermd> Yeah, that might just be a finger-o; thinking 'rich root' and forgetting to append the pack.
<dysinger> can you branch off of a  checkout ?
<fullermd> Yep.
<dysinger> I could see an advantage of checkout for svn and the branch off of that for work.
<dysinger> I don't know - maybe not.
<fullermd> I'd do it that way.
<fullermd> That way the thing that directly touches svn acts like an svn client would; helps reduce impedance mismatches.
<dysinger> y
<dysinger> Especially for me - I wouldn't use that checkout for anything other than tracking the remote branch
<dysinger> and merging into my topic branches
<fullermd> Really, I also work that way on multi-dev bzr projects; there's a shared trunk that I checkout.  I do trivial things directly on trunk, just like I did with CVS.  And branch off that for more involved things.
<dysinger> If make a branch and then want to push back to the parent - what's the best way to do that
<dysinger> I can re-specify the parent in the push command but that seems a bit redundant
<fullermd> Well, with this toplogy you wouldn't push back; you'd merge your topic branch _into_ the checkout, then commit that merge (and the commit in the checkout goes upstream)
<dysinger> ok
<dysinger> so it's done with merges
<fullermd> Sorta a hierarchial setup, rather than the mesh-like setup of more 'fully distributed' workflows.
<fullermd> Well, you _can_ do it with pushes.  But that gets you back to impedance mismatches with svn, and (IMAO, anyway) is more likely to lead to confusion.
<dysinger> don't want to do that
<dysinger> (mismatches)
<dysinger> I'll just keep it straight checkout and merge/commit into it.
<dysinger> from my branches.
<fullermd> Yeah.  This way you have the svn side, which acts like svn.  You have your bzr side, where you do whatever you want, bzr-style.  And all interaction between them funnels through your bzr-svn checkout.
<dysinger> excellent
<fullermd> Seems cleaner to me  [note, though, that I've never used bzr-svn, so this is all "how it fits in my head" and from reading about other people using it]
<dysinger> and if I want I can take one my branches and 'push' it off to a 3rd machine where I can share it with team mates distributed-style.
<fullermd> Right.  No problemo.  You can get all wild and wooly on the bzr side.
<dysinger> that's how I did all this with git so it makes sense
<dysinger> git/svn
<dysinger> I really like how bzr doesn't treat svn like a side-car-add-on
<dysinger> It's just a transport/storage plugin
<dysinger> git-svn is a one-off-hack
<fullermd> That's because we don't trust svn way off to the side, where we can't smack it   ;)
<dysinger> and the commands are different than the normal git flo
<dysinger> flow
<dysinger> It's sucky
<dysinger> (but fast)
<dysinger> I was in a svn working directory and I accedentally typed bzr st
<dysinger> and it told me the status
<dysinger> I was like ???
<dysinger> so then I commit with bzr too and it worked !?
<dysinger> that's too transparent
<fullermd> Heh.
<dysinger> bzr log worked - it was like it was a bzr repo
<dysinger> then I was looking at bzr init-repo help
<dysinger> and it has --subversion in it
<dysinger> so bzr-svn is pretty integrated.
<sabdfl> if you have a branch, with a few files added, and you want to split that into two branches which add different sets of files, can you do that easily with bzr?
 * dysinger is a noob
<fullermd> sabdfl: Mmm.  I think you'd have to sort of the files manually.  Maybe "branch ; merge --uncommitted", the rm the right files on each side?
<dysinger> I imagine you could always make two branches from the one
<dysinger> and just prune away until you had it like you like
<sabdfl> fullermd: i'm worried that rm'ing the files on each side would mean the whole lot get rm'd when these land in trunk
<fullermd> Well, I'm reading you as "bzr add'd but not committed".
<fullermd> If they're committed files you want to rm, then yeah, that would happen.
<dysinger> since bzr doesn't auto-commit merges though
<fullermd> In that case, I think you'd have to backtrack to before they were added, and recreate history from that point onward in two different branches.
<dysinger> you could merge the two branches back in
<dysinger> but revert the removes
<dysinger> and then commit
<fullermd> Well, or that.  And if you edit the files in the branch you don't delete them in, it'll conflict and you can resolve it from there.
<fullermd> That means adding to your work at merge-time.  I guess which is Right depends on how long they'll be unlanded, and how much history you'd have to rewind, and yada yada.
 * igc dinner
<lifeless> sabdfl: split the branch into two, delete on each side. then merge each side to the other with the following recipe:
<lifeless> bzr OTHER; revert .; commit -m 'sync with split branch'
<lifeless> the . is important
<fullermd> Twisted.
<lifeless> then you'll have two branches which think they are mutually merged (but aren't), so merging with trunk will do the right thing (well, you can test this, its late, but my head says this will work)
<lifeless> ciao
<lifeless> perhaps test locally first; merging both serially to a copy of trunk :)
<sabdfl> lifeless: bummer, i started doing this the hard way, and will just finish
<sabdfl> but have a note of the recipe and will try it next time
<sabdfl> thanks!
<rjek> Gah!  I hate Mac OS X.
<rjek> I can't install bzr on it from MacPorts, because it can't fetch paramiko from any of the places it knows about.
 * rjek wonders why Fink went out of fashion.
<rjek> So.  Is bzr available for Mac OS X 10.4 using a package management system that actually works? :)
<dysinger> rjek:  I just posted some instructions on the bzr-svn page about 6 hours ago which includes bzr install
<dysinger> without macports or fink
<dysinger> btw I think the #bzr channel peoples are soooo... awesome
<dysinger> and the bzr developers
<dysinger> it worsk
<Kamping_Kaiser> is the correct capitalisation Bzr bzr or BZR?
<dysinger> works
<dysinger> I think it's actually bZr
<Kamping_Kaiser> >,<
<dysinger> :)
<Kamping_Kaiser> :P
<dato> Kamping_Kaiser: the correct capitalization of the software is Bazaar, and the correct capitalization of the binary is bzr
<dato> if you'd like to use bzr to mean "Bazaar", then, well, write "bzr" :-)
<Kamping_Kaiser> dato, so its Bazaar? (not Bazaar-ng or any of the short versions?)
<dato> Kamping_Kaiser: yeah, Bazaar, but many people use bzr as well. Like Subversion/svn or Mercurial/hg
<Kamping_Kaiser> dato, thanks for that
<dato> you're welcome
<rjek> dysinger: Sounds fun.  URL?
<dysinger> http://bazaar-vcs.org/BzrForeignBranches/Subversion
<rjek> dysinger: Which version is Leopard?
<rjek> I have 10.4
<dysinger> 10.5 is leopard but it should work all the same IMO
<rjek> Does 10.4 ship with a version of Python that isn't too ancient?
<dysinger> I don't know that for a fact though
<rjek> (which I had assumed is the reason bzr is packaged more simply for 10.5 than for 10.4)
<dysinger> open a terminal
<rjek> What is this easy_install thing, too?
<rjek> I have Python 2.3.5, btw.
<dysinger> http://peak.telecommunity.com/DevCenter/EasyInstall
<rjek> ta
<rjek> dysinger: It appears to be doing something \o/
<rjek> Although it appears to be having the same difficulty as MacPorts: it can't reach www.log.net to download paramiko.
<dysinger> Should upgrade to 10.5 then! :)
<rjek> This Mac's lucky I've not thrown it out of the window.
<rjek> I *hate* Mac OS.
<dysinger> Then erase it and install something better
<rjek> Not an option, given the entire point of the exercise it to ensure something works under Mac OS :)
<rjek> I'd be furious if I actually paid for this Mac.
<dysinger> Something does work
<dysinger> As I experienced today
<dysinger> What is your pref?
<rjek> No, I mean I'm making sure a piece of our software's portable to it.
<dysinger> Is the hardware garbage?  That's rarely the case
<rjek> I hate Apple hardware almost as much as I hate their OS.
<dysinger> Oh are you a M$fanboy?
<rjek> No
<dysinger> Then BSD ? Linux?
<rjek> But I can tolerate Windows for longer periods than I can Mac OS: it still ultimately annoys me.
<rjek> All OSes annoy me: Mac OS is just top of the pile.
<dysinger> Wow.
<rjek> dysinger: My development environment is Linux.  Where I build Linux and Windows versions of stuff.  Mac OS stuff I have to do self-hosted given there's no good toolchain like MinGW for Linux yet.
<dysinger> Winblows is the top of my shit pile.  That's an absolute crap-pile.
<dysinger> rjex "I hate Apple hardware almost as much as I hate their OS."  Wow
<dysinger> What on this green earth do you actually like?
<rjek> I like my Thinkpad.
<rjek> It's built like a tank, doesn't have keylegends that wear off if you look at them too much, has three mouse buttons, and wasn't over-priced.
<dysinger> With what freedos?
<rjek> Erm.  Ubuntu as it happens, but you've left now.
<fullermd> I think freenode logs you off if you say 'freedos'.
<rjek> heh
<rjek> fullermd: Didn't kick you off. :)
<fullermd> I'm special.  My mother always told me so.
 * rjek grins.
 * rjek checks out the source on Linux box, burns it onto a CD-R, and shoves it in the Mac that way.
<fullermd> Do regular CD-R's work in a Mac, or do you have to get special multi-colored aerodynamic CD-R's?
<rjek> Crap, I hadn't thought of that.
<rjek> It might spit it out in disgust for being a cheap Tesco CD-R.
<codeslinger> hi, anybody awake?
<matkor> codeslinger: Yes, but I most likely will not be much help ;)
<dato> abentley: I'm sorry for the format flags mess
<abentley> No worries.
<codeslinger> Great!!!    question:  I don't see this in the manual.  is the physical location of a branch fixed or can I arbitrarily move it to another location?
<abentley> I could have read it more carefully, too.
<abentley> codeslinger: You can move it anywhere you like, even mirror it to another machine.
<codeslinger> cool!!!!!
<abentley> If you a shared repository, you have to keep the branch inside the shared repository.
<matkor> abentley: Even outside shared repository ?
<abentley> matkor: ^^^
<codeslinger> what if I move the repository too.  basically I just want to know about disk reorg and moving the entire structure, does it have any fixed path components?
<abentley> codeslinger: If you remove the repository too, that's fine.
<codeslinger> good. thanks.
<abentley> Many commands remember the location you ran it against last, e.g. "pull".  Those locations tend to be fixed locations.
<codeslinger> bind ????
<abentley> Yes, I believe bind is one of those.
<codeslinger> er, let me be clear.  can I fix that path with bind?
<abentley> Yes.
<codeslinger> great.
<abentley> If you have a checkout, and you move the branch you're bound to, you can just do 'bind'.
<brilliantnut> abentley: Actually, I think this is one of the problems that I'm facing.. If I have a branch or checkout bound to a shared repository. If the shared repository is no longer accessible, I can't unbind it...
<abentley> Similarly, you can fix pull with pull --remember.
<brilliantnut> neither was I able to bind to a different location..
<abentley> brilliantnut: Try switch --force then, but file a bug report please.
<abentley> But you mean "If I have a branch bound to *a branch in a shared repository*...", right?
<abentley> Branches aren't "bound" to repositories themselves.
<radix> why does 'unbind' even bother doing anything with the remote branch instead of just removing the association locally, out of curiosity?
<brilliantnut> right.
<brilliantnut> abentley: I did in fact mean a branch in a shared repository.
<brilliantnut> atleast, I was facing that behaviour with 1.1rc1... I haven't had an opportunity to check since 1.1 ... To be honest, I thought it was expected behaviour..
<abentley> Right, so if you have a heavyweight checkout of that branch, and you delete that checkout, "unbind" should work.  If it doesn't, it's a bug.
<abentley> Scratch that.
<brilliantnut> I did have a heavyweight checkout... but what do you mean by delete that checkout?
<abentley> If you have a heavyweight checkout of that branch, and you delete that branch, "unbind" should work.  If it doesn't, it's a bug.
<abentley> brilliantnut: thinko
<brilliantnut> no, what if the repository isn't accessible any longer.
<abentley> The repository for the branch?
<brilliantnut> yeah.
<brilliantnut> abentley: need to take a call, brb
<abentley> Most of the information provided through a branch is stored in the repository, not the branch.
<abentley> Everything you commit goes into the repository, not the branch.
<abentley> The branch is just a pointer to the data you committed.
<abentley> So if there's no repository for a branch, it cannot function.
<codeslinger> I have a project with multiple (mostly) independant parts.  there is a client program and a public website and then the private website after you login and then the admin web site etc.  some fo the php programs are shared between all of the apps. some are only shared between the web apps.  but most files are not shared at all.  what would be the ~best~ way to organize this?
<codeslinger> "if there is no repository for a branch it connot function"   but what if it's a heavyweight checkout?  doesn't the branch contain it's own copy of the repository?
<brilliantnut> abentley: back. Here's the situation that I was facing:
<brilliantnut> I have a central repository, and many branches on the central repository (specifically including a branch called HEAD)
<brilliantnut> I have a heavy checkout of HEAD on local
<brilliantnut> commits, pulls, pushes, merges etc. work fine.
<brilliantnut> now the repository, (along with all the branches) is down.
<brilliantnut> lets say that the location has been changed.
<abentley> codeslinger: If the heavyweight checkout is created inside a shared repository, it will store data in the shared repository.
<brilliantnut> at this point, I want to bind the checkout that I have to the new location..
<abentley> brilliantnut: So bind NEWLOCATION ought to work.
<abentley> No need to unbind.
<abentley> But switch --force NEWLOCATION should also work.
<brilliantnut> hmm. I didn't try --force
<abentley> Switch ideally would not require force.
<abentley> And it should at least suggest it on NotBranchError
<abentley> Something I'd like to fix, but I've got a big queue right now...
<codeslinger> thanks for all the help.   any suggestions on best practices for dealing with the situation of shared files between different projects?  I understand the subtrees are NYI
<codeslinger> Error 1 Operation not permitted --  I have a respoitory on a server and a local branch.  the server-side was created initially by doing a push of a local branch.  what I did is to set up a conflict with another copy of the branch and then resolve that conflict and commit the changes. then I did a merge.   Now when I do a push -- which used to work -- I get the Error.   any odeas what I am doing wrong?
<codeslinger> abentley are you still there?
<rjek> He's abended!
<abentley> codeslinger: Not off the top of my head.  Sounds like a permissions problem on the server.
<abentley> You can get a full traceback by doing "push -Derror"
<abentley> rjek: Unfortunately, I can't just idle in IRC.
<abentley> I have work to do.
<codeslinger> ok, fine, thanks, I understand....    I dont think it liked that I changed the path though....   I went back to the orgianl path and now I get  bzr: ERROR: Generic path error:  'zzzzz.fetch': Failure: unable to rename '../packs/zzzz.pack'
<fullermd> Sounds permission-y to me.
<codeslinger> Im logged in as root....
<codeslinger> seems like bzr is pretty buggy.  I see plenty of high priority bugs that are pretty old.  does anybody have opinions about the actualy usability/stability of bzr.   I mean the design is pretty darn terrific, I thinks its what Ive been looking for.  bug I am concerned about the apparent level of bugginess.  and now I am just running some simple use scenarios and appear to have been hit by a substantial problem.
<matkor> I use bzr since few month and never meet bug in it ... depends prolly what you are doing ...
<codeslinger> hi fullermd!  are you the one who wrote the "rant" about BSD vs Linux?   I checked out your site.
<codeslinger> matkor -- that is good to know.  what is your typical use scenario?   I've been at it for basically one day and already hit two problems.
<fullermd> Oh, lord, and here I thought it was safe to step outside again...
<dato> jelmer: regarding bug #180128, did I do wrong by cp'ing with svn? is there another way of doing the same with bzr-svn alone, in a way that the created branch is a cp, and I can push new changesets to it?
<ubotu> Launchpad bug 180128 in bzr-svn "Cannot push to a branch `svn cp'ied`" [Undecided,New] https://launchpad.net/bugs/180128
<matkor> codeslinger: what is typical use of bzr -  developing software in many places and many branches ;)
<fullermd> I've been using bzr for...  2 years and change.  I've hit a number of bugs in that time, but pretty much all of the bug ones have since been fixed.
<codeslinger> fullermd - you make some very good points about linux, it's exactly why I switched to gentoo.  and now trying out sabayon.
<fullermd> I should go through that thing sometime and do some cleaning and updating.
<fullermd> Of course, that's a subset of needing to do the same on, like, my whole webpage.
<codeslinger> I'm am trying to figure out what I can do and should avoid with bzr.  I just tried a use scenario of creating a conflict and resolving it and somehow it is now blowing up in my face.  it may be related to the fact that I changed the location of the server path due to another bug in which the automatic password conf file is not working.
<codeslinger> fullermd -- it was a good read.
<fullermd> I was happy with how it turned out.
<codeslinger> fullermd -- the thing is, that "Aunt Betsey" is not going to be willing to compile code from scratch.  she just wants something that works out of the box.
<awilkins> codeslinger: I keep thinking about the potential for gentoo to benefit enormously from a hug distributed P2P compile system
<awilkins> codeslinger: FOr most of the common hardware setups and use flag combos, there must already be binaries out there.
<codeslinger> yeah, I set up distcc locally but iy was a pain to get working.  spent spent was greater than time saved.
<awilkins> I don't update as much as I used to, my only gentoo box is a MythTV box now
<awilkins> I used gentoo because at the time it was the only distro I could get the hardware working on ; not least because it was the easiest to get the mm-sources kernel working on
<codeslinger> "spent spent" === "time spent"
<awilkins> But I found gentoo to be a great teaching distro - it really makes you learn a lot about Linux
<codeslinger> yes, gentoo seems to combine best of most worlds.  but the "learning curve" was pretty darn steep.  so far I am liking sabayon, it's gentoo packaged to "just work" out of the box.
<codeslinger> once I finally tamed the beast, I put gentoo on all of my servers.  debian and other distros drove me nuts with their dependancy hell.
<awilkins> Agreed, not having to install GTK to get the ncurses version of BitTorrent is very useful
<awilkins> This particular box doesn't even run a desktop, just MythTV in a bare X server
<codeslinger> we are way off topic but I guess nobody is objecting....   I have seen some references in the gentoo docs to the pre-compiled binararies.  but at a quick glance it looks pretty restrictive.  so I have not pursued it. sound like you have been using it,  what is your impression?
<awilkins> codeslinger: No, I don't use precompiled binaries, I still build from source, but not often
<awilkins> FOr MythTV I still build from source because the ebuilds lag behind the trunk so much
<awilkins> But I even do that less often as it gets more stable. I'd love a build that didn't use MySQL though, that thing is a piece of trash (doesn't survive a BRS reset very well)
<codeslinger> ah, okay.   lag... yes, but over-all pretty impressive, consider php for instance. they had the updated ebuild in about 3 days.
<awilkins> I wouldn't notice ; I don't even have a cron job running emerge --sync
<codeslinger> i've found mysql to be pretty solid. perhaps the cause is elsewhere.
<awilkins> codeslinger: It's probably because the box was overheating and shutting down non-gracefully
<awilkins> This was only happening in long transcoding jobs... I've underclocked it since and it's stable even transcoding 24/7 for 3 days straight.
<awilkins> I'd swap the CPU for a mobile variant but the motherboard is a budget model and has no VCORE support.
<awilkins> I'm happy with it though, Â£43 for onboard graphics with TV-out
<codeslinger> oh I'd never use a cron job for that.   it's jsut that I happened to be looking for the php upgrade and expected to have to install it from scratch and lo there it was already  to go.  that was one of the things that decided me to switch the servers to gentoo
<awilkins> They're probably a lot snappier on core packages
<codeslinger> if you've got hardware issues it is totally unfair to blame mysql for corruption.
<awilkins> It's not exactly ACID though, is it?
<codeslinger> I've got tables with a million plus records and mysql handled it without a hiccup.  impressed the heck out of me.
<awilkins> I suppose I'm being a little unfair... it got really annoying for a while though, having to repair the tables every couple of days
<awilkins> I'm more used to RDBMs like MSSQL and MySQL feels a little toy-like in comparison.
<radix> a database _should_ be able to handle power cutoff
<awilkins> radix: My point ; if the same thing happened to MSSQL for example, it would recover fine because the transaction log would be played back when it recovered.
<awilkins> AFAIK, MySQL doesn't _have_ a transaction log
<LeoNerd> MySQL doesn't usually have transactions, period
<fullermd> Oh, heck, am I busy working through Bash MySQL day?  Crap.
<awilkins> On the other hand, it's not exactly "enterprise" deployment, being a mythtv box. SQLite managed to be ACID though ; I'd be interested to see how easy it was to port MythTV to use that instead.
<LeoNerd> SQLite is nice.. it lacks a lot of abilities but it's very upfront about that. "Here's what we do, here's what we don't."
<codeslinger> mysql != toy  it's being used by some pretty big players such as the census buru and the airline reservation system.  if you think it toy because of minimal interface then try mysqladmin it is good.
<awilkins> In any case, I've not had to repair the tables since I underclocked the CPU, so hooray.
<LeoNerd> Er.. no... I think MySQL is a toy because of all the crazy things it does
<awilkins> codeslinger: I'm happy enough with SQLYog on windows and phpmyadmin
<codeslinger> transactiosn and logs are options that you turn on when desired.
<LeoNerd> Have you seen such things as the example SELECT * FROM table WHERE col IS NULL AND col IS NOT NULL;  ?
<LeoNerd> It returns a row :)
<fullermd> I prefer the high-quality data validation, myself.
<fullermd> 's all way the heck off the #bzr path, though.
 * awilkins likes bzr but hasn't really tried shared repositories yet
<codeslinger> yup, so I am going to say bye now.  see you around, good chating.
<awilkins> Am I rght in thinking that if I wan't proper merge tracking converting over a old CVS repository I;m going to have to do it myself?
<fullermd> Just reading that question gives me the twitches...
<awilkins> It's worse, it's not even a real CVS repository, it's MKS
<awilkins> I've already patched rcstools not to choke and die on the MKS RCS format though
<awilkins> MKS does at least have some notion of atomic commits
<awilkins> But it doesn't track merges and even if it did, the merges are being done here by some horrible old Java
<awilkins> (MKS itself is some horrible old Java too)
<awilkins> This stuff branches by copying individual files into their own "change package" folder and working on them there
<awilkins> I'm supposed to be developing this on the back of SVN but after a few days trying bzr I'm rather enamoured of it's speed and merge support
<awilkins> I'm fairly convinced that even if the final product is svn-driven, just using bzr for development and testing is going to increase my productivity enormously
<fullermd> Well, I ended up using bzr because I figured svn was mature enough to look at replacing CVS with, then looked at it closely.  So using bzr instead of svn sounds perfectly reasonable to me   :)
<awilkins> The only problem is that the Eclipse plugin is not ... mature
<awilkins> Which is a real stumbler for the automation that my users expect. *sigh*
<fullermd> Ah, well, I'm waiting to eclipse itself to mature so that it looks more like vi   ;>
<awilkins> Isn't there a vim editor plugin for Eclipse?
<brilliantnut> eclim
<awilkins> fullermd: Are you an MD or is that something else?
<fullermd> Oh, no, it's initials.
 * awilkins does healthcare IT
<fullermd> First account I had used last name and initials as the naming scheme, and it's only been a millennium since then; too little time to get aroudn to changing it.
 * fullermd doesn't, and is glad of it.
<krish> hi, in bzr branch http://bazaar.launchpad.net/~timepass/timepass/timepass-devel
<krish> ~timepass is project name
<krish> what is the next timepass for?
<krish> or is ~timepass the name of the team
<dato> krish: yes, the team
<krish> then the next timepass is for?
<krish> timepass-devel is my branch
<krish> what does the timepass between these two mean?
<dato> the name of the project
<dato> (to which the branch belongs to)
<krish> oo.  so i have to use     registrantofbranch/projectname/branchname always
<dato> yep
<krish> thks dato. :)  im new to bzr and its the first versioning system i m using. todays my first day. thks a lot
<dato> you're welcome
<LeoNerd> It's not a bzr thing - bzr doesn't care.. that's just a file path
<dato> krish: you have to use "registrantofbranch/projectname/branchname" for *launchpad.net*
<LeoNerd> It might have some significance to the launchpad system in particular... but... bzr cares not
<krish> oh ok
<krish> shall remember that :)
<ubotu> New bug: #183831 in bzr "Internal error with soft link" [Undecided,New] https://launchpad.net/bugs/183831
<mimir_> hey, i've got a question
<mimir_> i've done a bzr push to a sftp URL
<mimir_> and i only have the files "visible" at that location after i do a bzr update on the server
<mimir_> is there a way so that on push the repo on the sftp location will update?
<radix> mimir_: https://edge.launchpad.net/bzr-push-and-update
<dato> mimir_: not over sftp, but if you install bzr on the remote end, you can use bzr+ssh, plus the link radix gave you
<mimir_> thanks a lot. that's what i was looking for
<radix> oops. I guess that plugin is ssh only
<mimir_> i have ssh, no prob there...
<radix> although probably that works in the majority of cases where you have sftp access :)
<radix> it's the requirement of bzr on the server that's the strictest requirement
<mimir_> i'm installing the plugin right now
<krish> radix: do i need that plugin to work on launchpad too?
<radix> krish: no, not at all
<radix> the plugin doesn't really make sense with launchpad, you don't need working trees on the server
<krish> hmm ok
<mimir_> question... is there a way now to alias bzr push to execut bzr push-and-update?
<mimir_> i'm using BzrEclipse
<mimir_> and it only has bzr push...
<krish> doesnt bzr has a gtk frontend?
<krish> i m new to this.
<brilliantnut> krish: bzr-gtk
<krish> brilliantnut: i was suggesting mimir_
<krish> brilliantnut: may be u can help him out. i just read that bzr has a gtk frontend
<krish> brilliantnut: i dont even know how it looks :P
<dato> mimir_: mmm. push-and-update now is smart, and makes "push" alone itself update the remote tree, *iff* there is one
<dato> mimir_: so you just need to log to the remote computer once and create the tree there. you create the tree with 'bzr checkout .'
<mimir_> dato, here is how i work: 1. create on the remote server the repo (bzr init, bzr add, bzr commit -m "initial import"). then on local machine i do a bzr branch sftp://URLHERE
<mimir_> dato, then i work on the local branch, i do commits etc, until i'm ready to make a push back to the remote server..
<mimir_> dato, so i want now that on push the remote does bzr update... what is the plugin mentioned doing, right?
<dato> mimir_: yes, it will do that, as long as you push over bzr+ssh and not over sftp
<mimir_> ah... so on push i neet to do bzr push bzr+ssh://someurl ?
<dato> yeah
<mimir_> dato, cool, testing it now..
<dato> ok
<mimir_> dato, i think i'm doing smthing wrong...
<mimir_> dato,  bzr push bzr+ssh://science@myscienceisbetter.info/home/science/public_html/basilisk/
<mimir_> science@myscienceisbetter.info's password:
<mimir_> This transport does not update the working tree of: bzr+ssh://URL. See 'bzr help working-trees' for more information.
<mimir_> No new revisions to push.
<mimir_> ah... 1 sec..
<mimir_> dato, nope... i still need to do bzr update on server...
<mimir_> am i missing something?
<dysinger> Thanks for your help yesterday gang.  I am totally on bzr/svn now.
<beuno> mimir_, I use a cron job which runs bzr update due to permission problemas. AFAIK, bzr+ssh doesn't update the working tree, just the push-and-update plugin
<dato> mimir_: if you see the "This transport does not update..." warning, something's gone wrong. do you see push-and-update listed if you run `bzr plugins`? (Also, the directory under plugins should be named push_and_update, it can't be push-and-update)
<mimir_> let me check..
<krish> bye all
<beuno> mimir_, you have to do:  bzr push-and-update bzr+ssh://science@myscienceisbetter.info/home/science/public_html/basilisk/
<dato> beuno: nope
<mimir_> dato, thanks m8, it works now
<dato> beuno: check the commit log
<mimir_> dato, there was a problem with my push-and-update install
<dato> mimir_: very well
<beuno> dato, really?  aaaah, didn't know a new version was out
 * beuno learns something new
<mimir_> i just did bzr push-and-update and it automaticaly the sftp:// path
<mimir_> and it did the job quite well :)
 * mimir_ thanks dato and radix for pointing the right path :)
<dato> you're welcome
<beuno> that's odd, I was subscribed to the repo en launchpad, but I didn't get any notifications
<jelmer> yay, the 20th bzr-svn bug related to unicode \o/
<james_w> hi jelmer
<james_w> hi dato
<dato> hey, james_w. long time no see, I think?
<jelmer> hey James
<jelmer> 'evening Adeodato
<james_w> dato: yeah, hardware troubles. All sorted now, so I should be back with the code soon.
<dato> james_w: great
<rjek> jelmer: On the other side, my experience with bzr-svn was almost flawless apart from my misunderstanding of what the branch file thingy was for :)
<dato> jelmer: I'm going home now. I'll try to take a look at -pqm when I arrive.
<jelmer> dato: Cool, thanks
<slestak> can i bounce some bzr ideas off the room
<slestak> i am trying to plan a vcs system for my workgroup
<slestak> we have a shared codebae that is 75% plain text files, and 25% within binary files (more on that in a sec)
<slestak> its the 25% that is an issue.  the 4gl we use stores the file definitions and screen definitions withing the header of the actual db datafile.
<slestak> i think i am capable of coming up with a fuse fs kindof like sshfs that would allow regular fs-like access to thes contents of the binary files.
<slestak> has anyone dealt with a simialr setup, versioning selected contents of a vinary file, not teh whole bin file.
<rjek> The only occation I found myself needing fine-grained revision history over binary blobs I wrote a tool to convert the binary blobs to and from a textual format, and installed a pre-commit hook.
<slestak> thats kindonf what i am thinking, a wrapper that will extrac the records I need, and put tehm back safely.
<slestak> i was considering a fs-like interface so it will be familiar and transparent to any 3rd party tools that deal with bzr
<rjek> There's no need for a FUSE hack really.  The pre-commit hook idea is also more portable in case you want to check in or out on a non-Linux box.
<Manfre> what is the command to generate a diff of 2 revisions?
<slestak> rjek: thanks :)
<luks> Manfre: bzr diff -r R1:R2
<luks> er
<luks> that's svn :)
<luks> bzr diff -r R1...R2
<Manfre> thanks
<luks> actually it's bzr diff -r R1..R2
<luks> I should probably really try to not help anybody today :)
<Manfre> does bzr support the auto replace variables? e.g. $LastChangedRevision:
<Manfre> if so, can some one link me to a doc that explains it
<luks> no
<luks> the usual trick for build scripts is `bzr version-info`
<rjek> it's a shame you can't really do that (AFAICT) from bzr export.
<dysinger> Is there a way to get bzr-svn to remember your password like git-svn or just plain svn?  It's driving me nuts having to enter it all the time.
<luks> use svn to remember the password
<jelmer> dysinger: what transport are you using?
<luks> then bzr-svn will use the saved password
<dysinger> https
<dysinger> when I branched I put https://username:password@host/url
<dysinger> but now I have to enter my password everytime.
<dysinger> when update/pull etc.
<dysinger> That brings up another question.  A guy in here last night recommended that I checkout from svn instead of branch - said there was less chance for an impedance mismatch with svn.  Is that true Jelmer ?
 * fullermd <---- guy
<dysinger> heh
<dysinger> hey fullermd
<dysinger> I just wanted to check with 'the man'
<fullermd> I _wish_ it were last night.  It's still "earlier today" for me   :|
<dysinger> heh I am GMT-10
<dysinger> in the center of the ocean
<fullermd> Well, if you're going to be becalmed, you might as well have a 'net connection.
<jelmer> dysinger: can you rephrase that last bit without using "impedance"?
 * jelmer is not a native speaker, the only way I know impedance is related to electricity
<fullermd> Well, that's the context I draw it from too   :]
<dysinger> fullermd said that using checkout for an svn remote repo was better and there was less chance for problems
<dysinger> I found that at least it seems to me checkout is better for svn because "push" to svn on a branch I made the 1st time was painfully slow.
<fullermd> Well, that's not a checkout/push difference; that's some cache or other that had to fill.
<dysinger> I just want to make sure I am doing "the right thing" before I settle in on a pattern of work.
<jelmer> dysinger: Checkouts will be slow the first time as well
<dysinger> yes checkout vs branch is about the same
<jelmer> dysinger: checkouts are basically branches that push on commit
<dysinger> y
<jelmer> dysinger: They're not necessarily better than pushing, but they may match your workflow better
<fullermd> jelmer: My operative theory is that using the checkout to interface to svn via merging in work and committing (vs. merging from svn and pushing) is interfacing to svn how svn expects to be interfaced to, and so is less likely to confuse it or you (or both).
<fullermd> (i.e., matched impedances, no reflections)
<dysinger> What I am hearing is that branch vs checkout makes no difference to the bzr-svn plugin -but checkout matches svn workflow better
<AnMaster> changelog for 1.1?
<jelmer> fullermd,dysinger: yep, that makes sense
<dysinger> fullermd you used the word impedance again :)
 * fullermd nods.
<fullermd> Well, I considered using admittance instead   ;)
 * jelmer has a some idea of what it means now :-)
<jelmer> foss development is really good for my foreign language skills
<fullermd> Luckily, I have a pi-network tuner right here at my elbow to resolve such mismatches   :p
<lifeless> moin
<dysinger> So about that svn password - is there something I can stash in .bazaar/subversion.conf or something?
<jelmer> hey lifeless
<jelmer> dysinger: If you force svn to authenticate once, it will cache the password
<dysinger> hmm
<jelmer> see the bzr-svn FAQ for details
<dysinger> ok
<dysinger> It's asking me for a password everytime
<dysinger> FAQ! it doesn't work jelmer  svn info https://dysinger@xyz.com/svn works without password but then I immediately get asked for my password when doing bzr update <branch>
<dysinger> svn password is cached
<dysinger> bzr still asks everytime
<jelmer> dysinger: and if you don't specify a username to svn?
<dysinger> svn info works fine either way with no password
<rjek> Does bzr still produce an error if you try to do something with an http:// URL that requires auth but you don't specify a username?
<dysinger> maybe it's because I checked out the branch with bzr using the username:password@ notation
<lifeless> dysinger: try bzr bind bettersvnurl
<jelmer> dysinger: right, but if you specify a username to svn (using the username@ notation) it may not do any caching
<dysinger> ok I'll try it again
<lifeless> dysinger: that will update the url bzr has remembered
<jml> bzr.dev seems to take an awfully long time to pull
<rjek> jml: Lots of history.
<rjek> Try a checkout with --lightweight instead if you're not interested in editing the source so much as simply get the latest source.
<dysinger> that only works if you are always connected if I am correct
<rjek> dysinger: Sure, but if you're not interested in using it for development work and only as a way to check out the latest source, you'd need to be connected anyway.
<jml> rjek: I mean, pulling from my month-old copy
<dysinger> oh sorry I was thinking of my repo - not bzr.dev
<dato> jml: is your copy in knits or packs?
<dysinger> lifeless lol oops I already deleted my repo to start over.  dogh!
<lifeless> dysinger: heh, why delete the repo ?
<jml> dato: format is 'dirstate', I guess that means knits
<dysinger> Thanks to OS X I can time-machine back an hour ago and grab it.
<lifeless> dysinger: at most delete the branch; repositories have no configuration, only raw data, so for things like cached password etc the repository is never at fault
<dysinger> gatcha
<lifeless> jml: 'bzr upgrade'
<jml> lifeless: doing so now :)
<dato> bzr upgrade --pack-0.92 to be really sure
<dato> (in the rare case his copy didn't have packs-as-default)
<jml> why do people say knits when bzr says dirstate?
<dysinger> time machine is so awesome
<dysinger> restore -> click
 * dato thinks that part of bzr is messy, messy.
<dato> jml: if you know the difference between brach, repository, and working tree, because dirstate is a working tree format and knits a repository format
<lifeless> sweet
<lifeless> hpss call w/body: 'Repository.stream_revisions_chunked', 'home/robertc/bzr.dev/' ('pqm@pqm.ubuntu.com-2'...)
<lifeless>               172 bytes
<jml> dato: interesting. running bzr info in the top dir of a shared repository said the format was dirstate
<lifeless> down from > 1 MB
<jml> dato: I'm surprised that has anything to do with working trees
<lifeless> jml: see bug kthxbye
<dysinger> Grrr - when I do svn info http://url.com/svn it works fine.  We I try to bind my checkout to it it fails :  Duece:trunk tim$ b bind https://url.com/svn/trunk
<dysinger> bzr: ERROR: Invalid http response for https://url.com/svn/trunk/.bzr/branch-format: Unable to handle http code 401: Authorization Required
<lifeless> dysinger: try svn+https
<dysinger> k
<lifeless> or is it https+svn; svn first I think
<dato> yes
<dato> (svn+)
<lifeless> does it work ?
<dysinger> no
<lifeless> jelmer: ^ ?
<dysinger> I went into /tmp & created a new fresh repo & tried to checkout
<dysinger> first I did an svn info https://url....
<dysinger> then bzr checkout https://url <- fails
<dysinger> bzr checkout svn+https://url <- fails the same
<dysinger> that's why I added the username:password in the url last night.
<dysinger> I get bzr: ERROR: Permission denied: ".": PROPFIND request failed on '..... everytime
<lifeless> I don't know enough about bzr-svn to answer this sorry
<jelmer> Sorry, I don't know eithr
<jelmer> Subversion 1.5 and bzr-svn 0.4.6 should allow bzr to do the caching
<dysinger> whacked ok I am going to try one of my other accounts to see what's up
<dysinger> ok I am using bzr-svn stable but subversion 1.4.6 with patches
<dysinger> maybe I should go trunk
<jelmer> but the "svn info" trick has always worked for me so far
<dysinger> ^ trunk on subversion 1.5
<dysinger> Is trunk 1.5 subversion stable enough to use for everyday dependable development work?
<lifeless> jelmer: %
<jelmer> dysinger: imho, yes
<dysinger> They don't have a branch for 1.5 yet so I imagine you just compile trunk
<dysinger> and trunk needs no patches
<jelmer> yep
<dysinger> geez trunk is way easier to compile
<dysinger> I bet the problem is this
<dysinger> I am using os x's svn client to login
<dysinger> but bzr is using an updated svn library
<dysinger> that's off to the side.
<dysinger> maybe that's it
<lifeless> abentley: ping
<dato> jelmer: uploaded
<igc> morning
<jam> igc: morning
<igc> hi
<jam> spiv: any recent changes to Launchpad that would make bzr+ssh start failing?
<elmo> grr
<lifeless> jam ping
<spiv> jam: not that I know of
<elmo> plstobe bzr add not being relative to cwd
<lifeless> jam: I have an incremental patch I'd love instant-review on
<jam> lifeless: just a sec, phone call right now
<jam> will do after
<lifeless> jam: will mail it then
<lifeless> jam: so there are two unreviewed patches in this stack - the incremental one I just sent; and the smart server one that I rejected last night, but is actually good.
<spiv> lifeless: I reviewed that a moment ago
<lifeless> sweet
<lifeless> its a change from  >1.2MB -> 172 bytes  :)
<jelmer> dato: why the "sigh" about python-all-dev?
<jelmer> dato: and thanks once again for uploading :-)
<jam> lifeless: bb:approve
<lifeless> thanks
 * lifeless merges all 4
<lifeless> jam: its release time; could be a rollout or something has just been done
 * jam => family time
<keithy_> Is there an install for 10.4
<keithy_> Is there an install for Mac OS X 10.4
<dysinger> is easy_install on Tiger ?
<dysinger> can you open a terminal and type `which easy_install` ?
<keithy_> nope
<keithy_> is that what the 10.5 dmg installer uses?
<dysinger> I think so yes
<dysinger> I am on leopard so I just type `sudo easy_install -U paramiko pycrypto bzr`
<keithy_> seams silly to only release for os os that is barely months old
<keithy_> an*
<dysinger> oh I am sure there is a way
<dysinger> I just don't know it.
<dysinger> It's just python
<dysinger> code
<dysinger> Do you have macports installed ?
<keithy_> thats enough to make me suspicious
<keithy_> I cant stand python
<keithy_> yeah I am updateing macports now
<dysinger> wow be careful
<dysinger> :)
<keithy_> why is that not going to work either?
<dysinger> The heresy to say python sucks in here
<keithy_> ih that
<dysinger> s/the/that's
<keithy_> well written by a guy who doesnt understand object dispatch
<keithy_> sh, down boy
<dysinger> Python's a perfectly fine language - I prefer ruby myself or java
<keithy_> first language I ever write a hate sheet on
<keithy_> but I suspect it might have been the first book I bought on it was rubbish and that coloured my view
<keithy_> ruby's ok
<dysinger> I just like Ruby better nowdays - java paid the bills for 10 years
<keithy_> wow macports updated!
<keithy_> this might be ok afterall
<dysinger> I believe git and bzr etc are in macports
<keithy_> ive tried mercurial, now its bzr's turn.... does it have patch queues?
<keithy_> does it do binary diffs?
 * dysinger just came from git & now trying bzr
<fullermd> Ruby...  furrfu.  Crazy people, this internet thing has...
 * awilkins is using SVK fairly actively, tried git (windows) and is liking the look of bzr so far
<dysinger> hey easy - I didn't say python sucks.  I just said I like Ruby. :)
<keithy_> well Smalltalk pays my bills
<awilkins> keithy_: bzr will let you pass off to the diff tool of your choice
<dysinger> wow - they still make smalltalk ?
<dysinger> :)
<keithy_> not that sort of diff
<keithy_> when it stores in the revisions
<fullermd> Oh, well, I said python sucks  :p
<keithy_> does it store whole files or does it store diffs?
<fullermd> But hey, as long as the tool works, and *I* don't have to write the language, it can be in whatever it likes.
<dysinger> fullermd likes ???
<fullermd> Well, except Haskell.  Gotta draw the line somewhere.
<lifeless> keithy_: its stores both full files and diffs
<fullermd> I dunno.  I don't actually have a language I'm agog about these days.
<lifeless> keithy_: but chooses between them to balance time and space at each commit
<keithy_> so if I have a 50Mb file in 4 versions
<dysinger> I am not a fan of any language I can't read - haskell, erlang, scala etc all have totally bizarre syntax.
<fullermd> I like C, but it's so much manual bookkeeping.  I spend my days writing PHP and it's not bad, except for the big gaping suckages.  I like perl, but it irritates me in a lot of ways...
<lifeless> keithy_: in 1.0 or 1.1 you'll end up with 50MB gzipped + space proportional to the difference in the files, split on \n and represented as line deltas
<fullermd> But hey, perl 6 will cure everything.  And it's right around the corner.  No, really, this time for sure.
<keithy_> but binary fiels dont have lines
<lifeless> keithy_: they have \n in ~1/256 characters
<lifeless> keithy_: which is enough for the storage layer.
<keithy_> hmm not sure if it would work on a smalltlak image, can I change the split character
<lifeless> keithy_: but its not as efficient as something that looks for common sequences of bytes rather than fooo\n's. We know this is an issue and are looking at a new compressor in a couple of months time
<lifeless> keithy_: no, you can't, but it will work - it round trips losslessly; the worst case is you end up with 200MB of storage.
<keithy_> k
<lifeless> keithy_: (and which we will be addressing by 1.4 anyhow :))
<lifeless> folk version iso's :)
<lifeless> keithy_: you could also use the fuse interface someone was working on to the squeak code and version that in bzr; I suspect we'd need a little work to work on the fuse tree (we need os locks which you wouldn't really have, for a couple of files), but the fuse tree could back that part to local disk; :)
<keithy_> wow you know about that fuse interface!
<keithy_> interesting idea
<lifeless> it wouldn't get object state; but personally I like file-in imageless based smalltalks :)
<keithy_> I used to use st/x myself
<keithy_> and that did cvs versioning of classes
<lifeless> bbiab
#bzr 2008-01-18
<keithy_> well an idea for core dev... dmg installer for Mac OS X 10.4
<lifeless> spiv: ping; can we chat? if you're not deep in the flow; I have a proposal for 'what revisions I need to push detection'
<lifeless> keithy_: I'll mail the list for you if you like
<lifeless> keithy_: the dmg is done by community members :)
<keithy_> k
<keithy_> I'v been waiting for python to finish building for ages, does it take long?
<dysinger> that's the stupid problem with macports
<dysinger> It compiles EVERYTHING
<dysinger> it might as well compile an alternate kernel too for pete's sake
<dysinger> I don't use it.
<dysinger> ./configure && make are easy to use.
<keithy_> I think I have python on this mc 4 times now
<dysinger> what would it take to get easy_install on your mac ?
<dysinger> skip macports
<dysinger> if you have easy_install then it's just one line
<dysinger> to get the latest bzr
<dysinger> sudo easy_install -U paramiko pycrypto bzr
<dysinger> OS X comes with Python - you shouldn't have to be compiling Python.
<dysinger> http://peak.telecommunity.com/DevCenter/EasyInstall
<minghua> OS X's python is crippled pretty hard last time (10.3 days) I looked.
<jelmer> lifeless: is there a dmg yet? I thought there were people still working on it
<igc> maybe we should add easy_install instructions to the Download page
<jelmer> igc: easy_install doesn't provide a patched python-subversion
<foom> someone could make an easy_installable python-subversion, though, probably.
<jelmer> that would be nice
<keithy_> Error: The following dependencies failed to build: py25-paramiko py25-zlib
<jelmer> there have been quite a few people here trying to patch and build it
<jelmer> that reminds me, I need to get that memory leak fix into hardy...
<jelmer> because of the way the memory pool stuff works in apr, it's also a major performance improvement
<keithy_> so macports is hosed
<keithy_> I cant even find a skip option
<dysinger> Yeah I stopped using fink and macports years ago
<dysinger> same reason I stopped using gentoo
<dysinger> you are guaranteed to get pissed one day when the whole build system breaks down when you need it.
<keithy_> yeah I use knoppix for linux because I detest these installation issues
<keithy_> has everything preinstalled
<dysinger> debian and debian variants - accept no substitutes
<keithy_> but I cant beleive I have found a mac os x programme that is offering me no options
<dysinger> have you tried easy_install (or are you more inclined to the not_easy_install_hair_pulling method) ?
<dysinger> http://peak.telecommunity.com/DevCenter/setuptools#installing-setuptools
<dysinger> er better http://peak.telecommunity.com/DevCenter/EasyInstall#installation-instructions
<dysinger> try this
<dysinger> cd /tmp ; curl -O http://peak.telecommunity.com/dist/ez_setup.py ; python ./ez_setup.py
<dysinger> sheesh I am not even a python person :/  Help me out guys.
<lifeless> jelmer: I thought there was a 10.5 one
<dysinger> There is but you don't need it
<dysinger> easy_install -U does the same thing
<dysinger> It just looks prettier
<dysinger> and has docs
<jelmer> lifeless: Ah, it just doesn't include the python-subversion stuff then yet
<dysinger> (It = dmg)
<dysinger> I am updating the python-subversion instructions again on the wiki in the next 30 min
<dysinger> (for OS X)
<dysinger> It's better than my yesterday edit.
<lifeless> abentley: ping
<dysinger> lol I finally got time to install subversion (trunk) 1.5 and now it says svn: Unrecognized URL scheme for 'http://macromates.com/svn/Bundles/trunk'
<lifeless> abentley: I am looking at adding a 'current_search' parameter to get_parent_map; this will allow get_parent_map on the smart server to avoid sending duplicate data back
<dysinger> wtf?
<dysinger> svn+ssh works but it's not recognizing the http
<dysinger> grr
<keithy_> error: Download error for http://www.lag.net/paramiko/download/paramiko-1.7.1.zip: (61, 'Connection refused')
<keithy_> I give up
<lifeless> keithy_: you only need paramiko for sftp
<lifeless> keithy_: to just use bzr; if you have *a* python (2.4 or newer) just do this:
<lifeless>  - grab the bzr tarball
<lifeless>  - untar it
<lifeless>  - add that directory to your path
<lifeless>  * DONE *
<keithy_> it worked!
<hsn_> what is main feature of bzr-1.1?
<dysinger> version control
 * dysinger ducks
<keithy_> erm .. it doesnt install on Mac os  x 10.4
<keithy_> ;-)
<lifeless> max os X is awkward
<lifeless> its really geared for binary installs, but the vast chunk of unix programmes are not supplied as binaries by apple
<lifeless> spiv: the eagle has landed
<spiv> lifeless: sweet
<Talden> hsn - ditto.  It'd be nice to see the web-page announce 1.1 in the news and give some hint as to what is new (even if it's just "here's a faster, more stable bzr").
<lifeless> there is a changelog I thought
<lifeless> Talden: http://bazaar-vcs.org/
<lifeless> Talden: says "The main changes in this release are: improved diff, merge, annotate and reconfigure commands; more efficient ordering inside pack repositories; better http authentication, and various other bugs fixed. (full changelog)
<lifeless> "
<lifeless> Talden: and links to the full changelog.
<foom> lifeless: but the "News" section doesn't say anything
<lifeless> foom: see martins post about website maintenance
 * igc lunch
<jelmer> Hmm
<jelmer> the improved Inventory.repr() is nice, but it causes very large backtraces in some cases
<jelmer> I just got a single-line 700k error from bzr
<lifeless> jelmer: grats
<jelmer> lifeless: hi
<jelmer> lifeless, grats?
<lifeless> on 700K bt
<poolie> bt?
<bob2> (backtrace)
<jelmer> lifeless: ah, congrats?
<lifeless> jelmer: yes
<jelmer> you had me wondering there for a moment why that word wasn't in my 500-page en<->nl dictionary ;-)
<lifeless> WoW slang
<jelmer> well, with so many Australian bzr developers, I'm glad the main language isn't strine :-P
<bob2> does bzr not have an en_AU translation yet?
<jelmer> There is no localization yet
<jelmer> and both english and american spelling appear to be used
<jelmer> bob2: so what's different in en_AU from en_UK?
<jml> jelmer: very few things.
<jelmer> I can't seem to find any difference in the .mo files
<ntnhan> it seems that plugin email works only on client side, when I commit any code to server but email is not sent on server
<ntnhan> anybody has idea?
 * jelmer suddenly realizes he's up at 4 AM searching for differences between Australian and British language files for evolution and decides to get some sleep
<jelmer> ntnhan: It doesn't send email from the server side
<ntnhan> jelmer: yes, that's what I don't want :(
<beuno> ntnhan, is the server running the bzr smart server?
<ntnhan> beuno: no, it's just bzr installed
<beuno> ntnhan, I'm not sure how you can make the server send off emails if it's not actually running bzr when you commit
<beuno> (smart server would solve it in that case, as you can hook into it)
<ntnhan> bueno: how do we configure bzr running on server each time client commits?
<beuno> ntnhan, using the smart server  :D
<ntnhan> bueno: haha, thx, I didn't know it :), will give a try now
<beuno> ntnhan, then you can just hook into bzr, maybe even the current plugin will send off emails. jelmer?
<jelmer> I don't think the smart server can send emails when a revision is pushed to it
<jelmer> but it's been a while since I've looked at it
<jelmer> it being bzr-email
<jelmer> lifeless is the bzr-email maintainer so he's probably in a better position to comment
<beuno> ntnhan, maybe take a peek at http://bazaar-vcs.org/SmartServer/RemoteObjectHacking
<beuno> and of course, lifeless would be *the* man  :D
<ntnhan> beuno: ok, i'll try it
<lifeless> ntnhan: hi
<ntnhan> lifeless: hi
<lifeless> ntnhan: the bzr-email plugin fires on Branch.post_commit which is not currently invoked in the server process; as discussed above you will have to bzr using bzr:// (or bzr+ssh etc) for it to work /in principal/
<lifeless> but we have to make it work in fact too:)
<lifeless> there is a cron based solution folk have created which sends an email when a new commit is detected on the branch and works with any transport (rysnc, bzr, sftp, etc)
<beuno> there has to be someway to do it, Launchpad does it  :p
<lifeless> beuno: launchpad uses the cron based solution
<lifeless> beuno: not the exact same code but that logic path
<beuno> seems fairly trivial, just scan through the dir, save the last revid sent by email, and fire off
<beuno> (of course, almost anything seems trivial in irc  :P)
<lifeless> beuno: well code exists; kthxbye :)
<ntnhan> beuno: yes, but everybody wants to save time, need a ready cake
<ntnhan> :)
<beuno> ntnhan, that's how plugins get started  :D
<beuno> (or specs pushed into the trunk)
<beuno> file a bug
<beuno> requesting it
<beuno> the "let's get the aount of open bugs" fever in the upcoming sprint should take care of the rest!
<beuno> s/aount/amount
<dysinger> jelmer sorry to bother you again.  So I have subversion 1.5 trunk all compiled into /usr/local with neon and all is good.  I can do all the subversion functions with it - it works.  Then I try to use bzr 1.1 w/ bzr-svn stable and get bzr: ERROR: Not a branch: "https://.... for every single svn url I try.
<dysinger> This worked fine in subversion 1.4.6
<Odd_Bloke> dysinger: Try 'svn+https://...'.
 * Odd_Bloke can't remember if that works or not.
<dysinger> yeah not working either
<dysinger> already tried that
<Odd_Bloke> Well, jelmer will probably save the day.
<Odd_Bloke> He normally does. :p
<dysinger> I am trying to get closer and closer to his setup
<dysinger> svn+https blows up with a stack trace
<jelmer> dysinger: Do you have libneon built with SSL support?
<dysinger> regular https:// is acting like it's looking at as a bzr branch
<lifeless> dysinger: its jelmer's 4am :- I think you'll get little now :)
<dysinger> hah!
<lifeless> have you looked in ~/.bzr.log ?
<dysinger> He's up!
<dysinger> ah ok two good suggestions.
<lifeless> I wager its not loading the plugin
<dysinger> 1st svn ls https:// works and yes svn --version shows https
<dysinger> let me look at the log
<jelmer> dysinger: the svn executable from the location you just installed to and with the same DYLD_LIBRARY_PATH set?
<dysinger> FAQ!
<dysinger> one sec maybe my bad
<dysinger> I managed to install it in /usr/local/bin but svn --version reports 1.4.4 (version that comes with mac).  ???
<dysinger> This is kicking my ass.
<dysinger> I am setting DYLD and PYTHONPATH too
<dysinger> PATH has /usr/local first
<dysinger> ok I have more work to do
<dysinger> my neon didn't install right.
 * dysinger goes back to the salt mines
<lifeless> spiv: how do you get remote server backtraces ?
<j1mc> hello, i've read a little bit about the differences between bundles and regular patches, but i'm not sure i fully understand.  can anyone explain the advantages of a bundle vs. pushing up a regular patch (or set of patches) as a revision?
<lifeless> bundles and pushing revisions are roughly equivalent
<lifeless> think of it as a transport change
<j1mc> transport change?
<lifeless> however 'regular patches' means GNU patch output, which does not include: commit messages, mode changes, renames, deletes-as-deletes
<beuno> j1mc, basically, bundles have bzr metadata about the commit(s), and a regular patch just has the diff for the changes to the code
<lifeless> spiv: ping
<minghua> lifeless: deletes-as-deletes?
<j1mc> beuno: thanks.  (and thanks to you, too, lifeless).  what kind of bzr metadata might be included in the bundle?
<lifeless> minghua: 'foo is deleted' is different to 'foo has a patch that removes <entire list of old lines>'
<j1mc> ah, ok.
<lifeless> minghua: its particularly different in terms of the conflicts you can give the user; and also how do you represent 'trunc() this file' if a delete is shown as deleting all the contents ;)).
<minghua> lifeless: Ah, I see.  Thanks.
<Verterok-laptop> moin
<spiv> lifeless: http://rafb.net/p/JoRYz534.html
<lifeless> spiv: bb:approve
<Verterok> poolie, lifeless: I have a dmg for OS X 10.4 ready for a ride :)
<poolie> Verterok, yay
<spiv> lifeless: ta
<poolie> Verterok, can you upload it to launchpad?
<poolie> btw i spoke to them about the size limit
<Verterok> it's ppc only
<lifeless> Verterok: sweet
<poolie> is 60MB ok?
<lifeless> keithy_: ^
<Verterok> poolie: 6MB
<Verterok> there might be something wrong 6MB vs 60MB
<Verterok> this dmg only contains bzr+pycrypto+paramiko
<Verterok> aha, all the plugins missing :P
<Verterok> I'm going to add Rebase and bzrtools to it, but I don't have QT installed in OS X so no Qbzr :(
<Verterok> poolie: I misunderstood the question about the size (is too late here :P)
<lifeless> Verterok: l)
<Verterok> I have a dmg with bzr(pycrypto+paramiko) + bzrtools + bzr-rebase :)
<lifeless> care to add bzr-email
<Verterok> ok
<Verterok> lifeless: trunk?
<lifeless> yup
<Verterok> trunk has not been published yet
<lifeless> http://bazaar.launchpad.net/~bzr/bzr-email/trunk/
<lifeless> dunno what you mean by not published yet
<Verterok> is what launchpad say :)
<Verterok> https://code.launchpad.net/~lifeless/bzr-email/trunk
<lifeless> url ?
<lifeless> ~bzr
<lifeless> not ~lifeless
<Verterok> ok, sorry
<lifeless> thumper: https://code.edge.launchpad.net/~bzr/bzr-email/trunk <-
<lifeless> thumper: I didn't get any notification about that merge request
<lifeless> thumper: so I didn't know it exists
<Verterok> poolie: I'm going to upload it to: https://launchpad.net/bzr/1.1/1.1 it's ok?
<poolie> yes, thanks
<lifeless> spiv: down to 100 seconds in get_parents_map calls
<lifeless> spiv: thats down from 237
<spiv> lifeless: very nice
<spiv> lifeless: that's for branching bzr.dev from London?
<lifeless> yeah
<lifeless> 115 seconds on my current test
<lifeless> I'm done for the day;
<lifeless> I'll commit and push
<lifeless> if you re interested
<lifeless> http://people.ubuntu.com/~robertc/baz2.0/search-results
<lifeless> rev 3198 pushing now
<lifeless> 15 seconds from startup to starting the stream in my 'last 100' test
<lifeless> thats another 100% saving over my report earlier in the week
<lifeless> your patch when it lands will help debug
<lifeless> it seems to be falling into a 'one at a time' pathological mode
<lifeless> it should be walking minimum-depth-at-a-time, and it may be that there are places where the search collapses; but I don't expect that.
<poolie> lifeless, have a tolerable trip :)
<lifeless> so this needs some good analysis and reporting to figure out what is going wrong; the hg recursive approach may be something to reintroduce
<lifeless> I don't anticipategetting any hacking on this branch done next week
<lifeless> but I'm quite happy with where it is getting to :)
<lifeless> thats poolie
<lifeless> poolie: oh you might like to mail me anything you want (other than the baz package stuff) for discussion with the distro.
<lifeless> ciao.
<thumper> lifeless: yeah, damn eh
<thumper> lifeless: a bug report would be good :-)
<Manfre> is it possible to modify the commit message for a revision?
<poolie> Manfre, uncommit then commit again
<Manfre> is there anyway to modify a revision that is not the head?
<abentley> lifeless: The idea sounds fine.  I've never considered anything below Graph to be a stable interface.  It's Graphs that repos are required to provide.
<abentley> Whatever way is most efficient for them.
<ubotu> New bug: #183948 in bzr "can't PUSH over an sshfs fuse file share" [Undecided,New] https://launchpad.net/bugs/183948
 * spiv goes for a swim
<thumper> abentley: man, when do you sleep?
 * Verterok leaves, only two hours for sleep. seeya!
<caelum_> f
<AnMaster> how long as 1.1 been out?
<AfC> AnMaster: a few days
<AnMaster> ok
<sabdfl> poolie: ping
<soren> AnMaster: "Bazaar 1.1 was released on the 15th of January, 2008."  <---- Very first sentence on http://bazaar-vcs.org/
<AnMaster> right
<dato> jelmer: because I see python packages b-depending on python-all-dev *everywhere*, and it's not needed at all
<dato> jelmer: omg, I don't know if you saw my question yesterday about making the svn cp from bzr-svn itself, but I tried it and it works...
<dato> jelmer: so my bug has much less priority now, thanks to bzr-svn rocking ;)
<ntoll> hi, how does bzr merge handle a move or delete on one branch and an edit on the other (since they were branched)?
<ntoll> aha... just found the docs... looks like this case is handled
<asac> is there an easy way (short hand) to export a series of commits as one-patch-per-commit?
<stefanv> hey all, is there a way to remove binary files including their history from a bzr archive?
<stefanv> s/archive/branch/
<stefanv> I found that tracking jsmath-fonts is a big pain in the ass, with all its 20 000 odd files
<stefanv> maybe I can check out before their inclusion, and apply all the patches that happened after their inclusion
<lifeless> asak_: diff -r x..+1 in a loop perhaps ?
<stefanv> hrm, bugger, those files were there since revision 1
 * dato hands lifeless diff -c ;)
<stefanv> did an experiment now, and seems like you can remove all traces of a binary file from a branch by doing 'bzr remove'.  Why is that even possible?  Shouldn't you be able to revert to any point in history?
<dato> stefanv: no, remove does not remove all traces
<stefanv> dato: hrm, interesting: because I had 88Mb's worth of binary files, and now the repo in total is only 18Mb
<AfC> ... _is_ there a way to purge all evidence of something from a branch history & repo?
<AfC> I mean, in purist terms you'd never need to, but there are pragmatic reasons (material committed illegally, security sensitive or privacy sensitive information at risk of being divulged, etc)
<stefanv> AfC: well, I just made sure: when I remove those binary files, and do 'bzr uncommit', they don't come back
<stefanv> so it definately permanently erases them
<AfC> Assumint the
<AfC> revision hasn't leaked anywhere... but the revision itself it's still in the repository. I think you could fetch it if you knew it's revid
<stefanv> yes, if you knew which binary files to bring back (i.e. you still have the filename information)
<stefanv> AFAIK in an SVN repository, the binary data itself is also stored
<stefanv> hence my original question :)
<luks> no, you can't remove anything from the repository permanently without rewriting it completely
<stefanv> AfC: I would very much like to know the answer to your question above, as well.  sometimes, copyrighted code is checked into open source repos, which causes problems.
<luks> I guess the size difference is because you count the working tree size
<stefanv> luks: you cannot bring back those binary files, they are gone.
<luks> you can
<luks> bzr remove doesn't actually remove them from the history
<stefanv> well, since my repo is now only 3.3Mb large, I'd like to know where it stores those 88Mb worth of files :)
<stefanv> luks: no, sure, they *filename* info is still there... but the actual bytes are gone
<luks> nope
<stefanv> so, 88Mb in 3.3Mb, eh?
<luks> if you just did bzr remove and bzr commit, all the bytes are still there
<luks> the only thing I could imagine is that you haven't committed 'bzr add' of those files
<dato> sounds like it
<stefanv> they *were* tracked:
<stefanv> === removed file 'sanum/static/javascript/jsMath/fonts/cmbx10/plain/85/char73.png'
<stefanv> let me just recheck the original repo
<luks> bzr cat -r REVISION_IN_WHICH_THE_FILE_WAS_ADDED sanum/static/javascript/jsMath/fonts/cmbx10/plain/85/char73.png
<stefanv> ok, so it's head-in-the-sand time then?
<stefanv> hrm, but wait
<stefanv> if I do bzr log sanum/static/.... I should see something
<stefanv> yeap, I don't think those files were tracked.  why don't they show up in bzr status then?
<stefanv> ok, erase my previous 4 sentences
<stefanv> the files *was* tracked from revision 1
<stefanv> the bzr cat -r 1 command shows its contents
<stefanv> which explains why bzr status doesn't explain it
<stefanv> s/explain/show/
<stefanv> luks: are you sure the bzr behaviour you  describe above is correct?
<luks> yes
<luks> you can never ever permanently remove anything from the repository
<luks> it would break integrity of the repository
<stefanv> something very strange going on.  I can confirm the behaviour you describe with a new repo, but not with my other one.
<luks> the only way to remove them would be to "rewrite" the repository without those file
<stefanv> luks: ok, figured out what was going on
<stefanv> luks: the binary files are indeed tracked
<stefanv> luks: but they are *much* smaller when they aren't physically written to disk
<luks> 'physically written to disk' means in the working tree?
<stefanv> luks: about 20000 odd files, each taking up a minimum space determined by the file-system configuration
<stefanv> luks: yes, so if they are all stored in one big file, they are much much smaller
<luks> 88MB vs. 3MB still seems too big difference
<dato> 20000 files at 4k blog size would be 78mb
<stefanv> well, the files are tiny, and an inode needs a min of 4 or 8K right?
<dato> 20000 ~150 byte files make 3mb
<luks> hm, makes sense
<dato> so, it's possible
<stefanv> my apologies for not believing that bzr could compress 90Mb into 3Mb :)
<luks> :)
<stefanv> now, I also know better than to try and rsync that repo
<rjek> When I try to bzr push, I get an error about how the branches have diverged.  bzr merge then pulls these new changes.  There are no conflicts (the changes don't effect the same files).  What do I do after I've done that merge to allow me to push?
<luks> commit
<luks> every merge needs a commit
<rjek> Ah, so I commit the differences from somebody else's branch to my one?
 * rjek sees.  Ta.
<luks> yes
<rjek> As a convention, what do people tend to use as their commit messages for such merges?
<luks> I usually use "Merge <URL>" or "Merge <branch name>"
<rjek> Right.
<luks> but some people prefer more descriptive messages
<rjek> That seems fine.
 * Ng would be very happy if a post-merge commit that hadn't changed anything other than the merge would do that automagically, I never have anything to add to the logs from the merged branch :)
<luks> Ng: auto-merge is not always right
<luks> even if there are no textual conflicts, you can't be sure the merge is right
<Ng> luks: indeed. I only use bzr in very small and simple ways, so I appreciate that me wanting it to be easier isn't suitable for all ;)
<rjek> :)
<asac> lifeless: thanks ... didn't know about the +1 notation ;)
<asac> guessing a patch-filename from comment would be nice to have automated though
<dato> asac: I don't think that notation exists. you want diff -c
<asac> dato: ok ... -c is even better :)
<asac> btw, the foreach (ezbzr) branch isn't hosted at the place named on BzrPlugins page anymore. maybe remove it or contact the author.
<asac> naybe the bazaar-cvs.org page should start to auto-mirror branches of plugins where license permits it?
<abentley> thumper: Evidently, I slept just then.
<thumper> and I'm just about to
<abentley> (Geez, Thumper, when do you sleep?)
<fullermd> Sleep?  I heard of that once, I think...
 * fullermd checks google.
<radix> I find merge commits the perfect place for NEWS-style descriptions. At the least, I use those commits alone to generate the release announcement.
<radix> I also put ticket numbers in the commits for merges.
<radix> and describe the change in high-level
<luks> that works fine if you have a mainline and only merge feature branches
<luks> but it's not that useful when you randomly sync with a few developers
<radix> yeah. why would I do that random thing when I could do an organized thing? :)
<luks> dunno, the "decentralized" thing :)
<radix> my development is perfectly distributed.
 * radix goes to get breakfast
<luks> that doesn't mean decentralized
<abentley> jelmer: I don't plan to ever work on trac-bzr again.
<jelmer> abentley: oh, ok
<stefanv> abentley: I didn't follow the rest of the thread -- is trac-bzr maintained at all?
<abentley> stefanv: I have the impression that other people have been working on it.
<stefanv> abentley: that's good news -- many projects simply won't switch if there isn't a supported trac backend available
<AfC> Oh my. `meld` is amazing.
<AfC> I wonder if we can find a way to feed it from bzr-gtk
 * luks never really got any of those gui merge programs
<stefanv> I'm guilty of still merging with emacs
<jelmer> AfC: We've been discussing that, but the main problem at the moment is that there's no sane API that allows you to use it yet
<AfC> jelmer: fair enough
<jelmer> Of course, we could just fix meld but nobody has done that yet...
<AfC> jelmer: (I just had a conflict and so for the heck of it tried
<AfC> `meld DemoWindowRunner.java.OTHER DemoWindowRunner.java.THIS`
<AfC> and it was glorious)
<jelmer> yeah, it works and looks quite well
<AfC> luks: I haven't tried it as a merging program, but to show the diff it was really slick
<luks> AfC: I don't think you need to even specify filenames, it can figure out bzr conflicts itself
<radix> speaking of meld, I'd love to use it with bzr but bzr diff doesn't have a --diff-cmd parameter
<radix> (just for the diff viewing, of course. the merging would obviously require more work)
<AfC> Whoa. So for merging / conflict resolution you just click on the arrows...
<luks> radix: not sure if it works with meld, but there is `bzr diff --using`
<brilliantnut> if meld takes file1 file2 as arguments then --using will work.
<radix> that must only be in bzr.dev or something...
<luks> 1.1 I think
<brilliantnut> 1.1
<radix> ah, cool
 * radix clicks the little explodey down-arrow
<radix> looks like it's not packaged yet, or something. guess I'll have to wait a couple day s:)
<AfC> 'night
<luks> radix: it's in ppa
<elmo> missing postfix
<elmo> bzr: ERROR: unknown kind 'missing'
<elmo> ^-- halp?
<lamont> elmo: bzr version maybe?
<elmo> it's 1.0
<mikl> how do I fix conflicts? The docs talk about conflict markers, whatever that is...
<rjek> Manually, usually.
<mikl> ensuring that .BASE, .THIS and .OTHER files are identical wont allow me to resolve it
<mikl> nor will deleting them do the trick
<dato> mikl: edit the conflicting file to make sure it's resolved, and then `bzr resolve FILE`
<bac> mikl: using a tool like kdiff3 or meld makes it pretty easy
<bac> i use the extmerge plugin which you may want to have a look at
<mikl> bac: ok, thank you :)
<rjek> So, what are people's suggestions for web-based bzr branch/repository browsers that don't require a big fat framework?
<beuno> rjek, I've been working on a php-based solution
<beuno> but it's not releaseable
<TFKyle> beuno: implemented a lot of bzr in php?
<rjek> Eugh.  I'm not sure I'd want to run a php-based one.
<rjek> Especially given that we've banned PHP from our co-lo boxes.
<beuno> TFKyle, yeap, quite a lot
<rjek> Something that could do what bzr vis does would be extra lovely.
<rjek> Additionally, are their C bindings to bzr so I can use it as a library from C and other languages?
<corporate_cookie> im calling BZR from cron on a RHEL4 system with a parallel install of python2.3 and 2.4. Cron reports this error: /bin/sh: bzr: command not found. However bzr works otherwise
<corporate_cookie> any ideas ? : )
<rjek> What does "which bzr" say?
<rjek> It may not be in the PATH of the environment that runs the cronjob.
<corporate_cookie> rjek: it says /usr/bin/bzr
<rjek> Try changing your cronjob to use /usr/bin/bzr rather than just bzr.  If that doesn't work, it may not be able to find any Python.
<corporate_cookie> the job runs as root ...whos path is -bash: /usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin
<abadger1999> Does anyone know the plan regarding bzr versions and stability?  (ie: will there be a 1.0.x branch?  Will 1.x have API backwards compatibility? Business as usual?  Other?)
<rjek> The environment that your cron runs in need not be the same as the one you get if you log in as root.
<corporate_cookie> how do I determine what environment cron runs in
<corporate_cookie> (my linux foo is weak)
<rjek> corporate_cookie: Write a cronjob that just runs "env" - it'll email you with the environment :)
<corporate_cookie> good thinking! :" )
<rjek> I know nothing of Red Hat.  I've not used it in years.  I know less about Python, so if this doesn't reveal the answer obviously, I'm out of ideas :)
<jam> abadger1999: generally business as usuall. We've already released 1.1, and 1.2 is on the way
<abadger1999> jam: Thanks.  I guess I'll be updating for Fedora but holding at 1.0 for Red Hat/CentOS then.
<jam> rjek: as for C bindings, you can embed the python interpreter in your C program
<jam> rjek: then you would be working in terms of PyObjects, etc
<rjek> jam: Eugh.  I'd rather avoid having to speak Python.  And embedding Python into Lua in order to query stuff nicely sounds like a hack :)
<dato> abadger1999: I think cron resets PATH to something unuseable, you'll want to give PATH a value
<jam> understandable, I don't think our data objects are terribly hard, but it would seem silly to reimplement everything
<rjek> For example. subversion has a nice library you can link to directly from C.
<jam> rjek: sure, but it was *written* in C
<rjek> jam: Well, you can bind C functions to Python.  Is it not simple to bind Python functions to C?
<rjek> Lua makes this pretty trivial.
<rjek> I have no idea what Python's C interface is like, of course.
<jam> It's interface is pretty decent
<jam> IMO
<jam> of course, it is up to you whether you would rather embed python
<jam> or spawn a process and parse text
<jam> bzrlib is a rather rich api
<rjek> I'd rather use a C API, as that's then trivially used from pretty much everything.
<jam> and 'bzr' is more focused on clients than scripters
<rjek> Be it C, C++, Lua, or Perl.  Or whatever you fancy.
<jam> except then you are stuck with the C data model, etc.
<jam> and string processing and memory management is horribly painful at the C level
<rjek> For a slight inconvience you gain a lot of flexibility, though.
<jam> anyway, /me => away for a while
 * rjek shrugs, libsvn's API's pretty elegant.
<beuno> hmmm, I just upgrade a 3GB branch to packs, and now, the repository is twice it's size. repository/obsolete_packs/ seems to be the same size as repository/packs/.  Is this an expected behaviour?  (bzr 1.0)
<jam> beuno: you can nuke obsolete_packs/*, bzr will clean it up eventually, we only keep it around to avoid race conditions with when the OS writes out new files versus deleting old ones
<beuno> jam, great, thanks. Shouldn't there be a command that you cleans it for you?
<jam> At the moment, it will be done at the next "autopack"
<jam> which will be approximately 10 commits from now
<jam> I've posted to the list about having "bzr pack" do it automatically
<jam> we could add a new command, but it seems better suited to just add it into bzr pack
<beuno> yes, bzr pack seems like the most intuitive (in fact, I ran it before to see if it would solve it)
<ubotu> New bug: #184097 in bzr "[1.0.0] Should not die on error if cannot open .bzr.log" [Undecided,New] https://launchpad.net/bugs/184097
<_flx> hi
<_flx> is there any way when commiting with the command line to add endline in the commit message so separate two elements
<_flx> ?
<brilliantnut> _flx: is there a problem with opening the editor for entering your commit message?
<_flx> brilliantnut, no the I would like to do it with the "-m" option
<_flx> s/the/but
<BasicOSX> Is there a way to get a remote bzr repository without all of the history? I just want a working copy of the bzr tree, to us, and save the disk space by not having the history
<james_w> BasicOSX: I'm afraid you can't do that currently.
<LarstiQ> lightweight checkout?
<LeoNerd> bzr co --lightweight URL
<brilliantnut> _flx: if you're on linux, then most shells will let you add a \ at the end of your line to escape the new line
<LarstiQ> BasicOSX: for just a copy of the working tree, that works. But for any other bzr functionality it will have to hit the network.
<_flx> brilliantnut, thx you
<mtaylor> statik: I sent in the patch we were talking about
<jelmer> what's the proper way to get the per-file ancestry these days?
<ekimus_> hi, is check_signatures and create_signatures some magic thing? I just can't figure out how to specify the key, or do I have to explicitely set gpg_signing_command in the corresponding locations.conf section?
<ekimus_> hmm or ist the signature stuff just used for email submissions?
<Qhestion> anyone know where i can get paramiko (for sftp)? looks like the homepage is down :/
<Qhestion> ahh wait... nevermind
<Qhestion> its on launchpad :)
<james_w> It's obviously been to long, I can't believe I got that wrong.
<james_w> Hi LarstiQ, how are you?
<LarstiQ> james_w: improving, thank you. How about you?
<james_w> I'm well thanks.
<james_w> Do you think you'll go to the sprint?
<LarstiQ> james_w: not decided yet
<james_w> LarstiQ: it would be great if you were there so we have a chance to meet.
<LarstiQ> james_w: you're going?
<james_w> LarstiQ: hopefully, but probably only for the last couple of days.
<james_w> jelmer: will you be going?
<LarstiQ> james_w: cool, that's certainly something I have to keep in mind then.
<jelmer> james_w: Yep, I'll be there
<james_w> great.
<cr3> is bzr quicker or slower with some protocols? for example, is sftp known to be slow?
<mtaylor> cr3: yes
<mtaylor> cr3: sftp is _way_ slower than bzr+ssh
<mtaylor> cr3: of course, there are some situations in which you still want to use sftp
<mtaylor> cr3: such as when the server you are dealing with doesn't have bzr installed or has an old version installed
<deepjoy> if I want to use bzr as a server for the central repos with authentication with a relatively slow connection between the repos and the developers what format should I be using? i.e. bzr+ssh bzr+http sftp etc.
<beuno> deepjoy, bzr+ssh or bzr+sftp is fine
<deepjoy> also is are the repository format considerations I should be aware of
<deepjoy> I'm converting my repos from CVS using cvsps plugin
<deepjoy> is the default repos storage format that bzr 1.1 converts to the latest?
<deepjoy> or is there some other repos format that is not the default but may be different (not necesarily better) in it's performance
<beuno> deepjoy, yeap, packs, which is the format to use
<deepjoy> so I gather bzr+http is still in it's nacency and using apache for ldap auth using mod_ldap is not stable yet?
<deepjoy> so pack is the default on 1.1?
<beuno> deepjoy, bzr+ssh is the fastest method, bzr+http isn't ready for pushing yet AFAIK
<beuno> and yes, packs has been the default format since <0.92
<beuno> it has a lot of performance work done on it
<beuno> so using 1.1 and bzr+ssh seems like the way to go
<fullermd> No, it's existed since 0.92.  Didn't get switched to default 'till 1.0, I think.
<beuno> ah, could be true
<beuno> 1.0 and on for sure
<deepjoy> thanks
<beuno> np  :D
<deepjoy> I was trying to get bzr+http working some time back on 1.0 and spiv pointed out how to get it working for push
<deepjoy> it does do push
<deepjoy> the perf  is not too good yet
<deepjoy> I believe there is a verb addition task in launch pad for that
<beuno> ah, I haven't tried that out in a while
<beuno> good to know though
<pfharlock> I have a rather dumb question, if you delete a branch from a shared repository using the os filesystem commands, is there a way to get that branch back out of the repository?
<james_w> pfharlock: yes.
<james_w> pfharlock: the easiest way is to install the 'heads' plugin.
<pfharlock> ahhh, ok, so there isn't a built in way to do it.
<dato> I think I'd be amused by the output of `heads` in my repositories, where I do zillions of `uncommits`
<james_w> then run that (with an option that I forget, something like --dead), and find the one that you want, and then you should be able to 'bzr branch -rrevid:whatever another_branch new'
<fullermd> Hm.  Today's bzr.dev seems to not like talking to 1.0 over bzr+ssh...
<fullermd> r3191 works; 3192 fails.
<dato> fullermd: there's a msg from lifeless on list about that
<dato> fullermd: subject.*api break
<fullermd> No, that's bzr.dev <-> older bzr.dev, not bzr.dev <-> 1.0
<dato> ah
<dato> indeed, misread
<fullermd> Forgot about that mail, though.
 * fullermd wanders off to post a followup.
<dysinger> So I am going to keep playing with OS X bzr-svn but I have to comment that it's a PITA and not ready for the masses
<dysinger> Git-svn is orders of magnitude faster and smaller on disk.
<dysinger> But that is not a criticism - it's just is what it is :)
<dysinger> s/it\'s/it
<foom> the actual program git-svn is smaller on disk?
<dysinger> My repository on Git is 181MB - with bzr-svn it's twice that.
<jelmer> dysinger: Are you using packs?
<dysinger> --rich-root-packs y
<dysinger> Let me get the actual numbers
<fullermd> That's probably more git/bzr than git-svn/bzr-svn.
<dysinger> y
<dysinger> You guys totally win in the UI
<dysinger> I like it better
<foom> maybe bzr should just be a UI for git. :p
<dysinger> no
<dysinger> that would not work.
<jelmer> dysinger: Afaik the last comparisons actually showed that bzr's on disk format was in the same order of size as gits
<TFKyle> foom: that would kind of suck, you'd loose decent support for windows
<dysinger> hmm let me check myself.
<fullermd> I doubt that.  Maybe an un-repack'd git...
<dysinger> Yeah I just packed and pruned and GC git
<dysinger> but it's the entire trunk and 2 branches thats' 181MB
<jelmer> dysinger: Did you garbage collect for bzr ?
<dysinger> no
<dysinger> enlighten me
<fullermd> In some quick testing I happened to do the other month, bzr in packs won by a little bit (5% or so) against a straight git import, but repacked git was half the size or something.
<jelmer> "bzr pack" should do the packing I think
<jelmer> but I'm not sure if that's all you can do to make storage more efficient
<jelmer> fullermd: Did you try repacking the bzr packs?
<jelmer> lifeless: ^
<lifeless> jelmer: no we haven't
<lifeless> fullermd: yes thats known; its even in my email from tuesday or so about what we need to do for large projects
<lifeless> fullermd: '50% storage reduction' - we have multiple answers that give better compression; just have to choose one and implement
<lifeless> fullermd: and I know john is hoping to get onto that in th enext week or so
<fullermd> Oh, I know.  I wasn't _surprised_ by it.
<jelmer> lifeless: thanks
<jelmer> dysinger: out of curiosity - what's the speed difference between bzr-svn and git-svn like?
<dysinger> Well i can compare both packed and make some commits and updates with "time"
<dysinger> both repos with trunk and 2 branches :  git packed is 187M vs bzr packed is 347M
<fullermd> Really, my biggest current grump that's semi-storage-related is the inability to log multiple files at once (of which 'recursive log' is just a special case).  Smaller is good, but I'm not really hurting on size anywhere important.
<elmo> hey, can I whine about my bzr commit breakage again?
<dysinger> so 150MB is nothing to sneeze at
<elmo> bzr: ERROR: unknown kind 'missing'
<elmo> with 1.0; I couldn't find any bugs about it; before I go trying to boil it down to a reprdoucable test case, does anyone have any ideas?
<lifeless> elmo: file bugs always
<lifeless> elmo: knowing it happened is a useful data point; reproducability is great but not as important as knowing it exists (and always include the .bzr.log snippet for the error)
<lifeless> dysinger: we'll be fixing that by 1.4 I think.
<elmo> lifeless: sure, but I'm leary about how much info I can include in the commit msg
<elmo> err
<elmo> brain hard
<elmo> s/commit msg/bug/
<lifeless> elmo: nothing in the .bzr.log will have content, so unless you are naming files with your passwords :))
<lifeless> elmo: anyhow, sed FTW
<dysinger> So Jelmer my latest attempt to use a clean build of Subversion 1.5 trunk has failed too.  Everything works, I can use svn and all the transports (http/s, svn, ssh) but on bzr-svn I cannot use https without it blowing up.  I can use http etc no problem.
<dysinger> I get this -> Assertion failed: (g->gc.gc_refs != _PyGC_REFS_UNTRACKED), function instancemethod_dealloc, file Objects/classobject.c, line 2285.
<dysinger> Abort trap
<dysinger> :/
<dysinger> but only on https svn repos
<dysinger> svn ls, co, info etc all work with 1.5 and ssl
<lifeless> fullermd: you know the drill; bug or list discussion kthzbye
<fullermd> Eh?  For what?
<lifeless> fullermd: log N files
<ubotu> New bug: #184196 in bzr "BzrError: unknown kind 'missing'" [Undecided,New] https://launchpad.net/bugs/184196
<fullermd> Oh.  I'm pretty sure there's already at least one bug on that.  And besides, everybody knows it, and I thought handling that better was one of the points of the in-progress inventory work anyway.
<lifeless> fullermd: it can be supported to day; speed is orthogonal to functionality
<fullermd> bug 97715 at least
<ubotu> Launchpad bug 97715 in bzr "bzr log DIR should show changes under dir" [Undecided,New] https://launchpad.net/bugs/97715
<elmo> is anyone working on bzr support for reviewboard?
<lifeless> elmo: yes
<lifeless> elmo: statik's friends
<elmo> k
<elmo> git's interface is apparently only 150 lines or so is all
<elmo> anyway
#bzr 2008-01-19
<jelmer> re
<ubotu> New bug: #184237 in bzr "autopacking should be optional" [Undecided,New] https://launchpad.net/bugs/184237
<AfC> What do I have to do to get bzr to ask me to GPG sign when I commit? Doing the `bzr sign-my-commits` for two years of work after the fact seems a bit after-the-fact.
<jelmer> AfC: Set create_signatures=always in ~/.bazaar/bazaar.conf
<AfC> jelmer: ah, sweet. Thanks
<jelmer> or in the appropriate branch-specific place
<AfC> [I heard some moron complaining that bzr lacked this feature that made git superior, and I was like "hey, we have that in Bazaar, I'm sure" so I figured I'd dog food it to make sure.]
<AfC> So if the process that has locked a bzr branch etc no longer exists, could bzr just automatically break lock?
<Peng> AfC left, but I'll respond anyway. I don't know whether I agree or not, but if bzr will automatically break locks, it should print a warning message.
<pygi> quick question folks
<pygi> I'm trying to expose bzr repository over webdav to allow anonymous branching/checkouts, and I get this when I try it:
<pygi> Unable to handle http code 401: Authorization Required
<pygi> which isnt fun at all:)
<bob2> do your server logs elaborate on why (e.g. permissions)?
<pygi> bob2, nothing there
<pygi> just for an idea, bit does work if I set .htpasswd file in there :)
 * pygi should just use smart server
<rjek> I always get that from bzr unless I provide a username in the URL.
<pygi> yea, I know :p
<pygi> but heh :p
<rjek> ie, I have to do http://rjek@foo/.../ rather than just http://foo/.../, and it will correctly ask for the password.  A faff.
<pygi> I dont want a password :p
<fullermd> Well, good, 'cuz I don't want to give you one   :p
<pygi> funny folk :P
<pygi> anyway, will just use it as is, before I get some time to setup a smart server :)
<rjek> Well, if it's saying 401, then that's because your webdav server is set up to disallow anonymous acecss.
<rjek> So it sounds like your server's misconfigured.
<fullermd> What's with webdav, anyway?
<Peng> For anonymous branching, what's wrong with plain http?
<ubotu> New bug: #184292 in bzr "bzr bundle does not include tags" [Undecided,New] https://launchpad.net/bugs/184292
 * AfC tries to work out what needs to be backported to Subversion 1.4.6 for the bzr-svn plugin to work
<jelmer> AfC: There's a patch on the bzr-svn wiki page
<AfC> Ah
<AfC> jelmer: http://samba.org/~metze/subversion-1.4.0-metze-python-bindings.patch ?
<jelmer> yep
<AfC> Patch appears to apply cleanly to 1.4.6 ... building now
<AfC> Damn. Doesn't seem to have worked. :(
<jelmer> what problems did you run into?
<AfC> jelmer: kind of you to ask. The answer is "well, none, really."
<AfC> I took the existing package, added the patch line, and let 'er rip.
<AfC> I did one thing wrong and ended up having to build it a few times, but no matter
<AfC> But at the end of it all, I still have bzr-svn reporting it can't do it's thing, see README etc
<jelmer> AfC: Did you run ./autogen.sh --release ?
<jelmer> (see the instructions on the wiki)
<AfC> Python bindings got built, etc so I'm not sure what to poke
<AfC> Does the package run autogen? I doubt it
<jelmer> autogen.sh --release reruns swig
<jelmer> see the instructions on the wiki
<AfC> Shit.
<AfC> I was hoping just patching the sources and building would work.
<jelmer> we could include the changes to the files generated by swig in the patch
<jelmer> but that would probably mean having to put up a patch for each minor release of subversion
<jelmer> because that's much more likely to cause conflicts
<jelmer> AfC: what platform are you on?
<AfC> Gentoo
<AfC> I've been getting advice on from  the Desktop devs, but I just followed the wiki's instruction to run autogen and it still didn't work
<AfC> The ebuild for subversion has a long history, and it looks a bit fragile. They'll need to figure it out from here; I give up
<jelmer> there is a gentoo overlay that contains the patched subversion
<jelmer> it's on launchpad somewhere
<jelmer> though I'm not a gentoo user, so I haven't tried it
<AfC> Hm. I'll look for that, then. We don't use overlays as a matter of policy, though.
<AfC> But the ebuild itself might be usable.
<jelmer> https://launchpad.net/bzr-gentoo-overlay/
<AfC> jelmer: thanks. I'll look at it tomorrow
<zero-9376> hi can someone tell me if bzr-gtk will be available in gutsy soon? i have bzr 0.9 on my desktop and just upgraded my laptop and got bzr 1.0 but bzr-gtk was uninstalled in the process.
<jelmer> zero-9376: You mean in the gutsy repository on bazaar-vcs.org ? afaik existing packages in released versions of ubuntu are not updated, except for major bug fixes
<zero-9376> just looking in synaptic now version 0.90-1 is installed and 1.01 is availalbe (i have backports and proposed enabled)
<zero-9376> i just wondered if anyone knew whether the gtk tools would be arriving as well
<zero-9376> just added the bazaar-vcs repo and while bzrtools is available it still wants to remove bzr-gtk
<jelmer> I'm not sure the bzr-gtk package at bazaar-vcs.org is kept up to date
<jelmer> lifeless/poolie: ^
<jelmer> this keeps coming up
<ubotu> New bug: #184342 in bzr "Invalid url supplied to transport: "invalid port number  in url:" [Undecided,New] https://launchpad.net/bugs/184342
<ryanakca> since you're removing the bzr bundle command, I guess its preferable not to use it ? https://lists.ubuntu.com/archives/bazaar/2007q3/029497.html
<gustavonarea> Hello, everyone. At the organization I work for, we use subversion+trac in several projects and we're happy with both, but we're willing to give Bazaar a try. So I'd like to know if there's an *stable* alternative to Trac, compatible with Bazaar? I've only found dead projects
<deepjoy> why switch from trac :-) http://hotdesign.com/seybold/everything.html
<deepjoy> sorry wrong link
<deepjoy> https://launchpad.net/trac-bzr
<gustavonarea> deepjoy: thank you; I thought it was dead too, because of its website ( http://bazaar-vcs.org/ObsoletePlugins ). Is trac-bzr stable enough to be used in production environments?
<gustavonarea> oh, sorry... here's its website:
<gustavonarea> Trac Bazaar Plugin
<gustavonarea> A plugin for Trac (>= 0.10) that provides a version control backend for Bzr
<gustavonarea> As of version 0.10 Trac (http://projects.edgewall.com/trac/) does provide an abstract interface for version control systems. (http://projects.edgewall.com/trac/wiki/VersioningSystemBackend)
<gustavonarea> This plugin allows the use of Bazaar-NG for projects.
<gustavonarea> It's far from complete, and is based on Johan Rydberg's work for trac+darcs (http://progetti.arstecnica.it/trac+darcs/)
<gustavonarea> Oh, excuse me... I pasted my whole clipboard
<gustavonarea> I'm concerned about its stability because it'd serve this service: http://tracker.gnulinuxmatters.org/
<ryanakca> is there a 1.1 of bzrtools ?
<ryanakca> or ... would anybody know why bzr is still at 1.1~rc1-1 in Debian and 1.0 in Hardy, before I uupdate it?
<Verterok> moin
<pattern> is there a way to competely delete versioned files from a repository, so that all version history for that file is deleted from the depository as well ?
<deepjoy> somebody asked this question and one of the contributor's replied that you can recreate the repository from scratch without that file with all other versions but cannot delete it from the current repository since that would compromise repository integrity
 * deepjoy is an innocent bystander
<pattern> ok, but if i recreate a repository without that file, how can i get the version history for all of the other files in to it?
<deepjoy> by recreate I meant create patchsets and commit them 1 by 1 into the new repository
<deepjoy> with all the information
<pattern> ah
<pattern> that sounds like fun
<pattern> bazaar can't do that for me, then, i gather?
<deepjoy> as I said I'm an innocent bystander
<pattern> well, thanks for your help anyway, deepjoy
<pattern> maybe someone else here can answer that last question
<ubotu> New bug: #158883 in bzr-svn "ability to push non-lhs revisions" [Wishlist,Triaged] https://launchpad.net/bugs/158883
<luislavena> hello everybody
<Verterok> Hi luislavena
<luislavena> wanted to know if bzr-svn still needs the patched version of svn bindings...
<luislavena> I'm on Windows and subversion build process is still painful
<Verterok> luislavena: I think there is a patched version of the python bindings for windows
<luislavena> Verterok: yes, but they are badly built with VC8, which could show more problems than solutions.
<luislavena> Verterok: know as cross-runtime linking (subversion links to MSVCRT, and the bindings link to MSVCR80).
<luislavena> that affects malloc and free calls.
<Verterok> luislavena: if that is the case, I think the only solution is to patch the python-bindings using MSVCRT
<Verterok> but I don't know much about windows build process
 * Verterok is a *nix guy
 * luislavena now that being a windows-user make hima  second class citizen :)
<luislavena> s/hima/him a
<jelmer> luislavena: thre were updated bindings for Windows, but I think the link has gone dead
<jelmer> luislavena: you may want to subscribe to bug 161082
<ubotu> Launchpad bug 161082 in bzr-svn "very hard to get going on windows" [Medium,In progress] https://launchpad.net/bugs/161082
<luislavena> jelmer: you mean the ones at here: http://bazaar-vcs.org/BzrForeignBranches/Subversion
<luislavena> I just wonder (without a practical background) how Hg guys managed to use the standard bindings.
<jelmer> luislavena: no, different ones, posted as comment to the bug I just mentioned
<jelmer> luislavena: They don't use bindings at all afaik
<jelmer> they just invoke the svn binary
<Verterok> luislavena: I'm just telling you that my knowledge of windows and how it  build+link is practically 0 :)
<luislavena> Verterok: maybe you can read a ongoing articles series of 'X for Windows'...
<luislavena> Verterok: http://blog.mmediasys.com/2008/01/17/ruby-for-windows-part-1
<luislavena> as commented on the bug report, ruby for windows faces the same situation (can blow up in your face) :P
<Verterok> luislavena: thanks for the link
<pmezard> jelmer: we use the bindings in convert extensions. what the problem with them ?
<jelmer> pmezard: but you also invoke the svn binary directly, no?
<pmezard> for the "push" part yes. the bindings are used to retrieve svn revisions not to write them.
<jelmer> pmezard: There are a couple of bugs in the bindings that you don't hit that way
<jelmer> pmezard: (luislavena was asking why hg didn't require certain patches to the bindings)
<pmezard> jelmer: yes i understood that, and i was wondering why we would need such patches
<jelmer> pmezard: There's a huge memory leak in the bindings
<pmezard> jelmer: in the get_log part ?
<pmezard> or in general ?
<jelmer> not just there
<jelmer> in general
<jelmer> and there are several other issues
<jelmer> you will need a patch in order to be able to do commits using the bindings if you don't want to have a local subversion working copy
<pmezard> weird. is the svn api that complicated that swig bindings are hard to generate ?
<pmezard> ok
<jelmer> pmezard: The swig bindings are usually ok
<jelmer> but there are a couple of places where they were autogenerated but never tested
<jelmer> for example, where double pointers are used to return values but there's no swig typemap
<jelmer> s/double pointers/double pointer arguments/
<pmezard> interesting (i don't know swig, but it makes more sense why brian called the binaries for the push part). thanks.
<Peaker> Hey, bzr 1.0-1~gutsy1's Ubuntu package seems to be incompatible with bzrtools/bzrgtk Ubuntu packages.. is that right?
<jelmer> Peaker: Yep, the bzr-gtk package on bazaar-vcs.org hasn't been updated
<jelmer> lifeless: ^
<Peaker> oh, it seems a little ironic given that Ubuntu and bzr are both Canonical products :)
<pattern> does anyone know if there are any automated tools that will delete files from a repository, and then rebuild the repository from scratch, and move all the version history from the old repository to the new repository minus the deleted files?
<ubotu> New bug: #184457 in bzr-svn "bzr crash on commiting pending merges" [Undecided,New] https://launchpad.net/bugs/184457
<jelmer> pattern: There's only something like that for removing complete revisions
<pattern> ok
<pattern> thanks, jelmer
<welterde> hi
#bzr 2008-01-20
<awmcclain> Hey all... anyone up?
<Peng> Maybe.
<awmcclain> Anyone with experience intalling to ubuntu/debian from source?
<Peng> "python setup.py install"?
 * Peng wanders off.
<cpinto> hi all
<cpinto> i'm using bzr to be able to work disconnected from a subversion repo. after fetching the sources i did a bzr unbind. worked a little bit on them, committed stuff and i just did a bzr bind + bzr update as to update from the central repository. now I have a bunch of pending merges mixed with a few not yet merged changes to the code.
<cpinto> is there anyway to commit only the pending merges?
<Qhestion> how can i upgrad bazaar? downloading the newest sources and running "setup.py install" failed.
<Qhestion> my previous installation was bazaar v1.0
<fullermd> Well, you'd usually want to blow away the old install instead of just installing over it.
<Qhestion> hmm, bzr now gives me an error message...
<fullermd> But that wouldn't cause it to error out.
<Qhestion> well, the setup ran fine
<Qhestion> but bzr now give me an error:
<Qhestion> from django.utils.translation import ugettext as _
<Qhestion> oops
<Qhestion> bzr: WARNING: bzrlib version doesn't match the bzr program.This may indicate an installation problem.bzrlib from ['/usr/lib/python2.5/site-packages/bzrlib'] is version (1, 0, 0, 'final', 0)
<fullermd> That suggests that the install put bzrlib somewhere else.
<fullermd> Do you have any plugins installed system-wide (as opposed to in ~/.bazaar/plugins/)?
<Qhestion> but both times i just ran "sudo python setup.py install"
<Qhestion> no plugins.
<fullermd> 'k.  Then blowing away the 'bzr' executable and the 'bzrlib/' dir in site-packages should be all you need to deinstall.
<Qhestion> k. tryin it
<fullermd> (plugins install system-wide under bzrlib/, so you'd have to be more discriminating if you had them)
<fullermd> That'll give you a nice clean slate to work from.
<Qhestion> ok, that did it
<aklaver> Is there any particular reason why the deb packages are lagging behind the other binaries in being released?
<beuno> aklaver, what other binaries?
<dato> or what deb packages
<Peng> It surprises me that you guys don't get debs and whatnot out at the same time as releases when you're so good at everything else.
 * Peng shrugs.
<aklaver> The 1.1 installer for Windows and Mac.
<aklaver> There are no deb packages for 1.1 for either Dapper or Fiesty.
<Peng> There's a 1.1 deb for Gutsy?
<dato> no
<Peng> Exactly.
<dato> there is for hardy, and for debian unstable
<dato> (well, 1.1rc1, but the code is the same)
<Peng> Oh, huh.
<Verterok> aklaver: the 1.1 for Mac is *experimental* and only for ppc
<aklaver> It would seem a project sponsored by Canonical would have the resources to keep its own distribution up to date.
<beuno> aklaver, the packaging is done by volunteers actually
<beuno> (most of it)
<beuno> so it really depends on who has time
<dato> beuno: but robert is in "charge" of the gutsy/feisty/dapper/whatnot backports
<james_w> http://bazaar-vcs.org/releases/debs/dapper/bzr_1.0~rc1-3bazaar1_i386.deb
<beuno> dato, right, just not sure if it's part of "his job" or if it's more of a volunteer thing
<Verterok> what about PPA? https://launchpad.net/~bzr/+archive - http://ppa.launchpad.net/bzr/ubuntu
<james_w> but I don't see a 1.1.
<dato> some ubuntu person should step up and say, "I will take care of uploading from debian unstable to PPA as soon as the deb is out"
<dato> the situation would improve a lot with that, it's my opinion
<jelmer> dato: It's not the PPA that's the problem
<jelmer> dato: It's the fact that there's only one person with access to the debs on bazaar-vcs.org
<dato> I've already stated that I'd be happy to help with problems in those backports
<dato> jelmer: yes, but there was talk on the list to move from debs on b-v.o, to ppa, completely
<jelmer> dato: afaik that plan was never accepted though
<beuno> and we all have access to ppa
<Peng> Ooh, 1.1 debs are in PPA.
<dato> jelmer: I think poolie has 60% happy about it, and robert wasn't
<beuno> well, there is this email: https://lists.ubuntu.com/archives/bazaar/2008q1/036620.html
<dato> beuno: I completely missed that mail
<jelmer> same here
<beuno> I poked the list for the same issue
<beuno> I got that answer
<jelmer> if the ppa is going to be used, it would be nice to have the old location marked as deprecated somehow
<beuno> but no actual debs  :D
<dato> no
<dato> that mail doesn't say ppa is going to be used
<dato> ?
<dato> but it seems that it is
<beuno> nope, I think he meant uploading to bazaar-vcs.org
<dato> yeah, but https://launchpad.net/~bzr/+archive
<beuno> but neither has happened, so I don't know
<dato> what Peng said
<beuno> aaaaah
<beuno> right
<beuno> then we're using PPA, and it hasn't been made public I guess
<aklaver> So how do I go about setting up PPA as a repository to get packages from?
<dato> but then http://bazaar-vcs.org/DistroDownloads needs updating
<dato> aklaver: go to https://launchpad.net/~bzr/+archive, select your distro in the combo box
<beuno> yeap, which is what my original email stated https://lists.ubuntu.com/archives/bazaar/2008q1/036608.html
<dato> I think dapper's is broken
<dato> right, https://launchpad.net/~bzr/+archive/+build/493851
<beuno> aklaver, did all this help?   :D
<aklaver> Yes. I think the repository issue needs to be resolved. This is a project that is heavily promoted by Canonical.
<aklaver> There should be a clear path to Ubuntu updates.
<dato> aklaver: seems that it has been already, it's only the wiki page that needs updating
<beuno> re-sent an email to the list to try and finally close this issue
<jelmer> whoops, I just sent one as well
<beuno> ah well, it won't hurt to make some noise on the subject  :p
<jelmer> :-)
<Flare183> Is there a frontend of bzr for KDE?
<Peng> Flare183: QBzr?
<schierbeck> hi y'all!
<Flare183> Peng: thanks
<dato> schierbeck: hey. hope you don't mind I bug you: I was using bzr viz yesterday, and I was missing a tooltip somewhere indicating the branch nick.
<dato> schierbeck: I think it could be useful to have it somewhere.
<schierbeck> hi dato, no not at all. i've actually been working on improving the tooltips in the viz, but i'd like to use the gtk API introduced in a later version of pygtk than is currently required by bzr-gtk
<schierbeck> it's introduced in 2.12
<schierbeck> but even with that version i find it a bit tricky -- it'll need some work
<dato> aha
<dato> schierbeck: and will that bump the requirement of the version, or can its presence be detected, and just disable that feature if it is not? (which I think it would be good)
<schierbeck> data: it is entirely possible to do that, but i find that it increases the complexity of the code tremendously
<schierbeck> i'd like to look in to the possibility of bumping the required version of pygtk to 2.12
<schierbeck> i mean, is bzr-gtk even used on legacy systems?
<dato> well, 2.12 is pretty recent, isn't it?
<dato> well, "pretty"
<dato> personally I do not care, since *I* have it, but seeing how many people ask for bzr debs <gutsy...
<jelmer> schierbeck: if there's a good reason, I don't think it'd be a problem to require newer versions
<schierbeck> jelmer: it would really help me implement advanced tooltips in the viz
<schierbeck> dato: i've pushed a *very* early implementation of the new tooltips to: <http://bazaar.launchpad.net/~dasch/bzr-gtk/tooltips>
<deepjoy> schierbeck: The requested URL /00/00/21/a0 was not found on this server.
<schierbeck> deepjoy: you have to use bzr branch http://bazaar.launchpad.net/~dasch/bzr-gtk/tooltips
<schierbeck> the just symlink from .bazaar/plugins/gtk to the branch
<schierbeck> *then
<deepjoy> sorry
<dato> schierbeck: ok. info looks good, only, tooltips should only appear over the node, not over anywhere in the line, no? (but I'm sure you're already aware ;)
<schierbeck> np :)
<deepjoy> ya figured that out
<schierbeck> dato: yeah, i've tried to make it appear where i want, but i'm having some difficulties
<schierbeck> gtk.TreeView.set_tooltip_row() doesn't seem to cut it
<schierbeck> dato: fixed it!
<schierbeck> you should be able to pull the new revision
<schierbeck> jelmer: could i get you to take a look at a few patches sometime tonight?
<schierbeck> i've sent them to the ml
<jelmer> schierbeck: sure, will do
<schierbeck> thanks :)
<dato> schierbeck: I see. well, what I meant is that hovering the mouse *anywhere* in the line pops up a tooltip, which IMHO is not desirable. I think tooltips should show only over specific parts of the line, eg. the colored node.
<schierbeck> dato: hmm
<dato> schierbeck: try to move the cursor around a bit, slowly.
<schierbeck> i disagree -- each row represents a single revision, and it's only natural that the tooltip for a row show the metadata for that revision
<schierbeck> dato: i think that behavior is desirable
<dato> ok, then let's just disagree
<schierbeck> ok :)
<schierbeck> it's just that people don't always understand why only some parts of a row has a tooltip -- it's better to help them out
<misaka> Does anyone have any suggestions on how to use 'version-info' in a rails project?
<misaka> I don't see a '--format=ruby', for example.
<dato> misaka: but there is --template
<misaka> Is that in 1.x?
<dato> yes
<misaka> I've only got 0.9* here, don't see --template with version-info.
<dato> at least
<dato> misaka: it's 1.1, sorry
<misaka> *nod*
<misaka> Well, that's a good start, but ... hrm.
<misaka> How about an automatic way to keep a file up-to-date with the latest version-info?
<misaka> I saw the suggestion about using it in 'make' but it'd be nice if that was up-to-date with each update ...
 * misaka hasn't looked into what kind of hooks bzr might expose yet.
<schierbeck> misaka: have you tried parsin it as YAML?
<schierbeck> *parsing
<schierbeck> it looks compatible
<schierbeck> then you'll get a nice Hash object to work with
<misaka> Huh, there's a point.
<misaka> I'll give that a go.
<misaka> Thanks, nice one.
<schierbeck> no problem
<schierbeck> misaka: you could also use an autogen script to write the version info to a YAML file
<schierbeck> bzr --version-info > version-info.yml
<schierbeck> and then read it at runtime
<misaka> Not familiar with autogen ...
<schierbeck> it's just a bash script in the root of your project dir
<schierbeck> called autogen.sh
<asabil> hi all
<asabil> any plans to have tags displayed in bzr visualize ?
<misaka> scheirbek - Thanks, will check it out.
<schierbeck> asabil: yes
<schierbeck> asabil: have you tried out trunk?
<asabil> schierbeck: any branch already providing this
<asabil> no didn'y do yet
<asabil> I just checked out the code to try to implement it
<asabil> is it already implemented ?
<schierbeck> asabil: some aspects of it
<asabil> can you elaborate please ?
<schierbeck> try "mkdir -p .bazaar/plugins && cd .bazaar/plugins && bzr branch http://bazaar.launchpad.net/~bzr-gtk/bzr-gtk/trunk gtk"
<misaka> scheirbeck - About autogen.sh, is this something bzr or rails would run, or would it be by hand?
<schierbeck> asabil: well, there's a menu that lets you go to a revision by tag name, and the revision info pane displays the associated tags
<schierbeck> misaka: it's something you run before releasing
<misaka> Right.
<schierbeck> it's customary on autotools projects
<misaka> Ya, this being a rails project I'd probably make that a rake task, that's one way to do it.
<schierbeck> misaka: but if it's a ruby project, you might as well make it a Rake target
<schierbeck> :)
<schierbeck> is there a "release" task in Rails?
<misaka> But I'm going to check out the bzr hooks to see if I can try to keep it up-to-date automagically.
<asabil> wow
<misaka> schierbeck - No, not really.
<asabil> the new bzr vis is awesome
<misaka> scheirbeck - You'd be more likely to put it into capistrano, or whatever deployment/release process you use.
<schierbeck> misaka: well, okay
<schierbeck> misaka: tell me about it :D
<schierbeck> sorry, asabil: *
<asabil> heh, why sorry ?
<schierbeck> asabil: the message was meant for you, not misaka
<schierbeck> :)
<asabil> oh I just like the UI
<asabil> looks better and more user friendly
<asabil> I would however try to add something to the graph
<asabil> for example having a big dot inside tagged revisions can be better
<misaka> re: plugins, do I understand right that bzrlib/plugins can exist in the project root?
<schierbeck> asabil: yeah, i'm thinking that, too
<james_w> misaka: no. It's user wide or system wide.
<schierbeck> i've got a branch where there's an icon on the row if the revision is tagged
<schierbeck> jelmer: fuck, i've forgotten my username for bundle buggy -- is it your email or what?
<jelmer> schierbeck: it's "dasch", apparently
<schierbeck> then what the hell is my password...
<schierbeck> i'll just keep trying
<jelmer> see privmsg
<asabil> schierbeck: can you point me to that branch ?
<schierbeck> asabil: 1 min.
<schierbeck> asabil: it's at http://bazaar.launchpad.net/~dasch/bzr-gtk/viz-tags
<schierbeck> asabil: cd .bazaar/plugins/gtk && bzr merge http://bazaar.launchpad.net/~dasch/bzr-gtk/viz-tags
<asabil> schierbeck: seems like the branch is ... gone
<asabil> no is ok forget it
<schierbeck> :)
<asabil> hmmm, that's not exactly how I saw it
<schierbeck> i'm not sure changing the revision graph nodes will be enough
<schierbeck> (oh, by the way, the icon is way off -- we'll need a real "tag" icon)
<asabil> why would it not be enough ?
<asabil> the tag column is ... I don't know
<jelmer> schierbeck: Have you seen how giggle displays tags?
<jelmer> That's the sort of thing I'd prefer to see for viz as well
<jelmer> let me see if I can add a screenshot
<schierbeck> i've got it right here
<schierbeck> yeah, they have a treeview column with icons
<jelmer> hmm, maybe I'm confusing it with something else then
<schierbeck> and a tooltip displaying the tags when hovering the icon
<schierbeck> i think gitk has small labels on the revision graph indicating the tags
<jelmer> ah, I think gitk is the one I mean then
<asabil> that's how I would prefer it as well :D
<schierbeck> yeah, that's pretty cool
<jelmer> man, giggle has gotten slow
<schierbeck> yup
<asabil> http://www.jrock.us/branching.png
<schierbeck> well, i definitely think we should go the gitk way regarding tags, but it'll take some work
<schierbeck> but dear god gitk is ugly
<schierbeck> it's almost unbelievable
<jelmer> well, it's a tk app
<jelmer> they're bound to be ugly
<jelmer> :-P
<schierbeck> yup
<awmcclain> Hey all... I have an SVN repo that looks like /projA/[trunk|branches|tags} /projB etc. I want to convert just projA into bzr... can I do that by using bzr2svn on a SVN working directory ?
<awmcclain> * svn2bzr
<Peng> bzr-svn is more popular now.
<Peng> Not that that's very helpful.
<Peng> You could always just try it. At worst, you'll waste some bandwidth and time.
<awmcclain> Peng: Ah... so I'd use bzr-svn to create a bzr branch and then work from there?
<Peng> Yes.
<Peng> bzr-svn is a bit of a pain to install though.
<jelmer> peng: That heavily depends on your platform
<awmcclain> Well, here goes.
<jelmer> it should be quite easy for SuSE, Debian, Ubuntu, Gentoo Linux and Windows. Other platforms may be harder
<awmcclain> jelmer: is there a package for ubuntu?
<jelmer> awmcclain: yes, in universe
<Peng> jelmer: The svn bindings have been patched?
<awmcclain> jelmer: Do you know offhand if it's compatible w/ bzr 1.1?
<jelmer> Peng: Yes, Ubuntu feisty was the first that included the patches
<asabil> hmm, doesn bzr-svn still have the huge memory leak ?
<jelmer> asabil: that's been fixed although the fix is not included in the python-subversion packages yet
<asabil> ok nice to hear :)
<Peng> jelmer: Cool.
<asabil> still, last time I tried (on gutsy), I found bzr-svn still quite slow :/
<jelmer> asabil: an updated version will be uploaded to hardy in the next couple of days
<awmcclain> Is bzr-svn a pure python package? Can i get 0.4.6 using easy_install?
<jelmer> awmcclain: There is a package for bzr-svn compatible with bzr 1.0 in my debian repository at http://samba.org/~jelmer/debian/
<awmcclain> jelmer: I just install 1.1, will that matter?
<awmcclain> *installed
<jelmer> awmcclain: yes, it'll work with 1.1
<awmcclain> jelmer: Fantastic. Thank you
<asabil> schierbeck: http://ifaedi/~asabil/bzr-viz-tags.png
<schierbeck> asabil: you got a proper URL? :)
<asabil> oups sorry
<schierbeck> np
<asabil> oups
 * asabil wonders why ctrl+a behaves like ctrl+q sometimes
<asabil> schierbeck: http://ifaedi.insa-lyon.fr/~asabil/bzr-viz-tags.png
<schierbeck> asabil: is that working code?
<asabil> yes
<schierbeck> it looks pretty good
<asabil> I just cooked up something quickly
<schierbeck> can you try drawing a square instead of a circle, and remove the dot?
<asabil> I was more thinking about putting a pixbuf next to it
<asabil> with a small tag icon
<asabil> and remove the dot
<schierbeck> asabil: even better
<schierbeck> especially if you can write the tag text inside it
<asabil> not sure it is a good idea
<asabil> because technically speaking a revision can have multiple tags
<asabil> but let me try :D
<awmcclain> jelmer: I should follow the key installation instructions @ http://samba.org/~jelmer/debian/ in order to use apt-get on ubuntu, correct?
<schierbeck> asabil: they should be stacked next to each other
<asabil> ok will try
<jelmer> awmcclain: without works as well, but apt will give warnings about using untrusted packages
<awmcclain> jelmer: Ok, that's fine. Do I just add your url to my sources list? (Sorry, I'm not familiar with getting packages from other sources on apt-get)
<jelmer> awmcclain: See the instructions at that url
<jelmer> add the following line to /etc/apt/sources.list:
<jelmer> deb http://samba.org/~jelmer/debian/ unstable/
<awmcclain> Ahhhh
<awmcclain> Ok, sorry
<awmcclain> Ah, ok. perfect. gpg is giving me "no option --export-keys"
<schierbeck> awmcclain: just use --export
<awmcclain> done
<awmcclain> ty
<schierbeck> np
<awmcclain> ug, of course, since I installed bzr 1.1 from source it's complaining i don't have the package installed. Prehaps I'll just go from source. :)
<asabil> schierbeck: http://ifaedi.insa-lyon.fr/~asabil/bzr-viz-tags.png
<igc> poolie: call on now?
<poolie> igc, hi
<poolie> i'm at the sprint...
<poolie> sorry
<poolie> will call you
<igc> np
<awmcclain> If we're implementing a mainline workflow, it makes sense to serve a shared-repository, right?
<poolie> will call back
<poolie> awmcclain, yes,
<igc> poolie:dropped out ...
<awmcclain> poolie: I'm reading http://bazaar-vcs.org/SharedRepositoryTutorial now. Do I need to do something special if I've just created a branch from an SVN server using bzr-svn?
<LeoNerd> Lots of bzr-svn questions lately...
<Niklas_TechWorld> Is it good practise to have one bzr-repo per package? Or is that overkill? Im working on a project that I want to divide in 3 .deb - would you suggest I set up a x-repo/x-trunk for each of the .deb?
<radix> Niklas_TechWorld: I have a directory structure like ~/Projects/ProjectName/{trunk,other_branches}, and each ProjectName is its own bzr repository
<radix> Niklas_TechWorld: I'm not sure how this matches up with your use case of .deb packaging, but I would generally just build a .deb from a particular revision of trunk.
<Niklas_TechWorld> radix: Ok, so I guess you suggest me to split it up! Thanks for that. I thought that would be the best as well after having a look at the documentation. Thanks a lot!
<poolie> Niklas_TechWorld, i think either way would be ok
<poolie> if they're closely related i'd have just one, otherwise split it up
<Niklas_TechWorld> radix: I agree. One project = one deb = one repository.
<Niklas_TechWorld> poolie: Yeah, I was just wondering for consistency sake :)
#bzr 2009-01-12
<lifeless> yes, I can understand that
<lifeless> I think its reasonable to write a plugin to encode/decode bad names
<sportman1280> ok well question then.  the filename. does it just have to be valid CURRENTLY, or does it have to be valid all trough the repository history.  we have 10,000 revisions....
<sportman1280> so if i can just change the file thats in the svn repository, then thats great
<lifeless> sportman1280: if you are converting all your history, it has to be valid for all of history. Are you wanting to evaluate bzr to move to it, or you just want to use it to hack on current code?
<sportman1280> lifeless: the plan is to move to it
<lifeless> sportman1280: I'd look at editing a fastexport dump then, I think its probably best overall
<sportman1280> ok. now i have to figure out how to fastexport svn
<sportman1280> thanks
<sportman1280> btw, i agree there should be a plugin that can handle these situations :(
<sportman1280> lifeless: ok the fast importer. i played with it for hours earlier today. but had no success at even running it. any help?  i have the plugin installed int he .bazaar/plugins folder
<lifeless> sportman1280: well, you'll want the svn-fast-export to get your data out
<lifeless> as for bzr fast-import, what happened when you tried to run it ?
<lifeless> does the plugin show up in 'bzr plugins'
<sportman1280> thats the thing i couldnt get it to run at all
<sportman1280> http://pastebin.com/m661c1d68
<lifeless> ok, thats the fast-export side
<lifeless> you need pysvn installed from the look of it
<sportman1280> ok done trying again
<sportman1280> lifeless: I still get the same error :(
<lifeless> what does 'python -c import svn' do?
<lifeless> mwhudson: do you recall which package has the python module 'svn'
<mwhudson> i think that's the python-subversion bindings that you have to read the C api docs to use
<lifeless> sportman1280: which precise package did you install; there are multiple python svn bindings
<mwhudson> (package is called python-subversion iirc)
<sportman1280> python-svn is the only one i saw
<sportman1280>  python -c import svn
<sportman1280>   File "<string>", line 1
<sportman1280>     import
<sportman1280>          ^
<sportman1280> SyntaxError: invalid syntax
<lifeless> try 'python-subversion'
<sportman1280> lifeless: it can't download from a internet repository can it?
<lifeless> sportman1280: I don't know
<sportman1280> lifeless: dang
<sportman1280> ok thats it. i give up. 7 hours later and the stupid thing still doesn't work. bazaar clearly just isnt meant to be used :(
<sportman1280> now i get svn.core.SubversionException: ("Expected repository format '3' or '5'; found format '9'", 165005)
<sportman1280> :(
<lifeless> sportman1280: :(
<sportman1280> lifeless: ok i'll try a little more before giving up
<sportman1280> is there another way to dump the data and then import it back into svn?
<lifeless> svnadmin
<markh> is loading submodules a "supported" usecase for lazy imports - eg "from bzrlib import (ui, ui.text,)" - its failing for me in a py2exe environment...
<markh> (with the above in a string used by the normal lazy_import stuff...)
<spiv> markh: it is, yes.
<spiv> I'm not sure that "from x import y.z" is used much in our lazy_imports so far, though, so there may be a bug there.
<lifeless> markh: the brackets look odd
<markh> bugger - that means I need to look into a lazy_import bug rather than just rearrange the imports ;)
<lifeless> markh: try
<lifeless> from bzrlib import ui
<markh> lifeless: yes, the code in question is a larger block
<lifeless> in fact
<lifeless> what is 'from bzrlib import ui.text' *meant* to do
<markh> in a py2exe environment, 'ui.text' causes an attribute error, and dir(ui) doesn't show a 'text' attribute.  all works fine run from source
<spiv> lifeless: import "bzrlib.ui.text", and add "ui" to the local namespace.
<lifeless> markh: in bzrlib.ui add a lazy_import of bzrlib.ui.text as text
<lifeless> markh: lazy_import definitely doesn't know what to do with that import I think
<markh> it does from source, which is strange.
<lifeless> markh: I'm fairly sure its being masked
<spiv> markh: from source something else might be importing it ui.text?
<jamesh> I don't think the normal Python import statement would know what to do
<lifeless> I've checked the code and it claims to have support for this
<spiv> Oh, huh.
<lifeless> markh: up to you if you want to work around or dig deep
 * spiv wonders why he thought "from x import y.z" should work
<lifeless> lazy_import.py line 168
<markh> jamesh appears to be correct - its not valid Python anyway!
<markh> "from bzrlib import ui, ui.text" is a syntax error
<markh> lifeless: but you are saying lazy imports *should* support it regardless?
<lifeless> markh: no
<lifeless> I'm saying that the docstring in the code claims to support
<lifeless> from bzrlib import ui.text
<markh> strangely, it *does* support it!
<markh> just not in a py2exe environment
<jamesh> one of the perils of putting code in strings
<lifeless> jamesh: all code is strings
<markh> ok, thanks.  The code is in qbzr, so I'll take it up with them!
<lifeless> markh: I would try editing ui.__init__
<lifeless> as I suggested before
<markh> lifeless: I'm a bit lost then - you saying it *should* support that even though it would be a syntax error in normal python, and I should edit ui.__init__ to try and make it work in a py2exe env?
<lifeless> markh: did you see my suggesetion at 13:39?
<jamesh> lifeless: well, in this case it'd probably be possible to write a version of lazy_imports that didn't involve embedding code in strings
<markh> I think we have time skew, but yes.  However, I also saw your comment saying it should not support in the first place given its a syntax error, hence my confusion
<jamesh> which would let Python parse and syntax check the imports
<jamesh> and might let other tools see the imports without modifications
<lifeless> jamesh: suggestions appreciated
<lifeless> jamesh: I imagine an import hook might allow it but at a very convoluted cost
<markh> to my mind, the code I quoted is clearly wrong as it would be a syntax error in normal cases.  So I'm still confused if the consensus is bzrlib should support it, or should barf on it...
<markh> if it isn't that bzrlib should support it, I'm confused what my edits to __init__ would be aiming for.
<lifeless> markh: they may work around the problem
<markh> right - but presumably that woudn't be accepted as a patch?
<markh> which means it doesn't actually solve the problem I'm having in binary builds that anyone else (eg, John) creates.
<lifeless> markh: I'd accept it, as lazy importing a deep module like that is plain weird IMO
<lifeless> markh: and it will provide info on how lazy_import may be failing
<markh> lifeless: I'm really confused now :)  You would accept a patch that allows bzr's lazy imports to accept "plain wierd" things, rather than asking the code change to not be wierd?
<lifeless> markh: uhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
<lifeless> markh: AIUI you are not getting a barf, you are getting ui.text not imported
<lifeless> so ui is imported but ui.text isn't
<markh> my thoughts exactly.  I'm confused why the advice isn't simply "fix the wierd code" :)
<lifeless> 13:41 < lifeless> markh: up to you if you want to work around or dig deep
<markh> but why would I want to dig deep to support something plain weird?
<lifeless> if py2exe is failing to copy in ui.text, then jamesh's thoughts about a different style of import hook may be useful long term
<markh> clearly I should just fix the import to code that would be valid in regular python and everyone is happy!
<lifeless> markh: sure, I never suggested that you don't change it
<markh> right - I'm confused though why you would consider supporting it if it wasn't changed - but that's fine - I'll just quit while I'm ahead :)
<jamesh> lifeless: if you bung the imports into a function body, you can either (a) disassemble the code to find the imports or (b) run the code with a custom __import__() to catch the imports
<jamesh> tools like py2exe generally handle imports in function bodies just fine
<markh> yeah - py2exe just uses the modulefinder package, and that does scan the bytecode for imports iiuc.
<markh> jamesh: you comments above about using Python to check the syntax implies you think the behaviour I described (ie, that my example works anywhere) is actually a bug rather than a feature?
<jamesh> markh: I'd prefer that the lazy imports syntax mirrored what was possible with normal imports and not more
<jamesh> having something that is almost but not quite compatible but looks the same is going to cause bugs
<markh> so that is a "yes" :)
<jamesh> yeah.
<markh> ok thanks - just trying to make sure I wasn't *totally* misunderstanding things!
<lifeless> I don't see any reason for lazy imports to be more than regular import can do
<markh> lifeless: right - but my example shows they can in some cases, right?
<lifeless> markh: yes
<lifeless> markh: however thats in qbzr isn't it? I'm not aware of smartass stuff like that in bzr itself
<markh> but longer term, the best interests of everyone would imply noone tries to take advantage, let alone extend, the current behaviour and should use valid python syntax.
<markh> well - I'd call it plain "wrong" rather than smart-arse :) but yeah...
<markh> damn - changing the import to a python compatible "from bzrlib import ui; from bzrlib.ui import text" still doesn't work unless I make the change suggested by lifeless anyway (ie, adding 'import bzrlib.ui.text as text' to the lazy import block in ui\__init__.py).  Should I submit a patch even though I don't have a test case?
<garyvdm> If I do a repository.lock_read() and I *don't* do a repository.unlock() , nothing bad seams to happen.
<garyvdm> This is surprising!
<markh> tortoise itself works well with 1.11 though, including 64bit windows, so that's my bzr work for the day done...
<garyvdm> Is it ok to do that?
<lifeless> garyvdm: not in general
<garyvdm> Ok
<lifeless> markh: cool
<mwhudson> garyvdm: don't you get a warning printed somewhere when you do that?
<garyvdm> No
<garyvdm> I do get a warning if I don't unlock a branch.
<garyvdm> But not with a repository.
<poolie> spiv: is bzr+ssh://host/~/thing supposed to work now?
<spiv> poolie: not yet; there's a quick patch on a bug IIRC.
<lifeless> garyvdm: not sure why you don't see a warning; likely its because the pack family of repositories does its locking more lazily than branch
<lifeless> garyvdm: all the same, you should lock/unlock
<garyvdm> Ok
<poolie> ok, i just misremembered
<lifeless> 334 revs to go
<lifeless> poolie: that evo fix I did at UDS has been committed upstream :)
<poolie> yay
<thumper> lifeless: 334 revs to go until what?
<lifeless> thumper: my local repo has all the bad revs identified and the rest copied to a clean --1.9 repo
<lifeless> thumper: I need to do this to start dogfooding lp for my bzr branches amongst other things
<thumper> ah, ok
<lifeless> poolie: I'm done for the day I think
<spiv> spm: bzr's pqm appears stuck?
<spm> spiv: oki, fixoring
<spiv> spm: ta
<spm> spiv: cause was another one from vila: "Rev 3934: (vila) Fix bug 315737 by correctly querying the test feature" :-(
<ubottu> Launchpad bug 315737 in bzr "Test bzrlib.tests.test_osutils.TestChunksToLines fails" [Low,Fix committed] https://launchpad.net/bugs/315737
<spm> should be ok again now
<spiv> spm: thanks.  I'm surprised that that change by vila would cause pqm problems.
<spm> spiv: it's a resonably common (for a rare occourance) seems to hang on the email sending side for some reason. We just kill off the stuck mailing portion and everything works again.
<spiv> Wacky.
<spm> ie typicaly bloody sysadmins - went things break drag out the Biggest Sledgie you can find and start smashing daemons :-)
<spm> s/went/when/ . Other grammer errors left alone.
<poolie> i thought we tracked this down...
<poolie> :/
<poolie> there might be a patch attached to a bug in pqm?
<poolie> spm, didn't you and me look at this
<poolie> lifeless: night
<spm> poolie: I don't recall chasing that down? But you could well be right - I know we have chased other stuff down. :-)
<vila> hi all
<bitmonk> i'm trying to use bzr-svn, recent from packages on ubuntu 8.10, to push a branch to a new svn location, is this not possible? i get 'http does not support mkdir()'
<bitmonk> and if i try to point at a local path, i get 'parent of ___ doesn't exist', which makes sense, as it's a subloc of an svn repo with other packages..
<poolie> i think there's a separate command to create the new branch
<poolie> dpush?
<poolie> the repository must already exist
<bitmonk> trying clone..
<bitmonk> the repo exists, but i'm pushing to a subdir of a repo, so the file:/// path doesn't actually exist, a portion of it is within an svn repo..
<igc1> hey vila
<vila> spm: you said "seems to hang on the email sending side"... did you track it down to being *mail* related ? I had only see it occurs when I use a "lp:" url so I thought it was ssh related instead
<vila> but it's hard to tell from outside :-/
<vila> spm: I also tried to *stop* using "lp:" url (not that masochistic you know...) but pqm then just ignored my submissions without feedback (giving me hope to fix the problem :/)
<spiv> vila: well, the web interface said it got as far as "success: merge lp:~vila/bzr/bzr.integration/ http://bazaar-vcs.org/bzr/bzr.dev"
<vila> spiv: I know...
<vila> And, to me, that sounds like some connection not being gc'ed or something...
<vila> where both client and server are waiting the other end to say: I'm done
<vila> especially because when the pqm process is *killed* then my submission is successfully proceeded (sp?)
<bitmonk> vila: processed
<bitmonk> (nw)
<vila> bitmonk: thks
<bitmonk> np :)
<bitmonk> assuming you are not a native english speaker, whatever your language is, i'm sure i couldn't say client or server or computer or address or network ;)
<bitmonk> if you are, well, no offense, i'm glad to help with vocab where your high school left off ;)
 * vila needs one lost coffee to finish full boot
<bitmonk> (last)
<bitmonk> keep in mind that green tea has comparable caffeine to coffee, but is less addictive..
<vila> bitmonk: not native but I welcome feedback on any error I can make (language or anything else)
 * bitmonk broke the coffee adiction year sago
<bitmonk> vila: i love non-native english speakers, if only for the opportunity to be helpful when others aren't..
 * vila is already having a hell of a time curing its tobacco addiction, coffee helps in the mean time :)
 * bitmonk has often thought of moving out of the USA and can't imagine what it would be like to face the same social and economic challenges without barely knowing how to say "i'm sorry, but my clients have paid late.."
<bitmonk> yah i hear that
<bitmonk> gotta pick battles
 * bitmonk has cut back a lot on tobacco but hasnt killed like coffee
<bitmonk> i probably drink more than i would if i drank coffee, but i look for other sources of caffeine, whether i'm right or wrong, i dont like the coffay feeling.
<bitmonk> and that said when i used to liv eon coffee i honestly drank a crap load of canadian whiskey every night with my coworkers
 * bitmonk is pretty sure somewhere in that haze he lost a perfectly good automobile
<bitmonk> that light pole had a bad attitude! :-P
 * bitmonk hides
<bitmonk> anyway, eh, i still never figurd out how to push something initialized in bzr to svn, i swear i have before, i'll figure it later, for testing sake i just put the code into place with bzr where it's expected to have pulled from svn.
<vila> poolie: (reading logs backwards) I thought the pqm-stucked-problem was fixed too... and truth is it didn't manifest itself for sometimes... but no hard numbers there as often when tracking erratic bugs :-/
 * bitmonk tries to determine if building his Dom0 kernel in a DomU from the same sources, with same options, will take a comparable amount of time..
<bitmonk> oh wrong chan ;d
<vila> bitmonk: the answer should be: "it should", but that's a wild guess, I'm not using xen :-)
<bitmonk> vila: actually it took just under 8min when it takes almost 30min in Dom0, I must have missed something when mrproper-ing, or left a bunch of stuff out of menuconfig.. this, i find difficult to believe..
<bitmonk> esp as people on comparable hardware have told me that general kernel build takes around 25-30min (3.0GHz C2D)
<bitmonk> anyway, way out of scope for #bzr join in ##xen if you want to continue :)
<bitmonk> maybe it was helped by LVM having the right blocks cached, as i built the kernel in Dom0, then unmounted the LVM volume, restarted DomU, mounted the xfs vol, and build the same code after a mrproper..
<bitmonk> also the DomU has like 512M of RAM and Dom0 has like 3.5-4.0
<bitmonk> anyway, again, out of scope
 * bitmonk scuttles off to ##xen
<vila> bitmonk: thanks for the offer :-) I may try xen in a couple of months but virtualbox is enough for my needs so far
<bitmonk> xen i find quite interesting, though i've been a kernel-hearted-fool since high school some years ago ;)
 * bitmonk heart menuconfig
<igc> night all
<Haffi___> Hi, I'm trying to set up bzr on a server, I've published a branch to it via sftp. When I run bzr branch sftp://... and fetch the tree, edit a file, commit the changes, and finally run 'bzr send' then I get this error: bzr: ERROR: No mail-to address specified.
<Haffi___> How do I specify the mail-to address?
<bob2> --mail-to
<Haffi___> Do I have to specify it?
<bob2> third last paragraph of 'bzr help send'
<luks> that's not really accurate
<luks> the email address is only required for some clients (like the simple editor+smtp one)
<luks> if you are using a gui client, it's usually optional
<bob2> for /to/ or /from/?
<luks> to
<luks> e.g. I have it configured to use evolution, I just run bzr send and type the address in evolution's window
<bob2> oh
<Haffi___> but does the mail have to be sent? If I just skip sending the mail when evolution opens, does it matter?
<bob2> then you want -o
<Haffi___> right, then it's written to file or stdout
<bob2> where do you want the bundle then?
<Haffi___> It still seems like the changes aren't published
<bob2> all 'send' does is produce a bundle and optionally email it somewhere
<Haffi___> oh
<bob2> it doesn't affect any branches - are you trying to update the branch you branched from?
<Haffi___> hehe, yes
<Haffi___> I misunderstood the command
<Haffi___> which command should I use then? I guess 'merge' is to fetch changes from main branch?
<luks> bzr push
<Haffi___> yep, it worked
<Haffi___> thanks
<Peng_> Is it valid to have a revision ID "" (I mean, an empty string, not literally two double-quotes)?
<luks> I don't think revision IDs have any specified format
<luks> so I'd say it's valid, but I'd expect some code to break on that
<luks> because NULL revisions used to be represented as None
<Peng_> The exception raised is NoSuchRevision. It would likely be something else if it was actually invalid..
<spiv> Peng_: At a glance, the code would treat that as a valid revision ID I think.
<spiv> Why do you want to know?
<Peng_> I just wrote an email about it, actually, in Benn Finney's thread.
<spiv> It's bad enough that bzr's history has a revision "A" ;)
<Peng_> Haha, how'd that happen?
<Peng_> "silly commit"?
<Peng_> ...Creating a file called "b"?
<spiv> Peng_: I think a test that made a test commit accidentally modified that developer's real bzr.dev repo instead of a throwaway repo.
<Peng_> Anyway, I wanted to know because of Loggerhead. The URL "/files/" raises an error because it's a nonexistant revision, instead of doing something more useful like showing the index page.
<Peng_> But if it is a valid revision, that's correct behavior, if not convenient...
<spiv> Back before the test suite was as good as it is now at insulating tests from reality.
<spiv> (and vice versa)
<spiv> I think it'd be reasonable to disallow "" as a revision ID.
<spiv> It seems more likely to cause bugs than be helpful.
<Peng_> I don't disagree, but I don't care strongly enough to do anything about it. :P
<spiv> Well, you already did, by mailing the list ;)
<Peng_> Heh, good point.
<phinze> is there a quick way to tell bzr: 'add all of the files in the unknown list' ?
<beuno> phinze, bzr add?
<phinze> beuno: doh!  that was way too easy :)
<beuno> :)
 * phinze was automatically thinking of subversion where he had to do xargs magic for that sort of thing... and consequently didn't read line 1 of the help
<phinze> here's another one... is `bzr co foo; cd foo; bzr unbind` the equivalent of `bzr branch foo` ?
<beuno> I'm not sure, I don't use checkouts much
<luks> yes, it is
<phinze> luks: cool, thanks. just trying to get my head around this stuff
<abentley> phinze: It is *roughly* the same.  "bzr co" won't set the parent location, but "bzr branch" will.
<phinze> abentley: really, that's interesting, you'd almost think it would be the other way around
<phinze> that the checkout would be tethered to a parent and the branch would be free floating
<abentley> phinze: The parent location is used for pulling.  You shouldn't pull in a checkout.  You should update in a checkout, which uses the bound location.
<phinze> ahh
<phinze> so really for the decentralized workflow `bzr branch` is really what you'd want to use
<phinze> because bzr co + bzr unbind leaves you without a pull source
<rocky> phinze: yeah but the first time you pull into a branch that has no pull source, it remembers the new source
<phinze> rocky: okay nice, so there isn't all that much difference between the two in the end
<rocky> yeah, and you can always change the pull source again with --remember
<andresmujica> hi are newbies question allowed?? .. :)
<nDuff> andresmujica, absolutely
<andresmujica> hehe thks
<LarstiQ> does anyone here use bzr-hookless-email?
<andresmujica> i'm using a sw called 5-a-day, as far as i've check it uses bzr internally
<andresmujica> the problem is that i'm using from 2 different computers
<andresmujica> so i wonder
<andresmujica> which is the right procedure to use it
<andresmujica> when i change computers
<andresmujica> somehow update the local .bzr before any update??
<nDuff> andresmujica, are both systems able to connect to each other, or do you want to coordinate through somewhere (any SFTP/WebDAV/FTP/etc. space) they can both get through?
<andresmujica> there's a main place (code.kaunchpad.net)
<andresmujica> both point there
<nDuff> andresmujica, I think it might be easier to have both of them use bound branches
<nDuff> ahh
<andresmujica> but the revisions numbers are different because i mainly work at one of them, and sometimes at the other...
<andresmujica> so i suspect i've got to merge or pull or something like that before start my work...
<andresmujica> at the less used computer
<nDuff> if they're bound, that would make every commit automatically push to the server, and every update automatically check the server... but yes, you're right, you'd want to do some merging while setting it all up.
<nDuff> if the more-often-used computer has a superset of everything at the less-often-used system, you should be able to do a push to the server, bind the branch there (on the more-often-used system), go to the less-often-used system, do a pull and then bind that one as well.
<nDuff> ...if the more-often-used one doesn't have a superset, do a merge on it before the push.
<nDuff> ...do you have RSA keys or somesuch to get to the remote system? The software may be surprised if it gets prompted for a password during commit/update/etc. if it's written to expect that its repository will always be unbound (and otherwise purely local).
<nDuff> ("the software" == "5-a-day")
<andresmujica> yeap 5-a-day.. i'm making a mess with my branch :(
<andresmujica> yeap i've got the keys already in place on both systems
<seb_kuzminsky> in a distributed workflow with no central server, can i give my team-mates' branches nicknames locally?
<seb_kuzminsky> i want to be able to say "bzr merge alice", "bzr merge bob", etc
<seb_kuzminsky> and have "alice" and "bob" expand to the urls of those team mates
<james_w> seb_kuzminsky: not currently, though you may want to look at the bzr-bookmarks plugin
<seb_kuzminsky> thanks james_w :-)
<seb_kuzminsky> bzr-bookmarks is winrar!!  :-D
<rbriggsatuiowa> I am encountering the different rich-root support error while trying to clone
<rbriggsatuiowa> http://pastie.org/358686
<rbriggsatuiowa> I tried the suggestions on https://bugs.launchpad.net/bzr/+bug/272425
<ubottu> Ubuntu bug 272425 in bzr ""different rich-root support" error could be clearer" [Low,Confirmed]
<rbriggsatuiowa> but get an bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. error
<rbriggsatuiowa> when trying to do a  bzr upgrade --rich-root-pack
<rbriggsatuiowa> bzr co works just fine
<phinze> hi all i'm in the same spot as rbriggsatuiowa
<phinze> rbriggsatuiowa: if you bzr init --rich-root-pack foo; cd foo; bzr pull remote-foo; it works
<phinze> basically bzr clone is creating a repository of format pack-0.92
<phinze> which is not right
<phinze> because the remote bzr server is using rich-root-pack
<rbriggsatuiowa> stupid gentoo
<phinze> rbriggsatuiowa: mine's doing it too (ubuntu 8.10, bzr 1.6.1)
<rbriggsatuiowa> I double-checked the USE flags and don't seem to be missing anything
<phinze> rbriggsatuiowa: which version you on
<rbriggsatuiowa> Bazaar (bzr) 1.6.1
<phinze> yeah let's try upgrading to 1.10 (which the server is on)... msging you details
<phinze> yep, the problem was using a 1.6.1 client with a 1.10 remote branch
<andresmujica> ok, guys. i 've learned how to do it.  Thanks for your help!!!!
<andresmujica> see ya!
<ollie___> bzr mv concrete/blocks/autonav/ blocks/autonav
<ollie___> bzr: ERROR: Could not move autonav => autonav: blocks/autonav is already versioned.
<ollie___> could someone tell me why i am getting that message?
<ollie___> there is currently nothing in blocks/autonav
<ollie___> so i don't see how it can already be versioned
<ollie___> bzr remove blocks/autonav
<ollie___> blocks/autonav does not exist.
<rsc-> hi guys. I have a branch i'm working on. I make some changes, but instead I change my mind -- i want to commit those changes into a NEW branch. how do i do that?
<LarstiQ> rsc-: have you made the changes yet?
<rsc-> yes
<LarstiQ> rsc-: if so, you could `bzr merge --uncommitted path/to/branch/with/changes` from the one where you want them
<rsc-> ahh.
<rsc-> cool :)
<LarstiQ> did that help?
<rsc-> that should be automatic, yeah? no need for my intervention?
<rsc-> (assuming that both branches are identical)
<rsc-> (...except that one of them has uncomited changes)
<LarstiQ> should be, yeah.
<rsc-> cool.
<rsc-> you learn something new everyday.
<rsc-> thanks :)
<LarstiQ> Possibly you want to list a couple of files you want the changes from, and not others.
<adeel> can bzr handle resource forks (found in macs)?
<LarstiQ> adeel: I don't think it does anything special with them.
<LarstiQ> as most things are wont to do.
<adeel> LarstiQ, well i know svn has issues with it...where if i check in a file with a resource fork attached, it won't come out the same
<jelmer> adeel, I don't think it handles them at the moment
<jelmer> at least it doesn't handle extended attributes (Linux) or streams (Windows)
<LarstiQ> adeel: that doesn't suprise me, almost nothing handles them.
<adeel> yeah that's what it seems like
<jelmer> It would actually be interesting to seem them being used to store VCS metadata
<adeel> all i know is that bzr has been confusing the hell out of me...conceptually i get the idea, but actually getting my repo started has been a royal pita
<NfNitLoop> adeel: How has bzr been confusing you?
<jam> jelmer: ping
<jelmer> jam, pong
<jam> hi jelmer, for the win32 installers, I went ahead and kept using 0.4.16
<jam> Should I be trying to switch to the 0.5 series?
<jelmer> jam, no, at least not for any production-oriented setups
<jam> k, that's what I thought, but I figured I'd check, since there wasn't an 0.4.17 yet
<jelmer> I hope to release another rc in the next couple of days, then maybe 0.5.0 after that
<jam> jelmer: is 0.5 compatible with an 0.4 conversion? (I'm guessing not, but figured I'd check)
<jelmer> jam, no, although it does support using 0.4-style mappings if explicitly configured
<jam> jelmer: but it would create all new revision-ids, right?
<jelmer> jam, if the 0.4-style mappings are enabled, no
<jelmer> it would create the same revision ids that 0.4 would
<jam> so by default 0.5 isn't compatible, but it can be made so?
<jelmer> jam: yes
<jam> It would be good to have that well documented for an 0.5 upgrade
<jelmer> There's a README.UPGRADING file
<jam> It would probably be important enough to make sure it would get into the NEWS items for whatever bzr starts including it
<jelmer> jam: yeah, probably
<jelmer> jam, one of the things I hope to do in the future (as part of the effort to make bzr more aware of foreign branch support) is to have a subclass of DivergedBranches that indicates different mappings (but the same foreign revision)
<jelmer> including referncing the right docs about upgrading between bzr-<foreign vcs> mappings
<rocky> jelmer: remember that bug i showed you a while back with bzr-svn where it couldn't find the parent branch of a tag? don't suppose you've made any progress on that?
<jelmer> rocky, not sure
<jelmer> rocky, I've fixed *some* bugs, not sure if that included yours
<jelmer> do you remember the bug #?
<rocky> i dont'... but i did update from bzr-svn 0.5 branch and discovered that it now seems to depend on bzr 1.11
<rocky> so that means there won't be a 0.5 version that works on bzr 1.10 ?
<rocky> regardless, i tried with bzr 1.11rc1 + bzr-svn 0.5 branch (as of a couple days ago) and got the same error ...
<rocky> jelmer: just try "bzr co svn+https://dev.serverzen.com/svn/collective/Products.eXtremeManagement/trunk" and watch it complain about tags
<jelmer> rocky, that appears to require a password?
<rocky> jelmer: oh sorry, try the non https version
<rocky> that's anonymous use
<jelmer> ah, thanks
<jelmer> rocky, that seems to redirect me to the https url
<LarstiQ> ronny: what does the workingset accomodate?
<rocky> jelmer: ok, http://svn.plone.org/svn/collective/Products.eXtremeManagement/trunk/ definitely works, i just browsed to it in a browser ;)
<ronny> LarstiQ: manages a set of n branches, i view heads as branches
<LarstiQ> ronny: ok
<ronny> LarstiQ: im not entirely sure on the abstraction
<LarstiQ> ronny: what prompted you to include it?
<ronny> LarstiQ: stuff like hg's named branches
 * LarstiQ looks that up
<ronny> LarstiQ: and of course gits moving tag based branches
<ronny> thats clearly different than bze's directory branches
<ronny> *bzr
<ronny> LarstiQ: made a sense out of all stuff?
<LarstiQ> ronny: I read through http://www.selenic.com/mercurial/wiki/index.cgi/NamedBranches, but that isn't very enlightening
<ronny> LarstiQ: named branches are basically static tags on a revision
<ronny> LarstiQ: it can be used for tihngs like separate vendor branches or very long-lifed global branches
<jelmer> rocky, that's bug 312272, not fixed yet
<ubottu> Launchpad bug 312272 in bzr-svn "unable to find direct lhs parent" [High,Triaged] https://launchpad.net/bugs/312272
<ronny> hmm
<rocky> jelmer: ah cool ... don't suppose you have an eta? :)
<jelmer> rocky, should be pretty soon now
<rocky> great...  it's actually stopping me from getting anymore work done on my eXtremeManagement branch :(
<rocky> jelmer: btw, will 0.5.0 final run on bzr 1.10 ?
<jelmer> rocky, no, it will require at least 1.11
<rocky> jelmer: that's strange since 0.5rc1 worked on 1.10
<rocky> but no biggie
<jelmer> still quite some things have changed since rc1
<jelmer> ~20 bugs have been fixed since rc1 so far, that number will probably end up around 25
<rocky> gotcha
<rocky> no big deal, i don't mind upgrading to bzr 1.11 ... do you know when eta on 1.11 final is?
<rocky> that one bzr-svn bug is killing me tho
<jelmer> I think 1.11 final is already out actually
<jam> jelmer: just 1.11rc1
<jam> rocky: 1.11 final is this fri
<lifeless> hi jam
<jam> hi lifeless
<jam> good morning
<lifeless> jam: how are you going with merging stuff to bbc?
<jam> I've gotten a few things landed
<jam> I have a test suite run going to see if there is anything we need to focus on
<jam> hmmm.. 22 failures 13 errors
<jam> a lot of them close to trivial
<jam> like not using "assert" in the code
<jam> hmm. and a really random error from a piece of code getting a negative number that didn't expect one
<markh> jam: qbzr is broken in the 1.11rc1 :(
<markh> (and therefore most of tortoise)
<jam> Thanks for the heads up. Any idea why?
<jam> I just used the 0.9.6 release, I can go back to 0.9.5 if you think it is necessary
<markh> lazy imports :)
<markh> I mentioned it yesterday in IRC, but the discussion just fizzled out as I'm not sure exactly how to resolve it.
<jam> so lazy imports don't work with the packaging?
<markh> in short, qbzr does 'from bzrlib import ui.text' in a lazy import block, and while that works from source it fails in py2exe.  A potential solution was to fix bzr itself by having the ui package itself lazily import text
<markh> indeed, that was the only solution I could see - re-arranging the imports in qbzr also failed
<jam> do you have the tracebacks to why it is failing with py2exe?
<spiv> Why did rearranging the imports in qbzr fail?
<jam> It seems like it should be working
<markh> the discussion on IRC yesterday stalled after I asked if I should submit a patch even though I don't have tests, but that went unanswered...
<jam> And may signify a bug in the lazy import code
<spiv> markh: submitted code is > unsubmitted code.
<spiv> markh: (and code with tests > code without tests, but having a patch in the first place is a good start...)
<markh> spiv: I'm not sure why they failed to be honest, but I assume it was still something related to lazy imports
<spiv> markh: Hmm.  Maybe question that assumption? :)
<spiv> I'm just guessing.
<jam> so, for my immediate fix, I can do a 1.11rc1-2 with qbzr 0.9.5
<jam> at least people will have something that works
<jam> markh: I don't see any "import.*ui" or "import.*text"
<jam> in qbzr
<jam> (well, aside from the 'gettext' lines)
<markh> in commands.py
<igc> morning
 * markh finds it
<markh> mornin' ian
<jam> ah, there it is
<jam> lib/commands.py
<jam> I would guess the problem is doing:
<spiv> markh: wow, and it's a totally gratuitous lazy_import anyway :)
<jam> from bzrlib import (
<jam>  ui,
<jam>   ui.text,
<jam> )
<jam> I wouldn't expect that to be valid
<markh> yeah, we had this discussion yesterday with lifeless :)
<jam>      from bzrlib import ui.text
<jam>                           ^
<jam>  SyntaxError: invalid syntax
<markh> yeah
<jam> That syntax isn't valid python import
<spiv> jam: right, there's a bug that lazy_import allows that.
<spiv> (and a bug that qbzr does that)
<markh> but - it fails if you try the "obvious" thing that is valid Python syntax.  The detaisl escape me now and I'm yet to have my morning coffee :)
<spiv> markh: the obvious thing is "from bzrlib.ui.text import TextUIFactory", IMO
<markh> oh - well, I was trying "from bzrlib.ui import text" under the assumption the text name was needed - but you are probably correct that it isn't.
<spiv> markh: no, the code is clearly needing "ui.text" so it can use "ui.text.TextUIFactory" at the moment
<markh> yes - I was assuming it also used other attributes from that module
<jam> markh: http://paste.ubuntu.com/104124/
<jam> Would be my suggsetion
<markh> but - at lifeless' suggestion, the code as written works if you add "import bzrlib.ui.test as text" to the lazy import code in ui\__init__.py
<markh> jam: so just remove them from lazy imports?
<spiv> markh: actually I'd expect "from bzrlib import ui; import bzrlib.ui.text" in qbzr would work too.
<markh> s/them/it/
<jam> markh: they are used right away
<hsn_> is there way to define alias for URL which i can use with bzr push?
<jam> lazy doesn't do anything
<jam> hsn_: there is a "bookmarks" plugin
<jam> lp:bzr-bookmarks IIRC
<jam> then you get "bm:XXX"
<markh> yeah - in this case it needs to be fully imported anyway
<hsn_> jam: in bzrtools?
<jam> hsn_: bzr-bookmarks *is* the plugin
<hsn_> got it.
<hsn_> is there way to checkout just some directories from branch?
<jam> hsn_: not yet
<hsn_> http://bazaar-vcs.org/NestedTreeSupport -> this thing works already?
<lifeless> o
<lifeless> no
<markh> jam: so the plan is you will re-release with an earlier version of qbzr, and I'll ping the mailing list in the hope of a new release tomorrow?
<markh> new qbzr release
<markh> or will you hack the existing qbzr into shape?
<jam> markh: I just patched 0.9.6 => 0.9.6-win32 with a trivial 'don't make it lazy" fix
<jam> And I'll send that to the qbzr list
<markh> awesome - thanks
<NCommander> I was wondering if someone could try and confirm a bug in bzr-svn?
<NCommander> (I'm not sure if there is something locally thats causing the issue or not)
<jelmer> NCommander, sure
<lifeless> NCommander: moar details needed :P
<jam> poolie: ping
<NCommander> lifeless, I'm trying to checkout the following SVN repo:
<NCommander> bzr co svn://uclibc.org/trunk/buildroot
<NCommander> It bombs out with a UTF error
<poolie> jam, pong
<jam> poolie: Are we going to start back up with doing a weekly direct call between you and I?
<jam> We seemed to have faltered on that after the new year
<poolie> ah we have a bit
<NCommander> jelmer, also ^
<poolie> that would be good though
<poolie> should we talk now, or maybe tomorrow morning?
<jam> poolie: tomorrow would work best, I think
<jelmer> jam, that reminds me, I've been meaning to ask you what happened to the "This week in Bazaar" blogposts
 * igc food
<jam> I sort of "lost steam" in writing them. Well that and lost statik as my motivator
<jam> I'm a bit of a too-many-details sort of person, so it worked best to have someone who would know what a community would want to hear
<jam> markh: I uploaded 1.11rc1-2
<jam> can you give it a shot?
<markh> sure
<poolie> hello markh
<rockstar> jam, I'm still willing to help out on those.
<markh> hi poolie
 * NCommander pulsechecks lifeless 
<jelmer> NCommander, when does it fail, which revision?
<jelmer> (approx)
<NCommander> jelmer, after its done importing and starts building the bazaar tree
<NCommander> jelmer, I'm running the bazaar from Jaunty, so it might be a little behind the current release version
<lifeless> NCommander: can you get the backtrace from ~/.bzr.log please
<jam> rockstar: maybe we should give it another go this week. If you have the chance, try to think about things that we might want to talk about
<rockstar> jam, sounds good.
<lifeless> statik is still alive yes
<NCommander> lifeless, and jelmer http://paste.ubuntu.com/104142/
<jelmer> jam, Ah
<jelmer> jam, I thought they were quite useful
<lifeless> thats still in bzr-svn
<NCommander> oh
<NCommander> Any ideas how I can fix it, or at least work around it?
<jelmer> NCommander, I'm trying to reproduce it here
<NCommander> jelmer, it died for me in the high 22000s
<jelmer> NCommander: Ah, it died during "fetching revision info" ?
<markh> jam: now failing due to the svn plugin wanting 1.10 it seems
<NCommander> yeah, I reran it
<markh> or maybe bzrtools - its not clear
 * markh checks the log
<jelmer> NCommander, that's not occurring here, so at least this bug is fixed in 0.5
<NCommander> someone should update the ubuntu packaging
<jam> markh: I would expect it to be bzr-svn, just because I did pick bzrtools 0.11.0
<jam> but if you could poke a bit closer, I would appreciate it
<jelmer> NCommander, 0.5.0 isn't out yet
<NCommander> oh
<jelmer> debian experimental has a 0.5rc packaged fwiw
<NCommander> is it available in a PPA?
<markh> jam: the traceback isn't clear but it looks like svn:
<markh> 0.313  bzr-svn: using Subversion 1.5.4 ()
<markh> 4.361  Traceback (most recent call last):
<markh> ...
<markh>   File "bzrlib\api.pyo", line 82, in require_api
<markh> IncompatibleAPI: The API for "<module 'bzrlib' from 'C:\Program Files (x86)\Bazaar\lib\library.zip\bzrlib\__init__.pyo'>" is not compatible with "(1, 10, 0)". It supports versions "(1, 11, 0)" to "(1, 11, 0)".
<jelmer> markh, could very well be bzr-svn
<markh> certainly as of yesterday, svn failed like that
<jelmer> markh, that doesn't look like a released version of bzr-svn
<lifeless> markh: whats the caller above in the backtrace
 * markh needs glasses :)
<markh> 2 entries up is svn's __init__
<NCommander> jelmer, where can I find the bzr-svn snapshots or bazaar branch?
<jelmer> NCommander, http://people.samba.org/bzr/jelmer/bzr-svn/0.5
<NCommander> jelmer, empty folder
<jelmer> NCommander, it's a bzr branch
<markh> jelmer: is there a bzr-svn jam should be using with the 1.11 windows binaries?
<jam> markh, jelmer: lifeless originally made a change that bumped the bzrlib api number
<jam> that was supposed to land in 1.9, I updated it because it landed in 1.11
<enigma42> jelmer: I just checked out a branch from svn. After running a "bzr check" on the repo, I get "4 inconsistent parents". Is that bad?
<jam> I don't remember what off-hand
<jelmer> what happened to API-specific versions? :-)
<jam> ah, it was the "add_inventory_by_delta" change
<jelmer> ah, ok
<jelmer> that shouldn't be relevant to bzr-svn
<jelmer> I'll release a 0.4.17
<enigma42> jelmer: "And I get a bzr: ERROR: No such file" message when I try to branch over sftp.
<enigma42> (But not locally, interestingly enough.)
<jelmer> enigma42, hmm, that's strange - what version of bzr-svn?
<jam> jelmer: just make sure your tag propagates to bzr-svn's trunk :)
<jam> (lp:bzr-svn)
<enigma42> jelmer: bzr-svn 0.5 trunk revno 2281
<enigma42> jelmer: Let me pull up to revno 2293 and try again.
<jelmer> enigma42, the two things should not be related
<jelmer> enigma42, what file exactly does it give the error about?
<enigma42> bzr: ERROR: No such file: ('iovariableplugin.gro-20081110215858-yuu32hfdt8apjga0-1', 'kirby@kirby-ubuntu-dev-20090105202353-tv2de4iskr45pl68')
<jelmer> enigma42, hmm, in that case it could actually be related
<jelmer> enigma42, does the repository in question contain any revisions pushed with previous versions of bzr-svn?
<enigma42> This is a fresh branched just checked out of svn.
<markh> jam: seeing you need to make a new build, could you update tsvn too?  I've made some doc improvements yesterday and bumped the version to 0.2-candidate
<enigma42> jelmer: Yes.
<enigma42> enigma42: The *svn* repository contains revisions pushed with the previous version of bzr-svn
<markh> ack
<enigma42> jelmer: But the *bzr* repo was a fresh checkout from svn.
<markh> jam: actually, maybe scratch that, unless you are also willing to make a trivial change to the .cog
<enigma42> Just to make sure we're both talking about the same "repository" here. ;-)
<markh> (which would be the s/index.html/*.html/ patch I submitted yesterday that was apparently not looked upon favourably by bundlebuggy)
<jelmer> enigma42: this error is likely caused by incorrect bzr-svn metadata set by a development version of bzr-svn, but it's hard to say for sure
<enigma42> jelmer: Is there a way I can zap the metadata in SVN?
<enigma42> enigma42: I'm fine with loosing merge history in this case.
<markh> jam: I need to run out for an hour any time in the next hour.  Do you expect to have new builds up soon?  If so, I'll wait and test them before leaving.
<jelmer> enigma42, only by doing a "svnadmin dump" and removing them in the svndump
<enigma42> jelmer: Oh boy.
<enigma42> jelmer: With 0.5, is that changing?
<enigma42> jelmer: Since it will use revision properties instead?
<jelmer> enigma42, yeah, it's easier with 0.5 indeed (but only if you have subversion 1.5)
<NCommander> jelmer, so how do I use 0.5, I installed it and now get: No module named foreign
<jelmer> NCommander, you need bzr 1.11
<jelmer> sorry, 1.11rc1
<NCommander> I assume no packages exist ...
<jelmer> I think there may be some in the bzr ppa
<NCommander> nope
<NCommander> where do I find the source tarballs :-)
<NCommander> hey lamont
<enigma42> jelmer: Yeah, I get the same "No such file" error with bzr-svn 0.5 trunk revno 2293
<enigma42> jelmer: Do you know of a way of fixing up the bzr repo by hand rather than purging the svn properties?
<james_w> NCommander: try ~bzr-beta-ppa
<NCommander> Of course now that I actually have everything installed from source does james_w pop up with the handy to use PPA
<NCommander> :-P!
<NCommander> jelmer, and as an aside, the issue fixed in the latest bazaars
<NCommander> Thanks for the tip
<jelmer> enigma42, not really - the svn repository contains corrupt metadata, it's impossible to create a bzr branch from that
<jelmer> I guess we could add a svn-import option to skip reading any bzr-svn metadata
<enigma42> jelmer: That would be quite nice. :-)
<lifeless> james_w: the beta ppa doesn't have bzr-svn
<spiv> jelmer: thinking of bzr-svn options...
<enigma42> jelmer: I don't control the svn server, so I can't do a svn-dump.
<markh> bb in an hour...
<spiv> jelmer: I've seen a few people get surprised that bzr-svn will operate on a .svn checkout, specifically when they have .bzr and .svn control dirs for the same directory
<enigma42> jelmer: So I guess I'm out-of-luck than.
<lifeless> spiv: installing bzr-svn by default would fix that
<spiv> jelmer: it might be nice if there were a way to disable that feature in ~/.bazaar/locations.conf
<jelmer> spiv, that seems more like something for the bzr format probe logic
<jelmer> spiv: or do you mean being able to completely turn off support for .svn directories?
<lifeless> jelmer: if you probe in a subdir of the root of a svn tree, does bzr get told 'no branch' and keeps probing, or do you 'find' it immediately and return the root?
<jelmer> lifeless, it's always a BzrDir
<jelmer> whether bzr-svn considers a Branch to be present depend son the repository layout
<lifeless> jelmer: well, Tree I mean
<lifeless> jelmer: cause of the .svn dir
<jelmer> lifeless, same goes for tree
<lifeless> ok
<lifeless> so at the root of a tree, the bzr probe should occur first
<spiv> jelmer: the latter, at least for a given location
<lifeless> and thus a .bzr dir will win
<lifeless> in a subdir though, it might be nice for it not to find a ControlDir unless its the root of the tree, that would let colocated .bzr and .svn 'work as expected'
<lifeless> without needing special facilities
<lifeless> spiv: I don't really like the idea of turning it off
<spiv> jelmer: So I think it'd be possible to make SvnCheckout.probe_transport consult locations.conf before actually probing.
<jelmer> lifeless, the problem also appears to be that people try to "bzr add" .svn directories
<lifeless> jelmer: when a svn tree is under a bzr tree?
<jelmer> lifeless, or at the same location
<jelmer> that's actually what I've seen happen so far, rather than the use case spiv is mentioning
<spiv> It'd probably be enough to make .bzr always take precedence over a .svn.
<spiv> Because people can always use /usr/bin/svn to manipulate .svn dirs.
<lifeless> jelmer: smart_add will skip .svn dirs if they probe successfully as a branch
<jelmer> lifeless, what I mean is that people *want* to version the .svn dirs in some cases
<lifeless> jelmer: oh. they are insane?
<lifeless> hmm, bzrdir.is_control_filename needs to be pluggable
<lifeless> jelmer: ^
<lifeless> spiv: .bzr should already mostly take precedence; except for when bzr is run in a subdir of a .svn tree I think; I'd aargue that that is a valid bug
<spiv> lifeless: sure.  It's definitely been observed by various people that it doesn't necessarily take precedence.
<lifeless> spiv: the reason I am con making this toggleable is that its an option that adds complexity, and is pretty clearly only useful if the functionality isn't right
<jelmer> spiv, it does when they exist in the same directory, but .svn has control dirs in subdirectories as well, not just the tree root
<lifeless> jelmer: so whats the use case for versioning .svn ?
<jelmer> lifeless, poor mans tracking of an upstream branch in svn
<spiv> lifeless: If everything Just Works, then that's great.
<lifeless> jelmer: oh
<spiv> lifeless: Until it does, I'd rather have a toggle that can at least make working the way the user intends possible than not.
<lifeless> spiv: IME such toggles become the end result
<jelmer> jam, 0.4.17 pushed
#bzr 2009-01-13
<enigma42> jelmer: Are the "bzr:file-ids" and "bzr:text-revisions" old meta-data properties?
<jelmer> enigma42, the file properties you mean?
<enigma42> Yeah. They are file properties of the svn directory that contains the project.
<jelmer> enigma42, they are used by both bzr-svn 0.4 and 0.5 if you are not using svn 1.5 on the client and server
<enigma42> I tracked down that "missing" ID that I pasted earlier.
<enigma42> That ID that is being reported as "missing" is set in bzr:text-parents for the project I'm working with.
<enigma42> ack.
<enigma42> I mean "bzr:text-revisions"
<enigma42> NOT "bzr:text-parents"
<enigma42> jelmer: Sorry. Pidgin melted down and I lost my connection.
<enigma42> jelmer: Anyway...I found that problem id in "bzr:text-revisions" file property.
<enigma42> I'm wondering what would happen if I deleted the file property and committed that back in.
<jelmer> enigma42, it may help, but not guarantees bzr-svn won't look at the file properties in older revisions
<jelmer> s/not/no
<enigma42> OK. So, at best, the change would only work from the current revision onward.
<lifeless> spm: can you add markh as a committer to the bzr pqm please
<spm> lifeless: sure
<lifeless> thanks
<spm> lifeless: is done
<lifeless> markh: ^
<lifeless> markh: there is setup info in the dev guide
<markh> lifeless, spm: excellent, thanks.
<spm> markh: it's against your @skippinet address fwiw
<markh> excellent, thanks.  Will it see that address in a "reply-to"?
<markh> (I subscribe to the mailing list via a gmail acct)
<lifeless> markh: the mailing list is unrelated
<markh> oh - I thought maybe to pick up votes...
<lifeless> markh: this is for sending commits to the trunk, not for voting
<markh> ok, gotchya - thx
<markh> I'll read that guide as soon as I finish this little distraction I'm working on...
<rocky> where does bzr save the backups after a "bzr revert" ?
<james_w> rocky: in tree, as .~1~ files
<james_w> then .~2~ if there is a .~1~ etc.
<rocky> thx
<GNUcious> hello all...
<mrooney> Is there a way to authenticate with bzr-svn? When I do a checkout from the svn repository normally, it asks me for my password. But trying to branch it with bzr just gives me Errno 111 Connection Refused.
<markh> lifeless: you referring to the "Core Developer Tasks" section in that guide?
<mwhudson> mrooney: connection refused doesn't sound like a failed authentication
<mrooney> Ahh, and if I try http:// instead of svn:// I get "Unable to handle http code 401: Authorization Required"
<mrooney> mwhudson: okay well what about that? :)
<mwhudson> that sounds more likely, yes :)
<jelmer> mrooney, try svn+http://
<mwhudson> ah hi jelmer
<mwhudson> :)
 * mwhudson stops trying to google this
<jelmer> hey Michael :-)
<mrooney> jelmer: thanks, that seems to be doing something! Although it says the svn+ syntax is deprecated.
<jelmer> mrooney, that's correct, it will go away at some point in the future
<jelmer> mrooney, without "svn+" doesn't work atm because of a bug in bzr
<mrooney> jelmer: oh, so which (svn:// or http://) will work when it becomes removed?
<jelmer> mrooney, svn:// and http:// are different beasts
<jelmer> mrooney, svn:// is for use with the svnserve daemon on the server side
<jelmer> mrooney, http:// is for an http server on the server side
<jelmer> mrooney, svn+http:// will disappear and be replaced by a properly working http://
<mrooney> jelmer: okay, I have branched it which was super slick. Now I have committed and want to push, but I am not sure how to tell it my username (it isn't my unix username)
<jelmer> mrooney, it should prompt you
<mrooney> jelmer: it prompts for the password for my unix username
<mrooney> but that doesn't work since my unix username isn't a user on the repo, alas
<jelmer> mrooney, you should be able to use http://username@host/../ in the URL
<mrooney> oh yes that seems wise :)
 * mrooney hugs jelmer
<mrooney> thanks!
<jelmer> np
<mrooney> this is way more transparent than I expected, good job everyone who worked on bzr-svn!
<lifeless> ok, thats a day for me
<lifeless> ciao
<tsculpt> hello
<mi3> Hello, this is more of a general VCS question: what is the usual way to include code from other projects in your project?  Would you just put it in a subdirectory and ignore it with .bzrignore?  Also, what if it uses its own version control system?
<RAOF> mi3: Generally, people do _not_ include code from other projects.
<RAOF> You could put it in a subdir and ignore it; as far as I'm aware, there are plans for bzr to support the 'checkout of other bzr repository in this directory' concept, too.
<mi3> RAOF: So if I was borrowing code from an LGPL project and including it in my GPL project, I would generally exclude any code from the other project in version-tracking for my own.  That makes sense now that I think about it
<RAOF> What LGPL project? It's generally frowned upon to actually include the source of another project in your own (if you could possibly link to it).
<billam> If a branch gets copied (cp -r) to another spot and separate changes are made to both and committed, is there anyway to merge them back together?
<billam> Each thinks there are no new revisions to merge.
<mi3> RAOF: the situation is that I am including some LGPL code I wrote in one project, in another project (which will be GPL).  It is all written in PHP, and will essentially rely on 'include' statements for the linking.  When distributing it I want to distribute the whole thing, rather than have users have to download two parts from different locations.  If you can suggest improvements to how I'm doing it I'd be interested to hear
<RAOF> billam: works here; I copied a branch to foo-1 and foo-2, added different things to each, committed to each, then merged foo-1 into foo-2
<RAOF> mi3: I guess it depends on what the older project was.  If it's some form of library which is useful outside the new project, it might deserve to be shipped seperately. If no one else is interested in the old project, you can do what you want ;)
<RAOF> billam: How exactly were you trying to merge them?
<mi3> RAOF: The shared part is a library that may be useful for my own future projects. Thinking out loud here... I guess it is similar to how several Mozilla projects include gecko code, or thousands of projects include GTK+ code.  hmm
<RAOF> Please don't model on the gecko code; that's horrible to embed :)
<RAOF> You are of course free to do what you want.  Just bear in mind that if you've got a bunch of shared code across projects it makes most sense to factor it out as a library, and ship it separately.
<mi3> hehe, well the analogy really doesn't go too far.  If the gecko code is a car, then my library would be a single hub cap
<mi3> Thanks for your help
<RAOF> Once it's in a distro the package manager takes care of the dependencies.  And many distros will frown on code duplication, and packagers will curse your name :).
<mi3> ah yep I see.  I guess if it were ever to be packaged for a distro then it could be configured to all point to a separate central library.  I think my concern was how I was going to manage the source code, and I think I have my answer - that the app is project A, the library it's using is project B, and the two shall not be combined into a branch
<mi3> so that the same bit of source code is not version tracked in two different projects
<RAOF> That will probably make things easier, yeah.
<mi3> and I would have the option of distributing it separately too
<mi3> thx
<billam> RAOF, thank you for checking for me. I was using an improper path, works fine with the correct path.
<vila> hi all
<igc> night
<james_w> night igc
<Jc2k> morning
<LarstiQ> jelmer: is there a init.d variant for loggerhead serve-branches?
<Jc2k> does bazaar have any per repository configuration
<james_w> Jc2k: only locations.conf
<james_w> so not really
<Jc2k> james_w: oh, fail
<Jc2k> james_w: and locations.conf can't really be shared between users?
<james_w> no, it can't
<Jc2k> bugger :)
<james_w> there's nothing that is sticky to the branch or to the repository
<fullermd> Sure it can!  You just make it a FIFO with a perl script on the other end, see...
<LarstiQ> well, there is .bzr/branch/branch.conf
<LarstiQ> but that won't be copied verbatim
<Jc2k> so i'd like to have some things configured per repository, mostly hooks
<Jc2k> any branches in foo repository should email-on-commit
<Jc2k> but not in the bar repository
<Jc2k> and the email address might be different per repository, too
<Jc2k> locations.conf *could* work, but there are multiple users
<LarstiQ> Jc2k: not sure if this is what you want, but what about lp:bzr-hookless-email?
<Jc2k> email was just an example, i'd want to hack bzr-cia to be set-up-able per repo too
<Jc2k> and likely other random things
<Jc2k> in pre-change-branch-tip, i could take params.branch.repository.base and look for my own file, but that feels like complete gash
<Jc2k> (more post than pre, FWIW)
<loxs> folks, I have a repository bla/ with branches in it like bla/1.0.0, bla/1.0.1 etc. Now we are releasing new major release (2.0). Is it OK if I create a directory inside bla/ and move the branches from the 1.0 series to it?
<beuno> loxs, this is a shared repo you have in bla/ then?  if it is, then yes
<andrea-bs> Hello! Please, can somebody put bzrtools 1.11 to bzr-beta-ppa?
<loxs> beuno, yes, it's a shared repo
<loxs> beuno, so nothing will go wrong if I move the branches in such a way?
<beuno> loxs, not at all
<beuno> bzr will find the revisions
<loxs> thanks
<LarstiQ> just don't move the branches outside of their repository
<fatcnt> Hi guys. :-)
<fatcnt> I am new to bzr, and just wondering why bzr push --create-prefix bzr+ssh://alex@slice.gaww.net/home/alex/bzr/misc just publishes an empty directory
<fatcnt> from the same directory bzr log & bzr ls indicate both revisions and files
<beuno> fatcnt, is it empty, or does it have a .bzr file?
<fatcnt> drwxr-xr-x  8 alex  staff   272 Jan 14 00:23 .bzr
<beuno> bzr doesn't create working trees remotely
<beuno> so all your data is in the .bzr dir
<fatcnt> :/
<fatcnt> the howto indicates this is possible
<beuno> you can 2 plugins to create the working tree remotely: push-and-update, or, if you don't need bzr's metadata remotely (ie, a website) bzr-upload
<fatcnt> $ bzr push --create-prefix sftp://your.name@example.com/~/public_html/myproject
<fatcnt> 2 revision(s) pushed.
<fatcnt> ah, okay. I need plugins. cool.
<fatcnt> Or, I could just rsync it all up. That might be more effeicent too, right?
<fatcnt> How does bzr handle symlinks?
<beuno> fatcnt, well, bzr isn't very rsync-friendly, but you can do that too
<fatcnt> ait
<fatcnt> I just need to bzr update?
<phinze> is it bzr that's creating these foo.ext.~1~ files?
<jelmer> phinze, yes, when you "bzr revert" a file
<jelmer> phinze, the --no-backup option will prevent it from doing that
<phinze> jelmer: gotchya, thanks
<kinkie> Hi all.. quick question (I hope). Is it possible (directly or via some plugin) to perform content replacement in checked-out files a la RCS "$Id$"? Thanks!
<jelmer> hi kinkie
<jelmer> kinkie, there's some work happening at the moment to support that, not sure how much of it will end up in 1.11
<jelmer> igc, ^
<kinkie> jelmer: I'm not in a hurry. I'm just happy it's in the roadmap. Useful to put a snapshot date in the debugging output to a developing project.
<kinkie> Thanks
<beuno> jam, hi!  from what I've been reading, revnos are always calculated, and never stored. Is that interepretation correct?
<jam> beuno: ATM, yes
<beuno> jam, aha!  So finally I understand why it's so expensive  :)
<beuno> thanks for the confirmation
<jam> They technically vary based on the branch tip
<jam> though with some stability guarantees based on how the ancestry actually would change
<beuno> we do save the last_revno, right?
<beuno> and go from there down?
<jam> Right
<jam> yep
<jam> (Though I consider time to flow downward :)
<jam> most of the time, at least
<beuno> intersting, a lot of emails now make *so* much more sense
<phinze> jam: time flowing downward? such the pessimist!
<beuno> in muy head, tip == top
<jam> beuno: I *always* do 'bzr log --forward'
<jam> Considering my "bzr commit"
<beuno> so it *has* to flow downward
<jam> and my shell time goes downward
<jam> the command I wrote earlier is above the current one
<jam> I think "bzr log"'s default mode is an ugly hack because we don't know how many revisions the person wants
<jam> but we know they generally want the newest ones
<jam> (and it is consistent with all other programs that do that sort of thing)
<jam> but --forward is much more "logical" IMO
<jam> I realize that HTML pages (blog posting) etc work differently
<jam> as you expect old things to get pushed off the bottom of the page, to keep new stuff showing up first
<beuno> right, now we write it literally as a "log"
<jam> Certainly if you read a book, though
<jam> time goes "down"
<jam> Rarely does the next paragraph come before the previous
<beuno> although listings ordered by date can be expected in either order, depending on the relevance of the "newer" data
<beuno> if the terminal didn't scroll, then the current way is fine
<jam> beuno: and whether the arrow points up or down, right?
<beuno> right
<beuno> I think I'd still have a hard time for a while re-mapping the time flow in my head
<jam> beuno: well people expect to do "$VCS log | less"
<beuno> but it's worth experimenting the change with an alias
<jam> beuno: I would recommend "bzr alias log='log --short --forward -r-10..-1'"
<jam> It is what I use everywhere
<jam> I can always do "bzr log -r XXX" if I need more, or do "bzr log --no-aliases"
<beuno> jam, will try it out for a week and see how my happiness levels differ
<jam> but it gives me about 1 screenful of information
<jam> without scrolling
<jam> and giving the summary of what has been happening
<beuno> aaah, I forget how fast --short is...
 * awilkins just uses bzr qlog
<awilkins> But I'm evil
<jam> beuno: and "bzr log --short -r -10..-1" is multitudes faster than 'bzr log'
<jam> as in 4s versus 0.4s for bzr.dev on my machine
<beuno> jam, incredibly so. I never realized the big difference
<jam> beuno: well, I've personally made sure that bzr log --short -r -10..-1 is fast
<jam> as a) I use it all the time
<jam> and b) it is *possible* for it to be fast
<jam> as it doesn't depend on big history data
<beuno> right, no dotted revnos
<jam> yep, and we can find -10 by just walking back 10 revs from the tip
<jam> I don't know about other people, but I generally have a "My mind is thinking and hands are idle, so I'll type something" commands
<jam> It used to be 'ls'
<jam> it is now either "bzr st" or "bzr log"
<beuno> right, if bzr log is that cheap, it's absolutely more informative than ls
<beuno> it's amazing how a second or two changes your behaviour completely
<jam> yep
<jam> It goes into the "without thinking about it" timespace
<jam> versus "waiting for it, and switching context"
<jam> For TDD they give the threshold as about 10s
<jam> that >10s you will go look at something else
<jam> which will destroy your TDD cycling
<enigma42> Does anyone know if there is a way to have dpush create a new branch?
<enigma42> If not, how do I get a branch started so I can "dpush" the rest?
<jelmer> james_w, ping
<enigma42> jelmer: Is there a way to get "dpush" to create a new branch?
<jelmer> I think it should already be able to create new branches
<enigma42> I get "not a branch" errors.
<james_w> hey jelmer
<Lo-lan-do> Hi all
<Lo-lan-do> I'm trying out bzr and bzr-svn from Debian experimental (as opposed to the versions from unstable), and I'm having a few questions.
<jelmer> enigma42, Please file a bug
<jelmer> Lo-lan-do, hi
<Lo-lan-do> First, when I run bzr ls svn+https://svn.gforge.org/svn/gforge/trunk, I get a warning that I should use https://.../trunk instead.
<jelmer> Lo-lan-do, I was about to go to dinner, but please ask anyway, I'll be back in ~30 min
<Lo-lan-do> ...but when I do that, I get error: (51, "SSL: certificate subject name (gforge.com) does not match target host name 'svn.gforge.org'")
<Lo-lan-do> Hi jelmer
<Lo-lan-do> I'll probably pester you later on, I'll go to dinner soonish too :-)
<enigma42> jelmer: I filed a bug and included steps to reproduce it: https://bugs.staging.launchpad.net/bzr-svn/+bug/316205
<ubottu> Ubuntu bug 316205 in debian-installer "Regression: USB/Wireless keyboards not working on Jaunty alternate daily CD - from Alpha 2" [Undecided,New]
<enigma42> jelmer: Thanks again for all your help. :-D
<enigma42> Hm...it looks like ubottu grabbed the wrong bug. ;-)
<jelmer> Lo-lan-do, that's correct, it's a known bug in bzr
<bitner> http://launchpad.net/bzr-xmloutput/trunk/0.8.2/+download/bzr-xmloutput-setup-0.8.2.exe does not seem to give me a usable windows executable, does this work for anyone or is my firewall bungling something up -- the file I get is 24.5k
<bitner> error I get \\mypath\bzr-xmloutput-setup-0.8.2.exe is not a valid Win32 application.
<jelmer> enigma42, thanks
<NfNitLoop> bitner: is there a particular reason you need the 0.8.2 vers... oh, xmloutput.  duh.
<NfNitLoop> Hmmm.
<NfNitLoop> unfortunately, I don't have a windows box handy to test that on.
<Lo-lan-do> bitner: I get a 116K file with wget
<bitner> hrmmmmmm
<bitner> @#$ firewall
<Lo-lan-do> jelmer: Any known workaround, or shall I stay with svn+https:// instead?
<Lo-lan-do> jelmer: Also, a simple bzr update just took 28 minutes, mostly spent in "determining changes".
<Lo-lan-do> I'm running it again, in case it was due to some cache being refreshed for the 0.5 version, but it seems to be not much faster.
<kfogel> in bzrlib/status.py:_raise_if_nonexistent(), I'm trying to figure out why old_tree and new_tree params have those names instead of, say, inventory and working_tree.
<kfogel> Is there any reason why the more general names are significant?
<james_w> you can take the status between any two trees
<james_w> is that function only for working trees and their basis?
<mrooney> enigma42: it looks like you filed your bug in staging? That won't stick at all, will it?
<sabdfl> folks
<sabdfl> did status just get substantially faster on large trees?
<sabdfl> in brisbane-core?
<sabdfl> like, MUCH faster? 20%?
<sabdfl> or is this an artifact of something else in my tests?
<jam> sabdfl: in brisbane-core what revisions are you comparing against? I don't know of any specific work on status, though if your -core was a bit old I've been merging in bzr.dev periodically.
<jam> My first guess would be that you compiled the bzr.dev extensions
<jam> which would have an impact
<sabdfl> no, my test script always does that
<Lo-lan-do> Hm.  33 minutes to commit a single-line patch.  Not everything goes faster as time passes :-)
<Lo-lan-do> jelmer: Will you be at FOSDEM?
<Lo-lan-do> jelmer: If so, maybe I could entertain you for a couple of beers, and you could maybe diagnose what I keep doing wrong...
<jam> Lo-lan-do: are you sure all extensions are compiled? Certainly 33min is rather excessive
<Lo-lan-do> jam: This is on a branch bound to an SVN repo.  Most of the time is spent in the network.  *Lots* of https connections.
<LarstiQ> Lo-lan-do: jelmer will be at fosdem
<jelmer> Lo-lan-do, yep, I'll be at FOSDEM
 * LarstiQ has a hotel booking, but still has to see if he can stand upright
<jelmer> LarstiQ, flu?
<LarstiQ> jelmer: yeah
<LarstiQ> jelmer: I'm back at work, but not being able to understand people is a hint I'm not entirely fit yet. Also, the coughing and snot.
<jelmer> ah :-/
<Lo-lan-do> jelmer: Expect to be cajoled :-)
<thumper> jelmer: hi
<thumper> jelmer: what's the current usability status of svn-server?
<thumper> s/server/serve/
<jelmer> Lo-lan-do, :-)
<jelmer> thumper, pretty much the same as last time you asked :-)
<thumper> :)
<eleftherios> what is the name of that web-based bzr browser that is build with Paste. I think the name has something to do with turtle..
<jelmer> thumper, in other words, a proof-of-concept basically. It doesn't support incremental updates yet, nor commits
<thumper> ok
<thumper> eleftherios: loggerhead
<jelmer> thumper, most of the underlying logic is there already (required for the rest of bzr-svn), but the protocol code isn't there
<eleftherios> thumper: ah thanks!
<thumper> jelmer: is the protocol complicated?
<jelmer> thumper, no, it's not too bad
<mwhudson> morning
<LarstiQ> moin mwhudson
<guilhembi> vila: hello! thanks for your explanation on issue 3232; I'm not getting a word of it, but I'm re-trying :-)
<vila> guilhembi: rats, want some private chat for better explanations ?
<guilhembi> vila: good idea
<vila> here we go
<Lo-lan-do> jelmer: If you have a couple of minutes, could you have a look at http://pastebin.com/f5245a8a8 ?
<LarstiQ> jelmer: do you have any plans for fosdem btw?
<Lo-lan-do> It's the log from the two "bzr update", two "bzr status" and one "bzr commit"
<LarstiQ> jelmer: in case we might want to do something bzry, before I start volunteering for the Debian video team.
<Lo-lan-do> The timing information depresses me :-(
<jelmer> Lo-lan-do, whoa, that's really slow
<jelmer> Lo-lan-do, you may want to use -Dtransport also
<jelmer> (that will print the SVN remote operations)
<jelmer> LarstiQ, not particularly yet - meeting up with Lo-lan-do and Jc2k
<jelmer> LarstiQ, perhaps it's a good idea to have a meetup of all people interested in bzr
<LarstiQ> jelmer: count me in
<LarstiQ> jelmer: just a meetup, or maybe some sprinting as well?
<jelmer> LarstiQ, some sprinting would be nice as well, but it depends a bit on whether we can find space, etc
<Lo-lan-do> jelmer: Temporary output is at http://pastebin.com/f7dde941f
<jelmer> Lo-lan-do, thanks
 * Jc2k would be interested in FOSDEM/bzr action
<Jc2k> (alas my sprinting usefulness is limited to bzr-git and a few small plugins)
<LarstiQ> jelmer: we can ask the organizers :)
<LarstiQ> Jc2k: that's fine
 * Jc2k crosses his fingers and chants at bzr-git
<Lo-lan-do> Jc2k: Would that be two-way?
<Jc2k> Lo-lan-do: hmm?
<Lo-lan-do> Sorry, I thought you were implying you were working on bzr-git, and I wondered whether it's two-way (or planned to be).
<asabil> I think it would be very interesting to have a talk about the inner working of bzr during the FOSDEM
<asabil> and maybe explain the design decision/difference between bzr and git
<Lo-lan-do> asabil: As a user, I would love such a talk, yes.
<asabil> :)
<asabil> I think bzr weakest point is its marketing
<Jc2k> Lo-lan-do: i am, but not on that bit. its planned to be, but its just git -> bzr atm
<Jc2k> Lo-lan-do: (i'm writing a git server, so git users can clone and push to bazaar hosted repos)
<james_w> asabil: I think we're too late for a talk, but we can certainly discuss it
<beuno> jam, so, continuing our previous conversation, it should be easy-ish to cache the revnos in bzr itself, and invalidate (or update) the cache if the tip changes, right?
<beuno> makes me wonder if I should spend my time doing that instead of all the madness I have planned for Loggerhead to tip-toe around the slowness to get revnos
<lifeless> beuno: well my point is that its a bzrlib core issue
<lifeless> beuno: effort put into fixing it should be put into the core :)
<beuno> lifeless, right. I'm warming up to that idea.
<beuno> it scares me ten times as much, because of all the touches, but I guess it's part of learning
<lifeless> e.g. consider a plugin that maintains the cache per-branhc (like bzr-search does)
<beuno> right, that sounds like a nice start
<beuno> polish on top of the plugin until it's in a mergable state
<beuno> I may just do that
<beuno> I ahve to research a little to make sure it's the only thing I need to drop getting the full revision graph
<beuno> s/ahve/have
<jam> beuno: you'll need the merge depth
<jam> I believe
<beuno> right, to get the changed-files-per-mainline-commit
<mrooney> Is this worth reporting / anyone know what's going on? http://paste.pocoo.org/show/99505/
<jam> I also don't know what info you would want to be able to display non-mainline revs in a fold
<jam> jelmer: do you understand the SVN exception mrooney has?
<beuno> jam, well, can I access the merge depth without getting the full revision graph?
<jam> beuno: probably not, but you'll also probably want the mainline revision that merged that revision
<jam> merge_sort gives things to you in a specific order that you can use
<jam> so you probably need some way to preserve that ordering
<jam> I don't know how loggerhead caches it now
<Lo-lan-do> jelmer: Full log at http://pastebin.com/f39f8723e
<asabil> james_w: I think it is still possible to get a Talk
<beuno> jam, the only thing that LH caches right now, is what files changed in each mainline revision and it's children
<asabil> you will probably just need to contact them
 * mrooney waves at james_w
<james_w> hey mrooney
<LarstiQ> jelmer, Jc2k, Lo-lan-do: devrooms at fosdem are taken, so no official sprinting room
<beuno> lifeless, in part, what changed my mind about where to cache revnos, is understanding *today* that they where calculated every single time again
<Jc2k> we should hang around the GNOME guys in Bazaar t-shirts...
<jelmer> Lo-lan-do, thanks
<jelmer> mrooney, don't think I've seen that one before
<LarstiQ> Jc2k: hmm, mightn't that be offensive?
<jelmer> mrooney, please file a bug
<mrooney> jelmer: it seems to be the result of perhaps the output of a post-commit hook?
<mrooney> will do!
<jelmer> mrooney, please test with 0.4.16 / 0.4.17 as well
<jelmer> mrooney, I'm not sure, I think that gives a different exception
<Jc2k> LarstiQ: :] it wouldnt offend me, i cant speak for my Git using counterparts, though :]
<jelmer> Jc2k, asabil: it would be nice to talk about roundtripping revisions
<jelmer> at FOSDEM, I mean
<Jc2k> jelmer: yes
<mrooney> jelmer: is there a PPA for that by any chance? What is the easiest way to try those versions in Intrepid?
<Jc2k> jelmer: oh, git head just got a new command we need to look at too - git note(s)
<Jc2k> jelmer: for associating arbitary blobs with commits (but not in commits)
<asabil> jelmer: sure
<jelmer> mrooney, yeah, there is a PPA for the latest versions of bzr, I don't think it includes the latest bzr-svn at the moment though
<jelmer> Jc2k, ah, that sounds interesting..
<Jc2k> jelmer: it fills me with fear :-\
<jelmer> Jc2k, uhm, fear?
<Jc2k> jelmer: i dont think it would be the right place for us to stash mapping data, but it is another "thing" for us to worry about supporting
<jelmer> Jc2k, it sounds like the perfect place to store mapping data..
<Jc2k> im wondering if it might be local only - not sure how it would work with push/pull
<asabil> Jc2k: what about trying to get a slot in the GNOME devroom about bzr git-serve ?
<asabil> I know it maybe a bit late to ask
<asabil> but it would probably be possible to get a slot if you ask for it
<Lo-lan-do> jelmer: It seems that the SVN revision 6019 corresponds to the first commit I did through bzr-svn on that tree.  Dunno if that helps, but it looks conspicuously like bzr-svn does a get-dir for every subsequent revisions on the same branch.
<Jc2k> jelmer: see bf4d57
<Jc2k> asabil: only if i can get a demo working in next few days
<asabil> if you ask for a slot, you will get it working :p
<mrooney> jelmer: ta-da! https://bugs.edge.launchpad.net/bzr/+bug/316891
<ubottu> Ubuntu bug 316891 in bzr "bzr-svn: SubversionException on certain statuses of post-commit hook" [Undecided,New]
<mrooney> does it look okay?
<vila> beuno: Listen more carefullt next time, I *told* you :-)
<jelmer> mrooney, thx
<beuno> vila, did you?   I must have some level of ADD
<LarstiQ> I know I do.
<vila> I'm pretty sure it came on the table the time we walk together in loggerhead code, but some info needs more time than others to travel in brains :)
<beuno> vila, right. Maybe it's one of those things I had to discover, no matter how much it was explained to me
<vila> beuno: exactly, remember: learning is always painful or it's not learning :)
<beuno> I try to forget that  ;)
<jam> beuno: when will you learn ...
 * beuno hurts
<jam> :)
<markh> jam: installer looks good :)
<Jc2k> jelmer: i can push a git-mirror.gnome.org repo into bazaar and get it back out again intact (aside from something is stopping the refs from getting set correctly :\)
<jelmer> Jc2k, nice!
#bzr 2009-01-14
<Jc2k> jelmer: its not without its problems - it can only handle revisions that came from git as it stands for example.
<Jc2k> anyway, i think im going to sleep at this point :]
<jml> :( :( :( :(
<jml> I hit Ctrl-C during an up-thread --auto and now everything is screwed :(
<jml> switching down to trunk and doing up-thread manually all the way to the top seems to work ok.
<jml> (i.e. fix the problem of pending merges without working tree changes)
<jml> I hope I haven't actually screwed up the loom though
<lifeless> jml: interesting
<lifeless> jml: up-thread --auto probably wnats a KeyBoardInterrupt catch-and-rollback
<jml> it all started when I accidentally hit "bzr up-thread --auto" when I had uncommitted changes
<jml> and so hit C-c
<jml> hmm. bzr di -r branch:../trunk/ looks about right.
<lifeless> jml: bottom: might be easier :)
<jml> lifeless: but less reliable, given that the loom itself is now suspect.
<lifeless> jml: current-thread writes are atomic, and up-thread doesn't modify the bottom thread, so I don't see bottom: being faulty
<jelmer> rocky, hi
<jelmer> rocky, any chance you can confirm that bug in bzr-svn you were hitting is fixed now?
<rocky> ohh...
<rocky> unfortunately i'm away from my workstation atm, but i'll certainly try it as soon as i can
<lifeless> jam: still around?
<igc> hi all
<thumper> igc: hi
<thumper> igc: are you up for a quick skype call?
<igc> thumper: sure
<igc> thumper: http://arstechnica.com/news.ars/post/20090107-dvcs-adoption-is-soaring-among-open-source-projects.html
<lifeless> I need to pop out for a minute to the chemist
<lifeless> brb
<thumper> Tree transform is malformed [('versioning no contents', 'new-4')]???
<thumper> what does that mean?
<emmajane> hi all!
<emmajane> I'm trying to understand using launchpad for merging branches.
<poolie> thumper: it's either a bug in bzr, or in code that's calling in to bzrlib
<emmajane> Should there be a big "MERGE" button that I'm looking for?
<thumper> poolie: ta
<thumper> emmajane: launchpad doesn't merge branches for you yet
<thumper> emmajane: we have some kinda future plans, but it just isn't there yet
<emmajane> thumper, ah! probably why I can't find a button. :)
<thumper> emmajane: exactly
<emmajane> thumper, I'm glad to know I'm just a futurist instead of plain ol' daft. ;)
<thumper> heh
<thumper> emmajane: lets just say I have a loom with about 8 threads dealing with this topic
<thumper> that I haven't had time to get to
<emmajane> awww.
<thumper> ('cause I'm a manager now)
<emmajane> So I guess I shouldn't wait for the button to appear tonight? ;)
<thumper> and I don't get as much time to code as I'd like
<emmajane> (congrats on your promotion)
<thumper> emmajane: sorry, no
<thumper> emmajane: promotion was quite some time ago
<thumper> but thanks
<emmajane> thumper, heh. so you're only just coming to grips with never being able to code again. ;)
<thumper> well, I hope not never
<thumper> just not as often as I'd like
 * emmajane nods
<emmajane> so to merge I need to pull down the branch I want to merge into; merge; and then push back up?
 * emmajane has never done this before.
<thumper> emmajane: can you give me a concrete example?
<emmajane> https://code.edge.launchpad.net/~emmajane/ubuntu-desktop-course/udc-804/+merge/2799
<emmajane> that's sort of concrete, eh? :)
 * thumper looks
<thumper> right
<emmajane> I'm very happy to RTFM if there's anything specific for launchpad.
<emmajane> -beta needs to go into main.
<poolie> lifeless: can we catch up before you finish today, maybe at 4?
<thumper> emmajane: ok, so you are a member of the team that owns the target branch, so that means you can do it
<thumper> emmajane: did you want to move this to #launchpad?
<emmajane> thumper, can do. :)
<lifeless> poolie: shortly before owould be fine
<lifeless> and migod its hot out there
<poolie> isn't it just
<lifeless> anyone know of stats modules in the stdlib ?
<lifeless> e.g. to get stddev, IQR etc
<lifeless> can someone look at bzrlib.check.Check._check_one_revision
<poolie> thumper: hi
<poolie> lifeless: i'm pretty sure there is an SD function
<poolie> in math?
<thumper> poolie: hi, just helping emmajane on #launchpad
<poolie> thumper: whenever you like
<poolie> lifeless: in scipy according to google
<poolie> it's not in math
<lifeless> yeah, I knew scipy would have everything I'd need
<lifeless> but its not stdlib :(
<poolie> copy & paste?
<poolie> lifeless: what about that function?
<poolie> check_one
<lifeless> poolie: well several things
<lifeless> it calls check revision tree
<lifeless> which means we're extracting the inventory for every revision 3 times I think, maybe more
<lifeless> once there, once to generate the text key references, and once in check_weaves
<lifeless> check_revision_tree seems to check that the fileid iteration of the inventory only yields each id once; which seems rather redundant to me - its checking using too high an API pehaps
<lifeless> and then InventoryFile._check seems to double-check the sha1, which means we're extracting every file text twice (or more)
<thumper> poolie: call?
<lifeless> so I'm saying it seems like check can be halved in time without huge effort
<jml> how hard would it be to add a debug option to bzr that shows bytes transferred? is there one already?
<jml> (or can I trick linux into doing this for me somehow?)
<lifeless> jml: -Dtransport possibly, also see vila's transport debugging plugin
<jml> lifeless: thanks
<bob2> ethereal could, too
<lifeless> bob2: ELOWTECH
<bob2> hehe
<poolie> lifeless: yes that's all true
<poolie> about check
<lifeless> poolie: thanks, useful confirmation
<lifeless> you want that call now?
<lifeless> poolie: ^
<poolie> lifeless: talking to thumper at the moment but straight after that would be good
<lifeless> ok
<lifeless> I want to finish sharp at 4
<poolie> k
 * emmajane chuckles at poolie. I assure you it's mostly photos of knitting and looms. 
<poolie> i was seriously impressed by the looms
<emmajane> Thanks. :)
 * emmajane is pretty hardcore into the fibre arts.
<emmajane> That's only because I'm a recovering bookbinder though.
<fullermd> Aren't photos of knits deprecated?   :p
 * emmajane chuckles.
<poolie> emmajane: what was it that made you chuckle anyhow?
<emmajane> poolie, knitting and looms and bzr. It amuses me more than it should.
<emmajane> poolie, a friend of mine also runs a craft show called http://www.bazaarbizarre.org/cleveland.html
<emmajane> Alright. On that happy note. I'm going to give up on the idea of eating supper (it's 1AM) and trundle off to sleep. http://emmajane.net/node/884 <-- thanks for the help (although it happened over yonder, it all started here).
<vila> hi all
<Peng_> Good morning. :)
<poolie> hello vila, Peng
<poolie> sleepy
<igc> night
<LarstiQ> siretart: heya! In bug 317001 you say an unwriteable dir to watch cause bzr-hookless-email to traceback, I haven't yet managed to reproduce that (then again, I'm still sleepy)
<ubottu> Launchpad bug 317001 in bzr-hookless-email "ugly traceback when directory to watch is not writeable" [Undecided,New] https://launchpad.net/bugs/317001
<siretart> LarstiQ: yes. testcase: chown -R the branch to root:root and try as user
<siretart> silly use case, I know, but we have system configuration managed in a bzr branch, and wondered if I can setup the monitoring (bzr-hookless-mail) as non-priviledged user
<siretart> LarstiQ: btw, did you query me before?
<LarstiQ> siretart: not in a looong time
<siretart> ok. then it was someone else :)
<LarstiQ> ah, there needs to be a branch in place *doh*
<siretart> yes. I assume the plugin doesn't work else anyways..
<LarstiQ> siretart: it does, it notices branches that get created after it starts watching
<LarstiQ> (not branches that get mv'ed in the hierarchy, but I've almost fixed that)
<LarstiQ> siretart: and of course it needs to open a branch to trigger that traceback, I was just being stupid
<LarstiQ> siretart: I'll push your changes up in a sec, thanks for the patch!
<siretart> you're welcome!
<vila> guilhembi: ping
<ericvw> How do I have a branch un-ignore a file extension is ignored globally?
<ericvw> that is*
<jelmer> ericvw: I don't think there's a way to do that, but you can explicitly override the ignore by "bzr add <filename>"
<LarstiQ> it will version the file of course
<ericvw> jelmer: Okay, I will do that for now.  Thanks!
<Kobaz> how come sometimes i get: These branches have diverged.  Try using "merge" and then "push".
<Kobaz> and sometimes i don't
<Kobaz> sometimes it will merge for me, and it's auto
<Kobaz> here's an example
<fullermd> It will never merge for you.
<fullermd> The snarky answer is of course "because sometimes they're diverged, and sometimes they haven't"   :p
<Kobaz> files 1,2,3 exist in the repo, user A makes changes to file 1 and does a push, user B makes a change to file 2 and does a push
<Kobaz> and bzr will complain branches have diverged
<Kobaz> so now i have to do a merge
<Kobaz> even though nothing is in conflict
<fullermd> It's a question of what revisions are where.
<fullermd> If all the revisions on the far side are in your local history, they're not diverged, and push can Just Run.
<Kobaz> and then other times, person A will modify file 1, and person B will modify file 2, and then a pull is down, and the files are brought down and merged in
<fullermd> If there are revisions there that you don't have, though, you have divergeance.
<Kobaz> mmm
<Kobaz> so it has nothing to do with conflicts then
<LarstiQ> Kobaz: correct
<fullermd> Yah.  Push doesn't do merges, or create new revisions; it just moved around revs that are already created.
<LarstiQ> Kobaz: the divergence is about wether both branches have different revisions from a certain point
<LarstiQ> Kobaz: do you know the `bzr missing` command?
<Kobaz> yeah
<Kobaz> so if there are missing revs, then you need a merge?
<LarstiQ> sorry, phone call interrupted
<LarstiQ> Kobaz: no
<LarstiQ> Kobaz: if missing reports extra revisions for one side only, yours, or theirs, then you can pull/push and do not need a merge.
<LarstiQ> Kobaz: but if missing shows extra revisions for _two_ sides, that is when divergence has occurred and you would need a merge
<fullermd> If the other side has revs you don't, you're out of date and can pull.  If you have revs the other side doesn't, then it's out of date and you can push.
<fullermd> If you both have revs the other doesn't, then you have divergeance, and have to merge them.
 * LarstiQ nods
<fullermd> (that's a rather simplified way of looking at it, but it works)
<LarstiQ> Kobaz: does that make sense?
<Kobaz> sec
<LarstiQ> lifeless: oh oh, I got an Acer Aspire One, so now I have a laptop with working wireless ;)
<Kobaz> okay, i see
<beuno> jam, second day using yout log alias, and it's 100 times more comfortable to use. Speed and presentation-wise
<maco> hi um, bzr just told me that a file i have on launchpad.net has been locked for 900+ hours, and the error said to use " bzr break-lock lp-46717904:///~maco.m/5-a-day-data/main/.bzr/branch/lock
<maco> but when i do that, bzr then tells me that it's an unsupported protocol
<maco> why's it telling me to do something it can't do?
<jelmer> maco, try running bzr break-lock on the branch location
<jelmer> maco, that's a bug in the launchpad plugin
<maco> so remove the -##### stuff so it just says lp: like it normally does?
<jam> beuno: yeah, I like it a lot, too
<jam> a *long* time ago I proposed it as the default for "bzr log", but I think at that time we decided to be compatible with other systems
<jam> maco: yeah
<jelmer> maco, yeah
<maco> ok, thanks
<jam> bzr break-lock lp:~maco.m/5-a-day-data/main
<Lo-lan-do> jelmer: A thought occurred to me while I was eating my lasagna tonight.
<Lo-lan-do> The bzr-svn logs show that there are lots of "get-dir" requests going back and forth to the SVN server, but they all seem to concern past revisions.
<Lo-lan-do> Shouldn't their results be cached?  Surely that data is not expected to change over time, is it?
<jelmer> Lo-lan-do: Those results specifically are not cached but some of the data that is inferred from them are
<guilhembi_> vila: ping
<dereine> hi is it possible to follow symlinks?
<Lo-lan-do> jelmer: So... why not cache the rest and do without the round-trips?  Or am I talking complete nonsense?
<jelmer> Lo-lan-do: Too much caching takes up too much disk space
<jelmer> Lo-lan-do: Also, I'm not sure why it's looking at those older revisions at all
<Lo-lan-do> Well, I'd be willing to sacrifice some more disk space if it means a commit to SVN takes significantly less than half an hour.
<jelmer> Lo-lan-do, let's figure out first why it's looking at those older revisions
<jelmer> also, a single get-dir call isn't supposed to be as slow as it appears to be for you
<Lo-lan-do> Sounds like a plan.  How can I help?
<jelmer> should just be a single round-trip with about a kb of data
<Lo-lan-do> I guess the remote server is slow...
<dereine> anyone?
<LarstiQ> dereine: your question doesn't make sense to me as-is, could you elaborate?
<Lo-lan-do> But even if it weren't, there's a scalability problem: the number of requests is O(number of revisions committed through bzr-svn)
<fullermd> If they catch you, they might call the cops...
<dereine> i have a repo called config
<dereine> where i link all my config files
<dereine> but bzr only diffs the links itself and not the file behind it
<Lo-lan-do> dereine: Store the files under bzr and do the symlinks the other way round?
<dereine> no other way?
<jelmer> Lo-lan-do, It shouldn't be of that order though
<LarstiQ> dereine: no other way
<dereine> ok thx! btw bzr is awesome!
<Lo-lan-do> Hardlinks maybe.
<LarstiQ> Lo-lan-do: I doubt they won't be broken by bzr though.
<Lo-lan-do> LarstiQ: If you just use bzr as a backup mechanism and only do the restores by hand, myabe you can afford that.
<LarstiQ> Lo-lan-do: possibly
<LarstiQ> dereine: how are you using bzr that this becomes an issue?
<dereine> i have ~/.config
<dereine> no
<dereine> ~/config, there i would like to collect all config files for example ~/.bashrc
<dereine> and ~/.vimrc ...
<dereine> but i don't want to have my home folder as repo
<lifeless> jelmer: git pack delta compression
<LarstiQ> dereine: ah, right
<LarstiQ> dereine: I do that with a ~/dotfiles branch, and then I symlink ~/.zshrc to ~/dotfiles/.zshrc etc
<dereine> its still ok
<dereine> what is the difference between init-repo and init?
<Lo-lan-do> One initialises a repository, the other initialises a branch.
<dereine> mh i did not used init-repo
<Lo-lan-do> That's not strictly necessary.
<Lo-lan-do> A repo is just a way of storing data that saves disk space when several branches share some revisions.
<dereine> for my config i only need one branch
 * dereine still has to learn
<Lo-lan-do> Then no repo is needed.
<dereine> so i pushed my current branch to a webspace
<dereine> removed my local one
<dereine> bzr branch the webspace one
<dereine> so now i change a file locally
<dereine> how can i get them to the server?, so how can i commit on the server
<Lo-lan-do> Either you commit locally then push, or you bind your local branch to the remote one and every commit you do locally will automatically be pushed.
<dereine> what happens if i have no internet connection if i bind?
<Lo-lan-do> Then you can do bzr commit --local, and push only when you get back on the net.
<dereine> ah nice
<Lo-lan-do> Or bzr unbind, work, commit, bzr push, bzr bind
<dereine> wow
<dereine> thats much better than any cvs stuff
<Lo-lan-do> You know, I think that kinda was the point :-)
<Lo-lan-do> Note that a bound branch is also known as a "checkout".
<Lo-lan-do> So when you do "bzr checkout $remotebranch", it behaves the same as a CVS or SVN checkout.  Except you can do diff and log and annotate and whatnot even when you're not on the net.
<dereine> the idea of working locally is just much better!
<dereine> can you explain what https://launchpad.net/bzr-push-and-update does exactly?
<Lo-lan-do> Yeah.
<Lo-lan-do> When you're in a branch, you've got your files, and your .bzr dir.
<Lo-lan-do> That .bzr dir contains the history of the revisions so far.
<dereine> exact
<dereine> yes?
<Lo-lan-do> When you commit or log or diff, the command operates on that .bzr dir.
<Lo-lan-do> When you push to a branch, bzr mostly updates the stored revisions, ie the .bzr dir of that branch.
<Lo-lan-do> The actual (plaintext) files need to be updated separately.
<Lo-lan-do> If the branch is local, then they are updated automatically, but if the branch is remote then they're not.
<dereine> they are only updated if someone merges them from the repo?
<Lo-lan-do> Yup, or if the branch is local.
<dereine> a personal question, do you have your whole homefolder in a repo?
<Lo-lan-do> That plugin does the update for remote branches accessible through ssh.
<dereine> nice
<Lo-lan-do> No.  I have my ~/bin in a repo, and most of my ~/debian/* stuff, but I not the whole home dir.
<dereine> just wonders. because i wait for 5 minutes for a push a branch with files(not .bzr) of one mb
<igc> jam: w.r.t. log --short FILE not working ...
<igc> I think we need to always include_merges inside calculate_view_revisions if there's a fileid given
<igc> sound right?
<igc> that should give us the correct projection onto the mainline
<jelmer> 'morning Ian
<dereine> how can i save the repo , so that i only have to write bzr push?
<Lo-lan-do> bzr push --remember $remotelocation
<dereine> wow incredible
<Lo-lan-do> Although I think it remembers automatically the first time you push
<LarstiQ> it does
<jelmer> hmm
<jelmer> *somebody* should fix progress indication
<Lo-lan-do> ...or make stuff so fast that it's unneeded :-)
 * LarstiQ quickly goes to sleep
<jelmer> poolie, thanks for sending the standup notes again
<mwhudson> beuno: apropos of not much, the directory listing for serve-branches should probably paginated
<mwhudson> -d
<fullermd> Uh oh.
<fullermd> "mbp: several calls; today will bzrtools into ppa"
<Haffi___> Hi, I've pushed a few python files onto a ssh server I'm running, and me and a few others will be working on these files on separate machines. I've read the user guide but I'm not quite I understand fully the difference between using branch and merge or checkout and update
<fullermd> He ran out of verbs already   :(
<fullermd> Haffi___: Checkout gives you a [n additional] working tree on a branch.  Branch gives you a new independent branch.
<jml> "There should be a newer version of Bzrtools available, e.g. 1.12."
<jml> abentley: is this true?
<fullermd> Haffi___: Update is how you bring a working tree up to date with its branch.  Merge is how you integrate changes from 2 branches together.
<Haffi___> fullermd: So if we're trying to keep things centralized, then we should use checkout and update?
<fullermd> (also, rain causes rainbows, and babies come from good home-cookin')
<fullermd> Haffi___: That way you'd have everybody working in lockstep on one branch (CVS/SVN style).
<fullermd> Now, that doesn't stop people from making their OWN branches and working in them locally, then later merging them into the checkout of trunk.
<abentley> jml: No, it's a little early for 1.12.
<jml> hmm.
<abentley> bzrtools 1.11 won't emit that for a dev version of 1.12.
<Haffi___> But regarding concurrency, is it as safe? If I checkout the "latest" branch and work on a file, but in the meantime someone else has made changes to a file and pushed it to the branch when I send my changes in, does it matter shich method I use?
<jml> abentley: I somehow have 1.10...
<jml> I wonder how that got there
<fullermd> Haffi___: If you try to commit in a checkout and it's out of date, it won't let you; you'll have to 'update' first.
<jml> ahh ok. running from a branch.
 * jml pulls to get the happiness
<abentley> jml: So bzrtools 1.11 will work with it.
<jml> abentley: yeah, that works. thanks.
<abentley> jml: np
<fullermd> Hm.  I think it complained for me after bzr.dev changed...
<fullermd> I had to pull it before I could multi-pull my plugins.
<poolie> jelmer: oh, thanks for saying so
<poolie> glad you liked them
<Haffi___> I lost the connection for a bit there...
 * fullermd likes them too.
<abentley> fullermd: What version were you on when you did that?
<fullermd> A rev or two back.  Last pulled in Dec sometime.
<fullermd> r688 probably.
<abentley> fullermd: Well, the version number would be 1.11 then, and that was compatible with 1.12dev
<fullermd> Hm.  Well, I can't reproduce it.
<Haffi___> Are the IRC logs kept public somewhere?
<fullermd> Oh well.  I'll worry about it next time it happens, when I've forgotten about it   ;)
<fullermd> jam used to have them somewhere.  Dunno if he still does.
<fullermd> Only thing I said after your last was
<fullermd> Haffi___: If you try to commit in a checkout and it's out of date, it won't let you; you'll have to 'update' first.
<Haffi___> and update is just merging your working tree with the parent branch?
<fullermd> Pretty much, yah.
<jam> fullermd, Haffi___: If you look in the topic, you can see: http://irclogs.ubuntu.com/
<jam> http://irclogs.ubuntu.com/2009/01/14/%23bzr.html
<Haffi___> right, thanks... :)
<fullermd> Topic?  Well, shoot, why hide the info where nobody will ever look?   :p
<jam> That only seems to update every-hour or so
<Haffi___> I try to look at documentation and such before asking stupid questions, but sometimes you forget looking at the most obvious places
 * ToyKeeper tries to remember how to explicitly set branches URLs for :parent and :submit
<ToyKeeper> s/branches/branch/
<NfNitLoop> toytoy: --remember
<NfNitLoop> er, ToyKeeper
<ToyKeeper> Some commands have a --remember option, but the option name and the branch label don't match and the commands I want to use don't have --remember.
<fullermd> Parent would be pull, and submit...   mmm...   merge, I think?
<NfNitLoop> yep.
<NfNitLoop> Yeah, I've been confused by that before too.
<NfNitLoop> why aren't they just called the "pull branch" and the "merge branch".
<ToyKeeper> I'm still used to the way hg handles branch URLs...  it'll use 'default-CMD' for the 'CMD' command, if it exists, or fall back to 'default' otherwise.  It's simple and intuitive.
<ToyKeeper> To set one, edit .hg/hgrc
<ToyKeeper> Ah, found it.  .bzr/branch/branch.conf ; '%s_location = URL'
<ToyKeeper> I guess it doesn't allow arbitrary labels though, and 'submit_location' isn't the variable for the :submit branch.
<ToyKeeper> Odd.  :parent uses 'parent_location = ../trunk/' but :submit uses 'submit_branch = file:///full/path/to/trunk/'
<NfNitLoop> as you said, it's not meant for arbitrary aliases. :)
<ToyKeeper> If I have both 'submit_branch' and 'submit_location' set, bzr dies on commands like diff, even though 'submit_location' doesn't actually seem to get used for anything.
<NfNitLoop> so don't set submit_location?  :)
<ToyKeeper> Well, yeah.  It's just odd that it would be ignored when it's alone (since it's the wrong name), but cause a collision when the correct name is set.
<ToyKeeper> I resolved the original issue I was having, and now am just looking to see what's fragile or internally inconsistent.
<lifeless> jelmer: around?
<jelmer> lifeless, somewhat
<jelmer> lifeless, what's up?
<lifeless> pack delta compression - how did you implement that
<lifeless> its xdelta right?
<jelmer> I'm not sure it's xdelta completely, but it sure did look like it
<jelmer> it's apply_delta() in dulwich/pack.py in dulwich fwiw
<lifeless> how fast is your implementation? does it need C bindings to libxdelta? where is it?
<jelmer> no, it's implemented in Python
<jelmer> lp:dulwich
<jelmer> dulwich/pack.py
<jelmer> the function is called apply_delta()
<lifeless> did you write a compressor?
<jelmer> there's a create_delta() as well, but I didn't write that - Jc2k did
<lifeless> AIUI xdelta has a turing complete [or nearly] component
<lifeless> is that used?
<poolie> lifeless: i really don't think it's turing complete
<poolie> imbw
<poolie> but i don't think it can switch based on the content
<poolie> written out by the delta
<lifeless> poolie: I have no idea, haven't read the specs, just going on memorys of jams comments
<poolie> i guess it would be turing complete if you ran xdelta repeatedly on its own output
<poolie> but that would be weird
<jelmer> lifeless, I don't think that's used
<lifeless> jelmer: thanks
<jelmer> lifeless, but speed is an issue with the current in-python implementation
<jelmer> I'm looking at ways to improve it at the moment
<lifeless> jelmer: I'm putting together a compressbench tool
<lifeless> jelmer: it needs a VersionedFile interfface
<jelmer> it's ok for small repositories (loudmouth, ~500 revs, takes a few minutes)
<lifeless> or rather a subset of it
<jelmer> but for e.g. Samba just figuring out what objects to fetch takes a loooong time
<lifeless> is it byte orientated?
<jelmer> lifeless, is what?
<lifeless> and do you string join?
<lifeless> the deltas
<jelmer> lifeless, the git deltas are byte-based, yes
<lifeless> do they work in bits bytes lines
<jelmer> bytes
<lifeless> do you string join in your decompressor?
<jelmer> string concatenate, yes
<lifeless> do you know the length of the output when you start decompression?
<jelmer> lifeless, sorry, the delta-applyer does string concatenate
<jelmer> the decompressor is a simple zlib decompresser
<jelmer> and the output length is not known beforehand
<lifeless> jelmer: well, I meant the delta applier
<lifeless> which is a form of decompression :P
<jelmer> lifeless, sure, but it makes the terminology a bit confusing
<lifeless> well
<jelmer> as all objects (whether they're deltas or plaintexts) are stored zlib-compressed
<jelmer> in the packs
<lifeless> k, well ignore the zlib step for this discussion
<poolie> the length is still not known
<poolie> it's an instruction stream
<lifeless> poolie: it may be wrapped
<poolie> i guess you *could* run over it once as a dummy to work out the eventual length
<poolie> if you mean you could have a statement of the eventual length
<lifeless> poolie: and as jelmer has been coding this I'm asking him rather than digging up the pack spec to check
<poolie> sure
<lifeless> jelmer: so, do you know the output length of the object?
<jelmer> lifeless, so fwiw, the delta unpack algorithm does not use the delta length
<jelmer> lifeless, in dulwich' case we do know the delta length since we always do a complete decompress before applying a delta
<lifeless> jelmer: Its not the delta length; what I was getting at was that if you know the objec tlength you could mmap a region of the right size and decompress into place
<damijit> Hello, I am wondering if it is save to move the top level directory for a bzr project (i.e., the  one that contains the .bzr directory). Will this cause any problems?
<damijit> *safe
<jelmer> lifeless, ah, sorry
<jelmer> lifeless, the result size *is* known beforehand
<jelmer> it's one of the two variable-size headers of the delta
<RAOF> damijit: Yes, it's safe.
<RAOF> damijit: As long as the contents of that directory stay the same, bzr is (almost) entirely oblivious to where it is.
<damijit> RAOF: Thanks, that's good to  know
<jelmer> lifeless, we don't use the result size, just for verification purposes
#bzr 2009-01-15
<ToyKeeper> I wonder why bzr allows arbitrary :aliases for branch URLs but restricts it to a hardcoded set.
<ToyKeeper> The bookmarks plugin could be obsoleted by removing that restriction.
<fullermd> It doesn't allow arbitrary :aliases.
<lifeless> jelmer: we get significant performance boosts not string joining unnecessarily
<jelmer> lifeless: What about modifications of individual characters or slices in strings? Does that cause new objects to be created?
<lifeless> yes
<ToyKeeper> Ah, I see where it maps those.
<lifeless> jelmer: "foo" -> "fbo" requires a new string to be created [with some minor exceptions only usable inside the C api]
<jelmer> lifeless, that's what I figured - so mmap is the only way around it?
<lifeless> jelmer: without writing C
<jelmer> hmm
<pygi> poolie, obviously in a few days
<lifeless> I'm looking atht his with knits and gc at the moment too, you see
<pygi> poolie, more text, that is :)
<poolie> nice
<jelmer> lifeless, So I'm first going to see how far I can get without writing C extensions for dulwich
<jelmer> it would be really nice to keep it completely Python
<jelmer> some of the things I'm looking at are caching the raw texts using a LRUCache
<pygi> poolie, so can we write the book at that bzr hackfest? :)
<pygi> and when is that going to take place?
<mwhudson> you can fake a mutable string with array.array('c')
<mwhudson> _do not_ write c to modify pystringobjects
<lifeless> mwhudson: at what cost
<mwhudson> (not that you were i hope)
<lifeless> mwhudson: of course not
<mwhudson> lifeless: depends what you're doing, array objects support the buffer protocol so e.g. writing them to files shouldn't be significantly slower than strings
<lifeless> mwhudson: probably slice assignment
<mwhudson> i think in the easy cases that's just an memcpy
 * markh pipes up that the 'b' format string will turn out to be more py3k-friendly
<mwhudson> ah yes, probably
<mwhudson> i'm a python2 programmer, the difference between b and c confuses me :)
<markh> me too - but when porting code using 'c' and strings to py3k, it is almost *always* a simple matter of encoding it to bytes and using 'b' - while the py2k version can (optionally) avoid the 'encode' step for str() objects...
<markh> but still use 'b' as before
<markh> err - still use 'b' and work as it did before with 'c'
<lifeless> wow
<lifeless> 'b' is signed char
<lifeless> not 'byte' :P
<fullermd> That's one of those little tricks to make sure people read the docs  :p
<leefmc> would this be the place to ask  question about making a bzr mod?
<lifeless> leefmc: sure
<leefmc> lifeless: Thanks.
<leefmc> lifeless: Ok, well a while back i was questioning using bzr for project management, then i went down a few other roads, and finally i've come to the point where i need to make my own project management system.
<leefmc> Basically just synchronizing folders (with a few other things).
<leefmc> Now in the end, i can do this, but bzr is so capable of doing this. So i was pondering if it would be easier to make a mod for bzr so that bzr could have a repository inside a branch, or if my own solution would be needed
<leefmc> lifeless: Any thoughts?
<lifeless> I don't know quite what you mean by a repository inside a branch
<leefmc> lifeless: Making a repository, sit inside the directory of a bzr branch.
<leefmc> lifeless: ie: repo/branchA/repoB/branchB
<lifeless> uhm
<lifeless> do you want multiple branches there?
<leefmc> lifeless: where
<lifeless> branchA/repoB/branchB{1,2,3,4} ?
<leefmc> lifeless: repoA or repoB
<leefmc> well, yes, to both.
<lifeless> ok, so this is very different to nested trees
<lifeless> I think
<leefmc> Well, assuming i understand you.. not really. i dont see how /repoA/branchA/repoB/branchB[1,2,3] is any diff than /repoA/branchA/repoB/branchB
<lifeless> nested trees don't do repoA/branchA/repoB/branchB
<lifeless> they do branchA/branchB
<lifeless> in bzr repositories are *not semantic*
<lifeless> they are only storage optimisation
<leefmc> oh i see what you mean, yes, this is very different. I want a repository inside a branch. :)
<lifeless> well, you seem to want branches in a brnach
<lifeless> but you keep putting a repository there for some reason I don't quite understand
<leefmc> no, /repoA/branchA/repoB/branchB, i want repositories inside a branch, heh
<lifeless> because if you just wanted a repository in a branch, you wouldn't include the branchB
<leefmc> lifeless: Well if i have a repository inside a branch, what good is it without having branches itself? Perhaps im missing a part of bzr, but isn't there... "nothing" without a branch?
<leefmc> an empty repo does me no good.. heh, i want to use repoB
<lifeless> leefmc: right, there isn't anything without a branch, which is why I don't understand why you are asking for a repo in a branch
<leefmc> hence branchB
<lifeless> rather than a branch in a branch
<lifeless> leefmc: *why* do you want repoB to exist
<leefmc> lifeless: heh, i was hoping i didnt have to go this far :p, but ok.
<leefmc> This is about project management.
<lifeless> seriously, why not branchA/branchB{1,2,3}
<leefmc> im typing
<leefmc> My need is to have projects be uploaded to a central server, so i can download them from any computer, work on them, then upload, etc.
<leefmc> Not really revisioning
<leefmc> Now each project can often have programming projects, some are design, etc.
<leefmc> Really a project is very generic in my eyes.
<leefmc> So now with that said, i was hoping to avoid some trouble and use bzr + mod to make this happen. Otherwise im writing a small app for python to scan directories and synchronize everything, etc.
<leefmc> Now as far as a branch of a branch.. well i dont really want one project polluting another.. I mean, i've never delt with sub branches, but i cant name a branch "pytest" then, because another project might have that heh
<leefmc> half of my projects have the generic "trunk" for a branch.
<leefmc> I'd end up naming every branch as "project_name-subproject_type-somename" heh
<leefmc> In the end, im guessing i'll end up writing a python script :o, you didnt seem to jump up and say "oh its super easy!" so im guessing its easier to go with a custom app of my own. :o
<leefmc> lifeless: So thanks for the discussion :) (I swear i've had this with you before though haha)
<lifeless> igc: I've read the log thread; totally at a loss so far - skype if you're awake would be good
<leefmc> I've actually discussed this very same core problem.. 3 times in this channel? Cept now instead of trying to find an easy side-step to the problem, i just need to get it done right heh.
<lifeless> leefmc: well, I'm trying to understand
<lifeless> leefmc: and I don't - if they are things you can just version, just doig 'bzr init' in each 'project' and then using multi-push and multi-pull should be enough
<lifeless> stop mucking around with 'repositories' - None of your explanations mentioned repositories, so clearly you don't need them
<fullermd> Well, it IS super easy.  You just put it there.  But it doesn't DO much of anything.
<leefmc> lifeless: I thought you needed a repository to have branches/
<fullermd> I mean, you can put a unix domain socket inside a branch too.  Doesn't mean bzr does anything with it.
<lifeless> leefmc: NO, repositories are *not semantic* they are totally unecessary
<leefmc> lifeless: Hmm, so wtf are they for?
<lifeless> leefmc: they are what bzr stores its history data in
<leefmc> lifeless: So.. what history is not needed?
<lifeless> leefmc: if you have many branches of the same code, using a repository to let them share their storage is more efficient
<lifeless> leefmc: if you haven't manually created a repo, bzr creates one when it needs it
<AfC> leefmc: they are where your history lives. They can [as an entirely optional optimization that can be useful in some cases] sometimes be shared between branches.
<lifeless> leefmc: but unless you have multiple branches of the same thing you never need to think about repositories
<lifeless> leefmc: and you don't have that, from what you are saying
<leefmc> lifeless: Well.. i do, what if i duplicate a branch of code?
<lifeless> leefmc: then you have two branches
<AfC> leefmc: At heart, every Working Tree has a Branch and a Repository. In more advanced layouts they are not in the same place, but in simple cases [ie, starting out] they are co-located.
<leefmc> lifeless: In otherwords, what do you mean by "multiple branches of the same thing"?
<AfC> leefmc: you can have as many copies of a branch around as you care to have
<lifeless> leefmc: multiple branches of the same thing on the same machine
<AfC> bzr branch A B
<leefmc> lifeless: Ie, i dont want to run into a problem of bzr "deciding it needs a repository"
<lifeless> leefmc: there aren't any
<lifeless> leefmc: I think your problem is that you are thinking about repositories; stop doing that
<lifeless> leefmc: and it will all become much simpler
<leefmc> lifeless: Well im only thinking about them because they are the problem, and you just mentioned that bzr will decide if it needs one or not.
<lifeless> leefmc: humour me
<lifeless> leefmc: delete the concept from your head for a while
<AfC> lifeless: (with hindsight I wonder if you guys wouldn't have be better off calling it "Storage" or "Revision Stash" or something; "repository" seems to carry too much baggage for people from the old world, even if it is an accurate term)
<leefmc> lifeless: Heh, alright, im just afraid of ended up sh*t creek heh
<lifeless> leefmc: you won't
<lifeless> leefmc: because Branches are *the key concept*
<AfC> leefmc: Bazaar never leads you up shit creek. That's what makes it different.
<fullermd> AfC: "basket" was championed.
<AfC> fullermd: anything. Doesn't matter. Just not "repository" (again, with hindsight)
<leefmc> lifeless: So can i have this directory structure? "/brA/brA.A /brA/brA.B /brB/brA.A /brB/brA.B" with no problems?
<lifeless> yes
<leefmc> alright, sounds good, i'll give it a shot :)
<AfC> fullermd: too late now.
<AfC> fullermd: and nothing wrong with telling people they need to learn the current (ie, this project) actual definition of a term.
<leefmc> Yea in the quickstart, iirc, repos are added, and i always assumed they were done so for a good reason heh.. i never even would have fathomed that repositories are useless.. heh
<leefmc> So there is no case where i could find myself missing a repo?
<AfC> leefmc: they're not useless. They're just something that is internal, and you don't need to think about it right now.
<leefmc> AfC: Heh, not thinking about something "right now" scares me, when it is the core structure of hundreds of projects i am converting.
<leefmc> AfC: Thats like not bothering to figure out what an extra piece is. heh
<AfC> leefmc: changing layout later will not harm you. Branches are the first class entities and are peers. The rest is all supporting infrastructure that comes and goes. All you need to worry about, really, is where your branches are, and where your Working Trees are. For most common uses, the two are the same.
<leefmc> Not arguing with you guys ofcourse, i obviously know nothing, im just trying to understand where this plays in. I keep getting hints that repos have a use, but then im told to ignore it, and etcetc
<lifeless> leefmc: I've told you the use, and so has AfC
<AfC> lifeless: concurr
<fullermd> More to the point, if you DO decide to bring repos into the mix later, it's *VERY* unlikely that you'd cram them in the middle like that.
<fullermd> So they wouldn't affect that layer of thinking anyway.
<lifeless> leefmc: to reiterate: they are used internally for the historical data storage, and can be explicitly configured by users to cause multiple branches with the same history to use the same store
<AfC> ... but if you don't explicitly do that, no big deal.
<leefmc> heh
<AfC> so get on with it already
<leefmc> AfC: for me it will be "project_branches&trees/projectcodebranchA,projectcodebranchB,projectworkingtree"
<leefmc> roughly
<AfC> {shrug} sounds hugely overcomplicated to me, but whatever.
<leefmc> AfC: It is, using bzr.
<sii> that reminds me of tlas name-schemes.. :)
 * sii goes back to lurking
<leefmc> sii: Heh, its not a naming scheme, but i had to explain what each folder was
<AfC> leefmc: look, here's what we do [and this is what is described at  http://java-gnome.sourceforge.net/4.0/get/#source ]
<AfC> leefmc: ~/src/java-gnome is where I collect my branches.
<AfC> leefmc: *as it happens* I have done `bzr init-repo` there so that all the branches underneath it share storage
<AfC> leefmc: but I could have easily skipped this
<leefmc> sii: Really its just a project, and that project can have code in it that needs to be versioned. The project itself is strictly for me, so thats never uploaded to servers, but the code within the project, is uploaded to launchpad/etc
<lifeless> leefmc: thats all fine
<leefmc> sii: eg: /projects/some_website/code/trunk && /experimental && /working_tree
<lifeless> leefmc: that will work fine
<lifeless> if the projects are very big you may want to init-repo projects
<lifeless> but if they are small as most website projects are its totally unneeded
<leefmc> lifeless: So if i type "bzr push" inside of /trunk it will upload to launchpad, but if i "bzr push" inside of "some_website" it will upload it to my local server. Will that local server push include /code/trunk && /working_tree ?
<leefmc> i assume yes.. but i just figured i'd ask heh
<lifeless> leefmc: no it won't, because trunk and working_tree are different branches
<lifeless> leefmc: multipush will I think
<leefmc> argh :o
<leefmc> The point being, that i dont wanna push unfinished/committed code of /trunk to launchpad, so i just push my project to my local server. I dont want to have to push/pull 5 different branches everytime i change computers heh.
<leefmc> I really do thank you all for the help heh
<AfC> leefmc: then things like ~/src/java-gnome/one and ~/src/java-gnome/two and ~/src/java-gnome/something-else are the branches. That's it
<leefmc> My apologies for the trouble. Im just as frustrated, trust me heh.
<leefmc> AfC: Yea i understand that, but in my case, i'd also be pushing java-gnome. Not to mention i dont wanna push /one to launchpad, nor any other branches if they're unfinished, so i end up pushing them to my local server aswell, which also means im giving bzr a new place to push instead of the saved location, so i have to type that in, etc.
<lifeless> leefmc: grab the multipush plugin and test it out
<lifeless> leefmc: I feel like I say this every third sentence or so
<leefmc> On my quickly crap made app for this, i just type one command and it syncs it all, etc. It has problems though, which is why im going all out with the next version of it, but given that i'll be scanning entire file structures and syncing, bzr is so fast for this, i was hoping i could mod it to do that. In the end i think the biggest problem here is my desire to use bzr to do something its not intended for. Its not a workflow that bzr is fi
<leefmc> t to use, and its not sposed to be heh
<AfC> leefmc: will, it sounds like your options are a) to use Bazaar the way it's supposed to be used, or b) to write your own version control system.
<leefmc> AfC: Well thats the great thing, my projects are not in need of versioning, bzr was simply a bonus.. if it could work heh
<AfC> Whereas, c) constantly saying what you want to do instead of keeping it simple and using the tool for what it is designed for is not an option.
<leefmc> AfC: Well what i want is what i want heh, if i cant use bzr, so be it heh.. But in reality, that _is_ what i was here asking about.. if bzr would work for it..
<AfC> I hope you'll chose (a). At that point, I imagine people around here will be able to help you.
<leefmc> AfC: Well keep in mind im not abandoning bzr for code versioning..
<leefmc> AfC: Im just abandoning it for project management.
<leefmc> My apologies for asking such a loaded question heh, but you guys did help me find an answer, and i thank you.
<leefmc> Anyway, i gatta go, i'll be back later, thanks again :)
<ToyKeeper> D'oh.  After pulling the latest, 'bzr.dev info' fails with an error about bzrlib being too new.
<ToyKeeper> st, log, pull, and other commands are fine though.
<lifeless> ToyKeeper: could be a plugin
<ToyKeeper> Yeah, it works without plugins.
<ToyKeeper> Okay, it was bzr-svn interfering.
<ToyKeeper> Yay, after getting that fixed, it was really easy to make arbitrary :aliases work.
<lifeless> I'm not sure why you need that, can't the bookmark plugin just define things freeform?
<ToyKeeper> Why bother with a bookmark plugin when 4 lines in bzrlib can do the same thing?
<lifeless> well
<lifeless> maybe its better?
<ToyKeeper> Really, this does everything I've ever wanted for bookmarks:  http://rafb.net/p/3OKRhr80.html
<ToyKeeper> echo 'foo_location = file:///tmp/foo/' >> .bzr/branch/branch.conf ; bzr push :foo
<lifeless> hmmm
<lifeless> well, I'll let others comment
<ToyKeeper> I'd imagine it would need a bit more before being acceptable...  tests, code to include them in 'bzr info', and a command to set aliases.
<lifeless> personally, I'd really rather not have a :foo for user defined locations
<lifeless> just 'foo'
<ToyKeeper> That would be even better.
<lifeless> and I don't like NAME_location as a config key
<ToyKeeper> I don't either.  In both cases, I just followed existing convention.
<lifeless> it makes iteration hard, and can clearly collide with completely unrelated plugins that choose to have something called a THING_location
<lifeless> well no
<lifeless> you followed specific case code in bzrlib that doesn't do pattern matching
<lifeless> and that *has* to avoid colliding with user URL's and paths because its being globally defined by the tool
<lifeless> neither of which are relevant to your use case: arbitrary names aliases that the user can define
<ToyKeeper> parent_location and push_location are already used, at least.  I'm not sure if the others follow the same pattern.
<lifeless> the are chosen names
<lifeless> if a plugin creates e.g. search_parent_location = True
<lifeless> then doing 'bzr push search_parent' won't try to push to a directory called 'True'
<ToyKeeper> Yeah, I don't like the _location suffix either.  :)
<lifeless> so don't use it!
<lifeless> :)
<fullermd> Also, they're not aliases that we store locations for.  They're locations already stored for other reasons, that aliases were added for as a convenience.
<fullermd> That calls for slightly different implementation than "adding aliases"  :)
<ToyKeeper> If user URLs and special URLs used the same namespace, it might simplify things.
<ToyKeeper> Anyway, just wanted to check how the general concept went over.
<fullermd> I'm dearly in favor of the general concept of "in-base user aliases".
<rousskov> Hello. In a merge bundle, is revision's branch nick encoded anywhere but the <properties><property name="branch-nick"> field?
<lifeless> each revision has its own nick, which is in the properties
<lifeless> the bundle also records the branch that the bundle is claiming to be from, but I don't think it grabs the nick of that branch
<rousskov> Yes. But is it encoded anywhere but the XML element?
<lifeless> no
<rousskov> I am changing the XML element, but the commit message after applying the bundle shows the old nick.
<rousskov> "bzr bundle-info" shows the new nick
<lifeless> uhm
<lifeless> if you change the metadata in a revision it won't propogate, bzr assumes that such data is immutable
<lifeless> revisions are write-once; if you want to change something you need to create a new revision with whatever changes you want made to it
<lifeless> the rebase plugin can help with this
<lifeless> but its not a common operation, so not very polished
<fullermd> I would presume that were it successfully changed, merge would refuse to pull the revs out of the bundle...
<rousskov> I want to understand what happens first. I have two theories: (a) the nick is encoded in the bundle somewhere else or (b) the old nick gets resurrected from the repository based on revision ID or something like that.
<lifeless> fullermd: well, properties are advisory metadata not core, so they are not checksummed like tree contents are
<lifeless> rousskov: its part of a revision object in the repository; if you're working with the bundle in a repo that has seen the erevision before the revision is not decoded out of the bundle - it is skipped over
<rousskov> lifeless, this sounds like (b).
<lifeless> rousskov: indeed
<rousskov> So I should create a brand-new repository, right? So that it has never seen the old commit messages on a private branch?
<lifeless> rousskov: no, you should create new revision objects rather than trying to edit existing ones
<rousskov> But I have too many of them.
<lifeless> rousskov: help me out here :)
<lifeless> are you talking 10^5 or 10^6 revisions
<rousskov> I mean I have, say, 100 commits to a private branch. I want to share those commits with the world, but I do not want to share the branch nick
<lifeless> is the nick the only metadata that you need to change?
<rousskov> Yes, the only thing I do not want to share.
<lifeless> ok, two things we need to discuss; first how to make sure you don't have this situation again; do you know of the 'bzr nick' command?
<rousskov> I could, of course, just apply a dumb patch. I would prefer to preserve the history though.
<rousskov> lifeless, yes, now I do. But I did not at the time.
<lifeless> rousskov: ok cool
<lifeless> now for data cleansing
<lifeless> this is offhand, but I think the recipe is roughly:
<lifeless> bzr branch source_branch clean_branch -r before:first_problem_revision
<lifeless> cd clean_branch
<lifeless> bzr nick newnick
<lifeless> bzr rebase ../source_branch
<lifeless> and it should take a few minuts
<lifeless> *minutes*
<rousskov> What is source_branch? The private branch I want to clean?
<lifeless> yes
<rousskov> Hm.. Would not before:first_problem_revision simply ignore all the changes on that branch?
<lifeless> thats the idea
<lifeless> you want a branch that starts exactly where your current branch started
<lifeless> then you rebase everything from it to the new branch
<lifeless> as I recall rebase discards the nick as it goes
<lifeless> but let me check
<rousskov> So, if you are right, "rebase" will bring back all the changes, but not the nick?
<lifeless> oh damn, it will preserve the nick
<lifeless> gimme a few minutes, I'll whip up a branch of rebase that won't
<rousskov> FWIW, there were no revisions on the source_branch before the problem_revision.
<lifeless> rousskov: oh, I was assuming it was squid
<rousskov> It was branched off a public branch (and all the changes should now go back to that branch).
<rousskov> You may assume squid, yes.
<lifeless> so the history of the branch is much deeper than the changes you've made - bzr doesn't record an explicit marker when you run 'bzr branch' - which is why there are revisions before problem_revision on the branch
<rousskov> OK. Understood.
<lifeless> this will take a few minutes, my machine is in the middle of a very memory heavy analysis, a little thrashing involved :P
<rousskov> Thank you for taking the time to help me.
<lifeless> no probs
<lifeless> nearly there
 * rousskov stands by.
<lifeless> rousskov: I have it working but with a small caveat that is part of the current rebase UI
<lifeless> rousskov: I'm going to describe this, and if its ok with you we'll just go ahead, if its not I'll fix that now as well, or at least work around it
<rousskov> Sure, go ahead
<lifeless> rousskov: so the caveat is that to rewrite the revisions, rebase wants something *new* in the 'parent' branch its rebasing from.
<lifeless> think of rebase as moving all your work out of the way, doing a pull, then one by one replaying them back into your branch
<lifeless> if there isn't anything to pull it assumes it has no changes to make
<lifeless> (which in this case is false)
<rousskov> It is easy for me to commit to the dirty (or clean) branch. Is that what is required?
<lifeless> yes
<lifeless> just a 'bzr commit -m "Prepare xxx branch" --unchanged'
<lifeless> will do it
<lifeless> (don't do it now)
<rousskov> ^C
<lifeless> the effect is a single revision in the log that is rather meaningless
<rousskov> OK. At what point in your original process do I do an empty commit?
<lifeless> I'll check in a smoke test for this, push the branch and point you at the rebase plugin, and then give you a step by step
<rousskov> That is what I call service!
<lifeless> actually, we may not need that little workaround, found a command I thought existed but couldn't find for a bit :P
<lifeless> let me finish these tests
<lifeless> rousskov: ok
<lifeless> mkdir -p ~/.bazaar/plugins
<lifeless> bzr branch lp:~lifeless/bzr-rebase/dev ~/.bazaar/plugins/rebase
<rousskov> Branched 115 revision(s).
<lifeless> identify the first revision before the revisions you created in the badly nicked branch
<lifeless> e.g. bzr log
<lifeless> once you've found that number:
<lifeless> bzr branch -r THATNUMBER badly-nicked-branch fresh-branch
<lifeless> cd fresh-branch
<lifeless> bzr nick NICKYOUWANT
<lifeless> bzr replay -r -1 ../badly-nicked-branch
<lifeless> I have some other things I need to do
<lifeless> I"ll check back in in 10-15 minutes
<rousskov> Strange: Text conflict in src/cf.data.pre
<rousskov> lifeless, I resolved the conflict but running "bzr rebase-continue" yields "bzr: ERROR: No rebase to continue"
<rousskov> Hm. You told me to replay, not rebase, so perhaps that is OK.
<rousskov> I see many differences between $badly and $fresh so I am guessing replay stopped at some unknown point due to a conflict.
<rousskov> bzr log in $fresh shows revisions up to and including $THATNUMBER
<lifeless> rousskov: are you sure you got the right start rev?
<lifeless> there shouldn't be any conflicts
<rousskov> It was the smallest revision with bad nick minus 1
<rousskov> THATNUMBER=the smallest revision with bad nick minus 1, based on bzr log in $badly
<lifeless> ok
<lifeless> lets do rebase then, it could be something odd about replay
<lifeless> delete fresh-branch
<lifeless> bzr branch -r THATNUMBER badly-nicked-branch fake-upstream
<lifeless> bzr branch badly-nicked-branch fresh-branch
<lifeless> cd fake-upstream
<lifeless> bzr commit -m "Prepare DESCRIPTION branch" --unchanged
<lifeless> cd ../fresh-branch
<lifeless> bzr rebase --new-nick ../fake-upstream
<rousskov> What is the best way to delete fresh-branch?
<lifeless> rm -rf
<rousskov> Would not it remain in the repository?
<lifeless> yes
<rousskov> OK
<lifeless> rousskov: is that working better?
<rousskov> I am about to run rebase
<rousskov> Hm. Should I specify nick anywhere?
<lifeless> in fresh-branch
<rousskov> So I can leave it as-is if the $fresh directory name is OK, right?
<lifeless> yes
<rousskov> It is committing something
<lifeless> well thats a start
<rousskov> Done
<rousskov> Nick appears to be fixed.
<lifeless> cool
<lifeless> I'm offf for the night then
<lifeless> jelmer: when you get up - merge request in lp for it
<rousskov> lifeless, but the result is not the same branch I started with
<rousskov> I mean, running "diff -ur $badly $fresh" shows many differences in sources.
<lifeless> thats unusual
<lifeless> what do the changes look like
<rousskov> It looks like some of the changes from the trunk were not pulled in
<lifeless> thats weird
<lifeless> uhm
<rousskov> The $badly branch was synced with trunk a few times
<lifeless> jelmer: are you around
<lifeless> rousskov: I'd like to check a factoid or two with rebase' author
<rousskov> OK. Thanks for all the help so far.
<lifeless> I'll chat to jelmer my morning, if you can wait
<rousskov> I probably have to bail very soon :-(
<lifeless> and see if this known/expected
<rousskov> The missing changes have lower r number than THATNUMBER
<lifeless> thats extremely odd
<rousskov> But they were pulled into the branch later
 * rousskov is not explaining well
<vila> hi all
<lifeless> if you could drop me a mail perhaps with a little ascii art or something
<lifeless> I could show it to jelmer (who is european)
<lifeless> in about 14 hours
<vila> hey lifeless ! Nice to cross you here !
<lifeless> vila: hi, I'm just going in fact
<vila> I thought so, nice anyway :)
<rousskov> lifeless, If I do "bzr log" I can see my "merged from parent" message, referring to Amos changes. The original r number for Amos changes is smaller than THATNUMBER but the r number of my commit is higher.
<rousskov> lifeless, I will send email.
<lifeless> thanks
<lifeless> gotta run
<vila> igc: ping ping, still around by chance ?
<poolie> hey vila
<poolie> i'm just off myself though
<vila> hi poolie !
<vila> poolie: still there a few minutes^W seconds ?
<vila> :)
<rocky> jelmer: ping
<rocky> jelmer: just an fyi, the "bzr co" on latest bzr-1.11rc1 and bzr-svn 0.5 branch hangs indefinitely
<rocky> jelmer: scratch that, false alarm
<scode> bzr: ERROR: Unknown record type: '\r'
<scode> A repo suddenly cannot be bramnched, with that error.
<scode> I know it worked a few pushes ago.
<scode> The local repo is fine. All I've ever done with the repo is to push things to it over ssh.
<scode> Anyone recognize it? Google found a bug with a similar problem (though a different character for the unknown record type).
<james_w> scode: can you grab the backtrace out of ~/.bzr.log?
<scode> This is with bzr 1.9 (server) and 1.10 (clien).
<james_w> what was the bug number?
<scode> james_w: checking
<scode> james_w: 304848
<james_w> bug 304848
<ubottu> Launchpad bug 304848 in bzr ""Unrecognised container format" after push" [High,Incomplete] https://launchpad.net/bugs/304848
<scode> james_w: Hold on,w ill find a paste bin for the trace.
<scode> james_w: http://paste.lisp.org/display/73633
<james_w> this is over ssh?
<scode> I may have ctrl-c:ed an operation interactively btw (not sure). But I have always assumed semantics are crash-safe and thus a ctrl-c should always be safe. But it's possible I did.
<james_w> what ssh server?
<scode> james_w: The branch is local.
<scode> james_w: The pushing happened over ssh.
<scode> james_w: Branching fails over both http and locally (no ssh)
<james_w> what os did the pushes come from?
<scode> james_w: FreeBSD 8-CURRENT / Python 2.5 / bzr 1.10. Note that the local repository on my workstation is fine (and can be branched).
<scode> So the problem only happens when branching from the pushed-to repo.
<scode> james_w: And the pused-to repos is in a shared repository btw, without a working copy.
<scode> james_w: Server is FreeBSD 7.0-RELEASE, Python 2.5, bzr 1.9.
<james_w> it looks like something is corrupt
<scode> ("server" = machine with the pushed-to repository on it; also the machine on which I did the local branch test that generated the stack trace)
<james_w> I'm not sure exactly what though
<james_w> the packs or indices it seems
<scode> james_w: Yes. Although I of course cannot make guarantees, I feel it is unlikely to be a host system issues. The hardware/server in generla has good track record; nothing suspicious in dmesg; no crash has heppened in between (and besides i'm running w/o write caching). Various services running on the machine; haven't seen any indicators.
<vadi2> How can I change the "push branch" location? Even though I pushed to another branch now, bzr is still insisting that default should be the old one
<Lo-lan-do> bzr push --remember $newurl
<vadi2> thanks :)
<Lo-lan-do> Is there a simple way of keeping history linear despite commits done with --local?
<Lo-lan-do> Hm, that wasn't explicit.  I'll rephrase.
<jelmer> Lo-lan-do, bzr rebase --pending-merges
<Lo-lan-do> Assuming I'm working on a checkout, and for various reasons I do a few commits.
<LeoNerd> rebase++
<Lo-lan-do> jelmer: â¥
<Ollie|> i currently use bzr for my source repository on my dev server but am looking to now publish from my dev server to my live server. I will need to do some excludes on the live site e.g. a user upload area. Could someone point me in the right direction of the command(s) i would need to do this?
<jderemer> hello: im trying to setup a bzr server and i keep getting the following error: errorGeneric bzr smart protocol error: bad request 'GET / HTTP/1.0\r'
<Lo-lan-do> jelmer: That's more recent than 0.3, though, right?
<jelmer> Lo-lan-do, yeah, 0.5 I think
<jelmer> 0.4
<Lo-lan-do> Okay.  I'll keep the idea for later then.
<Lo-lan-do> (I reverted to the versions in sid for now, since I do quite a few commits these days)
<rousskov> jelmer, you are the rebase guru, right? Did Robert/lifeless had a chance to talk to you about using rebase to remove a badly chosen branch nick? He patched the plugin, but the result was not quite what he expected...
<jelmer> rousskov, yeah, he emailed me about it
<jelmer> rousskov, rebase doesn't process merges by default
<jelmer> you have to specify a separate option for that
<rousskov> Ah
<rousskov> --always-rebase-merges or --pending-merges?
<jelmer> --always-rebase-merges
<rousskov> Thank you. I could not guess which one by reading --help output. Pending where? Already present where?
<rousskov> Never mind, it is just me, I am sure.
 * rousskov will retry with --always-rebase-merges
<rousskov> I hope this will not screw up future bundles when I submit the changes for merging to trunk.
<jelmer> screw up in what regard
<jelmer> ?
<rousskov> Like a bundle would not apply because it contains revisions that should not be there because they are already in the repository under different IDs or something
<rousskov> I do not know the internals of how this works so my questions may make no sense at all.
<rousskov> If you tell me "it will work just fine, the option has no bad side effects", I will be happy :-)
<jelmer> yes, that will happen - that's why rebase is a bad idea in general
<rousskov> Hm. So what is the best option in my case?
<rousskov> Hand-detect missing mergers after running rebase and redo them by hand?
<jelmer> no, just use --always-rebase-merges
<jelmer> *any* rebase will break the revision ids
<rousskov> Ah.
<rousskov> How do broken revision IDs manifest themselves in practice?
<jelmer> you get divergedbranches errors
<rocky> jelmer: i updated the 0.5 branch and the lhs parent error went away but now i got the knit corrupted error (i commented on the launchpad bug regarding it)
<rousskov> jelmer, sigh. It looks like --always-rebase-merges disabled Robert's plugin changes because the new/fresh branch ended up committed changes with the old nick.
<rousskov> And it did not help with the missing commits issue either :-(.
<rousskov> In other words, I got exactly the same result, except all branch commits have the old nick.
<rockstar> jam, ping
<jam> hey rockstar
<rockstar> jam, still on for TWiB today?
<rockstar> jam, also, did you see that I replied to that bzr-stats merge proposal from about 6 months ago?  :)
<jam> rockstar: yeah I saw that, jelmer approved it, did you need me to specifically merge it?
<rockstar> jam, well, not you specifically, but would like it merge please.
<rockstar> Er, merged.  English and its tenses...
<jelmer> I already merged it
<rockstar> jelmer, hooray!
<rocky> jelmer: did you see my comment earlier ? (i got dc'd) regarding the knit corruption error ?
<jelmer> rocky, yep
<dereine> hi
<dereine> is it possible to get a diff of every changed version of a file?
<lifeless> dereine: all the changes made to a single file?
<dereine> yes
<lifeless> yes, but not with a single command
<dereine> ah ok is it possible to see th version when something changed?
<lifeless> log FILE will report all the revisions that changed/renamed/merged the file, and bzr diff -r before:rev..rev PATH will givethe diff
<dereine> thx
<beuno> dereine, and bzr annotate FILE will tell you the last revision that changed each line
<lifeless> you may also like 'bzr annotate FILE'
<lifeless> or 'bzr gannotate FILE'
<fullermd> diff -crev would be shorter
<LarstiQ> or `bzr qannotate` (or via qbrowse, which is what I usually do)
<dereine> thx
<dereine> ok i will never ask is it possible
<LarstiQ> dereine: failing that, via bzrlib ;)
<dereine> LarstiQ: bzr is just awesome i have a usbstick with a win/lin version, i can stick in everywhere and get all my projects from my ftp only repo
<LarstiQ> dereine: I'm glad you like it :)
<dereine> i just have to bring other people to use it, i know some people, they don't use any control versioning system
<fullermd> Hey, I know insane people too.
<dereine> i'm just happy to use bzr local for this project
<dereine> i have to say, which file i changed
<dereine> everytime!
<poolie> hello all
<GaryvdM> Hi poolie
<poolie> hello Gary
<pickscrape> How do I get a list of the things on my shelf using the new shelf? (e.g. equivalent of bzr shelf list)
<vila> bzr shelve --list
<vila> pickscrape: I think you need 1.11 though
<pickscrape> Yeah, just discovered that. :(
 * pickscrape digs in .bzr/checkout/shelf/
<vila> what ? -- list :-) or you have only 1.10 :-( ?
<pickscrape> That I only have 1.10
<vila> Why don't you upgrade ?
<pickscrape> I'm sticking with what the PPA gives me. 1.11 is still in RC isn't it?
<pickscrape> Though I might be forced to upgrade... 1.10 offers no facility to unshelve anything other than the most recent does it (stack-style).
<vila> pickscrape: Ok, but I think 1.11final is for today (australian time) though
<pickscrape> oh right
<pickscrape> vila: I'm wrong anyway: it does let you unshelve an arbitrary shelf ID.
<vila> here you go...
<vila> Don't put too much on your shelve anyway :-)
<pickscrape> I just use it when I have to switch branches. Normally it's empty, I'm just in a bit of a tizz at the moment. :)
<pickscrape> I should qualify: when i have to switch branches mid-development.
<xokaido> hello all...
<xokaido> is anyone here?...
<thumper> yes
<xokaido> hello... :)
<fullermd> No.  We left early to get boozed up.
<xokaido> I have a little problem in bzr trying to commit my changes using FTP...
<xokaido> an SFTP too...
<xokaido> the problem is it throws error saying: "FTP temporary error: 451 /PROJECT/.bzr/repository/upload/bx526oqloa4dovzp8ji5.fetch: Append/Restart not permitted, try again. Retrying"
<xokaido> does anyone have idea what to do?..
<fullermd> That falls into the category "FTP is too damn weird, and your FTP server is broken"
<xokaido> fullermd, thx for your reply, but FTP server works just fine...
<fullermd> Well, no it doesn't.  If it did, the APPE would work   :p
<xokaido> it has no problems other then with bzr...
<fullermd> What's the problem over SFTP?
<xokaido> it simply can't see the branch...
<xokaido> it says there is no branch...
<fullermd> Oh.  How nice of it.
<fullermd> You sure it's looking at the right path?
<beuno> xokaido, sometimes you need to specify the full path over sftp
<xokaido> yes, I do...
<fullermd> (specifically, it will work from / if you don't put a ~ in it)
<xokaido> because with bzr log ftp:// it shows correct log...
<beuno> fullermd, I think bzr doesn't expand ~?
<fullermd> bzr+ssh doesn't.  sftp deos.
<fullermd> And does, too.
<beuno> xokaido, did you try both variants?  relative and absolute path?
<fullermd> xokaido: Try sftp://server/~/[path]
<xokaido> beuno, thank you very much, with full path sftp works... :)
<xokaido> but how about ftp?...
<fullermd> FTP is a wonky protocol.  That it ever works is kinda astonishing.
<xokaido> is there a chance to get it to work?...
<beuno> xokaido, FTP, as fullermd says, your server is probably "broken"
<fullermd> The problem here is that your server is refusing to APPE[nd], and to compound the sin is giving a TEMPORARY failure for it.
<beuno> or "not working as well as it could"
<fullermd> If it actually gave a "No, sorry, I don't support APPE", I think bzr would actually work around it.
<fullermd> But since it's a temporary failure, we just keep retrying (like it said to), and it never works ('cuz it's broken)
<fullermd> For some reason, this is apparently a really common failure with FTP servers.  I don't know why.
<xokaido> fullermd, thank you very much... can I fix this somehow?...
<fullermd> Not short of replacing the server software, no.
<fullermd> But if SFTP works, it's probably a lot better all around anyway.
<jelmer> lifeless, awake yet?
<xokaido> yes, in this way I can work with SFTP but in other situation I will need FTP...
 * fullermd will be a happy, happy camper on the day when the last FTP server can be shut off forever...
<xokaido> :)
<fullermd> Well, since SFTP works here, the FTP case would be on a different server.  So maybe it'll have a different daemon running  ;)
<xokaido> fullermd, thank you once again for your attention... we hope other FTP server would work better... :)
<fullermd> It's probably possible bzr could be hacked to handle that case better.
<lifeless> jelmer: yes
<lifeless> jelmer: was just on a call
<xokaido> one more problem... :-(
<lifeless> beuno: sftp://host/~/ is the same as scp host:
<lifeless> sftp://host/ is the same as scp host:/
<xokaido> am trying to use cdiff from bzrtools, but it says: "Plugin "Bzrtools" is not up to date with installed Bazaar version 1.6.1"
<xokaido> but it was the latest... :-(
<lifeless> xokaido: latest from where?
<xokaido> from bazaar website
<xokaido> http://bazaar-vcs.org
<xokaido> from here...
<lifeless> xokaido: the message may be misleading then, because bzrtools definitely had a 1.6 compatible release; bzr itself is up to 1.10 now
<jam> poolie: ping
<jam> Just a quick comment about the new progress bars that you merged
<jam> It seems to be nesting things incorrectly
<xokaido> bzr version shows this: "Bazaar (bzr) 1.6.1"
<jam> I sent something to the list
<lifeless> xokaido: yes, and if you got the latest bzrtools, then you will have bzrtools for 1.10
<jam> But it seemed like something that you would want to look at directly.
<fullermd> Or 1.11.
<xokaido> lifeless, how can I fix this?...
<poolie> jam: pong
<poolie> i'll check it out
<lifeless> xokaido: well, install matching versions
<fullermd> xokaido: It's got a list of old versions; find the 1.6.x one and grab that.
<lifeless> xokaido: I don't know how you installed bzr or bzrtools; but 'however you installed them'.
<xokaido> you mean bzr itself or just tools?.
<lifeless> xokaido: you can either upgrade bzr to a version matching bzrtools, or downgrade bzrtools to a version matching your bzr
<xokaido> how do I upgrade bzr?... is there bzr checkout ?
<jam> thanks
<GaryvdM> xokaido: how did you install bzr?
<xokaido> GaryvdM, from slackware package...
<xokaido> I downloaded it from bzr website...
<xokaido> I have experience neither in svn nor in cvs... :-(
<xokaido> but bzr seems to be the coolest thing...
<jelmer> lifeless, so, stacked branches rely on versionedfiles very much at the moment
<xokaido> I could quickly understand what's going on...
<jelmer> lifeless: and versionedfiles don't match svn very well, so it would be nice to have somewhat more dedicated API's available that don't require serialization of revisions, etc.
<GaryvdM> xokaido: Not sure who did that package. Need to nudge them to update it.
<xokaido> GaryvdM, I'll try to reinstall it using sources...
<lifeless> jelmer: indeed it would
<lifeless> jelmer: did you see my query about rebase
<jelmer> lifeless, I did see it and chatted with him here on IRC a bit
<xokaido> GaryvdM, thank you very much... it works now just fine... :-)
<lifeless> the special thing seems to be that the merges were of branches from the same branch point
<lifeless> I'm wondering if there is an off-by-one error in there somewhere
<jelmer> lifeless: could be, I think there's another open bug about this
<lifeless> where in the code is the 'I should skip a rev' logic
<LarstiQ> hmm
<lifeless> jelmer: also was the patch ok
<jelmer> lifeless: generate_simple_plan()
<LarstiQ> oh that's precious
<xokaido> wow, the coolest plugin is the 'shell' command in bzr.... much thanks to the author... :-)
<lifeless> LarstiQ: whats precious
 * xokaido says: thank you guys all... 
<LarstiQ> lifeless: it seems it is already reported as https://bugs.edge.launchpad.net/bzr/+bug/82555
<ubottu> Launchpad bug 82555 in bzr "Merging to an empty branch doesn't work" [Medium,Confirmed]
<LarstiQ> lifeless: merging into an empty branch. bzr log of all of it shows me one revision, with revno 5 in this case.
<lifeless> score
<lifeless> branch version?
<LarstiQ> lifeless: Branch format 6, if that is what you're asking
<lifeless> yeah
<LarstiQ> I was trying to reproduce a bug where the revnos would go into the negatives
<LarstiQ> but either I forgot how to do that, or it has since been fixed
<LarstiQ> or well, bugs differently
<mwhudson> oh that's interesting
<mwhudson> i've seen borked branches in a state like that
<rousskov> lifeless, thanks for following up. Jelmer told me to use --always-rebase-merges but that had no effect except for disabling your nick hack (I got old nicks after completing the same procedure).
<rousskov> I have a bad feeling about this. Perhaps we tried too hard and now the repository is not in the expected state, toying with us.
<rousskov> lifeless, why do you not recommend editing the <nick> field in a bundle and applying the bundle to a fresh branch in a fresh repository? Is it going to screw things up in the future?
<LarstiQ> I'd assume the nick is included in all the hashes etc
<rousskov> Does not look like it.
<rousskov> The edited bundle applies cleanly.
<LarstiQ> really?
<LarstiQ> does it also apply that nick?
<rousskov> bzr bundle-info works, etc.
<rousskov> No. That's the problem.
<LarstiQ> you edited in the for-human text part, or in the encoded machine readable part?
<rousskov> The theory is that the repository already saw those revisions so it just skips them.
<james_w> the nick is stored in the revision
<LarstiQ> Ah, or that.
<rousskov> I edited the machine readable part.
<LarstiQ> rousskov: so yeah, then you'd effectively be creating more than one content for a given revision, thereby violating an important invariant
<LarstiQ> rousskov: ok
<lifeless> rousskov: several reasons; you want to prevent disclosure of that data; its extremely hard to be sure that you won't disclose it if the revids are the ame
<rousskov> but what if I do not care about the revision with the old nick? I am willing to dump/delete it.
<lifeless> secondly folk ask for this sort of history edit from time to time; I think its important to have a simple slick answer
<LarstiQ> fair enough
<LarstiQ> rousskov: I don't know your situation exactly, but you could use the remove-revisions (or similary named) plugin to punch that revision out.
<lifeless> LarstiQ: the revision contents are fine
<rousskov> I would love a simple slick answer as long as it is not a "no, you should have thought about it earlier"
<lifeless> rousskov: clearly thats not an answer
<rousskov> not yet :-)
<sevenseeker> can I use bzr-svn on an existing svn workingcopy?
<rousskov> LarstiQ, So you recommend a) generating a bundle b) removing old revisions c) applying the edited bundle?
<lifeless> rousskov: so, --always-rebase-merges is needed
<jelmer> sevenseeker, yes
<lifeless> rousskov: I think its a bug that its needed, because bzr has enough info to tell that the merge is needed
<lifeless> jelmer: ^ for discussion
<lifeless> rousskov: what happened when you tried with --always-rebase-merges --new-nick ?
<LarstiQ> rousskov: I hesitate to recommend things, I don't have enough information and wouldn't like to irrevocably destroy your data.
<rousskov> I got old nick and same missing revisions.
 * LarstiQ trusts lifeless to help rousskov out.
<rousskov> LarstiQ, post your lawyer's address just in case anyway.
<LarstiQ> it being almost 01:00, it's waaay past my bedtime anyway.
<LarstiQ> rousskov: :)
<lifeless> jelmer: ping, can we spend some time on this
#bzr 2009-01-16
<lifeless> jelmer: I'm happy to put the effort in but I need clarity
<jelmer> lifeless, not sure I follow
<LarstiQ> rousskov: good luck! I'll check backlog tomorrow to see how it played out for you. And hire a lawyer ;)
<sevenseeker> I am looking at http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#bzr-svn and http://bazaar-vcs.org/BzrForeignBranches/Subversion but am either not seeing it or I have a client or svn problem
<jelmer> lifeless, there can very well be a bug that's causing bzr-rebase to skip some merges unnecessarily
 * LarstiQ goes to bed
<rousskov> FYI. I have to leave in 20 minutes. but I will be back.
<lifeless> jelmer: rousskov tried rebase --always-rebase-merges --new-nick
<lifeless> jelmer: he says it stopped setting the nick, and still skipped the merges
<lifeless> I can't see why it would stop setting the nick
<jelmer> sevenseeker, not seeing what?
<jelmer> lifeless, Well, you're the author of --new-nick :-)
<lifeless> jelmer: thanks :P
<sevenseeker> how to use an existing working copy... the example creates a bzr repo first then checks out
<lifeless> rousskov: can you edit rebase.py (~/.bazaar/plugins/rebase/rebase.py)
<rousskov> Sure
<jelmer> sevenseeker, just run bzr in the working copy
<jelmer> lifeless, I'm happy to help wrt the merge bug though, but I think I'm not more qualified than you to say anything about --new-nick
<lifeless> --- rebase.py   2009-01-15 06:07:29 +0000
<lifeless> +++ rebase.py   2009-01-16 00:02:38 +0000
<lifeless> @@ -177,6 +177,7 @@
<lifeless>          oldparents = parent_map[oldrevid]
<lifeless>          assert isinstance(oldparents, tuple), "not tuple: %r" % oldparents
<lifeless>          if len(oldparents) > 1:
<lifeless> +            import pdb;pdb.set_trace()
<lifeless>              additional_parents = heads_cache.heads(oldparents[1:])
<lifeless> rousskov: then run the process as previously described, with "--new-nick --always-rebase-merges"
<rousskov> OK.
<lifeless> it will drop into a debugger, similar to gdb
<lifeless> at the merge revisions
<lifeless> n will step a line
<lifeless> s
<rousskov> do you want me to create another fake_upstream?
<lifeless> s will step into
<lifeless> rousskov: no, the fake upstream is fine
<lifeless> just a new fresh-branch
<rousskov> OK
<lifeless> bt will get a backtrace
<lifeless> print EXPR will print the expression
<sevenseeker> jelmer: ok, so I want to not only use bzr on the checkout but in essence branch that workingcopy too, can I safely initialize a bzr repo on top of a svn working copy?
<sevenseeker> jelmer: btw, I appreciate your help and clues :)
<lifeless> rousskov: when it stops the first time, I'd like to identify if its one of the revisions that was being skipped
<lifeless> so 'p oldrevid'
<jelmer> sevenseeker, not sure I follow. You can create a bzr branch based on the working copy by running "bzr branch <location-of-working-copy> <location-of-bzr-branch>"
<lifeless> then in your BADBRANCH run bzr log --show-ids, and grep for the revid
<rousskov> Is it bzr branch $badly $fresh
<lifeless> yes
<rousskov> Or bzr branch -r $THATNUMBER $badly $fresh
<lifeless> the former
<rousskov> OK
<lifeless>   bzr branch $badly $fresh
<lifeless> cd $fresh
<lifeless>   bzr rebase --new-nick ../fake-upstream
<lifeless> except with --always-rebase-merges added
<rousskov> OK. I am in the debugger.
<lifeless> p oldrevid
<rousskov> OK. I did the grep in $badly.
<rousskov> Found parent and revision IDs
<rousskov> Found two matches: parent and revision-id
<lifeless> look at the revision with that revision id
<sevenseeker> jelmer: we use svn and I want to use bzr for local changes, but I want to branch our trunk...  I am getting this http://paste.lisp.org/display/73676
<lifeless> (if you didn't get context, you might prefer less and a search in the output)
<sevenseeker> when I run: bzr branch <svn working copy> <new bzr branch>
<lifeless> or bzr log -r rev:$REVISIONID
<jelmer> sevenseeker, that's a bug fixed in the 0.5 unfortunately
<sevenseeker> oic
<rousskov> I have context.
<lifeless> is it one of the merges that were getting skipped?
<jelmer> sevenseeker, it should be possible to work around it by using "bzr branch <repository-url> <bzr-url>"
<sevenseeker> would bzr URL be (since it is non existent on my box) something like file://foo/spam/eggs?
<rousskov> lifeless, no
<rousskov> It is a change on a $badly branch
<jelmer> sevenseeker, no, it can be a local path
<sevenseeker> awesome, thank you I will try that
<lifeless> rousskov: then you're looking at a child of the revision
<lifeless> rousskov: please do  bzr log -r rev:$REVISIONID instead
<rousskov> You are right, sorry.
<rousskov> I looked at parent match, not revision-id
<lifeless> thats ok
<rousskov> The revision-id change was indeed skipped, I think.
<lifeless> ok good
<rousskov> It is a merge from a parent branch.
<lifeless> now we try to figure out why it is being skipped
<lifeless> what does 'p skip_full_merged' show
<rousskov> FYI. I only have a few minutes
<lifeless> ok
<rousskov> False
<lifeless> when you need to go, go. But this is stuf I can't reproduce
<rousskov> I understand.
<lifeless> ok
<lifeless> hit n ENTER
<lifeless> keep doing that until the line it shows is
<rousskov> -> parents = [new_parent]
<lifeless> if parent in additional_parents and parent not in parents:
<rousskov> -> if parent in additional_parents and parent not in parents:
<sevenseeker> jelmer: seems to have worked, I will be working on it tonight and see for sure... thank you very much
<lifeless> 'p parent'
<lifeless> 'pp additional parents'
<lifeless> 'p parents'
<lifeless> pastebin that if you can, it won't disclose the nick we're removing
<lifeless> go around the for parent in parents loop using 'n ENTER'
<lifeless> oh never mind
<lifeless> I see the bug
<lifeless> jelmer: bad code is bad :)
<lifeless> thats rousskov
 * rousskov crosses fingers
<lifeless> jelmer: please look at the loop: summarised as 'for parent in parents: parents.append(parent)'
<lifeless> jelmer: shouldn't that be 'for parent in oldparents: parents.append(parent)'
<rousskov> lifeless, do you want me to make that change and retry? If yes, what do I do with the current debugging session? I do not want to corrupt repository by killing something in the middle of an update...
<rousskov> lifeless, I will try follow your future instructions in about an hour. Thank you.
<jelmer> lifeless: yeah, I think so
<poolie1> thumper: woo
<poolie1> let's go
<thumper> poolie1: OK
<lifeless> rousskov: I will write a test case for this
<lifeless> rousskov: and if it fixes it you should be able to just pull in the changes
<lifeless> jelmer: whats the bug number I'm fixing?
<poolie1> thumper: https://bugs.edge.launchpad.net/bzr/+bugs?field.searchtext=upgrade&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
<poolie1> blaaaaah
<lifeless> jelmer: bug 266897 fixed
<ubottu> Launchpad bug 266897 in bzr-rebase "bzr-rebase loses merges" [High,Triaged] https://launchpad.net/bugs/266897
<jelmer> lifeless, cool
<lifeless> rousskov: when you return, cd to ~/.bazaar/plugins/rebase, bzr revert, bzr pull
<lifeless> rousskov: then repeat the test - make a new fresh branch, cd to that, bzr rebase --new-nick ../fake-upstream
<lifeless> rousskov: you do *not* need --always-rebase-merges
<lifeless> jelmer: https://code.edge.launchpad.net/~lifeless/bzr-rebase/dev
<lifeless> jelmer: I'd really like to be able to rebase when there is nothing new to pull in
<lifeless> jelmer: to allow rebase to support just doing edits like this
<jelmer> lifeless, that should already be possible
<lifeless> jelmer: no, it complains/errors
<lifeless> jelmer: replay gave spurious conflicts
<jelmer> lifeless, if you are already up to date to master, it will just pull
<lifeless> jelmer: no, wrong graph case
<lifeless> jelmer: imagine that master hasn't changed
<lifeless> jelmer: and you object to the concept of rebase-to-do-a-pull because it turns tested code into untested code
<lifeless> :)
<lifeless> jelmer: anyhow, if master hasn't changed, but you want to cause a rebase to be executed, it refuses
<jelmer> lifeless, yes, why would you want to rebase in that case?
<lifeless> you have to do a commit to master - a no-change commit - to force it to rebase
<lifeless> jelmer: I have several use cases. This nick editing is one of them
<jelmer> lifeless,  I don't think rebase should be a generic history patching tool
<lifeless> jelmer: another is to combine two revisions out of the set being rebased
<lifeless> jelmer: a third is to exclude a revision
<lifeless> jelmer: its all part of the overall rebase -i stuff
<jelmer> lifeless, That doesn't make any sense until -i is implemented
<lifeless> chicken and egg
<jelmer> right
<lifeless> so it makes sense now
<lifeless> its just that its not very useful until -i is implemented
<jelmer> sure
<lifeless> anyhow
<lifeless> I'm not asking that it rebase by default when there is nothing new on master
<lifeless> just that there be some way to say 'trust me and JFDI'
<jelmer> lifeless: Happy to merge a patch that implements a --force-rebase or something like that, although I don't see the point in just generating new revision ids
<lifeless> jelmer: sure, neither do I unless some other change is actually occuring
<lifeless> jelmer: I'm at a bit of a loss about how to make a --force-rebase option though
<jelmer> lifeless: I think it shouldn't be a separate option perhaps, but an implicit part of -i (which would need a separate generate_..._plan() function, etc)
<lifeless> je	well it would have been useful for rousskov here
<jelmer> lifeless, ah, you mean for --new-nicks ?
<lifeless> yes
<jelmer> I see rebase mostly as a tool for shaping the graph, not one that changes the actual contents of revisions
<lifeless> which *is* implemented
<jelmer> not sure I follow?
<jelmer> what is implemented?
<lifeless> new-nick is implemented :)
<lifeless> anyhow, I think there is such overlap in shaping the graph and setting content that we shouldn't write two tools
<jelmer> I think the UI from rebase is confusing if people are using it for other things than rebasing on a master branch
<jelmer> If you want to fix up a couple of revisions, you don't need the concept of a master branch at all
<lifeless> well
<lifeless> we need these fixup capabilities
<lifeless> common requests:
<lifeless> edit revision metadata
<lifeless> delete badly added files
<lifeless> split out history when a project is factored out
<jelmer> I agree we need the fixup capabilities, I just don't think rebase should be the answer.
<jelmer> We need a separate tool that can apply specific modification commands to a range of revisions
<lifeless> why?
<jelmer> because rebase is aimed at rebasing revisions of one branch onto a master branch, it's UI has the notion of a current branch and an upstream branch on top of which everything is done.
<lifeless> well bzr has that concept itself
<jelmer> It's confusing that people would need two branches if they are just trying to fix a couple of branch nicks
<lifeless> I don't see it being an issue
<jelmer> Also, if we're going to end up making rebase the place to rewrite the contents of revisions, it will grow horribly complex (in code as well as UI)
<lifeless> anything that rewrites contents will contain all of rebase
<lifeless> except for [perhaps] some of the plan generation
<jelmer> lifeless: Executing the plan would be different
<lifeless> jelmer: not much
<jelmer> lifeless, since rebase can just do a merge, but in other situations (changing the conents of the revision) this is not sufficient
<lifeless> jelmer: I think you are 'borrowing trouble'
<jelmer> lifeless, I don't see there's a significant amount of code that can be shared between rebase and e.g. a tool that removes a directory from a range of revisions
<jelmer> lifeless, borrowing from where?
<lifeless> jelmer: they both need to plan out what will be done to allow recovery; they need to assign new revision ids, they need to preserve merges, they need to setup a working tree for each output revision and do a commit
<lifeless> jelmer: this is *identical*
<lifeless> jelmer: the only difference is that an edit needs to occur to the tree before the commit
<jelmer> lifeless: preserving merges isn't a problem if you're not changing the graph
<jelmer> lifeless, Setting up the working tree is trivial, it's a simple revert.
<lifeless> jelmer: look, if I put up a merge you object to, we can talk about it
<lifeless> right now we're arguing about whether it conceptually fits, and we clearly don't agree about what work the code has to do
<lifeless> I'm not working on arbitrary editing at the moment
<lifeless> so the only thing I care about right now is whether the new-nicks patch is acceptable
<jelmer> lifeless, I think the discussion about the concepts is important. I object to the new-nicks patch because it's changing the revision contents, not the graph shape. I really think that should be a separate command.
<lifeless> jelmer: ok; I'll fork rebase then I guess
<lifeless> jelmer: because I don't want to reinvent all the useful stuff in rebase
<jelmer> lifeless: Uhm, what about just adding a separate command provided by the rebase plugin?
<lifeless> jelmer: I don't understand, it would be a complete copy and paste
<rousskov> lifeless, 1 conflicts encountered. Should I resolve and continue-rebase?
<lifeless> jelmer: rebase already changes the contents of revisions - thats what it does because it pulls in changes at the middle of the graph
<lifeless> rousskov: yes please
<lifeless> rousskov: continue-rebase --new-nicks I think
<lifeless> rousskov: I deliberately avoided recording new-nicks in the plan, because I wanted to be minimal
<rousskov> Sigh. Too late. I ran rebase-continue without --new-nicks
 * rousskov will redo.
<lifeless> rousskov: hmm, I need to add the option
<lifeless> one second
<jelmer> lifeless: it would just take a simple revision range, much like replay and not have any of the other arguments, not pull rather than rebase if master was an ancestor of the current tip, etc
<lifeless> jelmer: well I thought replay would be appropriate
<lifeless> jelmer: but it caused conflicts for rousskov; so I figured there was something wrong there
<rousskov> lifeless, but I see signs of progress: everything got merged and I have a mixture of old and new nicks, as expected.
<rousskov> well, rebase is causing conflicts now as well.
<lifeless> jelmer: I mean, rousskov's use case should just have been 'branch from the start point; replay --new-nick BADBRANCH'
<lifeless> jelmer: but it conflicted, which is weird
<jelmer> lifeless, I think replay would be much more appropriate than rebase
<lifeless> jelmer: I added new-nick to replay as well
<lifeless> jelmer: I don't see why it shouldn't be in rebase, its valid to want to new-nick *and* rebase-on-master at the same time
<lifeless> rousskov: pull again please, rev 117 should give you a continue-rebase supporting --new-nick
<rousskov> OK. Will redo, specifying --new-nick with continue-rebase.
<lifeless> jelmer: I also think there is some conflation in our discussion; I haven't been referring to the plugin throughout, not to the specific command
<lifeless> jelmer: except for about 3 statements
<jelmer> lifeless: Sure, and perhaps you might want to insert a new revision in between some of the revisions you're rebasing. That doesn't mean it has to be part of rebase.
<jelmer> lifeless: Your patch does add --new-nicks to the rebase command, so I think it's relevant.
<jelmer> especially since replay is hidden at the moment
<lifeless> jelmer: it does, because replay is [I assumed erroneously] conflicting; but as rousskov says now that rebase is handling merges correctly t is conflicting as well
<jelmer> lifeless: So it makes most sense to me to have a new command "bzr filter-revisions" or something that can take an awful lot of command-line options and will just apply them to each of the revisions specified.
<lifeless> jelmer: if you want me to remove --new-nick from cmd_rebase, I'll do that, but I think its unhelpful to do so because these transforms are not as separate as I think you think they are
<rousskov> . o O ( success! )
<lifeless> rousskov: excellent
<lifeless> rousskov: sorry I didn't reply to your december mail : I was on leave then
<lifeless> and didn't see it till now
<jelmer> lifeless, not separate in what regard? Separate from graph changes?
<lifeless> yeah
<rousskov> lifeless, jelmer, Thanks for all the help.
<lifeless> I find users tend to want several different changes all at once
<lifeless> rousskov: no problem
<rousskov> lifeless, next time folks complain that bzr does not work well on Windows, I will skip a round. :-)
<lifeless> hah
<rousskov> So I now have about 10 useless branches. Is there a better strategy than "rm -rf" to get rid of them completely?
<lifeless> unless you plan to rsync the entire repo somewhere public, I suggest you just rm -rf and ignore them
<lifeless> they won't propogate unless they are referenced
<rousskov> Does not plan to rsync
<lifeless> and they will be nearly trivial in disk space
<rousskov> OK. I am not going to suggest that there should be a branch removal command :-).
<lifeless> we're going to add one, for remote server access
<lifeless> but it won't delete the content immediately
<lifeless> there is a plugin that can do that I think
<lifeless> resurrecting old content can be very useful
<lifeless> and the planned gc command will be a generic cleanup-my-repo tool
 * rousskov nods. I am just thinking of folks committing really top-secret-stuff by mistake (I was not).
<lifeless> rousskov: yeah. Its because of that that unreferenced content is not propogated
<rousskov> How does repo know what is not referenced if I just rm -rf a checked out branch?
<lifeless> the branch has a pointer in it
<lifeless> the branch tip, and the tags, are refs into the repository
<rousskov> Sure, but I removed the branch. Is there a pointer from repo to the branch?
<lifeless> no
<rousskov> branch foo bar; rm -rf bar.
<lifeless> yup
<rousskov> How will repo know that bar is not referenced?
<lifeless> well, 'bar' had the same refs as 'foo', because you took no actions on the branch after making it
<lifeless> so there isn't anything that is not referenced
<lifeless> branch foo bar; bzr commit -m 'new' bar; rm -rf bar
<rousskov> OK. Let's assume I committed to bar before rm -rf.
<lifeless> that would create a new revision in the repo
<rousskov> How would repo know that this new revision is not referenced?
<lifeless> the repo can tell its not referenced by gathering all the refs, then walking the graph; anything in the repo not found by the walk is unreferenced
<rousskov> I still do not see how repo will distinguish between me running "rm -rf" and "echo rm -rf" in some random directory that it does not know about.
<rousskov> I guess my definition of "referenced" is wrong.
<lifeless> rousskov: perhaps
<lifeless> the branch has the reference
<lifeless> if the branch isn't there, there isn't a reference
<rousskov> But repo does not know that the branch is not there.
<lifeless> yes it does
<lifeless> the branch is contained within the repo if it is using it for history storage
<rousskov> Are you saying I should do rm -rf   *in the repository*?
<lifeless> rousskov: no, just the branches you don't want
<rousskov> But in the repository?
<lifeless> rousskov: wherever the branches are
<lifeless> rousskov: I don't know where that is related to any repositories you may or may not have :)
<rousskov> Repo is in /home/rousskov/programs/bazaar/repos/squid/
<rousskov> Branches are in /home/rousskov/Edit/squid3/
<rousskov> All the commands you told me were executed in the second directory.
<lifeless> with that layout, you probably aren't using the repository for history storage at all :)
<lifeless> which is fine
<rousskov> But each branch command creates something in the repository.
<lifeless> rousskov: does it?
<rousskov> Should I rm -rf that something?
<rousskov> lifeless, it sure does!
<lifeless> rousskov: by something, do you mean a directory under /home/rousskov/programs/bazaar/repos/squid/ ?
<rousskov> One directory per branch
<rousskov> Yes
<lifeless> with the basename of the branch ?
<rousskov> Yes
<lifeless> ok, they are the branches
 * rousskov ducks
<lifeless> you probably also had copies of the branches in Edit
<rousskov> So I should remove both with rm -rf, right?
<lifeless> yes
<lifeless> rm -rf anything with the name of the temp branches you were working with
<rousskov> Is my layout wrong? I thought I followed Squid3 instructions when setting this up.
<lifeless> I think its fine
<lifeless> its a little confusing when you use bzr's purest capabilities, because you're in the emulated cvs mode
<rousskov> Am I using bzr purest capabilities?
<lifeless> somewhat
<rousskov> Like --new-nick?
<lifeless> well new-nick was created for you :)
<lifeless> by purest I mean working in fully distributed mode
<lifeless> if there isn't an explicit repository bzr just creates one inline in the branch object
<lifeless> anyhow
<rousskov> And I am emulating CVS because I keep repo separate?
<lifeless> yes
<rousskov> I see.
<lifeless> it just means that how you see bzr work everyday isn't its default mode
<lifeless> its fully supported and I use it in that way for squid myself
<lifeless> (the way you do)
<rousskov> It also means I confuse bzr gurus when talking about branches that are actually branch copies.
<lifeless> or branch references
<lifeless> note that all the commands worked
<lifeless> the only confusion occured at the end when talking about cleaning things up:)
<lifeless> food time, bbs
<rousskov> Thanks again.
<lifeless> jelmer: I'm not against having a filtering specific command, but I think it really would just make rebase and replay into shims
<lifeless> there are other options already present on rebase that control what content changes happen
<lifeless> (always-rebase-merges is one)
<poolie1> jamesh: is that actually true that smtp through gmail doesn't file it as sent?
<poolie1> hrm
<jamesh> poolie1: I don't think it does.
<jamesh> iirc it is just an SMTP server
<jamesh> it is usually up to the MUA to store sent messages
<poolie1> yes, but this is magic
<poolie1> it does store it
<poolie1> i just tested
<jamesh> hmm.  I'd tried this out in the past, so either I didn't notice it storing copies (as the MUA I used did so) or it has added the magic since then
<poolie1> it might be that if your mua also writes into Sent it de-dupes them
<poolie1> it does seem to do that pretty aggressively
<poolie1> also the sent message is marked as read
<jamesh> right.
<poolie1> so it's easy not to notice it
<jamesh> well, it was a pretty quick hack and does let you defer sending the message
<poolie1> yeah
<poolie1> it's very useful and a clever hack
<poolie1> but... Pedantical :-)
<lifeless> dot com
<pygi> kfogel, poke
<kfogel> pygi: perk
<pygi> kfogel, you have mailz!
<pygi> probably not very useful atm, I'll make sure to write something more detailed tonight if it'll be of any use
<kfogel> pygi: see my response :-)
<pygi> kfogel, afaik it'll be available as e-book, yes
<pygi> kfogel, I could probably send you a TOC if you wish?
<kfogel> pygi: e-book under an open license (one that will permit us to remix, etc)?
<kfogel> That would be *terrific*.
<pygi> kfogel, no :/
<kfogel> pygi: who is publisher?
<pygi> Packt Publishing
<kfogel> pygi: hmmm.  Have you asked them about doing a CC-BY or CC-BY-SA license?
<kfogel> many publishers are willing these days
<kfogel> O'Reilly does it *all the time*, it doesn't seem to hurt sales.
<kfogel> (I think it probably increases sales, at least for some books, in fact.)
<pygi> O'Reilly isn't interested in a bzr book tho :)
<pygi> but that doesn't matter really :)
<kfogel> pygi: no, I just mean as a point to tell Packt.
<pygi> kfogel, nop, we haven't asked them to publish the book under an open licence
<jamesh> pygi: are they not interested in printing one, or not interested in paying an advance for one?
<pygi> jamesh, they're not interested in bzr right now, because DVCS is not that big of a market, and they're already covering git
<kfogel> pygi: what I'm getting at is that, for our purposes, a book will have zero impact on bzr adoption if it's not free online.  Because for someone to buy a book, they've already made the decision -- they're making an investment in bzr.  We need to provide materials to get people to that point, *before* they buy a book.  One great way to do this is to have the book be open.  Then they can poke around investment-free.
<kfogel> pygi: Would you like to ask them?  Personally, I can tell you that making my book open (producingoss.com) was the best decision I ever made about that book.  It has become much more popular than it ever could have been otherwise.  Plus, I got free translations out of it!  Some of which are now being published.
<pygi> kfogel, I can understand that
<pygi> kfogel, I'd need to talk (again) with Szi and Jon about that, but asking isn't a problem
<kfogel> pygi: I don't mean to be a downer, but: don't even think about royalties.  You're not going to make any more than the advance on this book (you probably already know that).  The benefit is really to your reputation.  In which case... having it circulate more freely == more benefit.
<pygi> kfogel, haha, no, I'm not thinking about royalties
<Toksyuryel> they SHOULD make a bzr book :( bzr is so awesome
<jamesh> I suppose O'Reilly has all that web 2.0 money though, so doesn't need to make a profit from selling books any more
<pygi> Toksyuryel, we're on it ;)
<kfogel> pygi: cool, talk w/ Szi and Jon and see what they think.  If they'd like to talk to me about what it did for ProducingOSS, I'd be happy to talk about it.
<kfogel> pygi: but http://producingoss.com/translations.html will give you some idea :-).
<pygi> kfogel, I've sent you a mail that has TOC btw
<pygi> kfogel, hehe :)
<pygi> yea, I have that book, google bought me one :p
<kfogel> pygi: oh, heh!  Prolly has my signature in it, then.
<pygi> aha
<Toksyuryel> you would think that the official RCS of choice for the GNU project would catch the attention of the O'Reilly people
<Toksyuryel> maybe it's too much of a moving target still though
<pygi> Toksyuryel, its just that git is much more widely used
<pygi> and linux kernel ofcourse is git
<jamesh> Toksyuryel: they didn't do a book about Arch either, when it was the official RCS of choice for GNU
<jamesh> I think Bazaar will have to work on its own merits
<Toksyuryel> I thought Arch was a distro
<pygi> and even the Git book isn't too big (I think 200 pages, I'd need to look)
<pygi> Toksyuryel, arch linux is a distro :)
<jamesh> (and it shouldn't have any trouble there)
<Toksyuryel> well, git NEEDS a book to even understand it
<jamesh> Toksyuryel: http://www.gnu.org/software/gnu-arch/
<Toksyuryel> it is written in some kind of goofy alien language
<pygi> kfogel, if we end up actually doing that, I'll include you in conversation with Packt, if it'll be needed
<Toksyuryel> I don't think "the linux kernel uses it" should be a metric really... they used bitkeeper for a while remember. plus I think linus is still anti-gpl3
<kfogel> pygi: great.  Note that I can be much more diplomatic and calm than I was here in IRC tonight (I figured with you I could just be very direct).
<kfogel> :-)
<pygi> Toksyuryel, tons of projects adopting git is a metric tho :)
<pygi> kfogel, haha :D
<Toksyuryel> pygi: that makes me cry :( I really broke down in tears when I saw that perl had switched to git
<fullermd> Diploma...   IRC...    what?
<pygi> fullermd, the cheese
<fullermd> Mmm, cheese.
<Toksyuryel> we need better PR for bzr. gotta get more buzz out there
<Toksyuryel> how to do that though?
<pygi> Toksyuryel, just have patience :)
<fullermd> The early bird catches the worm, but the second mouse gets the cheese.
<Toksyuryel> fullermd: that's a good quote
 * Toksyuryel writes that one down
 * fullermd can't even remember the first time he heard it.
<fullermd> The first step to better PR is to make every large project's first reaction not be "Holy crap, this is slow"
<Toksyuryel> there is a limit to how much speed you can squeeze out of python. and last time I brought up the notion of switching to C there were a lot of groans :P
<pygi> kfogel, ok, if you'll have any questions about TOC; please shout ...  gotta do some work now :(
<kfogel> I have to say, I haven't experienced speed problems so far.
<kfogel> pygi: will do (haven't seen email yet, am working on something else)
<fullermd> True, but there's hg sitting right there laughing at the idea that C is needed to be $LOTS faster than bzr.
<Toksyuryel> bzr's speed comes not from its code execution but from its ease of use
<kfogel> fullermd: I too am skeptical that C vs Python is a major factor here.
<fullermd> A lot of things are slower, but the network is what really kills you.
<Toksyuryel> you spend a lot less time fumbling with it than you do with other rcs
<jamesh> Toksyuryel: a number of the places where bzr feels slow, the CPU isn't pegged
<fullermd> And really, bzr [last I looked, anyway] utterly creams hg and git over dumb servers.  Neither of them seem to go for much more than "OK, works" in that case.
<jamesh> that can indicate that the interpreter speed isn't the issue
<fullermd> But they both have good smart servers.  bzr...   er...   well, it HAS a smart server...
<Toksyuryel> bzr's dumb server is as smart as its smart server :P
<lifeless> kfogel: We typically get a 30-60 percent time reduction when we pryex inner loops
<fullermd> The smart server has historically been a really GOOD dumb server.  Actual smarts are slowly trickling in.
<fullermd> But still.  I wish the VFS layer on it had never been written.
<lifeless> kfogel: I think we could get a further 50 percent redution on the output with real C and not refcounted memory-scattered structs
<kfogel> lifeless: wow.  But the big question is, on what operations is this the case?
<fullermd> One way to look at it is that we're in a way better performance position than hg or git.
<kfogel> fullermd: ?
<fullermd> Because we have both there; we KNOW things can be radically faster.  And we can even tear them apart and see how.
<fullermd> We don't have to look at things and think "Yeah, that sucks...   but I don't know if it can really be made faster"
<lifeless> kfogel: status, sequence matching, local dirstate parsing, knit index parsing [obsoleted], B+Tree index parsing (in 1.9 and newer formats)
<kfogel> fullermd: mrm.  I don't get the feeling that either git or hg developers ever say that to themselves :-).
<fullermd> Well, no.  That's why we're in this position   ;p
<lifeless> python is very fast at adhoc stuff, but C is maaaassively faster when used end to end
<Toksyuryel> converting the codebase would take quite a while though
<Toksyuryel> I get the feeling that bzr is still in something of an experimental phase where they are still trying features and looking for the best way to handle things
<Toksyuryel> like the constantly changing index format
<Toksyuryel> it is easy to quickly impliment that stuff for testing in python
<lifeless> Toksyuryel: there are no plans to convert all of the code base
<Toksyuryel> once the codebase settles down, I think is when a potential conversion to C should pop up on the radar
<lifeless> Toksyuryel: there is significant community attraction to being python
<Toksyuryel> it's a nice buzzword, sure
<lifeless> Toksyuryel: we already have C extensions for inner loops
<lifeless> Toksyuryel: its not a buzzword; I started a thread about this in uhm, september or october
<lifeless> we're experimental in the sense that we continually reevaluate what we have and look for improvements; there are some areas that are more in need of such improvements than others
<Toksyuryel> lifeless: I am not suggesting that the experimental nature is a bad thing; it is one of the things I love about bzr
<lifeless> good!
<lifeless> but there is some confusion out there about what it means
<jamesh> Toksyuryel: so, code in C often runs faster than code in Python, but code in Python is usually easier to change.
<jamesh> if you know you've got the fastest possible algorithm and data structures, then converting to C might be a good idea if speed is a problem.
<jamesh> if you've using the wrong algorithm, fixing that problem can speed things up more than a Python->C conversion would
<jamesh> so starting from Python code is a plus there.
<Toksyuryel> jamesh: that's my point
<jamesh> Toksyuryel: one problem is that it is difficult to tell whether you're code has settled into the best possible algorithms.
<jamesh> someone might come up with something faster, or external matters change requiring changes in the project
<Toksyuryel> jamesh: well I can say with certainty that a new release every month is not "settled" :P
<pygi> kfogel, wake up
<kfogel> pygi: ?
<kfogel> pygi: (just about to go to bed, actually)
<pygi> kfogel, is the only reason you think it doesn't solve the problem its non-openess, or because it doesn't include what you imagined?
<kfogel> pygi: both, but mainly the latter.
<pygi> kfogel, well, we can obviously fix that
<pygi> but I'll let you go to bed I guess, so poke me when you want to talk
<kfogel> pygi: a bzr book is a great thing.  But newcomers don't want a book (they just want to know that one exists!).  What they want, when evaluating bzr, is something that says "Yes, you can accomplish your familiar task XYZ using bzr, and here's how."
<kfogel> pygi: if you tried to make the book solve this problem, that would only ruin the book :-).
<pygi> :P
<kfogel> pygi: ok, good night for real.  See you later!
<pygi> kfogel, ok, ok
<pygi> night
<lifeless> uisn't the cheatsheet that?
<pygi> lifeless, obviously, not in a connected, workflow-like way? You'd have to ask kfogel :p
<lifeless> have a good weekend
<pygi> thanks, the same :)
<lifeless> min 0.00234603881836
<lifeless> max 0.0709958076477
<lifeless> avg 0.00280290386045
<lifeless> times to extract a single inventory text with in-memory index and hot cache
<lifeless> min 0.00236701965332
<lifeless> max 0.0570821762085
<lifeless> avg 0.00280372190905
<lifeless> dev 0.00103978222127
<lifeless> std dev added
<lifeless> poolie1: ^
<vila> hi all
<poolie1> lifeless: hi
<lifeless> $ bzr compressbench
<lifeless> Raw size 3461880213
<lifeless> Compressed size 141152371
<lifeless> durations:
<lifeless> min 0.00240206718445
<lifeless> max 0.0537631511688
<lifeless> avg 0.00287260593959
<lifeless> dev 0.00104769617119
<lifeless> per_k_times:
<lifeless> min 5.22243953561e-05
<lifeless> max 0.00116888823111
<lifeless> avg 6.24545846438e-05
<lifeless> dev 2.27784216077e-05
<Jc2k> lifeless: how is the compression going? rob still swoons everytime he hears "group compress"
<liw> I have branch foo (upstream code) and foo.deb (packaging for .deb); I had to do a bugfix release without doing a new upstream release, so I did bug fixes in foo.deb; what's the best way of merging only the changes that affect upstream to foo?
<liw> would merging the foo.deb branch into foo, but removing debian/* before committing work ok?
<james_w> I believe so
<liw> hmm, if I do that, then merge into foo.deb again, debian/* gets removed, which is undesireable
<james_w> but if you run "bzr revert debian" when merging back it should resurrect, no?
<james_w> that might mean that it will try and add debian to foo again next time you merge
<liw> you know, it's really nice to be able to test these things without committing to a central repository and ruining everyone's day :)
<james_w> ah, if you merge .deb to foo, rm debian, commit, merge back and "bzr revert ." then commit it may do the right thing
<james_w> i.e. do a "null merge" back straight away
<liw> yeah, that seems to work
<liw> thanks!
<Jc2k> LarstiQ: ping
<LarstiQ> Jc2k: pong
<Jc2k> LarstiQ: are you the one to speak to about bzr-hookless-email?
<LarstiQ> Jc2k: I mentioned it on the mailing list, so I guess so :)
<LarstiQ> Jc2k: I've only recently taken over maintenance, but shoot
<Jc2k> LarstiQ: cool, i'm looking at making a more generic version and didnt want to turn up with it out of nowhere
<LarstiQ> Jc2k: what are you thinking of?
<Jc2k> what i want to do is have post-commit and post-change-branch-tip hooks, but outside of the bzr instance that actually commits
<LarstiQ> right, that makes sense
<Jc2k> i have a test script (with tests) that does this, but its seperate to bzr-hookless-email atm
<Jc2k> there are some unanswered issues though - like i dont really want to use Branch.hooks[] because they would end up getting run by the bzr instance that lands the commits and by the script that is scanning
<Jc2k> but at the same time, it would be nice if things like bzr-cia could 'just work' for both modes of operation..
<Jc2k> LarstiQ: and of course, bzr-hookless-email would then be the wrong name: it would be all about the hooks and it wouldnt just be about email :p
<james_w> you could define a new hook point, and each plugin could register in both?
<james_w> or you could extend the API somehow
<Jc2k> james_w: the main problem with the 1st is each plugin would have to be aware of both entry points and have configuration foo to only fire from one of those
<Jc2k> i had thought about new hook points that defaulted to firing from the existing hook points, but which could be fired externally 'after the fact' if you install this plugin
<LarstiQ> Jc2k: I'm willing to work on this
<LarstiQ> Jc2k: would you mind replying on the mailinglist stating your intention?
<Jc2k> okie dokie. i'll push the play branch i have too.
<LarstiQ> cool
<phinze> is there a good doc somewhere for "how to land a feature branch" ?
<phinze> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#sending-changes <-- looking at that
<Jc2k> LarstiQ: mail sent, with a stupid typo :(
<LarstiQ> Jc2k: thanks
<phinze> here we go... http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#merging-a-feature-into-the-trunk
* You're now known as ubuntulog
<delaney> hi, I'm trying bazaar but it seems tortoisebzr does not work correctly on XP64.  Not getting the add/diff/etc menus, works fine from the console.  Is this a known problem?
<jelmer> delaney: I think that's supposed to be fixed in the latest version
<delaney> 1.11?
<delaney> rc
<jelmer> deepjoy, yeah
<delaney> Well if I init from command line I can add etc, but if I init via tortoisebzr it does work
<delaney> get bzr: ERROR: No WorkingTree exists for "
<jelmer> not sure then, sorry
<delaney> heh, actually I'm getting it with a second right click... weird, that has to be a bug.
<delaney> But still no option to add.
<delaney> thanks anyways jelmer
<mib_2nb27u> I wanted to ask: there is a lot of progress on some features like stacked branches, views etc in recent bzr versions. But are there any plans to get bzr's speed closer to git?
<Lo-lan-do> mib_2nb27u: I regularly wonder about that too.  Apparently the standard answer is that bzr is pretty fast already (and it keeps improving), *apart* from startup time.
<Lo-lan-do> And startup time seems to be mostly Python's fault.
<mib_2nb27u> Does it mean that hg is equally slow?
<Lo-lan-do> Various strategies are being tried to mitigate that.
<Lo-lan-do> No idea, I don't know hg :-)
<mib_2nb27u> I thought that hg is almost equal to git
<Lo-lan-do> (I hope I didn't talk too much rubbish)
<mib_max> Are there any  known chunks of code in bzr that could be optimized to get better performance or bzr already hit maximum performance allowed by current on-disk format?
<Lo-lan-do> I don't know myself, but maybe others do.
<fullermd> Plenty probably.
<fullermd> It's just mostly not a matter of "rewrite this function so it's faster", so much as "redesign the numbers, responsibilities, and positionings of abstraction layers".
<kumi> Anyone know if nested tree support will land this year? It's the only SVN feature that makes me jealous
<mib_max> so this speed problems is derived from design of bzr and to make it comparable to git, bzr must be rewritten?
<mib_max> Why then all this new features are being added into flawed codebase?
<Lo-lan-do> I guess it's because there are people adding features and others working on speed.  It's not an either/or case.
<luks> it's now flawed, it's called extensible
<vila> kumi, the year is still young, all dreams are possible :-)
<vila> mib_max: welcome on the channel, we appreciate your enthusiasm
<mib_max> speed improvements aren't that visible (going from 100x times slower to 50x times slower than git is very good, but ...)
<vila> bzr is layered so that some features can be added while other layers are rewritten for better performances
<vila> s/added/& in some layers/
<mib_max> vila, and are there any plans to stop adding new features and make previous usable performance-wise
<Lo-lan-do> Why stop adding features?
<vila> mib_max: no, that's more fun that way
<mib_max> Lo-lan-do, to make old features usable?
<Lo-lan-do> People who add features are not necessarily the ones able to improve performance anyway.  Stopping them from adding useful code would be counterproductive, right?
<vila> seriously, this is a free software project, different people have different aims
<vila> Lo-lan-do: exactly
<vila> Many bzr users are perfectly happy with the actual performance
<mib_max> of course, but I though that bzr is Canonical sponsored project and there are some developers working on it from Canonical, right?
<vila> I personally have problems with performance for one project, but for most of my daily usage, performance is not a concern
<vila> mib_max: and Canonical also ask for features with priorioties higher than performance (AFAIK), so what ?
<Lo-lan-do> vila: It sometimes is, for me.  Emacs has decided to ask bzr whether a file is up-to-date whenever I open it, which means a one-second delay everytime I open a file.  It gets boring after a while.
<vila> Lo-lan-do: is that vc.el related ?
<mib_max> vila, is it so? I thought their goal would be to make bzr use as wide as possible, but most projects switches to either hg or git, because they are much faster
<Lo-lan-do> vila: Possibly.  How can I check?
<vila> mib_max: I don't know the internals of Canonical so I can't speak for them
<mib_max> vila, and another question: doing "bzr branch lp:bzr" is quite slow for me, I believe mostly it is because it is downloading 96Mb repository for 15Mb project
<vila> Lo-lan-do: I'm using emacs myself and I don't have the problem, what's your version ?
<mib_max> that big size of repository is because of a lot of changesets or what?
<vila> mib_max: the initial branch may be slow but you're asking for it so I think I don't understand your problem
<Lo-lan-do> vila: 22.2.1 from sid
<vila> Lo-lan-do: 22.1.1 here, so I will have to use my 8-ball
<Lo-lan-do> mib_max: Try a lightweight checkout if you don't want the full history, or a stacked branch.
<vila> Stacked branch is for pushing, why are your branching bzr mib_max ?
<mib_max> the problem for me that repository size is about 10x of source tree size
<mib_max> Is branching bzr forbidden operation in bzr?
<Jc2k> i think the bzr repository is in an older format?
<vila> mib_max: cool down, I'm asking about your expected needs to give you an appropriate answer :)
<vila> 96 ~= 6 x 15...
<vila> So what ?
<mib_max> actually it is 12, not 15, I will convert it to git and see how it will perform
<mib_max> vila, no problem here, I just thought that bzr is incapable of branching such big changests, e.g. I wasn't able to branch lp:mysql, it tooked too long and made me bored
<luks> this looks like regular trolling to me :)
<mib_max> vila, I believe bzr branch definetly needs to output some more information about how much it is downloading instead of just rotating |
<Jc2k> i think trunk bzr does.
<vila> mib_max: try bzr.dev
<vila> :)
<mib_max> ?
<mib_max> I tried
<mib_max> it shows some corruption
<vila> Wait ! It's not performance related ! It's a feature ! *You* don't want it. Isn't it ?
<mib_max> No revisions to pull.] Pull phase 0/2
<mib_max> It is performance related
<mib_max> it is so slow, that it needs to show that it is still working and not frozen
<vila> You mean your internet connection ?
<mib_max> "No revisions to pull.] Pull phase 0/2 " - output from ./bzr pull on latest bzr.dev
<mib_max> maybe
<vila> Care to check your CPU usage and network usage ?
<mib_max> It would be much better if bzr will tell me that it is downlading at XXX Kbps
<vila> <Jc2k> i think trunk bzr does.
<vila> <vila> mib_max: try bzr.dev
<mib_max> it is not providing it me for pull
<mib_max> Will try for branch
<vila> Oh wait ! No, I have to write that for http :-)
<vila> It works for sftp only so far
<mib_max> it provides something for branch that is major good step here)
<mib_max> but I think better will be not copied "records" but bytes
<mib_max> And of course pull operation needs it too
<mib_max> What lp:bzr uses? http or sftp or bzr?
<Lo-lan-do> I'm sure your patch will be much appreciated.
<vila> mib_max: when did you try bzr branch lp:mysql ?
<mib_max> I tried to found pull.py, just as log.py but it is not there, where is pull output in source tree?
<mib_max> vila, what do you mean "when" if you want I could do it now
<vila> mib_max: please do so
<Jc2k> the new progress stuff is swweeet.
<mib_max> using bzr.dev or bzr 11_rc
<vila> bzr.dev
<mib_max> time ~/bzr/bzr branch lp:mysql-server .................
<mib_max> what lp: is using? sftp, bzr or http?
<vila> all of them
<Lo-lan-do> And IPoAC
<mib_max> btw, bzr.dev does branch much better, now I have some moving numbers on screen :)
<vila> time -p bzr branch lp:mysql-server so-what
<vila> Branched 2710 revision(s).
<vila> real 211.17
<vila> user 38.37
<vila> sys 47.93
<vila> That includes building the working tree on a NFS mounted file system
<mib_max> I am doing it still
<mib_max> what is your internet connection speed?
<vila> 22Mdown/1Mup
<mib_max> 4Mdown/0.7Mup, so I will do it about 5.5 times slower
<mib_max> what is the size of .bzr in mysql?
<vila> du -sk .bzr
<vila> 680332	.bzr
<amanica_> as far as I can see lp: = bzr+ssh://bazaar.launchpad.net/
<mib_max> 680Megabytes?? oO
<vila> But I use a shared repository which contains many more than just lp:mysql-server, so I didn't just download that :-)
<mib_max> Because you already had that revisions?
<mib_max> Ok I will Ctrl-C it
<vila> I had to download an additional pack file of about 7M containing the revisions I didn't have
<mib_max> Ok. Another thing. Could you explain me some statements on http://whygitisbetterthanx.com/#cheap-local-branching
<mib_max> Is it true that bzr can do thit as easy as git and author of site is incorrect?
<vila> mib_max: <vila> time -p bzr branch lp:mysql-server so-what
<vila> <vila> Branched 2710 revision(s).
<vila> <vila> real 211.17
<vila> <vila> user 38.37
<vila> <vila> sys 47.93
<vila> Sounds pretty cheap to branch a ~130M tree to me
<vila> and will certainly be faster if I was using a local FS
<mib_max> It is your old results. You cheated, having most of revisions locally)
<Jc2k> you can also have one working tree and use 'bzr switch' to connect it to different branches
<vila> mib_max: I think luks was right
<mib_max> Download speed meter and reporter in bzr.dev makes it more clear that in that case internet is bottleneck
<mib_max> what lucks said?
<mib_max> luks*
<mib_max> Am I loosing messages?
<vila> Either you're trolling or you don't understand what you're talking about, you asked about cheap branching, not initial branching
<mib_max> I don't thaught that this repository will be 600M in size, bzr didn't told me that and was just rotating
<mib_max> *rotating |
<mib_max> Now in bzr.dev it makes much more sense
<pickscrape> Branching mysql into a clean shared repository just took me:
<pickscrape> real 911.39
<pickscrape> user 231.38
<pickscrape> sys 9.57
<pickscrape> Creating a local branch of the branch I just created took:
<pickscrape> real 35.62
<pickscrape> user 4.19
<pickscrape> sys 2.08
<mib_max> From hd or internet? I realized that in my case internet was bottleneck, sorry for complaints.
<pickscrape> My first branching was from launchpad. I didn't have any revisions previously downloaded.
<mib_max> you have pretty fast internet access to lauchpad :)
<Jc2k> mib_max: if you were using a standard bazaar workflow (shared repository, branches with no trees and one working copy) then you could do 'bzr branch foo bar' and it would be instant. inside the working copy you could do 'bzr switch bar' - any commits there would now be recorded against the bar branch.
<pickscrape> Verizon fios (15MB down)
<Jc2k> mib_max: you could then bzr switch foo and be back on the first branch
<mib_max> Jc2k, is it answer for the question about whygitisbetter? I understand what you said, but statement on that site made me thought that my understanding is somewhere flawed ;) site should be updated.
<vila> mib_max: which is why I did the bzr branch above, not to cheat, but to show that things doesn't have to be slow with bzr just because everybody repeat the meme
<vila> This channel is more about answering questions about bzr than doing advocacy for or against it or any other DVCS (at least that's my impression after a couple of years)
<mib_max> Ok. Ok. I apologise for complaint about slow branching from lp. bzr wasn't showing me that it is my internet connection that sucks. Bzr.dev got this nearly fixed so no problem here for now.
<mib_max> what tool I should use to view docs in bzr.dev/docs/developers ? It contains some includes ...
<vila> make docs; use $your_favorite_browser doc/index,htlm
<vila> make docs; use $your_favorite_browser doc/index.html
<mib_max> emerge docutils did the magic for make docs
<mib_max> thanks)
<mib_max> is performance-roadmap document from that directory outdated?
<mib_max> Are there any ways to read what was written during my connection loss?
<vila> what connection loss ? Ctrl-c ?
<mib_max> adsl provider breaking connection every 24h to do accounting
<vila> Oh my... spiv ! Here is a use case to retry hpss requests !
<vila> mib_max: I don't think so
<mib_max> :)
<vila> mib_max: there is no general answer, were you doing a bzr branch ?
<mib_max> I am about IRC :)
<vila> no disconnection msg appeared here
<mib_max> I am using mibbit.com to connect to IRC
<mib_max> maybe their server was connected all the time
<vila> I see
<mib_max> Are there any updated performance_*.txt from doc/developer as ones in that dir talks about changes planned to do after 0.16, about switching from knit repo etc
<vila> mib_max: unfortunately no, some of the ideas described here have been implemented, some are working on, certainly all of them will be addressed at one point, but the document itself hasn't been updated
<vila> s/working/worked/
<mib_max> is it possible for mere mortal to understand that topic and try to contribute to performance optimization of bzr? Any easy starting points?
<vila> mib_max: you're welcome, my suggestion will be to start running 'bzr selftest' first
<vila> second, go to launchpad and search for bugs tagged 'easy' or 'trivial'
<mib_max> what is tradition? are all tests to pass?
<vila> All commit on bzr.dev pass all tests on our gate keeper (nick pqm)
<vila> All submissions should pass all tests
<mib_max> 14 errors so far
<vila> What os ?
<mib_max> for example
<mib_max> ERROR: blackbox.test_remove.TestRemove.test_remove_one_deleted_file     exceptions must be strings, classes, or instances, not exceptions.OSError
<mib_max> linux gentoo
<vila> here you go :-)
<vila> patch welcome !
<mib_max> so you say that on your gatekeeper all tests passes?
<vila> python version ?
<mib_max> 2.5.2
<vila> wow
<mib_max> ?
<mib_max> 2208/15811 in 3m28s, 26 err, 4 missing
<vila> That's very very surprising
<Jc2k> im seeing quite a few "run() got an unexpected keyword argument 'verbose'
<vila> If you do 'bzr log --short' in your bzr working tree you will see all commits done on the Patch Queue Manager
<vila> All of those commits were done after a 'make check'
<mib_max> maybe some problems are because of execution? I execute bzr in bzr.dev working tree
<vila> mib_max: that's what I do many times every day : './bzr selftest'
<mib_max> actualy am using PATH/bzr selftest
<mib_max> "~/bzr/bzr selftest"
<vila> selftest should report which bzrlib is used and which python version is used in the first output lines
<Jc2k> im seeing lots of loom related errors
<vila> Jc2k: loom.... shouldn't fail more than ... oh wait... if they are stacked branch related, the bug is known
<mib_max> it is using 1.12dev
<mib_max> 44errs so far
<mib_max> make check failed too
<mib_max> I think it is some problems with pyx files
<mib_max> http://www.mibbit.com/pb/iZYhA6
<mib_max> maybe I built pyrex libs in a bad way
<vila> mib_max: sounds like a probable cause or a bad version of pyrex (I think we blacklisted one version of pyrex)
<mib_max> deleted *.so from bzrlib
<mib_max> now things are going better
<mib_max> I am using pyrex 0.9.8.5
<mib_max> is it bad?
<vila> I don't think so, I think 0.9.8.4 had problems
<mib_max> what is recommended version?
<vila> did you run a bare 'make' ?
<mib_max> yes
<vila> I don't know, jam should
<beuno> branching large branches with --stacking is awesome. Why don't we advertise that more?
<vila> beuno: because you do that better than us ? :-)
<mib_max> pyrex modules are causing problems
<mib_max> vila, what version of pyrex are you using?
<beuno> vila, heh, maybe, maybe. I guess I'll need to blog!
<vila> mib_max: I don't use any because I run from the same sources for several OSes
<vila> but I'm not a good example :)
<mib_max> vila, so you are running selftest using only python modules?
<beuno> vila, btw, I'd like to have a (voice) chat with you at some point about a few ideas around bzr-upload
<vila> beuno: we should try that this week-end (where are you this week-end ? Argentina ?)
<beuno> vila, sounds good. I am in Argentina. We can ping-pong and see when both of us are awake and lucid
<mib_max> vila, how long does it usually takes to run all tests?
<vila> mib_max: locally yes, but in some branches under some OSes (mainly Ubuntu) I build them sometimes
<vila> mib_max: ~10/15 minutes in my case
<vila> But once you work on specific problems you don't have to run the whole test suite every time
<vila> There are different ways to select a subset of the tests
<mib_max> is it ok: /home/max/bzr/bzrlib/lockable_files.py:116: UserWarning: LockableFiles(<bzrlib.transport.local.LocalTransport url=file:///tmp/testbzr-FwhMsk.tmp/bzrlib.tests.blackbox.test_shelve.TestShelveList.test_shelf_order/work/.bzr/repository/>) was gc'd while locked   warnings.warn("%r was gc'd while locked" % self)
<mib_max> Lockable file was gc'd while locked
<vila> I don't like it but it's not a test failure, just noise
<mib_max> And it is ok to have XFAIL with bug # attached? (known bug)
<vila> XFAIL == expected failure
<mib_max> ok
<vila> That's how we track some problems that are known but not yet addressed
<mib_max> yes it is what I thought
<vila> beuno: sounds like a good plan
<mib_max> are there any ways to run tests in several threads?
<vila> nothing automatic yet, this is discussed from time to time but nobody never did it (which is an indication that nobody really needs it)
<vila> But the test framework itself doesn't forbid it either
<mib_max> will it be x time faster to run it across x cores? If runned on tmpfs it is cpubound, right?
<vila> Most of the test addicts prefer to run the "right" test for the part they are working on and that generally run in seconds
<vila> s/the right test/the right testS/
<mib_max> i see
<vila> running the full test suite is for when you do a break or switch to another task :)
<vila> or before submission of course :)
<mib_max> vila, btw what's the point of running selftest if I have no changes now and they all will pass, won't they? :)
<vila> The point is to make sure they all pass so that you know which one you break :)
<vila> And you just ran into that don't you ?
<mib_max> into what?
<mib_max> Into breakage of tests by bad pyrex?
<vila> yup, I think we had a bug here on gentoo and it will be helpful if you could file it on launchpad
<vila> s/we/had/we *have/
<vila> gee
<vila> s/we had/we *have*/
<mib_max> :D
<mib_max> As far as I understand gentoo doesn't use pyrex to build its own bzrs, it uses .c provided by tarball
<vila> mib_max: pyrex 0.9.6.4-1ubuntu1 on hardy
<vila> synchronicity :-) I was wondering about that
<mib_max> it is because current stable pyrex in gentoo is older than one, needed to build bzr
<vila> mib_max: You'll have to find someone more knowledgeable about pyrex than me though
<mib_max> downgraded to 0.9.6.4 and problems are gone
<mib_max> or no
<mib_max> they are still here)
<mib_max> does pqm use pyrex?
<vila> mib_max: try jam if he come online later, I will leave shortly
<vila> pqm certainly uses pyrex but I don't know which version
<mib_max> ok thanks
 * pickscrape runs selftest on gentoo too to see what happens...
<vila> mib_max: pyrex0.9.7-1 on intrepid, so this one should works too (I'm pretty sure some core devs run intrepid (or may be they are already on jaunty...)))
<mib_max> vila, pyrex 0.9.7 is not available in gentoo :( only 0.9.6 and then 0.9.8
<vila> :-)
<mib_max> will leave it as it is for now
<pickscrape> So far I just have an XFAIL
<pickscrape> mib_max: how far in did you start getting errors?
<mib_max> pickscrape, are you using bzr from gentoo or from bzr.dev? have you built pyrex modules?
<vila> I'm sure a patch ensuring we're compatible with 0.9.8 will be warmly welcome, if you're interested in working on performance, ensuring the C extension works is definitely part of it
<mib_max> about 150-200 tests
<pickscrape> Aha, I've got 4 now, but only after 1000 or so.
<mib_max> I get first near 150
<pickscrape> mib_max: I'm using a vanilla bzr.dev checkout with nothing made, but I just realised I ran bzr rather than ./bzr, so I'm starting again
<mib_max> you wont get problems because with make you won't use pyrex modules
<pickscrape> ok, I just ran make and restarted
<mib_max> it worked? are you using pyrex from ~?
<pickscrape> No, I'm getting errors
<mib_max> on stable pyrex it complains about some modules incompatible with such old version of pyrex
<pickscrape> pyrex 0.9.4.1
<mib_max> and in the begining of make you have complaint from bzr?
<pickscrape> Ah yes, it did complain about that.
<pickscrape> But the results I'm getting a different to those I got before running make.
<mib_max> :)
<pickscrape> s/ a / are /
<pickscrape> All of the errors so far are "exceptions must be strings, classes, or instances, not exceptions.OSError"
<mib_max> some here
<pickscrape> Oh well :)
<mib_max> *same*
<gotgenes> What information is stored about a merge when I commit it? Is there somewhere I can view it? I can't seem to find anything about it in bzr log, but I see Launchpad knows a merge occured.
<lifeless> gotgenes: log shows merges as indents
<davidstrauss> Is it possible to merge in zero revisions to merely establish a common ancestor?
<ronny> hi
<gotgenes> lifeless: Oh, it surely does. But I did bzr log -l 1 and it was only showing the commit message.
<gotgenes> Is that a bug?
<ronny> is there any way to get something like WorkingTree.list_files thats not recursive and pinned down to a specific dir/file
<gotgenes> Shouldn't it show the associated commit message?
<pickscrape> gotgenes: you asked it to show only one revision, which in your case was the merge revision
<lifeless> gotgenes: there is a discussion at the moment on the list about this; it is arguably a bug
<lifeless> gotgenes: but its arguably right too :P. We may add log -c, like diff -c, to show the log of everything from before:X to X
<gotgenes> pickscrape: True; but I guess the commits from the branch I merged from are relevant to the commit of the merge.
<pickscrape> gotgenes: that could be quite a large can of worms though :)
<lifeless> ronny: 'bzr ls'
<gotgenes> lifeless: Ah okay. That seems a good compromise.
<lifeless> ronny: perhaps
<ronny> lifeless: im in search of an api
<lifeless> gotgenes: you can simulate it today with bzr log -r before:foo..foo
<lifeless> ronny: cmd_ls in builtins.py then
<lifeless> ronny: sorry that I don't have more detail offhand
<gotgenes> lifeless: Excellent tip! Many thanks. :-)
 * ronny goes reading
<gotgenes> Also, out of curiosity, is anyone here at all familiar with any efforts to integrate bzr into NetBeans?
<ronny> lifeless: oh, seems like the ls command is just using the full recursive version and ignores parts of the resultset
<lifeless> ronny: do you need status like results?
<lifeless> ronny: e.g. do you need unversioned files as well as versioned?
<ronny> lifeless: yup
<ronny> lifeless: its for anyvc workdir status info
<lifeless> ronny: ah
<lifeless> ronny: then 'iter_changes' definitely
<lifeless> its the workhorse for status
<ronny> does that give me unversioned/ignored=
<lifeless> if you ask it to
<lifeless> gotgenes: http://bazaar-vcs.org/IDEIntegration
<ronny> is that api considered very stable?
<ronny> cause i'll offload the actual implementation to javier ^^
<gotgenes> lifeless: Yeah, I see "We Need You" though I'm not a Java developer.
<lifeless> ronny: iter_changes is pretty stable yeah
<ronny> sweet
<lifeless> its exposed in bzr-xmlrpc too
<lifeless> for eclipse and other VC's that want status information
<gotgenes> lifeless: Is that a wiki (community editable) page?
<ronny> well, in pida we "invented" anyvc for vcs abstraction
<lifeless> gotgenes: yes
<ronny> and boy is abstracting branching patterns fun
<gotgenes> lifeless: excellent. I'm looking for a way to actually edit it. I see Komodo supports Bazaar and would like to add it to that page.
<gotgenes> Ah, okay
<gotgenes> got it
<bialix> garyvdm: ping
<amanica_> I see all the bzr code have unix style line endins. How is it kept that way?  Is there a test for it or were we just lucky?
<amanica_> I ask because I'm about to add such a test as part of the trailing whitespace cleanup. and I'm just wondering.
<amanica_> I cant find any documentation about thit in HACKING either
<amanica_> so I'll add some
<bialix> but not all text files in the bzr.dev has LF-only
<bialix> have
<beuno> amanica_, be aware that branches with styling cleanups are usually rejected because of all the spurios conflicts they cause
<amanica_> I know
<bialix> poolie explicitly asked about this cleanup
<amanica_> yip
<beuno> ah, cool
<amanica_> bialix I tried to find offending stuff, but could not
<bialix> tools/win32
<bialix> but it's not py
<amanica_> ah, but at the moment its not checked
<amanica_> its not part of bzrlib so its not considered part of the code
<bialix> so I guess the real answer on your initial question: because all bzr hackers are linux guys
<amanica_> contrib is also like this
<amanica_> :)
<amanica_> so I thought that while I'm at it, I can check for that too
 * bialix wanna to say to garyvdm that we have the fix for gentle stop subprocess problem
<ronny> "gentle stop" ?
<bialix> yep
<bialix> without using hammer and BFG
<bialix> with "please" :-)
<ronny> where can this happen?
<bialix> it's for QBzr
 * bialix mutters: why for initial push to lp told about using default stacking branch, if the push anyway send all the data?
 * bialix waves bye
<jam> Jc2k: Some of the loom failures should be fixed in loom trunk
<jam> We updated "bzr status" to add another parameter
<jam> and loom "monkeypatches" "bzr status" and thus also needed to be updated
<Jc2k> jam: ah cool
#bzr 2009-01-17
<jml> jam: if there's better practice for wrapping a bzr command in a plugin I'd love to read about it.
<Ng> how easy/sane is it to call bzr's api directly from a python app if you just care about really simple add/commit stuff?
<beuno> Ng, pretty easy
<beuno> Ng, http://bazaar-vcs.org/Integrating_with_Bazaar
<LarstiQ> Ng: bzrlib is supposed to be usable that way
<Ng> nice :)
 * beuno waves at LarstiQ 
<LarstiQ> hey beuno :)
<jml> hey, the new progress bar in the bzr in today's ppa is pretty nice.
<LarstiQ> jml: yup!
<LarstiQ> jml: it not cleaning up properly is a bit suboptimal, but even then I rather like it.
<jml> yeah.
<jml> it actually does make bzr feel faster. :)
<jml> although, who knows, maybe there were performance improvements in the update as well :)
<LarstiQ> nafaik, I think you're right about it subjectively feeling faster
<jam> jml: well, you could have used "*args, **kwargs" and then pulled out only the ones you actually cared about
<jml> jam: yeah.
<jml> jam: I just cargo culted from the way loom handled "switch", which was probably not the wisest thing
<enigma> Quick question: Is there any plan to add  "--format" to bzr branch?
<enigma> So I could do: bzr branch --format=1.9 sftp://....
<enigma> I've noticed that I'm doing a "branch" and then "upgrade" a lot.
<enigma> Since we've been keeping our bzr server using the rich-root-pack format.
<enigma> And I like having 1.9-rich-root on my workstation.
<jml> enigma: I don't know of any.
<Ng> hmm, what about for initialising a repo from a python app - is there a better way than bzrlib::builtins::cmd_init?
<LarstiQ> enigma: I only know of bzr init; bzr pull to accomplish that
<LarstiQ> enigma: interesting idea though
<jml> enigma: but it sounds like a good idea. if you start filing a bug at http://bugs.edge.launchpad.net/bzr/+filebug, Launchpad might show you a bug that's already filed.
<jml> Ng: umm...
<jml> Ng: I think I've written public code that does this somewhere.
<enigma> Oh...I guess I didn't think about using a repo....thanks for the tip.
<jml> Ng: https://code.edge.launchpad.net/~jml/+junk/bzr-establish -- it probably either calls cmd_init or copies from it.
<enigma> So, I would do "bzr init-repo --1.9-rich-root" and then any branches I pull into that repo would automatically use 1.9-rich-root?
<fullermd> They would automatically use that repo format, yes.
<fullermd> I think they'd default to the upstream branch format, though.
<Ng> jml: thanks :)
<fullermd> So you'd probably get to sift through a bunch of 'unnamed'.
<LarstiQ> Ng: I'd probably use bzrdir.create_repository(shared=True)
<LarstiQ> Ng: like cmd_init_repo does as well
<jml> I wish looms had better toolchain support
<enigma> fullermd: "unnamed"?
<enigma> fullermd: I didn't realize I could run a different branch format than the repo format.
<fullermd> Well, you'd have to, since the repo format can't store a branch   :)
<enigma> What does the repo store? Just revisions?
<fullermd> 1.6 introduced a new branch format; I think --1.9-* uses that, instead of branch6.
<fullermd> Yah.
<enigma> OK.
<enigma> fullermd: Thanks for the help.
<fullermd> There are 3.5 formats involved; the repo, the branch, and the WT, plus a half in the container format.  They can be largely varied independently.
<fullermd> The various names like --1.9-rich-root etc are aliases for {repo X, branch Y, WT Z}
<enigma> Oh...if I'm running the 1.9 branch format on an client and I push back to a 1.0 branch format, is that going to cause problems?
<fullermd> I don't think so.
<fullermd> Generally branch formats don't introduce hitches like that; it's mostly repo formats.
<fullermd> (like the rich-root vs. poor-root hump)
<fullermd> Between branch5 and branch6 there were some, since branch6 supports tags and b5 didn't.  But the push would still work; it just wouldn't copy any tags.
<enigma> fullermd: OK.
<enigma> fullermd: What's the "WT"?
<fullermd> I don't _think_ the 1.6 branch format made any changes that will hiccup like that.  But I don't really know; I haven't looked much at it.
<fullermd> Working tree.
<enigma> Oh, OK.
<jml> are there already Python libs for parsing diffs?
<pygi> hi folks
<dwt> Hey guys, I'm looking for the current data of the performance testing history in bzr
<dwt> http://bazaar-vcs.org/PerformanceHistory
 * dwt indicates that I might find it at
<dwt> http://codespeak.net/bzr/perf_history/summary_bzr.dev.html
<dwt> but unfortunately thats not the case. :/
<dwt> anymore
<dwt> could somebody please advise?
<maxb> Why doesn't "bzr branch" remember the source as a saved push location, and can I make it do that?
<LarstiQ> maxb: you can bzr push :parent
<maxb> aha
<maxb> thanks
<LarstiQ> maxb: after that, it will remember the push location
<LarstiQ> maxb: on why it doesn't do that, in the model of standalone branches, theoretically it is very unlikely you will push to the same place you branch from
<LarstiQ> in practice, I don't know if that is a good decision, although frequently it is true for me
<rocky> jelmer: hey, i don't suppose you come up with any sort of work around for that bzr corruption bug that was reported a little while ago? (bzr-svn)
<jelmer> rocky, no sorry, I haven't had time to look at that yet
<rocky> maxb: any time you want bzr to remember a push/pull/merge location just remember to use --remember when you do it
<rocky> i can imagine time is limited :)
<jelmer> rocky, working on other bzr-svn bugs atm
<rocky> as it is for all of us
<rocky> i've been working on ClueReleaseManager (pypi server) lately ... to go along with ClueBzrServer (bzr-over-http) and ClueMapper (trac project admin tool)
<rocky> which reminds me...
<rocky> jelmer: has trac-bzr got any love lately?
<jelmer> rocky, not much news, Alexander was working on a minor bug fix
<rocky> jelmer: what's the last known versions of trac and bzr it works with?
<Jc2k> jelmer: the dulwich thing we were talking about; didnt need an api change but there was a buglet that i fixed.
<rysiek|pl> hi all
<rysiek|pl> guys, does anyone of you use bzr through sftp?
<rysiek|pl> a branch that a few devs use?
<rysiek|pl> I ave run into some problems with permissions. specifically, the whole branch is owned by root:bzr and all the devs are in the bzr group
<rysiek|pl> but if a dev creates a new file, it gets owned by devuser:bzr and the perms are set so that the group hasn't got write access to it
<rysiek|pl> which causes obvious problems here ;)
<rysiek|pl> so my question is: how do you overcome such problems? bzr --serve? some nifty sticky perms with proper umasks for all the devs?
<rysiek|pl> any hints?
<kumi> I use umasks and setgid on my branch
<rysiek|pl> kumi: I found this helpful bugger: https://lists.ubuntu.com/archives/bazaar/2008q1/038455.html
<rysiek|pl> kumi: are you using sftp or bzr+ssh?
<kumi> Oh I see, you're using sftp. We use bzr+ssh
<rysiek|pl> right, that makes it clear
<rysiek|pl> thanks
<rysiek|pl> I'll switch to bzr+ssh
<kumi> Are you on linux? you might be able to continue using sftp if you use ACL
<rysiek|pl> yeah, on linux
<rysiek|pl> ACL? ACL for what?
<kumi> setfacl/getfacl
<rysiek|pl> ah, rigt
<rysiek|pl> I'll investigate into that, thanks
<LarstiQ> rysiek|pl: openssh had a problem with not respecting setgid bits in sftp, that got fixed in http://www.openssh.com/txt/release-5.1
<LarstiQ> rysiek|pl: in the meantime, I do like kumi and use acls
<rysiek|pl> LarstiQ: thanks
<rysiek|pl> LarstiQ: don't acls work only on XFS?
<LarstiQ> rysiek|pl: I use them on ext3, I'm sure they work on reiser too.
<rysiek|pl> right, thanks
<LarstiQ> and probably ext4 and btrfs
<kumi> I think you have to mount the fs with the acl option though
<rysiek|pl> ok
<mxpxpod> does bzr-svn support making svn tags?
<jelmer> mxpxpod: yes
<mxpxpod> jelmer: just use bzr tag, right?
<jelmer> mxpxpod: yep
<mxpxpod> jelmer: thanks
<mxpxpod> jelmer: how does it know where to store the svn copy it makes?
<jelmer> mxpxpod: if you have a standard svn layout (trunk, branches, tags), it will create a new directory in tags/
<mxpxpod> jelmer: even if I've just pulled directly from trunk, right?
<jelmer> mxpxpod: yes
 * jelmer back in ~15 minutes
<mxpxpod> jelmer: thanks a ton, that's great
<luks> jelmer: if I do a nasty thing like svn mv foo/trunk foo/branches/old-trunk; svn mv foo/branches/new-trunk foo/trunk, how much will it break bzr-svn?
<jelmer> luks: depends on what you mean by how much
<jelmer> luks: bzr-svn will most likely give you a divergedbranches error (unless new-trunk is a direct ancestor of old-trunk)
<luks> jelmer: I mean if do a clean branch from foo/trunk, will it stop on the move, follow the move, follow the move but using a giant delete + add?
<jelmer> luks: it will follow the move
<luks> great!
<luks> thanks
<jelmer> luks: no delete + add involved
<luks> I wasn't sure if it works cross-branch as well
<jelmer> it only works if the old location is recognized as a branch location
<rysiek|pl> hmmm
<rysiek|pl> I jost got a crazy idea
<rysiek|pl> would it be possible to version a single dir
<rysiek|pl> within two branches?
<rysiek|pl> using mount --bind?
 * rysiek|pl 's gotta test it, although it probably will fail spectacularly
<chaynesin> Need help setting up server repo with trees
<davidstrauss> chaynesin: ok
<davidstrauss> chaynesin: what's the problem you're trying to solve that the docs don't clearly address?
<davidstrauss> chaynesin: (re: PMed question) "no trees" = "no working copy"
<davidstrauss> chaynesin: oh wait, *without* using no tree
<davidstrauss> hmm
<davidstrauss> chaynesin: by default, pushing and committing to the server tree will not update the server's working copy
<davidstrauss> chaynesin: regardless of whether the server has tree or no tree set
<chaynesin> is there any way to maintain a server repos with working files that updates automatically with push or commit or anything else that can be done via ftp?
<davidstrauss> chaynesin: yes, with a bzr plugin
<chaynesin> so bzr has to be installed with that plugin on the server? what's the pluging?
<davidstrauss> chaynesin: https://launchpad.net/bzr-push-and-update/
<davidstrauss> chaynesin: not sure how well it will work with sftp, though
<davidstrauss> chaynesin: ssh is generally a better solution for server repo access
<rysiek|pl> I have a python script that runs in a screen session, watching certain changes with inotify
<rysiek|pl> and running a bash script that updates the tree
<davidstrauss> rysiek|pl: why don't you just run the plugin i linked to?
<rysiek|pl> davidstrauss: I didn't know of that plugin when I needed that
<rysiek|pl> davidstrauss: besides, this plugin (as a bzr plugin) will *not* work with ftp/sftp
<chaynesin> so the plugin is clientside but requires ssh access. i think that will work for me.
<davidstrauss> rysiek|pl: neither will your approach work with ftp/sftp
<beuno> chaynesin, or bzr-upload
<rysiek|pl> davidstrauss: oh, but it does :)
<beuno> which will work with ftp
<Peng_> The bzr-push-and-update plugin simply makes bzr automatically run "ssh foo@bar bzr update /path/to/branch" after pushing, so you need bzr installed remotely.
<beuno> but it won't keep a repository on the remote side
<beuno> just the working tree
<rysiek|pl> davidstrauss: it just sits in a screen session monitoring the .bzr directory for changes that occur upon commits, pushes, merges, etc, and runs the bash script
<rysiek|pl> anywhoo, just my $.02
<amanica_> is it ok for me to send a merge-directive to the list without a bundle (just a public branch location)?
<beuno> amanica_, yeap
<davidstrauss> amanica_: should be fine
<amanica_> thanx
<beuno> amanica_, but sending in the actual patch makes it a lot easier to review
<amanica_> the bundle is 1.1MB
<chaynesin> is bzr-upload another pluggin  that runs on the client?
<beuno> chaynesin, yes
<Peng_> Heheh. I think someone sent a bundle that large a while ago; I don't remember what the reaction was.
<beuno> amanica_, I've sent bigger ones
<Peng_> amanica_: Just out of curiosity, what's your patch about? How'd it get that large? :D
<rysiek|pl> chaynesin: from what I understand, there is no way to have a "server-side" bzr plugins, unless you are using bzr --serve and bzr://
<beuno> SVGs and PNGs  :)
<amanica_> :) last time I did that it got stuch so I had to zip it
<davidstrauss> rysiek|pl: bzr+ssh uses server-side bzr binaries and plugsin
<rysiek|pl> davidstrauss: yeah, sorry for the omittance
<chaynesin> how do bzr-upload and bzr-push-and-update different, just in the command they ask via ssh the server bzr to run?
<davidstrauss> chaynesin: bzr-upload is not designed to work in tandem with a server-side repository+tree
<beuno> right, it just uploads the working tree
<davidstrauss> bzr-upload is designed to publish the working tree
<beuno> and keeps a reference of what you uploaded last
<beuno> so iy just uploads the changed files
<beuno> s/iy/it
<beuno> it's mostly targeted at web development
<chaynesin> looks like bzr-push-and-update is what I want, so I have to install bzr on the server, but can that be done w/o root?
<davidstrauss> chaynesin: yes, but you'll have to make sure the bzr binary is in PATH or manually specified in the client commands
<chaynesin> thanks a lot, i guess that's it for now.
<amanica_> :( without the bundle it it still 994K  so I'm considering it with --no-patch as well. (I'll attach useful diffs for reviewing)
<amanica_> Peng_ sorry I only saw your question now. it removes all the trailing white space from the code (about 3000 lines)
<amanica_> (and yes, martin requested it)
<amanica_> (aka poolie)
<amanica_> beuno: do you think I can send it with --no-bundle and --no-patch ?  or do you think I should just send the big file?
<Peng_> amanica_: Ah, that. Cool. :)
<sjokkis> hi i've fucked up and commited an empty revision. how do i check out a previous one?
<amanica_> beuno: it compresses to 285K, so maybe I can attach that also...
<amanica_> sjokkis do you want to uncommit it?
<sjokkis> i guess so
<sjokkis> oh right, that's a command
<sjokkis> gotcha
<sohail> hi
<sohail> is there an equivalent of svn cp?
<Peng_> sohail: No
<sohail> Peng_, then how do I record that I copied a file
<Peng_> sohail: You can't.
<Peng_> sohail: Bzr's nifty rename support comes at the price of making copies more difficult, and nobody's done the work yet.
<sohail> Peng_, so I use double the space...
<Peng_> sohail: I guess so.
<sohail> Peng_, in a way I guess it is good... It made me do some overdue refactoring :-)
<jelmer> Peng_: I don't think the rename support makes copies more difficult
<jelmer> Peng_: it's just that the developers seem to not want to implement copy support that works worse (in terms of merge) than rename support
<Jc2k> jelmer: around?
<Jc2k> jelmer: im adding SSH support to dulwich (should be easy..) but i really should change the API here..
<davidstrauss> How can I get my blog added to Bazaar Planet?
<davidstrauss> I mean Planet Bazaar.
#bzr 2009-01-18
<jelmer> davidstrauss: I think one of the Canonical folks is in charge of it, not sure who. Probably best to mail Martin
<davidstrauss> jelmer: Can I get Martin's email address?
<jelmer> davidstrauss, If you're a bzr contributor you should know that already :-)
<davidstrauss> jelmer: I've been posting a bunch about Bazaar and Drupal on my company blog, and I'd like it to find its way into the Planet.
<davidstrauss> jelmer: I'm a Drupal infrastructure team member, and we use Bazaar for a number of projects.
<jelmer> davidstrauss, What's the URL of your blog?
<davidstrauss> jelmer: If you only want to see Bazaar-related posts, http://fourkitchens.com/tags/bazaar
<davidstrauss> jelmer: Thanks. I've emailed him.
<ledge> svn-to-bzr question
<ledge> I have a svn repo that I'd like to import a sub-project into bzr
<ledge> i.e. I want to import /trunk/project into its own bzr repo, but svn-import seems to only want to pull the entire repo in
<ledge> is this possible?
<ledge> I've split apart the svn repo with svnadmin dump/load so that I re-import only /trunk/project into a new repo, and import that, but I still wind up with reponame/trunk/project as the bzr structure which is cumbersome
<ledge> I'd like to wind up with a bzr branch just called project/ as the root of the new brach
<ledge> (I could just take an export and import into a new bzr, but I'd like to keep revision history if possible)
<jelmer> hi ledge
<jelmer> ledge: You can use "bzr branch <url> <bzr-branch-name>"
<ledge> does that bring down revision history with it?
<ledge> (I'm pretty much a bzr noob right now)
<jelmer> ledge, yes
<ledge> well
<ledge> that's pretty easy then
<ledge> :/
<ledge> thanks.  :)
<ledge> I was sure I had to go through svn-import somehow...
<ledge> there it goes, it's working.  yay!
<KragenSitaker> Hi.  I have bzr 0.11.0.  How do I bzr branch lp:liveusb?
<thumper> KragenSitaker: `bzr branch lp:liveusb`
<thumper> :)
<KragenSitaker> it complains, "bzr: ERROR: Not a branch: /home/kragen/devel/lp:liveusb/"
<thumper> KragenSitaker: ah 0.11
<thumper> :(
<thumper> sorry
<thumper> you should upgrade bzr
<KragenSitaker> I assume "lp:liveusb" is short for some longer URL?
<thumper> KragenSitaker: it is
<thumper> KragenSitaker: you have an ancient bzr
<KragenSitaker> well, in a way, that's what I'm trying to do --- by virtue of installing a new OS
<KragenSitaker> what URL is it short for?
<KragenSitaker> pretty much all of my software on Debian Etch is ancient
<james_w> http://code.launchpad.net/liveusb should work I believe
<KragenSitaker> thanks!
<thumper> james_w: I'm not so sure
<thumper> https maybe
<james_w> hey thumper
<thumper> KragenSitaker: http://bazaar.launchpad.net/~probono/liveusb/main
<thumper> KragenSitaker: that is the long name for lp:liveusb for reading
<KragenSitaker> thumper: awesome, thanks!
<thumper> hi james_w
<thumper> KragenSitaker: however
<thumper> KragenSitaker: you won't be able to read it
<thumper> KragenSitaker: with 0.11 as the format is packs
<KragenSitaker> :(
<thumper> KragenSitaker: which needs at least bzr 0.92
<thumper> KragenSitaker: can you install a later bzr?
<KragenSitaker> this is stupid.  why can't probono make tarballs?
<KragenSitaker> I'm trying to install Ubuntu!
<thumper> heh
<KragenSitaker> which includes a current bzr
<thumper> ubuntu is easy to install
<thumper> KragenSitaker: check http://bazaar-vcs.org for Debian debs
<KragenSitaker> well, liveusb sounded the easiest of the options on https://help.ubuntu.com/community/Installation/FromUSBStick
<thumper> KragenSitaker: http://backports.org/debian/pool/main/b/bzr/ (debian backports)
<KragenSitaker> oh, that's probably an easy enough solution
<thumper> KragenSitaker: for my installs I normally just burn a cd
<KragenSitaker> thumper: yeah, I have a burned CD, but the new machine doesn't have a CD drive
<thumper> KragenSitaker: ah
<KragenSitaker> I figured a USB key cost about the same as a CD drive and would be more useful
<KragenSitaker> I wasn't counting on having to update my backports GPG key ring in order to install an updated version of bzr in order to download a third-party utility to make the USB key bootable
<KragenSitaker> I thought it was something on the CD, or at least a tarball on the web
<KragenSitaker> sorry for the rant
<KragenSitaker> and thanks for the help!
<thumper> :) np
<KragenSitaker> I'm off to install
<cammoblammo> Does anyone know what the hold up with bzr >1.5 is in Debian sid?
<Toksyuryel> cammoblammo: Debian is the hold up. I thought it was common knowledge how slow Debian updates.
<cammoblammo> Toksyuryel: I know Debian can be slow, but other packages seem to get in within days of upstream release. Every version since 1.6 has been in experimental, but I don't seem to be able to put my finger on why none of them have been moved to sid.
<Toksyuryel> bzr has been releasing like once a month. they might be waiting for it to settle down a bit
<pygi> Toksyuryel, nothing wrong in once-per-month release cycle
<cammoblammo> And hasn't it been that way a while anyway?
<Toksyuryel> pygi: never said there was anything wrong with it. just said that they might be waitinng for it to settle down a bit. I don't know. I don't use Debian.
<luks> Toksyuryel: the intersection between debian developers and bzr developers is not empty, so that's probably not the case :)
<Lo-lan-do> If I set up a branch in a repository, but the branch has different permissions than the repo (write access for someone else), will commits to that branch work?
<Lo-lan-do> Apparently not.  I guess that's what stacked branches are for.
<jezdez> how do I programatically get the location of a bzr repository clone?
<jelmer> jezdez: The location of a clone after it's been made?
<jelmer> not sure I follow
<jezdez> jelmer: sorry, I wasn't very clear :) I mean the location of the original repository
<jelmer> jezdez, generally, repositories are not cloned but branches
<jelmer> for the location of the parent branch, see Branch.get_parent()
<jezdez> right, that's just me confusing the terms in the different dvcs :)
<jezdez> is there a way to get that information through the bzr command?
<Lo-lan-do> There's at least "bzr info | awk"
<jezdez> Lo-lan-do: indeed, that's what I've been using until now
<isr> hi!
<isr> When I push to a remote server and then use bzr diff on the remote machine to see the difference between the last commit and the working tree, it doesn't return any differences.
<isr> Does this sound right?
<Lo-lan-do> isr: You need a bzr update on the remote machine, I think.
<Lo-lan-do> isr: Actually, probably not.  I think I read what you want to do backwards.
<isr> Lo-lan-do: I do a bzr update to get the tree up to date, but before that I do a bzr diff to see what was changed, cause the working tree is out of date
<Lo-lan-do> I see.  Then my answer is the wrong one, sorry.
<isr> Lo-lan-do: I would expect to see the differences of the last commit and the tree, or even a "tree is out of date" text
<Lo-lan-do> And I don't know the right answer, either.
<isr> Lo-lan-do: Thanks anyway
<kfogel> If my submitted [MERGE] request is in Bundle Buggy already, should I poke on the list if I don't see any action (either positive or negative), or just wait?  Not sure what the standard procedure is.
<kfogel> It's been in there a few days.
<james_w> kfogel: just wait normally
<kfogel> james_w: ok, thanks
<james_w> there are plenty of merge requests :-)
<kfogel> yes, I imagine so :-)
<james_w> feel free to poke if it's blocking something, or it's been to long I believe
<james_w> unfortunately I can't vote, so I can't help I'm afraid
<jezdez> how would I get the parent branch of a checkout?
<james_w> try "bzr info"
<jezdez> programmatically
<Peng_> You could check how "bzr info" is implemented. :D
<Peng_> bzrlib.builtins.cmd_info
<jelmer> jezdez, you mean the master branch of a checkout?
<jezdez> jelmer: yes
<jezdez> Peng_: thanks, that's a good pointer
<jelmer> jezdez: I think it's just Branch.get_master_branch()
<jezdez> you mean BzrBranch.get_master_branch()=
<jezdez> ?
<jelmer> yes
<jelmer> well, BzrBranch is the implementation
<jelmer> Branch.get_master_branch() is the interface
<jezdez> oh, I see
<jezdez> the formats
<jezdez> maby I should just parse the command line output :P
<jezdez> in case you wonder what I'm trying to do: I'm adding bzr support to pip
<jelmer> jezdez: Branch.open("/path/to/branch").get_master_branch() should do it
<jelmer> hi davidstrauss
<davidstrauss> jelmer: hi
<vadi2> Is it possible to search for a string across all files in all of the revisions in a branch?
<vadi2> (need to locate if the string ever existed)
<Peng_> vadi2: Maybe use bzr-search?
<jezdez> jelmer: awesome, that works.
<vadi2> Peng_: I don't have such a command
<Peng_> vadi2: It's a plugin.
<Peng_> Anyway, yeah, bzr-search can totally do that.
<vadi2> it seems 8.10 does not has a package for it. I'll try the bzr stable ppa
<vadi2> (it does appear in 9.04 repository though)
<Peng_> It's not in the PPAs.
<Peng_> That's cool that it'll be in Jaunty though. :)
<vadi2> Oh. that's dissapointing
<Peng_> You can just "bzr branch lp:bzr-search ~/.bazaar/plugins/search" or something.
<vadi2> heh: http://paste.pocoo.org/show/100279/
<vadi2> Peng_: I branched, but it says the following: "Unable to load plugin 'search' from '/home/vadi/.bazaar/plugins'"
 * Peng_ dies
<Peng_> I guess this is why they invented apt. :P
<vadi2> Guess so. What to do?
<Peng_> Oh.
<Peng_> You may have put the plugin itself in ~/.bazaar/plugins/search/trunk or ~/.bazaar/plugins/search/search or something, instead of ~/.bazaar/plugins/search.
<vadi2> No, it is proper
<vadi2> http://paste.pocoo.org/show/100280/
<Peng_> Oh, 100,000 pasts. Congrats pocoo. :)
<vadi2> Yeah, I like their pastebin.
<Peng_> Is there a traceback? Perhaps in ~/.bzr.log?
 * Peng_ doesn't understand why bzr-search wouldn't work. Old bzr version maybe?
<vadi2> That file is huge
<vadi2> I'll delete it and try the command again
<vadi2> this is a debug log for diagnosing/reporting problems in bzr
<vadi2> you can delete or truncate this file, or include sections in
<vadi2> bug reports to https://bugs.launchpad.net/bzr/+filebug
<vadi2> 0.597  encoding stdout as sys.stdout encoding 'UTF-8'
<vadi2> 0.614  bzr arguments: [u'search']
<vadi2> Oops
<vadi2> http://paste.pocoo.org/show/100284/ is what I meant to paste
<vadi2> maybe getting the latest version of the plugin against not the latest version of bzr wasn't a good idae
<vadi2> *idea
<Peng_> Yeah, your bzr is too old. What version is it?
<vadi2> whichever 8.10 comes with..
<vadi2> 1.6.1.1
<vadi2> er, 1.6.1
<Peng_> Yeah, it requires something newer than that.
<Peng_> Um, sorry this is such a pain.
<Peng_> I think it might have been quicker to just start grepping. :P
<vadi2> Would that cover past revisions however?
<garyvdm> nope
<Peng_> No, but "grep foo; bzr revert -r -2; grep foo; bzr revert -r -3; ..." doesn't take *forever*. :P
<vadi2> Uh. Heh
<Peng_> I guess you could use the PPA bzr.
<LarstiQ> how about using bzr-bisect?
<vadi2> what's that do?
<LarstiQ> vadi2: bisect! :)
<LarstiQ> vadi2: it is used to find when a bug was introduced for example
 * LarstiQ missed some context so maybe this is not a suitable solution
<vadi2> Thanks for the tip, I'll need it for another problem
<vadi2> right now I need to search for a string across all files in bzr across all of their revisions
<LarstiQ> vadi2: you give it a range of revisions, and then it will start to do a binary bisection to find the revision you're looking for
<LarstiQ> vadi2: ah
<LarstiQ> vadi2: I don't think there is a ready answer for that
<garyvdm> vadi2: try revert search to rev 61
<vadi2> It's the 'I'm definitely positive it I did this, but I cannot find it' type of moment
<LarstiQ> vadi2: right
<vadi2> garyvdm: not 52?
<Peng_> Or upgrade bzr.
<garyvdm> ok
<Peng_> vadi2: Well, it wouldn't take long to try them and find out. :D
<vadi2> r52 seems to have worked, thanks much
<Peng_> 61 didn't?
<vadi2> would be nice if there was a bzr-plugins ppa or something
<vadi2> I didn't test 61 :\
<vadi2> 52 just says added support for 1.6 so I'm happy
<amanica_> Peng_ thanks for the tip, but sadly bundlebuggy still ignores me. I think I should wait for aaron to set me straight. Hopefully this doesn't block reviews..
<Peng_> Huh.
<Peng_> Maybe BB just doesn't like you.
<amanica_> my thoughts exactly :)
<Peng_> Ohh. Maybe BB doesn't like using bzr+ssh?
<amanica_> aaarg
<amanica_> I want to refraigh from sending more spam untill aaron can tell me what goes for what
<amanica_> is he on holiday?
<Peng_> I dunno.
<Peng_> I vote for sending one more message, but I'm not the one sending it, soo. :P
<amanica_> it looks like my full bundle went trough on the list, but BB ignored that too
<vila> garyvdm: ping
<garyvdm> Hi vila
<vila> hey :)
<vila> I just finished reviewing your patch for bzr-upload
<garyvdm> Cool!
<vila> I think we started on the wrong foot :-/
<vila> Take a look at lp:~bzr-upload-devs/bzr-upload/upload-from-remote-branch (built on top of your patch), read my review, and tell me what you think
<garyvdm> Ok
<vila> I won't stay there long, so take your time :-) Just wanting to "talk" a bit as a review may sounds more rude than it is
<vila> garyvdm: on another subject, you said you'll work on qbzr regarding the new UI, I had to too
<vila>  
<vila>  
<vila> -class SubprocessGUIFactory(ui.text.TextUIFactory):
<vila> +class SubprocessGUIFactory(ui.CLIUIFactory):
<vila>  
<vila> seems to be enough (and simpler because there are circular dependencies otherwise (simplifying)) do you know why qbzr was using a TextUIFactory ?
<garyvdm> Re:review - that cool.
<garyvdm> I'm not sure why it was using TextUIFactory, but I can tell you why it is now.
<jelmer> has anybody else seen problems with the new progress code
<jelmer> just hit the recursion limit :-(
<garyvdm> P.S. I've pushed new revisions to lp:qbzr
<vila> garyvdm: why is it now ?
<vila> jelmer: file a bug
<garyvdm> qbzr now displays the transport activity
<vila> hmmm, that's a very good reason...
<garyvdm> I reuse some of the TextUIFactory code to generate the transport activity string.
<luks> vila: it used TextUIFactory, because it implemented methods I didn't have to implement on my own
<vila> then I think qbzr should define that class in a lower package that it can lazy import :-/
<vila> luks, garyvdm : I tried to play a bit *without* pushing down the class definition but I went nowhere
<garyvdm> Yes- I've moved the class and import to lib/subprocess.py
<vila> so if qbzr *needs* textUI *and* you want to lazy import (which are both valid wishes :-)...
<vila> garyvdm: great, I should pull :-)
<vila> I'm off, have fun
<garyvdm> Some of the methods that I'm using fro TextUI are _private. I'm going to document what we could use and maybe submit a patch.
<vila> garyvdm: excellent idea
<vila> Try to do that sooner than later (i.e. before 1.12 is out), there is a window here before the API is freezed
<vila> Ideally bzr-gtk should do the same... I may give it a try if a find the time :-/
<lifeless> moin
<jelmer> hey lifeless
<amanica_> I suspect that BB is not processing mail (maybe I upset it. sorry), or maybe it just hates & ignores me now...
<lifeless> jelmer: some issues were reported on the list
<jelmer> lifeless, thanks, I'll have a look there
<jelmer> lifeless, so I've pondered a bit more over rebase
<jelmer> lifeless: what about just adding these sorts of options to a "bzr rewrite" command (copying, or perhaps replacing replay) ?
<jelmer> That could be the primary interface possibly, and rebase could just be there for git refugees
<lifeless> jelmer: something like that, sure. But replay can't do all rebase does atm; seems to me there are three branches needed:
<lifeless> working
<lifeless> source to pull --overwrite from
<lifeless> source to replay onto the new tip
<lifeless> in rebase working is ., source to replay is ., and source to pull from is 'parent'
<lifeless> the ability to plan out an operation and save it is something that would be useful for replay too, IMO
<jelmer> Yes, I agree
<matthewlmcclure> I'm seeing some strange behavior with coverage tracing in bzrlib.tests.make_bzrdir and bzrlib.transport.get_transport.  The tracer stops tracing when the latter returns control to the former.  Anyone here who can help?
<lifeless> I don't have a canned answer sorry
<thumper> morning lifeless
<lifeless> hi thumper
<jelmer> whoa, the bzr-svn cache seems to actually be slowing it down significantly these days
<matthewlmcclure> When I run bzr --coverage cover selftest -v test_push_onto_just_bzrdir , the coverage results look wrong.
<matthewlmcclure> cover/bzrlib.tests.__init__.cover indicates that the first several lines of make_bzrdir were covered, but the lines after get_transport were not.
<sohail> do you guys advocate multiple bzr repositories or one repository? for example, I have one gigantic repository with projects and config files
<lifeless> matthewlmcclure: I don't have any experience using cov sorry
<lifeless> sohail: we advocate what works for the individual
<matthewlmcclure> thanks lifeless.  anyone else here who does use coverage?
<sohail> lifeless, yeah I'm not sure if that is working for me
<sohail> bzr push takes forever
<lifeless> of a new branch or of a single commit?
<sohail> lifeless, single commit
<lifeless> thats odd
<lifeless> it shouldn
<lifeless> 't really be related to tree size
<sohail> yep... pretty repeatable too
<lifeless> what protocol are you pushing over?
<sohail> I do bzr push <wait> CTRL-C bzr break-lock $LOCATION bzr push <done immediately>
<sohail> version 2 it seems to say
<sohail> well it says "upgrade server" and then reconnects using version 2
<lifeless> sohail: sftp | bzr+ssh | bzr+http | ftp | webdav
<lifeless> sohail: which of those are you using?
<sohail> bzr+ssh lifeless
<lifeless> what is your bzr version?
<sohail> on push target, 1.3.1, source 1.9
<lifeless> upgrade the target
<sohail> lifeless, ok I'll do that
<lifeless> the last change to WhoUsesBzr is ...odd
<jelmer> you mean the adding the references to other DVCSes?
<jelmer> That one didn't make much sense to me either
<lifeless> http://git.or.cz/gitwiki/GitProjects?action=info
<lifeless> same guy
<lifeless> same on darvs
<lifeless> same on darcs
<lifeless> this person has whipped around a bunch of wikis cross linking
<poolie> good morning
<jelmer> hi poolie
<lifeless> hi
<poolie> hello jelmer, lifeless
<poolie> lifeless, do you want to meet up today?
<lifeless> sure
<lifeless> I need to be back here not much after 3, or at 3 ideally
<poolie> i could come there
<lifeless> jelmer: have you written a VersionedFiles interface to dulwich?
<jelmer> lifeless, not yet
<jelmer> it's in the pipeline though
<lifeless> where would it go
<lifeless> bzr-git? dulwich? somewhere else?
<jelmer> bzr-git
<jelmer> dulwich is just a Python implementation of the git file formats/protocols, independent of bzr
<lifeless> yeah
<lifeless> jelmer: have you upgraded bzr-git to rich roots or subtrees?
<jelmer> lifeless, yes, it writes rich roots
<lifeless> jelmer: trying to sync my branch and it barfs :P
<lifeless> no the repo
<jelmer> lifeless, oh, the repo is rich root as well
<jelmer> so we could "bzr join" dulwich
<jelmer> the two are developed in lockstep at the moment, we'll remove dulwich again once the dulwich API is more stable
<Peng_> jelmer: You marked bug 308353 as fixed. Are you sure? I still get the error. I tried nuking bzr-svn's cache; I'm trying a new repo now.
<ubottu> Launchpad bug 308353 in bzr-svn "[0.5] KeyError in old_inventory when branching Lighttpd 1.4" [Medium,Fix released] https://launchpad.net/bugs/308353
<jelmer> Peng_, The fix hasn't actually been pushed yet, will do that in a minute
<jelmer> Peng_, pushed now
<Peng_> Heh, okay.
<Peng_> You shoulda said "Fix Committed" then. ;P
<Peng_> jelmer: Still got the error. Do I need to delete the cache or anything?
<jelmer> Peng_, where did you pull from?
<jelmer> revision-id: jelmer@samba.org-20090118223431-v2g3dql9rv2ikjpa ?
<Peng_> jelmer: 1.) http://people.samba.org/bzr/jelmer/bzr-svn/0.5/ 2.) Nope. The tip is, uh, jelmer@samba.org-20090118221826-68xux6yq6a482k2f .
<jelmer> Peng_, that should be sufficient; can you remove the cache and try again?
<Peng_> Aye.
<jelmer> ah, crap - it may not actually be fixed
<jelmer> Peng_, I only checked --stacked and lightweight co for some reason
<Peng_> jelmer: Ah. I'm using regular branches..
 * jelmer tries with regular
<jelmer> Peng_, ok, it's still there
<jelmer> Peng_, Sorry
<Peng_> :D
<Peng_> jelmer: Is this a one-line change to make it apply to regular branches too, or more complicated?
<igc1> poolie: sorry I missed the call
<igc1> my plan for today ...
<poolie> np
<igc1> release updated log benchmarking numbers; package usertest wrappers so others can more easily use it; reviews; reply to kfogel re doc; log --merge-revisions (i.e. make it orthogonal to formatters while keeping current behaviour)
<kfogel> igc: I'm not sure I ever saw that reply "re doc" -- what was the subject?
<kfogel> Was it in the "Short, task-based bzr doclets for real-world use cases." thread?
<jelmer> Peng_, no, it's not a one-line change
<jelmer> Peng_, just added bzrlib.plugins.svn.tests.test_fetch.TestFetchWorks.test_fetch_replace_self_open that demonstrates the problem
<igc> kfogel: shrt, task-based bzr doclets
<igc> reply coming ...
<Peng_> jelmer: Alright. Thanks for your work. :)
 * igc food
#bzr 2010-01-18
<lifeless> spiv: seen poolie
<lifeless> spiv: I think its because the command  finding hooks have been cleared inappropriately
<lifeless> spiv: and/or a chdir has been done inappropriately.
<spiv> lifeless: hmm, quite likely.
<spiv> lifeless: regarding poolie, I haven't seen/heard anything.
<Noldorin> jelmer, hello?
<jelmer> Noldorin, hi
<Noldorin> hey
<Noldorin> jelmer, any idea about that strack trace for bzr-svn?
<jelmer> Noldorin, which stack trace?
<Noldorin> jelmer, http://pastebin.com/m122b7c64
<Noldorin> did you catch any of the convo with spiv ?
<jelmer> no, I haven't
<Noldorin> that describes it all anyway...trying to push to an svn repo with bzr-svn
<Noldorin> always worked until recently :S
<jelmer> Noldorin: have you pushed to this codeplex repository before?
<Noldorin> jelmer, yep, worked many times
<Noldorin> and haven't really changed the bzr repo
<Noldorin> it might have happened when i cancelled a push to svn one time :S
<jelmer> Noldorin: remove the 'layout = None' bit in ~/.bazaar/subversion.conf
<Noldorin> jelmer, it has guessed-layout = None
<Noldorin> do i want to remove that?
<jelmer> Noldorin: can you remove that ?
<Noldorin> (or comment it out?)
<Noldorin> ok
<Noldorin> jelmer, ok, it's doing better now...
<Noldorin> [-                   ]    208KB     3KB/s | analyzing repository layout:fetchi
<poolie> hi spiv, lifeless?
<Noldorin> jelmer, 1900KB now...seems to be going a bit long :/
<jelmer> Noldorin, it'll do the full repository analysis again now
<Noldorin> fair enough
<Noldorin> jelmer, so what's thie about layout...? why do i have to remove that line from the conf file?
<jelmer> Noldorin: it contains the guess repository layout
<jelmer> you had to remove it because it contained an invalid value (None)
<Noldorin> ah
<jelmer> not sure how that got in there though
<Noldorin> so by default there shouldn't any there...?
<spiv> poolie: good morning
<jelmer> Noldorin: it should be there, it should just have the right value :-)
<jelmer> Noldorin, does it work now?
<Noldorin> jelmer, ah fair enough...still going
<Noldorin> 3500KB now
<Noldorin> what should be the right value?
<jelmer> Noldorin: it'll be determined by bzr-svn automatically
<Noldorin> ok
<jelmer> or you can specify one - see "bzr help svn-layout"
<Noldorin> fair enough.
<Noldorin> heh, just waiting still. 4MB seems like an awful lot, and it's still going ...
<lifeless> abentley: the fix for you has landed
<lifeless> poolie: hi
<Noldorin> jelmer, does this make sense that so much is being downloaded? 5.5MB now and 0/36100
<Noldorin> it looks like it's downloading the entire revision history of codeplex, hah :P
<jelmer> Noldorin: No idea, sorry
<jelmer> Noldorin: it might be a codeplex issue, I've seen issues with it before
<Noldorin> ah right
<Noldorin> hrm
<Noldorin> no worries then. thanks anyway
<jelmer> Noldorin: I
<jelmer> 'm happy to help debug though
<jelmer> Noldorin: If it keeps going, you might want to try again with -Dtransport
<Noldorin> jelmer, ok i think i'll try that then
<Noldorin> hmmm
<Noldorin> it shows [####################/] now
<Noldorin> does that mean it's almsot done?
<Noldorin> jelmer, hmm?
<spiv> Noldorin: it means we probably made the right decision to remove the progress bar in 2.1 ;)
<Noldorin> spiv, hehe, fair enough
 * Noldorin cancels it
<spiv> Noldorin: chances are it's making progress, but I couldn't say how long it would take
<Noldorin> spiv, yeah. so i've run it with Dtransport now
<Noldorin> what should i check?
<spiv> Noldorin: that'll add a lot of debug output to ~/.bzr.log
<Noldorin> ok
<spiv> Noldorin: so you can monitor that and hopefully get an idea of what it's doing
<Noldorin> "hopefully"
<Noldorin> mm
<Noldorin> spiv, http://pastebin.com/m67c3cc57
<Noldorin> that's what .bzr.log gives
<Noldorin> spiv, any ideas?
<jelmer_> Noldorin, hi
<jelmer_> Noldorin, this is indeed a codeplex issue
<jelmer_> Noldorin, it's not behaving as a svn server should
<Noldorin> hi jelmer_
<Noldorin> you read the pastebin eh?
<Noldorin> hrmm
<jelmer_> yeah
<Noldorin> yay for MS again
<jelmer_> any chance you can file a bug with them?
<Noldorin> jelmer_, sure, if you tell me what to put in it :)
<Noldorin> since i don't fully understand the source of the problem
<jelmer_> all I can say based on that pastebin is that it doesn't actually provide all data that is requested by the client when you do a log request
<jelmer_> If you specify the line that's being repeated in .bzr.log and your repository URL I should be able to help narrow that down
<jelmer_> I'm off again, back later
<Noldorin> jelmer_, ok, thanks...
<Noldorin> i'll try to submit that tomorrow
<Noldorin> (late here, so i'm off to bed)
<Noldorin> night
<spiv> poolie: going to fetch mary, brb
<poolie> k
<lifeless> poolie: what version of subunit were you using when you had the problem stream on friday?
<poolie> um
<jelmer> uhm!
<poolie> hello :)
<poolie> are you at lca?
<jelmer> hi :-)
<jelmer> yep
<jelmer> james_w: ping
<poolie> lifeless: i think 0.0.4-4
<poolie> btw it has no __version__
<lifeless> poolie: yeah I should add one
<lifeless> poolie: ok, well I still have no explanation then; its missing the xfail outcomes
<lifeless> poolie: and I can't trigger the fault myself so far
<xnox> Now when I run bzr I always get the pre-commit hook running
<xnox> I don't believe I created any myself
<xnox> how do I find out which out of my ~10 plugins is missbehaving?
 * xnox wants to know what's it's doing
<lifeless> xnox: do you mean that qwhen you commit you see 'running pre commit hooks'
<xnox> yeap
<xnox> and sometimes it takes a while (on big binary blob commits)
<xnox> lifeless: it wasn't there before...
<lifeless> thats bzr telling you its at that point in the commit. It doesn't really mean anything in and of itself. Each prec ommit hook run will have its label printed out separately.
<lifeless> xnox: you can however get a list of the installed hooks.
<lifeless> uhm
<xnox> oh my I do have quite a few hooks
<lifeless> ok in python
<lifeless> import bzrlib.plugins
<xnox> I think I know what it is. I've enabled bzr search / index on this repo and it's activated on tip change
<xnox> $bzr hooks
<lifeless> import bzrlib.plugin
<xnox> showed me =)
<lifeless> bzrlib.plugin.load_plugins()
<lifeless> bzrlib.branch.Branch.hooks['pre_commit']
<lifeless> yeah, that will too :)
 * xnox says everyone on #bzr just love to do everything with bzrlib =)
<lifeless> however index is post_change_branch_tip
<xnox> true
<xnox> then I'm clueless
<xnox> cause there are no post_commit hooks installed yet it stops there for while
<xnox> bzrlib.branch.Branch.hooks['pre_commit'] is just a pointer and not callable
 * xnox whatever is the real name for pointers in python "object in memory"?
<lifeless> reference
<igc> hi all
<xnox> aha! =) thank you
<lifeless> whats the callbacks list though?
<lifeless> I have to go, perhaps igc can help you :)
<lifeless> ciao
<xnox> lifeless: it's empty via bzrlib method also
<xnox> callback=[]
<xnox> =((((
<xnox> maybe another day
<james_w> hi jelmer
<jelmer> hey James
<jelmer> james_w: can I upload current bzr-bd to sid?
<james_w> sure
<jelmer> james_w: would you be ok with 2.2 as version number for that, or would you rather see a 2.2~ ?
<james_w> 2.2 is fine
<james_w> jelmer^
<jelmer> james_w: thanks
<james_w> no, thank you
<jelmer> james_w: Is there still a debian branch somewhere with the Maintainer: etc set properly?
<james_w> there may be one on bzr.debian.org
<james_w> it's probably a fair way behind if it is
<vila> hi all !
<james_w> salut
<thumper> james_w: hey
<james_w> hey thumper
<thumper> james_w: you coming around?
<james_w> yeah, I'm still writing
<thumper> james_w: so is everyone here :)
<james_w> you need me soon?
<thumper> if you are getting more done there, feel free to finish first
<james_w> thumper: we're just ordering some pizza, I'll come over post-prandially
<vila> prandially: ENOTFOUND
<james_w> vila: after eating
<mwhudson> isn't "prandially" basically a frenchism?
<vila> james_w: thanks :) I mostly deduced it from the context but my online dictionary raised the error above and I was wondering where the word was coming from..
<vila> mwhudson: It doesn't ring any bell....
<james_w> from the latin apparently
<vila> oh, prandial, got it
<vila> mwhudson: so the English jumped over the French for this one :)
<mwhudson> ah
<poolie> hello vila, mwhudson, james_w
<vila> hey
<james_w> hi poolie
<mwhudson> hello poolie
* vila changed the topic of #bzr to: Bazaar version control  | try https://answers.launchpad.net/bzr for more help | http://bazaar.canonical.com/ | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.0b4 and 2.0.3 released
<spiv> vila: hello patch pilot :)
<vila> spiv: ;)
<spiv> vila: I'm about to go on leave (I'll send mail about this shortly), so you may need to take care of https://code.edge.launchpad.net/~spiv/bzr/per-file-merge-hook-491711/+merge/17279 ;)
<vila> spiv: before you left, I haven't yet look at your merge hook ... hehe good
<vila> spiv: roughly, are you confident enough to land for 2.1.0rc1 or is it something for 2.2 ?
<spiv> vila: I think it may actually be ready to land now
<spiv> And I think it'd be good for 2.1.0rc1
<vila> ok
<spiv> It's fairly low risk, I think.  The bits that are likely to break are probably shallow.
<vila> spiv: so you can fix them in your part-time ? ;-)
<spiv> e.g. maybe the news_merge plugin might accidentally cause tracebacks on some corner case, and will need to be made a little more resilient to just giving up when that case happens.
<spiv> vila: right ;)
<spiv> The sooner it lands, the sooner any bugs will get shaken out, of course ;)
<spiv> But it would be a useful feature to land for udd
<spiv> Especially if someone at the sprint can write a debian/changelog merger (see my mail to the udd list)
<vila> spiv: Yes I read that, I'll look into it asap
<spiv> Having glanced at it again, I think it might actually be really easy...
<spiv> I had been thinking it'd be good to do at the sprint, but maybe you'll just do it today ;)
<spiv> (for someone other than me to do at the sprint, of course)
<vila> spiv: I think it's a really good target for the sprint and will spread the knowledge better.
<spiv> vila: *nod*
<vila> spiv: but I'll note to land it
<spiv> vila: thanks :)
<mwhudson> james_w: hi
<poolie> spiv/vila, what is?
<mtaylor> spiv, vila: debian/changelog merger ++
<vila> poolie: per-file-merge-hook
<poolie> that sounds good
<poolie> vila, thanks for being patch pilot this week
 * igc dinner
 * beuno waves at vila 
 * vila waves at beuno
 * jelmer waves
<vila> beuno: you're abroad again right ?
<vila> jelmer: You're never up that early so you're definitely abroad too :)
<jelmer> vila: I'm in NZ :_)
<spiv> mtaylor: Hopefully quite soon! :)
<vila> bingo :)
<spiv> mtaylor: I already have a bzr NEWS file merger :)
<mtaylor> spiv: yippee!!!
<mtaylor> spiv: as someone who does a lot of merging between packaging backport branches, I will welcome this new feature
<spiv> But someone else will get to write the debian/changelog one I think, I'm about to become a parent :)
<beuno> vila, no, I'm startiong early so I can finish early. I'm signing the contract to move into a new apartment
<mtaylor> spiv: congratulations!
<beuno> heya jelmer
<vila> beuno: wow, *that's* early !
<vila> beuno: Congrats for the new apartment ! I'm happy to hear that !
<beuno> mwhudson, if you're around, I'm curious about LH's performance since the latest patch
<spiv> mtaylor: thanks!
<poolie> hello beuno
<poolie> how nice to see you
<mwhudson> beuno: it's been ok
<beuno> hey hey poolie
<beuno> mwhudson, significantly more stable?  or "meh"?
<mwhudson> beuno: hard to say at this stage
<mwhudson> beuno: perhaps a little better
<poolie> spiv, I am asked to approve or disapprove of your paternity
<poolie> that's kind of a big question :)
<jelmer> beuno: Yes, congrats!
<beuno> jelmer, how's LCA?
<jelmer> beuno: Nice :-) Preparing our talks for tomorrow's miniconf at the moment.
<vila> spiv: so regarding per-file-merge-hook, I think you addressed jam's remarks but I'd wait for his comments/approval before landing
<poolie> vila, tanks for the progress review
<vila> ta
<mwhudson> james_w: i'm trying to use bzr-builder and failing
<mwhudson> james_w: it would be good to fix this before tomorrow :-)
<spiv> vila: great, thanks :)
<vila> spiv: I'm reviewing right now, a couple of tweaks so far, nothing serious.
<vila> spiv: I really like your refactorings...
<spiv> vila: phew :)
<vila> spiv: done.
<lifeeth> Hello folks.. I was wondering if there was a bzr utils suite that can be used without installation on windows?
<spiv> lifeeth: what do you mean by "utils suite"?
<lifeeth> I mean just the bzr.exe
<spiv> lifeeth: there are a fair few plugins available that don't need speicial installation.
<spiv> Oh, hmm.
<spiv> Not sure, sorry :/
<lifeeth> Ok..
<lifeeth> Need to package it with a portable app -- so was wondering if there was just one executable that can be used
<flavour> Cool, there is a channel :)
<flavour> Apply change? [yNfq?]
<flavour> on bzr merge -i
<flavour> What is the 'f' for?
<flavour> Please tell me it's 'forget'
<flavour> As in 'don't commit this change & then don't bug me about it again'
<flavour> I have a criss-cross merge
<maxb> I suggest you press '?'
<flavour> maxb thanks
<flavour> What does 'finish' mean then? Same as my hoped-fr 'forget'?
<flavour> Or just 'stop processing more files, but process the ones already 'y''d?
<spiv> flavour: the latter, IIRC, but I can never remember...
<flavour> So is there any way of telling Bzr to 'never hassle me about this change again'?
<flavour> Any other way of cleanign a criss-cross merge other than one side dleeting & repulling afresh?
<tumbleweed> flavour: bzr revert, bzr revert --forget-merges ?
<flavour> Well, I want to keep 2 LP branches in sync
<spiv> flavour: never in which sense?  If you do regular (non-cherrypick) merge, and resolve it and then commit it, then the next time you merge those changes will not be reconsidered.
<flavour> Syncing often (coding for Haiti)
<flavour> If I do a normal merge then I will lose a whole bunch of changes
<flavour> Which I'll have to reapply manually
<spiv> Lose in what sense?
<flavour> Well, the incoming merge wants to revert a whole bunch of changes I just made
<spiv> Well, you can revert those files before committing.
<flavour> So I'd have to reapply the change again to each of the files
<spiv> i.e. "bzr merge ../other-branch; bzr revert file1 file2; bzr commit"
<flavour> Then it'll hassle me about merging again next time I think
<spiv> No, it won't.
<flavour> I'll try it, thanks :)
<spiv> So long as "bzr st" shows a pending merge.
<spiv> Then bzr will remember that you've merged in that revision (and thus all the parent revisions of that, too).
<spiv> And it won't try to remerge them.
<spiv> criss-crosses can make it hard to determine which changes are already merged, but even then "bzr merge --lca" tends to do a pretty good job.
<tumbleweed> question I asked on the weekend (when the channel was dead). We are doing a big code-reorganisation. Some files can be "bzr mv"ed. But there's a lot of movement of things from one file to another. No way to carry history, right?
<Peng> tumbleweed: Right.
<spiv> tumbleweed: right, unfortunately.
<tumbleweed> thanks
<Peng> tumbleweed: If you're moving the majority of a file, it may make sense to "bzr mv" it then create a new file. (You can do that in the same revision. I think.)
<tumbleweed> yeah, unfortunatly that only goes so far
<spiv> (Although someone might in the future write a fancy tool to analyze the history later and use heuristics to track code moves across files, that doesn't exist yet.)
<flavour> http://paste.pocoo.org/show/166677/
<flavour> -lca made no difference to me unfortuantely...I tried it
<flavour> I know clearly which files should 'win'
<flavour> with only minor tweak
<flavour> But a lot of files
<flavour> Rest of the files reverted ok, but not this one
<spiv> flavour: that "input line too long" is a weird error, I assume there's something wacky happening with your shell of environment.
<spiv> s/of/or/
<flavour> Win32, so what do I expect? ;)
<spiv> flavour: I expect weird voodoo that I can't diagnose for you :)
<flavour> now getting it with just bzr ver
<flavour> Let me cycle the shell
<spiv> flavour: I'd suspect you have something that's growing an environment variable or alias every time you run 'bzr'
<flavour> yeah, that fixed it
<flavour> cmd window exhausted
<flavour> Looks good...am going to docuemnt this for future & try it on some other branches I have probs with - many thanks!
<michaelis> Hi. I could use some help organizing my project. Does anyone have some time to spare?
<michaelis> I only have a couple of questions and it will probably not take more than 5-10 minutes.
<Peng> michaelis: Someone might, but you'd have to ask your questions to find out. :P
<michaelis> I was thinking a private chat session but I can post my questions here.
<Peng> I, for one, don't know enough to want to talk one-on-one, but I might be able to contribute a little bit of you ask in the channel.
<rubbs> Peng: is correct... usually it's best to ask the group. that way different people can weigh in and help out with your problems
<rubbs> if you're worried about hogging the channel... don't worry, it's usually not that busy.
<Peng> Besides, that's what the channel is for.
<vila> spiv: I'm not sure I understand the meaning of "That's very much for the extra review.", is it "you're asking too much" or "you reviewed a lot" ?
<vila> spiv: or yet another meaning ? ;)
<michaelis> I work in a municipality with water distribution/cleaning and we have many files that we would like to version control. It's everything from simple text documents, pdf's to PLC programs. Since there are many facilities and every facility has its own set of documents, every facility, according to me, is organized as a shared repository. Thereafter every specific set of directory, such as e.g....
<michaelis> ...PLC programs, are organized as a shared repository beneath the previous one. Finally, every PLC program in the facility is a branch with a working tree. Could this work?
<michaelis> The most simple thing would be if you could checkout only part of a working tree but since this isn't possible I have to come up with something else.
 * rubbs goes and gets some pen an paper.
<rubbs> I am too visuall of a person... I have to draw that out.
<rubbs> just a sec.
<bialix> michaelis: what is the question?
<bialix> many nested repos with branches?
<bialix> yes, this will works
<bialix> but what your intent?
<michaelis> How should I organize it in the most convenient way.
<bialix> it depends
<bialix> convenient for what?
<rubbs> michaelis: is this what you are thinking?
<rubbs> http://paste.ubuntu.com/358487/
<bialix> do you want to combine several branches as the complex project?
<rubbs> michaelis: I think that's what he means... each Facility is a project of several branches
<rubbs> er
<rubbs> bialix: ^
<michaelis> Thats right.
<bialix> makes sense for me, rubbs
<rubbs> ok, so you may be looking for the SCM plugin.
<bialix> michaelis: where is your branches there?
<michaelis> Since I can't checkout parts of wokring tree I have to make every specific part of the facility a branch.
<bialix> scmproj plugin
<rubbs> michaelis: that's correct. you'd have to made each part a branch.
<bialix> michaelis: that's right, dvcs require you to think in the term of entire tree, not subdirectories
<michaelis> Another thing, I run bzr in a windows environment with the gui explorer.
<bialix> michaelis: TortoiseBzr or bzr-explorer?
<michaelis> Bzr-explorer.
<bialix> both are ok
<rubbs> mmm... bialix you run the scmproj right? I'm not sure how that works with guis
<rubbs> ah... cool
<bialix> if you will want to use scmproj you need to make some operations via console or qrun dialog
<bialix> rubbs: there is no GUI for scmproj yet
<michaelis> I myself am not afraid of running the shell version but it has to manageable by others.
<bialix> michaelis: bzr-explorer has feature of open the directory with nested branches as some sort of the project
<michaelis> But the others will mostly checkout and commit. Can I the use scmproj?
<bialix> so if you open fac1 or fac2 you should see all nested branches
<bialix> if others will work only in separate branches then scmproj will be mostly transparent for you
<michaelis> bialix: Exactly. Now when they open fac1 they see yet another shared rep with e.g. blue prints and below that there are a set of branches for every device in that fac.
<bialix> scmproj may help you to define directory structure for your branches (I calling them components in scmproj) and easily get entire project from the server for local work
<bialix> also you can commit several branches at once, or push changes of the project back to the server
<bialix> so only 1st step (get project for local work) is important. After that your colleges may work in separate branches
<michaelis> My colleges main interest is to checkout one branch at a time, make modifications to it, and then commit the changes.
<michaelis> There hardly will be any multibranching work going on.
<bialix> if so then do you need a requirement to recreate the structure from http://paste.ubuntu.com/358487/ somewhere locally?
<bialix> or you just need to select the way how to keep your branches on the server?
<michaelis> The structure must be on the server. How my colleges organize it locally is not my problem.
<bialix> then you can keep all related branches (PLC programs, text, pdf) in the separate shared repositories with branches for each facility
<bialix> is it enough for you?
<michaelis> Yes.
<bialix> then you don't scmproj at all
<bialix> don't need
<michaelis> But if you look in http://paste.ubuntu.com/358487/ then fac1 and PLC are shared rep according to me. PLC_prog1 and PLC_prog2 are branches.
<michaelis> They have to be able to checkout PLC_prog1 and PLC_prog2 seperatly.
<bialix> you said you don't need this structure on the server
<michaelis> seperatly =  separately
<michaelis> I obviously misunderstood you.
<bialix> you don't need fac1 and fac2
<bialix> You need only PLC - shared repo, PLC_prog1 and prog2 as branches
<bialix> docs -shared repo, and nested branches
<bialix> and so on
<bialix> remove from the picture work and fac1
<bialix> remove them as levels
<bialix> and you'll see both fac1 and fac2 are the same
<michaelis> I misunderstood you. Since there are more than 200 fac here I need them to be represented as shared rep.
<bialix> you're on the road to troubles
<bialix> does your fac have something in the common?
<michaelis> Otherwise every branch will be called fac1 - plc_prog1, fac2 - plc_prog1 and so on. There will be more than a thousand branches in the explorer window.
<michaelis> They all lie in the same country... ;D
<bialix> I suggest you keep fac1 as one unite branch then
<rubbs> michaelis: you could still do this... but nesting shared repos isn't going to help you much (I think)
<michaelis> That was the idea from the beginning and my question was if there was any other way than having fac1 as a shared rep.
<bialix> no
<bialix> fac1 should be a branch
<rubbs> you could do a shared repo at the PLC/docs/txt levels, but adding another at the fac level isn't going to help you much
<michaelis> Indeed.
<bialix> you won't checkout the subdir of that branch, but that's better than thousands of branches
<rubbs> but if he has lots of stuff within each fac# then a big branch isn't really helpful either
<michaelis> I have to take a 15 min tea break and talk to my colleges. I'll be back in 15.
<michaelis> Thanks for the help so far.
<rubbs> k... I'll brainstorm a little
<bialix> the views maybe help?
<rubbs> mmm... maybe. I"m wondering if pulling all that history down is going to be a problem.
<bialix> if there is local network it won;t be a main problem
<rubbs> does bzr know if a shared repo is a few dirs up? I guess I'm asking because if he creates a shared repo at /work and has folders for each facility, then he could have branches
<rubbs> bialix: I think he said it was all over the country.
<Peng> rubbs: Bazaar looks all the way up to the root for shared repos, and uses the first it finds.
<rubbs> cool... so what if he put just one shared repo at the top of his dir structure and divided his branches out the way he wanted
<rubbs> the fac# level directories don't have to be branches themselves, they are just there for organization right?
 * rubbs forgot that michaelis is on break.
<rubbs> My guess is that nesting a shared repos isn't going to save you room. i.e. a shared repo doesn't look to see if there is a shared repo above it.
<michaelis> I'm back.
<michaelis> That was a long 15 minutes.
<rubbs> ha... it happens
<rubbs> so my question is (since nesting shared-repo's isn't going to help) is there something wrong with having a shared repo at the top, and having the fac1 and PLC directories as just directories? That way you could have the projects in their own branches and use the dir structure to organize them
<michaelis> The problem is that when a college want's to check out blue prints for a specific object and and I want to check out a PLC-program we both end up checking out the same branch even tough this shouldn't be necessary.
<michaelis> Or maybe I didn't understand you.
<michaelis> The way I see it it will have to be: fac1 - shared rep, blueprints in fac1 - shared repo, an object specific blueprint in blueprints in fac1 - branch, so that there's only the possibility of checking out blueprints concerning one object at a time.
<rubbs> right...
<rubbs> let me illustrate what I mean...
 * rubbs goes to pastebin again... just a sec.
<rubbs> http://paste.ubuntu.com/358522/
<rubbs> a little messy, but I think that should show what I meant..
<rubbs> if you wanted to check out a txt doc from fac1 and a college wanted to checkout plc_2 from fac1 those would be separate branches
<rubbs> but to you, they would be organized by fac
<rubbs> there is no need to have a shared repo at each dir level. that wouldn't save you any space.
<michaelis> That is a good idea.
<rubbs> bzr also keeps all individual information that is different in it's own branch, so you would get all the space saving of the shared repo but the flexibility of differing projects
<michaelis> How would this look like in bzr-explorer.
<rubbs> bzr-explorer would not know the dir structure intelligently. It would only know about each individual branch at a time.
<rubbs> but each branch could be kept in it's own tab.
<rubbs> so bzr-explorer would only know about /work/fac1/PLC/plc1 but won't know anything about /work/fac1/PLC/plc2 unless you opened a tab to that location.
<michaelis> I don't see how I can omit the "thousand branches in explorer" problem.
<rubbs> do you need to have them all open all the time?
<michaelis> First I create a shared repo "work".
<rubbs> right
<michaelis> Then I create a branch at location work/fac1/blueprints/object_blueprint
<rubbs> right
<michaelis> So that object_blueprint has it's own work tree.
<rubbs> correct.
<rubbs> the idea of the shared repo isn't like a repo in svn. It's just a place that common revisions can be stored to save space...
<michaelis> But if I have 200 fac and 5 subdirs in each fac then I will have 1000 branches in a non hierarchical structure, or have I misunderstood something here?
<rubbs> You would have have some sort of heirarchy, but it would be via the system's directories.
<michaelis> I understand.
<rubbs> so to check out any branch, I would just have to know the dir structure.
<michaelis> That was my main concern. How to present the branches in a well structured order.
<rubbs> as far as bzr is concerned, it doesn't care where the branch is, so you can organize your branches in any dir structure you want. You just have to point bzr to the branches location, and it will work
<michaelis> I could create a shared repo for every fac and by doing so my colleges would, naturally, work with one fac at a time.
<rubbs> are you looking at a centralized workflow then? like having only checkouts and not branches?
<michaelis> Yes I had figured that out but I was hoping to not have thousands of branches in the bzr-explorer.
<michaelis> Explain the concept of centralized workflow to me.
<michaelis> The files on the server should be the latest ones and if you want to make any changes you check them out, modify them, and then commit them to the server again. That is the workflow I had in mind.
<michaelis> So yes, some sort of centralized workflow is needed.
<rubbs> so like svn, centralized workflows usually mean that I'm only working with one revision on the tree. I "checkout" code and work on it and when I commit, it gets sent to that central location. It's sometimes called lock-step development. De-centralized -hybrid approach would be that there is a central branch, but I have my own branch. I do my work in my branch and when I'm ready to I merge in my changes (I can do several commits before merging)
<rubbs> you were looking at a central -lock-step development workflow then.
<michaelis> Yes it seems so.
<rubbs> bzr is really designed for branching (whole history, not just one revision) and working on the branch. Then when you want, you merge your changes back into the central location.
<rubbs> if I have a branc, and you have a branch, and we both work on the same project we can merge our changes...
<rubbs> it allows for more concurrent development
<rubbs> I can work on fac1 and you can too
<rubbs> I merge my changes in..
<rubbs> then when you are ready you can merge yours in.
<michaelis> I see. But what happens if we work on the same dwg file?
<rubbs> the beauty of it is that with the merge, we both can work on it, and not have to worry about being "out of date" every time we commit
<rubbs> that is where some intelligent merging is needed.
<rubbs> so bzr will look and see that you and I worked on the same file
<rubbs> it will then tell you that there was a conflict and ask you to resolve them.
<rubbs> (this assumes I merged first)
<rubbs> you then look at the dwg file and see what the differences were.
<michaelis> Naturally. Then we would have to solve the conflict "manually".
<rubbs> right
<rubbs> this is the same with just about any VCS thought
<rubbs> though*
<rubbs> All of this stuff is possible with SVN or others, but bzr, git, and mercurial are best at merging.
<rubbs> It's the merging that allows for people to work at the same time on the same project.
<rubbs> if you have your 1000's of branches organized it shouldn't matter who is using what
<michaelis> No of course not.
<rubbs> just merge in and manually take care of conflicts as they come up
<rubbs> To present your branch structure (organization) to your colleages, you would just have to let them know the dir structur
<rubbs> structure*
<michaelis> I get the point. But it would be much easier if we could check out parts of a working tree instead of having to check out a whole branch.
<rubbs> then I would look at something like SVN. bzr won't be able to do that for you :(
<michaelis> But that isn't posibble.
<michaelis> I understand.
<rubbs> I'm not sure if this helps, but bzr also uses views
<rubbs> so you would have all of your branch there, but with views it masks away things you don't care about.
<michaelis> That sounds interesting.
<rubbs> so if you had the branches at the fac level, then you could create a view that hides everything except the PLC directory or something to that effect
<michaelis> I wonder if it is possible to set views up in the bzr-explorer.
<rubbs> I'm almost certain you can. I'd have to check.
<rubbs> just a sec.
<rubbs> also if igc is on, he's the main dev on bzr-explorer
<rubbs> ping igc
<michaelis> He is away.
<rubbs> ah... thanks
<rubbs> mmm... doesn't seem to have a gui button for doing it, but I could be wrong.
<rubbs> I'm not giving up on that yet though.
<michaelis> You keep on fighting! ;D
<rubbs> ha
<rubbs> well, I know that if you created the view, that bzr-explorer would support it. So if you masked off everything except PLC dir it would only show PLC in explorer, but I'm unsure of how to set it.
<rubbs> it might have to be in a command line argument... but I think you can even do those within bzr-explorer
<michaelis> I see.
<michaelis> I have learned a lot and I will take this newly achieved knowledge and make the best of it. Thanks for the help.
<rubbs> np.
<michaelis> I'll come back for more talk about views.
<rubbs> i don't know if youw ant, but you could email igc he could help much more with bz-rexplorer
<rubbs> great!
<michaelis> Maybe I'll do so.
<rubbs> do you know igc's email?
<michaelis> I thought I would get it from a simple whois but that was not the case.
<rubbs> ian.clatworthy@canonical.com
<michaelis> Do you have it?
<rubbs> he should be able to help ^
<michaelis> Thank you.
<michaelis> Thanks again and bye for now.
<rubbs> bye, good luck!
<michaelis> Thank you.
<aquarius> I have a branch of the trunk of a project. At some point in the past, a change was introduced that broke another project that uses this one. What I want to do is: run the main project test suite; if the tests fail, step back one bzr revision in the subproject, repeat.
<aquarius> how do I do the "step back one revision" bit? :)
<tumbleweed> bzr uncommit?
<tumbleweed> (you'll have to follow it with a bzr revert)
<rubbs> you could also branch at a revision
<aquarius> ooh, so just "bzr uncommit; bzr revert",repeatedly. That's ideal.
<rubbs> also you could look at the bzr-bisect plugin
<rubbs> it's built to do just exactly what you are looking for
<aquarius> rubbs, I could do, yeah, but I don't know which revision has the problem, and looking up all the revnos is fiddly
<rubbs> bzr bisect is supposed to emulate the git bisect functionatility
<rubbs> aquarius: it's automatic
<aquarius> I assumed it was. I don't really understand git bisect :)
<Peng> You don't have to uncommit if you only want to revert the working tree...
<aquarius> rubbs, how is it automatic?
<Peng> Even without a bisect plugin, it's easy to do a binary search yourself.
<aquarius> rubbs, I just do bzr branch lp:project the-revision-that-broke-it and it works? :)
<rubbs> at least I think it's automatic... the git version is.
<rubbs> you write a short script to run your test... have it return 0 if works and 1 if doesn't
<aquarius> peng, hang on, not sure I understood that
<rubbs> it will go through your history in a binary search and find the revision in which it changed
<rubbs> admittely I didn't do it auto matically with bzr. just manually (I didn't have a lot of history)
<rubbs> aquarius: he means find any revision that is working (liek the first one) and find one that isn't (like the last one)
<aquarius> man, I'm prepared to do it the stupid drone way rather than anything clever ;)
<rubbs> then pick the revision that is in the middle of the two, and do the test
<tumbleweed> aquarius: http://doc.bazaar.canonical.com/plugins/en/bisect-plugin.html
<rubbs> if it doesn't work, it's in between the first and the middleone.
<aquarius> yeah, I get roughly how a bisect works
<aquarius> but there are only, like, nine revisions I need to check. This is not the kernel we're talking about here ;)
<tumbleweed> heh
<rubbs> even then. a bisect is still faster.
<aquarius> I shall bzr uncommit && bzr revert my way backwards until I work it out
<rubbs> you can say.. revision 12 is good, revision 19 is bad
<aquarius> not when you take into account that I have to work out how to do it :)
<rubbs> it can help you find it quicly
<Peng> You don't need to uncommit. Just "bzr revert -r 123".
<rubbs> aquarius: fair enough. Peng is correct, you can just revert your tree, no need to uncommit
<Peng> Doing a manual binary search is really easy. If you know it's between revisions 10 and 20, revert to 15, run the test. If it succeeds, revert to 17 and try again, ...
<aquarius> yep, and that's now precisely what I'm doing :)
<aquarius> thanks!
<rubbs> np.
<lornajane> can someone help me?  I'm just starting to use bzr and I'm confused!  I have changed a few files, but I don't want to commit all of them
<lornajane> how can I tell bzr which files should be in this commit?
<rubbs> lornajane: you can do a few things. You can do a commit and list the files.
<rubbs> so like if you have file1 file2 and file3 and you only want to commit the first two you can do this
<rubbs> bzr commit file1 file2
<lornajane> rubbs: that's how I would do it with svn - but it complained that I also have files that aren't added
<lornajane> surely that's my problem, not bzr's problem? :)
<rubbs> have you created new files in this revision?
<rubbs> or possibly moved one of the files?
<lornajane> rubbs: I have created new files in my working copy and not added them yet, I don't need to include them in this commit
<lornajane> I guess I can just add them though
<rubbs> lornajane: no
<rubbs> do'nt add them
<rubbs> you can shelve them
<rubbs> so do this: bzr shelve name_of_files
<rubbs> that will "stash them away" then do your commit... then do a bzr unshelve and they come back
<lornajane> oh, that's cool!
<lornajane> I should do that with my config files
<rubbs> I love it... use it more than I care to admit
<lornajane> stuff like this is why I need to get out of my svn rut :)
<rubbs> alternatively, if you know you're never going to want to commit them, you can add them to your ignore config (bzr ignore name_of_file)
<rubbs> also to learn more about shelve (really cool feature IMO) just run bzr help shelve and that will tell you everything you need to know!
<lornajane> yes, I have bonded with bzr help - using bzr-svn because I travel so much with dodgy connection (on the train, for example) and the help has been surprisingly helpful
<lornajane> and the command naming is close enough to subversion that I can find things
<rubbs> yeah... when I don't know what to search on, I just do bzr help topics and I usually find what I need
<gerard_> anyone working on bug #395514 ? ( https://bugs.launchpad.net/bzr/+bug/395514 )
<ubottu> Ubuntu bug 395514 in bzr "bzr update with local updates and commits does an unexpected merge" [High,Confirmed]
<ubottu> Launchpad bug 395514 in bzr "bzr update with local updates and commits does an unexpected merge" [High,Confirmed] https://launchpad.net/bugs/395514
<gerard_> ah, good bot
<alamati> Hi all
<alamati> my native lang is not english, sorry
<alamati> I have problem with bzr
<rubbs> what is your problem?
<alamati> when I enter: bzr pull
<alamati> alamati@ThinkPad:~/Desktop/transmission$ bzr pull
<alamati> Using saved parent location: bzr+ssh://bazaar.launchpad.net/~vcs-imports/transmission/trunk/
<alamati> No revisions to pull.
<alamati> I got that message
<alamati> but I sure that there are new codes
<Peng> What's the problem?
<Peng> Oh. :D
<rubbs> can you tell me what the output of bzr revno is?
<Peng> alamati: How do you know there are new revisions?
<alamati> alamati@ThinkPad:~/Projects/transmission$ bzr revno
<alamati> 8457
<alamati> bzr missing
<rubbs> he's right, his tree is out of date
<alamati> how I can update?
<rubbs> trunk is at 8465
<alamati> yes yes
<Peng> alamati: Try running "bzr update"
<Peng> It *probably* won't do any damage. :D
<alamati> alamati@ThinkPad:~/Projects/transmission$ bzr update
<alamati> Tree is up to date at revision 8457.
<alamati> I trust you :D
<alamati> humm
<rubbs> does bzr status say anything?
<alamati> no
<idnar> alamati: I notice you changed from ~/Desktop/transmission to ~/Projects/transmission there
<idnar> did you move the directory, or do you have two of them?
<alamati> exactly right
 * rubbs will be right back.
<alamati> I move the directory
<idnar> okay
<alamati> what do I do?
<idnar> I'm not sure what the problem is, hopefully somebody else will have an idea
<alamati> thanks
<Peng> alamati: Just to be sure, does "bzr info" say it's a standalone or repository branch?
<rubbs> alamati: did you just want to make this branch be *exactly* like the one at bzr+ssh://bazaar.launchpad.net/~vcs-imports/transmission/trunk/?
<rubbs> oh, do what Peng says first
<alamati> I did
<alamati> alamati@ThinkPad:~/Projects/transmission$ bzr update
<alamati> Tree is up to date at revision 8457.
<rubbs> no do bzr info
<alamati> yes I want to make this branch similar at official repo
<rubbs> that tells us things about the branch you have, not if it's up to date
<alamati> alamati@ThinkPad:~/Projects/transmission$ bzr info
<alamati> Standalone tree (format: unnamed)
<rubbs> if we can't find out what is wrong from bzr info, then I can tell you how to make it work.
<alamati> Location:
<alamati>   branch root: .
<alamati> Related branches:
<alamati>     push branch: bzr+ssh://bazaar.launchpad.net/~vcs-imports/transmission/trunk/
<alamati>   parent branch: bzr+ssh://bazaar.launchpad.net/~vcs-imports/transmission/trunk/
<alamati> alamati@ThinkPad:~/Projects/transmission$
<rubbs> alamati: I can't seem to find out what is wrong with it, so we are going to try to overwrite the branch and pull the lastest from bzr... so do this: bzr pull --overwrite
<rubbs> this will make it *exactly* like it is on launchpad.
<Peng> Worst case, you can at least make a new temporary branch to work in: cd ~/Projects; bzr branch transmission transmission2; cd transmission2; bzr pull --remember lp:transmission
<alamati> Oh woow
<rubbs> but then his tree still wouldn't reflect the trunk
<alamati> I can upgrade to latest revision
<rubbs> so you figured it out? you solved your problem?
<alamati> you solved my problem
<alamati> really thanks
<alamati> ;)
<Peng> We did?
<alamati> bzr pull --overwrite
<rubbs> Peng: I think the overwrite worked
<rubbs> alamati: I'm glad something worked out for you!
<alamati> this command solve
<Peng> Oh, interesting. Well, I'm glad it worked. :)
<rubbs> I still don't know why that was necessary, but we got him to where he needed to be
<rubbs> alamati: glad to hear everything worked out
<alamati> thanks rubbs & Peng
<alamati> I think that bzr is more complicated that svn
<rubbs> alamati: it can be for a while, but once you get the hang of it, it gets better
<alamati> and I don't understand why we first commit and then push
<rubbs> just keep practicing ;)
<maxb> I'd replace "more complicated" with "different underlying paradigm"
<rubbs> alamati: that is because you can then do multiple commits before you push.
<alamati> of course
<rubbs> alamati: it takes a little while to understand it. It took me a while.
<Peng> It's also so you don't have to be online to commit.
<Peng> Which doesn't sound important until your Internet connection goes down or you're on a plane. :D
<alamati> yes, this is nice situation
<intellectronica> jml: around? know anything about bzr builder recipes?
<bialix> hi GaryvdM
<GaryvdM> Hi bialix
<bialix> how are you?
<bialix> do you have any plans re qbzr 0.18?
<GaryvdM> Good, you?
<bialix> more or less
<GaryvdM> I
<bialix> I can wait with release till morning
<bialix> please, don't disconnect
<GaryvdM> My typing slow
 * bialix fears your internet
<GaryvdM> I working on major features (find in annotate and diff, diff refactoring.)  But I have shelved those.
<GaryvdM> *I was
<bialix> ok, I understand
<bialix> we need to decide what will be our policy re Lucid
<bialix> we made very good with 0.14 and Karmic
<bialix> I'd like us to continue our success
<GaryvdM> I'm now just trying to fix bugs
<bialix> I've stumbled with code layout refactoring
<bialix> it affects explorer
<bialix> and I'm not sure about TBZR
<GaryvdM> Yes - I think that 0.18 should become a stable branch, like 0.14
<GaryvdM> I want to look at:
<GaryvdM> bug 487115
<ubottu> Launchpad bug 487115 in qbzr "qcommit: qt warning message in the console when files grouped into directory" [High,Confirmed] https://launchpad.net/bugs/487115
<bialix> oh, yes
<bialix> this is very nasty
<bialix> did you read my comments?
<GaryvdM> yes
<bialix> it's 100% repeatable, I just don't know where to start
<GaryvdM> bug 505987
<ubottu> Launchpad bug 505987 in qbzr "show_file_differences in Annotate history pane crashes" [Undecided,New] https://launchpad.net/bugs/505987
<GaryvdM> Ok - going to reboot into windows to look at 487115
<GaryvdM> bialix: cool - I can reproduce it.
<gerard_> guys, how about this test for bug #395514? http://pastebin.ca/1756446
<ubottu> Launchpad bug 395514 in bzr "bzr update with local updates and commits does an unexpected merge" [High,Confirmed] https://launchpad.net/bugs/395514
<lifeless> mtaylor: yo
<mtaylor> lifeless: yo. just uploaded
<mtaylor> lifeless: and... tested the install and stuff :)
<gerard_> how do I check if local commits are present?
<gerard_> also, please look at my patch: http://pastebin.ca/1756446
<lifeless> mtaylor: 0.9.8 ?
<lifeless> ?
<mtaylor> lifeless: yup
<mtaylor> lifeless: well, 0.98
<mtaylor> lifeless: but yeah
<lifeless> gerard_: sorry, I'm at a conference, can't really look at the patch for you. hopefully someone else will do so today sometime
<gerard_> that's allright
<gerard_> I'll attach it to the bug report if nobody does ;)
<lifeless> mtaylor: looks a it better. seems wasteful for the pandora configure to do c compiler checks etc
<mwhudson> james_w: ping
<bialix> GaryvdM: gnight
<lifeless> james_w: bug 509325
<ubottu> Launchpad bug 509325 in bzr "merge & tree shape alteration hook for packaging" [Undecided,New] https://launchpad.net/bugs/509325
<james_w> hi mwhudson
<MTecknology> I made a change to some code, the code was changed in that time but there's shouldn't be any issues with that
<MTecknology> how can I resolve this?
<mwhudson> james_w: can i get your help to come up with a good example of a bzr builder recipe?
<james_w> sure
<mwhudson> i can't find any packaging branches that just have the contents of the debian directory in them
<mwhudson> lots of branches that just contain a debian directory, but i don't think they work with builder :/
<mwhudson> james_w: btw "nest foo lp:bar ." fails in a surprising way
<mwhudson> (i didn't expect it to work, really, but it tries to lock . twice)
<james_w> look under lp:~ubuntu-desktop
<mwhudson> james_w: for example, http://bazaar.launchpad.net/~ubuntu-desktop/notify-osd/ubuntu/files looks like a branch to use with merge, not nest
<mwhudson> james_w: also http://bazaar.launchpad.net/~ubuntu-desktop/gedit/ubuntu/files etc
<james_w> ah yeah, those won't work
<james_w> sorry, I mis-remembered
<james_w> do you have to show nest for packaging?
<mwhudson> i guess not
<james_w> I can find one that would work, but they are rare
<mwhudson> i guess i'll use merge then
<james_w> note that you can't merge e.g. gedit either, as they don't share revision history
<mwhudson> right :/
<mwhudson> i can do bzr-git maybe
<mwhudson> james_w: so, for this recipe: http://pastebin.ubuntu.com/358692/
<mwhudson> james_w: to build the tree, it seems i want to do something like "bzr dailydeb --no-build example.recipe ."
<james_w> yes
<mwhudson> then cd into the built tree and run "bzr builddeb -S --native"
<mwhudson> then cd ../build-area and say "see, look! a source package"
<james_w> yes
<mwhudson> cool
<mwhudson> sigh, time to think about buying a new laptop battery
<james_w> note that your deb-version should have 0.4.2+ or something at the start
<lifeless-droid> Buy with the laptop:)
<james_w> otherwise the version number will be 239 or something, and it will take a long while for bzr-git to reach that version number
<mwhudson> james_w: ah yes, the one i'm actually using has been fixed like that
<james_w> cool
<mwhudson> (it references local paths)
<lifeless-droid> use the deb version macro?
<mwhudson> lifeless-droid: ah right
<mwhudson> james_w: "{debupstream}-{revno}+{revno:packaging}" ?
<mwhudson> i get confused about the rules wrt '-'
<james_w> that would work
<mwhudson> james_w: good enoguh
<mwhudson> 1~1 < 1 < 1+1 in debian version numbers?
<james_w> correct
<james_w> 1 < 1-1 < 1+1
<mwhudson> cool
<mwhudson> and the first (or is it last) '-' is special?
<mwhudson> but i guess for a native package like this "who cares"
<mwhudson> time for drinks
<RumblePure> How to write a new log-format that only prints commit-message?
<lifeless> RumblePure: have a look at one of the existing ones
<RumblePure> lifeless: None of them print _only the commit-message of a given revision.
<RumblePure> *_only_
<RumblePure> lifeless: I want to print the commit-message only, nothing else. This is for the purpose of a makefile.
<lifeless> RumblePure: sure, you can do that, you'll need to look at the existing ones code to see how to do it itis all
<RumblePure> lifeless: I've installed binary, you think the source code is there for log-formats? *non rethorical question* _)
<RumblePure> * :)
<lifeless> if you are on einwdows there is a zip file with all the source. Or you can look at plugins whic provide log formatters.
<RumblePure> lifeless: I'm on ubuntu, I looked for plugins for log formats but no success.
<rubbs> RumblePure: try this -> http://wiki.bazaar.canonical.com/BzrPlugins
<lifeless> 0http://wiki.bazaar.canonical.com/BzrPlugins
<lifeless> look for history exploration
<rubbs> you can install those plugins by putting them in your ~/.bazaar/plugins directory (you can create that dir if it doesn't exist)
<RumblePure> Haum, this might help: "Shows most recent commit messages "
<rubbs> try it, if it doesn't work, you may be able to hack it to your needs.
<NfNitLoop> Hrmm, odd bzr-svn issue.  I've committed a change locally.  Pushed it to my branch in svn.  and done a 'pull' from there.  But 'bzr log' still doesn't show the 'svn revno' like things below it.
<NfNitLoop> I've seen this before, but I thought doing a 'bzr pull' had fixed it.
<RumblePure> Thx guys, I'll try it.
<lifeless> mtaylor: please upgrade t o 2a for pandora-bild.kthnx
<mtaylor> lifeless: mordred@camelot:~/src/pandora-build$ bzr upgrade .
<mtaylor> bzr: ERROR: The branch format Meta directory format 1 is already at the most recent format.
<lifeless> mtaylor: ok cool
<mtaylor> :)
<lifeless> mtaylor: you don't need the .
<lifeless> like 'ls' we default to the current working directory
<mtaylor> cool
<lifeless> for everything except init-repo
<lifeless> james_w: ping
<lifeless> james_w: It would be nice if debrelease did mark-uploaded
<james_w> I'm not sure what the difference is between that and dch -r
<lifeless> debrelease uploads
<lifeless> e.g.
<lifeless> debrelease --dput ftp-master uploads the built package in .. with the current changelog version to ft-master
<james_w> well, dch -r does the tagging, so maybe that's the correct place for the d* tools
<lifeless> does dch -r do 'bzr mark-uploaded' at the moment ?
<james_w> yes
<lifeless> ok cool
<james_w> indirectly
<maxb> indirectly?
<doctormo> Odd problem with caling cmd_push from bzrlib's builtins... when it's being called from a process that's been run from a command line, it works, when it's called from a detached gui, it stalls, no response.
<doctormo> Any ideas?
<maxb> What's a detached gui?
<doctormo> maxb: Not being run from a command line
<maxb> Can you reproduce the problem in a simple script that imports bzrlib?
<doctormo> maxb: No
<doctormo> Perhaps it's some weird threading issue, I know that this code running through nautilus-python isn't just simple threads.
<Noldorin> hi
<Noldorin> i'm wondering: when i branch the main branch for a release (say, 0.1.0)...
<doctormo> It's the only command from bzrlib that I'm calling through builtins, everything else I'm calling direct calls because I'm doing custom things. So perhaps I shouldn't use the cmd_push command in this way?
<Noldorin> and i find bug fixes i want to make
<Noldorin> is it wise to merge across branches?
<Noldorin> i so, should it be from 0.1.0 to main or vice versa?
<NfNitLoop> Noldorin: merging across branches will work, but your history gets hard for a human to make much sense of. :p
<NfNitLoop> If you just want to merge into 0.1 and main, you can make your fix on 0.1 and merge into main.
<maxb> Noldorin: Because of the way DVCSes track history (all ancestry or none of it), it is best practice to make bugfixes in the earliest branch they apply to and merge them forwards
<NfNitLoop> if you have several branches ... yeah, do what maxb says.
<NfNitLoop> so you'd make a new "bugfix branch" at a "least common denominator" location that all of your destinations have in common... make your fix, then merge it into the 3 locations.
<maxb> You certainly can cherrypick from trunk to a release branch, but bzr won't give you any help in tracking what has been merged that way. You'll be at the mercy of reading commit messages.
<Noldorin> hmm
<NfNitLoop> s/3/N/ :p
<Noldorin> i see
<Noldorin> maxb, so merging bug fixes from a release branch to trunk is just about all i should do?
<Noldorin> (or even need to do)
<NfNitLoop> in this case, yep.
<Noldorin> NfNitLoop, bug fix branch...never heard of that
<Noldorin> ok
<NfNitLoop> Noldorin: It's a branch that contains [code from source X] plus a bugfix.
<NfNitLoop> makes it easy to merge in *just* The bugfix to several locations.
<NfNitLoop> but, if you're only fixing bugs on 1.0, then it's your bugfix branch. ;)
<NfNitLoop> er, 0.10
<Noldorin> NfNitLoop, that's a good point
<Noldorin> yeah, i feel any bugs that get fixed in trunk, should *never* be merged into existing branches
<Noldorin> only future releases
<maxb> Noldorin: Why do you feel that? What about a bug which is fixed on trunk and then discovered to affect an earlier series?
<Noldorin> maxb, if the early release is flawed, then so be it. it's the natuer of development
<Noldorin> if there's a newer release, why bother anyway?
<maxb> What if there isn't a newer release yet, and won't be for a couple of months?
<maxb> What if the old release series is one you've committed to long term support for?
<NfNitLoop> What if you have clients who refuse to upgrade a major revision because it involves data migrations?
<NfNitLoop> :p
<NfNitLoop> *cough*  Not that I've EVER seen that.
<maxb> heh. There's still some MySQL 4.0 running here
<fullermd> Then you pretend you're MySQL and just stick incompatible changes in the middle of a minor revision.  Duh.
<maxb> lol
<NfNitLoop> hehe.
<NfNitLoop> whoops.  /wc is window close, not /window change.
<NfNitLoop> IRCFAIL.
<maxb> yay irssi
<fullermd> Yeah, /wc's are for flushing.
 * kfogel is away: afk for some hours; see you antipodal people later probably
#bzr 2010-01-19
<lifeless> sssss
<litwol> Hello. Is there a way in bzr to find out what will be updated if i execue 'bzr update' command ? similar to 'svn status -u'
<spiv> litwol: hmm, not that I know of.  It probably ought to have a --dry-run or --preview option (like 'bzr commit' and 'bzr merge' do, respectively).
<spiv> litwol: file a bug?
<lifeless> hi poolie
<twisted_steel> what is the option to package all files from a repository into a tar.gz? I did it 6 months ago, but can't find it any more
<lifeless> bzr export foo.tar.gz
<twisted_steel> ahh, export.  thank you
<pattern> i interrupted bzr in the middle of a commit... is there a chance of its database getting corrupted?
<Peng> pattern: Perhaps if you're using an extremely old disk format. But otherwise no.
<pattern> cool
<pattern> thanks
<vila> spiv: ping
<vila> hi all ! :)
<Anteru> Hi
<gerard_> sooooooo
<gerard_> when is this bug going to be fixed? https://bugs.launchpad.net/bzr/+bug/113809
<ubottu> Ubuntu bug 113809 in bzr "update performs two merges" [High,Confirmed]
<gerard_> the attached patch looks good to me (though I have only little experience with the internal workings of bzr)
<gerard_> gogo bazaar devs
<gerard_> I love the rest of bazaar but this just plain sucks
<gerard_> that bug is a duplicate of a lot of other bugs btw
<gerard_> those really should be marked that way
<spiv> gerard_: huh, there's a patch that was partially approved that disappeared.
<spiv> gerard_: I just poked vila, the patch pilot this week, by email to suggest he take a look.
<gerard_> thx
<gerard_> my boss already finds bazaar a little scary, no need to keep bugs like this around
<vila> spiv, gerard_ : I'll have a look at it but it seems to require more work, it was reviewed 'Needs_fixing' not 'Approved'
<vila> spiv: are you around or not really ?
<gerard_> vila: is there any reason noted why it needs fixing?
<vila> https://code.edge.launchpad.net/~craighewetson/bzr/update_with_local_commit/+merge/10320
<spiv> vila: not really, but I may glance at IRC from time to time...
<vila> spiv: ok, how about a few questions of the per-file merge hook ? There are two points that compromise the landing: 1) repeated access to the config, 2) license for the cachedproperty
<vila> spiv: you're away until thursfay (at least) right ?
<vila> surfday, yes, *Thursday* damn it
<gerard_> vila: ah, so it needs some minor changes?
<gerard_> I could make those later this week
<gerard_> I've already written a testcase for it anyway
<gerard_> I think I also have a better error message
<vila> gerard_: good, I'll look into it then, the weird thing is that the merge proposal is marked as 'Merged'...
<spiv> vila: for 1, make the plugin store it on the hook params, e.g. "val = getattr(params, 'news_merge_files, None); if val is None: ..."
<spiv> vila: for 2, someone needs to ask an LP person about it
<spiv> vila: it's not "crown jewels" code so I doubt there will be any issue, but it might take time to find the right person and get them to say "ok".
<vila> spiv: 1) ! of course, I thought about caching it but didn't think about letting the plugin do it
<vila> 2) But why do you think your first version was bogus ? I didn't *test* it properly but..
<spiv> vila: probably flacoste or maybe even ask jml
<spiv> vila: the cache was global, not per instance
<vila> global ? A local variable ? What makes you think so ?
<spiv> (Two different definitions that used @cachedproperty would have their own cache, but not two instances of a class)
<vila> ha, yes
<vila> hmm, still, I preferred your lighter version :-/
<spiv> vila: try "class C(object): def __init__(self, x): self.x = x; @cachedproperty; def y(self): return x**2", then "print C(1).y, C(2).y"
<spiv> vila: so, FWIW, I read through the LP version and I think it's good and correct
<spiv> vila: and as short as it can reasonably be while being as featureful and clear as it is.
<vila> spiv: ok, I'll look into it and try to get an approval for the additional diff (time to use that pre-requisite parameter again :)
<vila> gerard_: weirder, it seems that the original branch has been replaced with bzr.dev, lp shows an *empty* diff so I don't even know where the code is right now, I'll ping craig in the mp about it
<gerard_> vila: :o
<vila> gerard_: That's the first time I see such a weird thing...
<cjwatson> so, the new 'bzr rebase-foreign' command sounds like exactly what I've been after for a while.  However, when I run it (in a checkout of lp:~ubuntu-cdimage/debian-cd/ubuntu, with NEW_BASE pointing to a checkout of lp:debian-cd) it just says "Nothing to do."  Am I doing something wrong?
<cjwatson> is it possible that bzr-rewrite can only deal with branches imported using things like bzr-svn, not cscvs?
<cjwatson> I wouldn't mind (all that much) having to generate a map for it matching up old and new revision ids, if I knew how ...
<swathanthran> can i some how know how much data i would be downloading, before doing a bzr update?
 * swathanthran wanted to update his emacs trunk.
<maxb> swathanthran: I don't think such support exists.
<vila> cjwatson: I don't think there are constraints on the branches except for some common ancestry and the fact that the revisions you want to rebase are not already part of the branch you're targetting, but I confess no experience with rebase-foreign
<maxb> cjwatson: I think the problem is that your branches don't match one of the preexisting matcher algorithms written into the plugin. Some custom hackery is probably needed. Especially as there seems to be an off-by-one relationship in revision numbers and arch patch-X numbers between the two branches.
<cjwatson> maxb: indeed, base-0 would translate to r1 in bzr-speak, patch-1 to r2, etc.
<maxb> Not quite what I meant - both of your branches have arch-derived revids, but base-0 in one is patch-1 in the other
<Morbus> g'day, i'm trying to tweak the bzr emailer.py to get the branch nick into the subject line.
<Morbus> so, since branch is added to self in the init, i was hoping to add self.branch to the subject() function.
<Morbus> but, i'm not sure how to get the branch *nick* - i'm not a python coder.
<Morbus> is it just magically branch.nick? ;)
<Morbus> self.branch.nick, rather.
<maxb> try it and see? (I think it is)
<Morbus> yeah, i had just tried it, but intro'd a syntax error somewhere else and panicked ;)
 * Morbus is trying again.
<vila> it is, but where did you find an emailer.py ?
<Morbus> bzr: ERROR: Server sent an unexpected error: ('error', 'not all arguments converted during string formatting')
<Morbus> https://launchpad.net/bzr-email/trunk
<Morbus> also linked from the bzr plugin handbook guide thingy.
<vila> yeah the plugin, found it fater asking ;)
<vila> err, after
<Morbus>    def subject(self):
<Morbus>         return ("[bzr] [%s] r%d - %s" %
<Morbus>                 (self.branch.nick,
<Morbus>                  self.revno,
<Morbus> is the start of my revised subject line.
<Morbus> and is giving the above error.
<Morbus> on commit.
<vila> the error means that you have more arguments than mentioned in the format,
<Morbus> ah, tht's true.
<vila> Use paste.ubuntu.com instead of pasting here
<Morbus> i left the url in cos i didn't want to delete it.
<Morbus> thought extra args would just be ignored.
<vila> Morbus: ha, coming from C ? ;-)
<Morbus> nah, php/perl.
<Morbus> i don't even know if it works over there, honestly ;)
<Morbus> welp, no errors that time.
<Morbus> now just have to wait for the email.
<Morbus> :D
<vila> Morbus: congratulations !
<Morbus> i'm surprised emailer isn't being regularly updated.
<vila> Morbus: bzr core is, I'm pretty sure almost all of emailer.py should be deprecated and use the core version instead but nobody found the time to do that so far
<Morbus> vila: wait, there's a core version?
<Morbus> since when?
<Morbus> i just set this up a few months ago.
<vila> Morbus: well, smtp_connection is part of core, I'm sure about that. There are certainly features of bzr-email that are not, I just don't know exactly which
<maxb> cjwatson: I hacked it to guess the relationship between your revids, and it rebased 395 revisions, but then it exploded with an AssertionError when it first hit a merge in the ubuntu branch. I'm afraid I'm out of time to look at it today. :-/
<Morbus> vila: ah.
<Morbus> email came through. self.branch.nick works fine. thanks much.
<cjwatson> maxb: *nod*, thanks for looking
<swathanthran> ok.. i used http://bzr.savannah.gnu.org/r/emacs/trunk/ to do the initial checkout last week.. now it looks like that trunk is blank but latest revision is seen on lp how can i change the url of bzr update?
<cjwatson> swathanthran: you mean blank as seen in a web browser?
<vila> swathanthran: what does 'bzr  log -l5 http://bzr.savannah.gnu.org/r/emacs/trunk' says ?
<swathanthran> when i do bzr update it says uptodate upto revision 99318. but launchpad has it up to 99375
<swathanthran> bzr log -l5 shows only upto 2010-01-13
<vila> swathanthran: so the trunk is not blank, good.
<vila> Now you have to decide which branch you want to track. Is the lp one supposed to be a mirror of the savannah one ?
<swathanthran> oh sorry i forgot to add the link:)
<rubbs> swathanthran: do you have a branch or checkout?
<swathanthran> ok.. i have a checkout of trunk and i want to update trunk..
<swathanthran> bzr log -l5 http://bzr.savannah.gnu.org/r/emacs/trunk shows it upto 19 itself.. so the branch don't have a problem..
<swathanthran> terribly sorry i have to go out now..
<rubbs> oh. ok. I'll keep thinking
<lornajane> apparently my branches have diverged.  That doesn't sound good to me
<vila> lornajane: 'bzr missing' should display the differences
<rubbs> diverged branches mean that you have a branch and someone else has a branch and that you both want to push to the tree. The other person(s) have already pushed
<rubbs> you have to do a merge to make yours work
<lornajane> yes, I've been offline for a few days
<lornajane> I have a lot of local commits and the rest of the team have been working too
<lornajane> this is exactly why I use bzr-svn :)
<lornajane> its just that I've only just started and I'm confused.  Your explanation doesn't sound like its broken though, so I'll try the missing thing and see what happens
<lornajane> The bzr error message about the diverged branches was very friendly and helpful
<rubbs> good to hear.
<rubbs> lornajane: http://doc.bazaar.canonical.com/bzr.2.0/en/tutorials/tutorial.html?#merging-from-related-branches that might help a little too
<lornajane> rubbs: thanks!  I'll look
<rubbs> np
<lornajane> I expected it to just update and either merge it or conflict
<rubbs> bzr tries to do the safest thing when possible. It wants you to merge it explicitly because a merge in the background could throw some things off.
<rubbs> it's safer to just tell you that the branches are now diverged and let you know that you have to merge them.
<toytoy> guys, anyone have successfully installed bazaar in eclipse?
<toytoy> rubbs, are you talking to me?
<lornajane> rubbs: makes sense once you know that's what's happening
<toytoy> ah no, sorry
<rubbs> toytoy: heh. no problem.
<rubbs> lornajane: good. We try to make it less complicated
<rubbs> toytoy: I haven't played with eclipse in a long while.
<rubbs> toytoy: are you looking for full integration?
<rubbs> or just looking for bzr to be separate?
<toytoy> rubbs: yeah, somewhat like cvs feature in eclipse. that is cool! I want something like that for bazaar. is there any?
<rubbs> as far as I know, there is, but it takes some setting up. I'll see if I can find the docs again.
<lornajane> I don't think I understand the workflow of this :(  So normally I just pull changes
<lornajane> my branches had diverged, which is fine
<lornajane> so I merged, I got a conflict, I resolved that and marked it as resolved
<lornajane> now I'm confused by two things
<lornajane> one: stuff that is coming in is showing as local changes in my working directory
<lornajane> two: I have a pending merge tip, no idea what that is or what I should do about it
<lornajane> should I be RTFMing? I can't quite see how this process is going to work
<rubbs> toytoy: http://wiki.bazaar.canonical.com/BzrEclipse/Installation
<toytoy> okay rubbs, I found one but yeah it doesn't work perhaps i need to do more. I got this error bzr: Error: no such option: --short
<toytoy> do you know that one? yeah that's the one i'm installing, indeed
<rubbs> toytoy: I'm not sure if bzreclipse is still in active development. I'm not sure if anyone else knows more. I know it has been done before, I just can't find out where.
<rubbs> lornajane: problem one: My guess is you have one branch, and you merged in your changes from the trunk correct?
<lornajane> rubbs: correct
<rubbs> lornajane: if that is the case, then that is the reason your trunk looks like the "local" branch. When doing a merge, the place you are merging is on the left side. The place you are getting the merge from (i.e. the trunk) is always on the right. There is a way to get around this...
<rubbs> lornajane: you actually need two branches in this case (if you always want to make the trunk on the left). One branch will be your branch you have now. and the other branch will be a Mirror of the trunk.
<rubbs> so you would have to create a branch from the trunk. cd into that mirrored branch, and then merge in the changes from your original branch.
<rubbs> then you can push your mirrored branch back to the trunk.
<rubbs> does this make sense so far?
<rubbs> it's a little complicated, but once you get it, it kind of make sense
<rubbs> you want a "mirror" of your trunk, and a "working branch." Once you are done with your working branch, you merge them into your "mirror" and then push from the mirror. Your working branch can then be updated.
<lornajane> I *think* I understand :)
<rubbs> for problem two it's a little more simple
<rubbs> bzr doesn't automatically commit after all the conflicts are marked resolve (or for any merge for that matter). To finish your merge you have to do a commit. I usually just say "merging in xxx branch" in the message.
<lornajane> right
<rubbs> the pending merge tip is just telling you that in this commit the merge will take the two "tips" or "heads" and merge them to one.
<rubbs> I might raise a bug about how best to set up a workflow for people in your situation. We've had a few people with similar problems before.
<lornajane> rubbs: even a picture I think would help.  I am confident with SVN and I can't be the only person moving over
<rubbs> I think I'm gonna work on that now. I'm working on a "google doc" that will be really basic, but at least it's something.
<rubbs> I'll show it to you in a few minutes.
<rubbs> after I show you I'll work on polishing it up.
<lornajane> rubbs: sounds great :)  I hope I'm not making work for you!
<rubbs> lornajane: not at all! your distracting me from work I really don't want to do (I've been searching for a reason to procrastinate all morning ;) ) and I have plenty of time to get it done
<lornajane> so, I'm definitely making progress, but I'm sort of confused on what to do next
<lornajane> I have updated and put my branch changes into my trunk.  Now I want to push the commits I made back to subversion (I used bzr-svn to check out).  Can I send the commits as they were done locally or can it only be a monster commit?
<rubbs> lornajane: you know, I'm not entirely sure (I've done very little bzr-svn work myself)
<lornajane> rubbs: hehe, maybe I'll improvise and then blog about it.  I can clean up in SVN if I have to
<rubbs> I'm sorry.
<vish> hi.. how to do a merge in lp? ken Accepted the merge , but he isnt sure how to do it...  ;)  https://code.launchpad.net/~vish.../ubuntu/lucid/human-theme/bug507632+bug495644/+merge/17538
<vish>  do i set the status to "merged" or... does  he have to do it?
<rubbs> vish: whoever has write access to that particular branch can do it. They do it by pulling from the trunk (mirror whats on lp) and then merge in the changes from your trunk (off of lp) and then push the result to the lp trunk.  At least I'm pretty sure that's what will work. It's been a while for me to be honest.
<vish> ah , i thought so too.. :(
<vish> but it seems a waste of bandwidth ;p  if the user has changed only one line of a huge branch , the author has to fully download the merge branch too :s
<rubbs> no... they don't actaully
<rubbs> if they just use the lp: shortcuts, it only will download the changes
<rubbs> so you only need a mirror of the trunk.
<rubbs> using ssh+bzr will keep the bandwidth down to a minimum
<rubbs> so in the trunk the command would be "bzr merge lp:branch-to-merge-from" and then once that's all done "bzr push lp:trunk"
<rubbs> er by in the trunk I meant in the mirror of the trunk
<vish> rubbs: ah.. ok thanks :)
<rubbs> np
 * cjwatson typos 'bzr blog'.  Hmm.
<Kinnison> hmmmmm indeed
 * Kinnison ruffles cjwatson 
<cjwatson> LTNS!
<cjwatson> jam: thanks so much for the fix for bug 494269.  I find the notion of being able to change the tree root rather magical ...
<ubottu> Launchpad bug 494269 in bzr/2.0 "tree transform cannot change root id" [High,Fix released] https://launchpad.net/bugs/494269
<maxb> ooh
<jam> cjwatson: yeah, I think there are still some paths that don't get it right, but at least more of them are working now
<vila> cjwatson: try lp:bzr-guess :-D
 * maxb should retest
<vila> morning jam !
<jam> morning vila
<maxb> I managed to get some WTs into an entertaining state by pull --overwrite-ing and unrelated branch
<cjwatson> vila: hah
<Kinnison> vila: ooh handy
 * Kinnison installs
<vila> jam: just a quick check from patch pilot to patch pilot :) Do you still take care of the ignore-exception mp and the 392428 one ?
<vila> bialix: any news about gary ? I don't remember seeing him here these days...
<bialix> hi vila, jam, et al
<bialix> vila: I've chatted with him last night
<cjwatson> jam: merge-package (lp:ubuntu/vim <- lp:debian/vim) is mostly working now, but I'm getting a load of "Conflict adding files to Contents.  Moved to root."  What do those mean?
<bialix> Gary made qbzr 0.14.6 release last night
<cjwatson> Contents being an actual file in the vim tree
<vila> bialix: ok, I'll ping him from lp about his unicode-bom-detect mp then
<bialix> unicode? do you have a link?
<vila> https://code.edge.launchpad.net/~garyvdm/bzr/unicode_bom_detect/+merge/17076
<bialix> thx
<bialix> interesting
<vila> bialix: Yeah, what did you expect from Gary ? :-D
<bialix> me? anything!
<vila> hehe
<lornajane> I'm reading some instructions here http://www.szakmeister.net/blog/2009/oct/12/bazaar-subversion-super-client/ which suggest I want to merge to the repository rather than pushing.  Does anyone have any thoughts on that?  I'm using bzr-svn and I want to push changes on my trunk back to subversion
<rubbs> lornajane: not sure about what you just posted, I'd have to read it. but I finished my very rough slide presentation.
<rubbs> here it is: http://docs.google.com/present/view?id=dhc4j5xm_90gr8227ch
<rubbs> if the current directory marker is in open space that means the directory just above the branch directories.
<rubbs> opps just realized that my permissions on that file were a little too tight. if you had trouble you should be able to view it now
<lornajane> I can see it
<lornajane> that's a good description of what I was doing with the simple changes
<rubbs> ok, cool. I'm also reading the article you posted above.
<rubbs> lornajane: the article correct, you want to merge into the mainline, but they mean the mirror of the mainline (I think). That means that your mirror on your computer should *always* be treated as if it were the subersion server. That way you always get your history right. Once you have checked that it's correct, you can then push up to the server.
<lornajane> rubbs: but will my many commits to there be many commits to SVN or just one?
<rubbs> just one. if you want to do many commits you need to look at rebasing.
<lornajane> meh, I thought this was going to be much easier :)
<rubbs> that article seems to have a section on it
<rubbs> rebasing "rewrites history" so that all your commits look like they came from the latest revision instead of an old one (which is what is happeing with yours)
<rubbs> that way you can then push up to the main branch and it will all look like your commits came from the tip. and you will get all your commits as little ones rather than as one big one
<lornajane> that sounds promising
<rubbs> it's a flaw with svn in that it doesn't keep merged history
<lornajane> I'm hoping this will get easier/quicker as I get used to it
<rubbs> that's why a merge in svn will look like one big commit.
<lornajane> I've spent half my afternoon wondering how to update and commit :)
<rubbs> lornajane: I don't use svn that much anymore but this will get easier with a little practice. most of it isn't that time consuming, just a little bit of work in the begining
<rubbs> once you get a workflow that works, it's pretty easy
<rubbs>  < lornajane> I've spent half my afternoon wondering how to update and commit :)
<rubbs> ^^ been there before
<jam> cjwatson: my best guess is that the same file exists in both branches but with a different file-id, so we get a conflict and have to put the files side-by-side
<lornajane> rubbs: yes I'm sure I've been here before too :)  I'll always be using central SVN repos but I love having bzr functionality on my working copy, if I can figure this out its going to be excellent
<rubbs> lornajane: I think it will work out for you. If you have more questions, just let us know. We'll try to help you out.
<lornajane> rubbs: this channel has been great so far - and the community is the main reason I'm persevering with this rather than following the crowd in my sector to git
<cjwatson> jam: that was my first guess, but there are no .moved files or similar in the working tree
<jam> cjwatson: the other possibility is the root id issue. In that in one tree it looks like Contents should be in '' with root id X, and in the other tree it looks like it should be in '' with root id Y. And root id Y isn't present in the first tree, so it seems like a conflict
<jam> (root ids are mostly allowed so that you can do stuff like join by reference or join by value, and have things show up in the appropriate subdir)
<rubbs> lornajane: I use git a little too (for work) it's not bad. Their community has worked well for me. For me though... bzr-svn had a few less problems than git-svn and a whole lot less problems than hg-svn. That and bzr makes it easy to contribute back to them ;)
<jam> it wasn't really intended that the *same* project should get 2 root ids
<jam> however, people did 'bzr init' 2x, rather than 'bzr init + bzr branch'
<jam> etc
<jam> especially with the udd stuff
<cjwatson> jam: right.  It's a bit of an incomprehensible message though - what am I meant to do with a conflict when I have no alternatives to choose between? :-)
<lornajane> rubbs: I just can't bear ruby fanboys telling me that if I don't think git is the best thing ever, then I know nothing.  These are just tools and I just want to use them, not argue about it
<lornajane> git is pretty good, sure, but if I'm going to get flamed in their channels then I'd rather use something else :)
<rubbs> haha good points
<starenka_> hi, i just want to checkout/branch source from a lp project (bzr :D), is there a way how to checkout "lightweight"? I mean i dont need any history, just need the lastest source to compile it
<starenka_> (bzr n00b, sorry)
<jderose> starenka_: bzr checkout --lightweight YOUR_BRANCH
<starenka_> ty
<eydaimon> I'm wanting to merge to specific files from one branch to another.  bzr merge ../trunk/file1 ../trunk/file2 gives errors complaining about extra arguments, and merging one file at a time gives error during merging of second file saying there are uncommitted changes. How can I merge more than one file at a time?
<Kinnison> Erm, bzr operates by revision for merging IIRC
<Kinnison> so you can't really merge by file
<Kinnison> (unless this is a new feature I didn't know about)
<eydaimon> but it appears to be very possible to merge just one file
<eydaimon> seems to me I would have to merge and commit one file at a time otherwise
<eydaimon> and if I can do that, it should support multiple
<Kinnison> Why do you want to only merge specific files; rather than revisions?
<eydaimon> what if the files are spread out over multiple revisions?
<eydaimon> and there are other changes in those revisions I don't want merged
<Kinnison> Sounds like a very unfortunate situation
<Kinnison> I honestly don't know; sorry
<Kinnison> you could try:
<Kinnison> for F in file1 file2 file3; do bzr merge -force ../trunk/$F; done
<Kinnison> since the --force option makes merge ignore uncommmitted changes and continue anyway
<eydaimon> well, luckily it's not happening. I can actually use the change
<Kinnison> I'd prefer using the revisions
<Kinnison> since then history is nice and neat
<eydaimon> but to me it's easier to keep track of what files I need rather than the revision
<eydaimon> and since the above case is possible... just seems like something that would be supported
<eydaimon> what's the bzr file needed to specify username?
<Kinnison> username?
<maxb> eydaimon: Try using bzr help whoami
<Kinnison> If you want to tell bzr what author/committer name to use, then do: bzr whoami "My Name <email@domain.com>"
<eydaimon> found
<eydaimon> ~/.bazaar/bazaar.conf
<eydaimon> well, one guy is checking in as root...
<Kinnison> that guy needs to be spanked
<Kinnison> (unless you're doing some kind of etckeeper thing)
<eydaimon> he didn't want to touch his mac by installing stuff on it, so he is running virtualbox with redhat and doing his dev on there....
<eydaimon> don't ask ...
 * Kinnison won't :)
<lifeless> Kinnison: he might like it
<Kinnison> In that case, even if I were tempted to ask; I wouldn't want to know :-)
<eydaimon> heh
<Chocobo> Hi all.  How well does bzr handle large files?  I know this is an issue with hg and git.
<luks> not much better, I guess
<luks> what specifically are you interested in?
<Chocobo> Oh I have a project with a lot of large binary data files.
<lifeless> Chocobo: how large is large
<Chocobo> 100 MB or so.
<Chocobo> I would like to keep it in revision control because it is part of the project.
<lifeless> as long as you have 300MB ram it should be fine.
<lifeless> [and you are using 2.x]
<NfNitLoop> Hrmm.  'bzr log' on this svn branch doesn't show 'svn revno:' for something I pushed from my local branch.
<NfNitLoop> Not sure what's causing that...  doesn't seem to generate an error or anything.
<NfNitLoop> Oh, come to think of it, it doesn't show svn revno for anything that was a result of a merge, it seems.
<NfNitLoop> I guess so it can continue to show the bzr mergeinfo?
<maxb> Hmm, the bzr-beta-ppa is not in very good shape :-/
<maxb> Is there any convenient trick to running bzr from a working tree, but with C extensions?
<maxb> Or should I find somewhere in my homedir to install it to, and use PATH and PYTHONPATH?
<fullermd_> `gmake`
<maxb> oh, neat, I didn't even look for a Makefile once I'd seen the setup.py
<igc> morning
<lamont> given a CVS repo with N branches, and possibly some violations of nature (hi lifeless), is that trivial to import into bzr yet?  even at one directory tree per branch?
<lifeless> lamont: cvs2svn can output fast-import streams
<lifeless> lamont: if it can handle your repo, then yes.
<lamont> ah, cool
<lifeless> lamont: as we can import fast import streams
<lamont> and FWIW, it's not _my_ repo (this time)
 * lamont cries a little as 'rcs' and 'subversion' both wind up on his machine
<maxb> cvs2svn(bzr) does a decent job these days. Give me a prod if you find a problem, I've been hacking on it lately
<lamont> will do
<rockstar> jam, you're not at LCA are you?
<mwhudson> rockstar: he is not
<jam> rockstar: nope, I believe lifeless is
<rockstar> jam, I wonder if I might schedule a call with you tomorrow as I land the last of the branch upgrade work.
<rockstar> Er, the launchpad branch upgrade work.
<jam> rockstar: sure, what time is good for you?
<jam> I need to be going soon, though
<rockstar> jam, how 'bout 10 AM your time tomorrow?
<jam> rockstar: sounds good right now
<rockstar> jam, okay.  If something comes up, feel free to send me an email with a new time.
<maxb> bzr-rewrite is eating my brain
<cjwatson> lamont: I did actually manage to use cscvs to import multiple branches; since there was already a cvs->bzr import on Launchpad using cscvs, I figured I was best off sticking with the same tool
<lamont> cjwatson: coolness.
<cjwatson> lamont: https://code.launchpad.net/~cjwatson/launchpad-cscvs/openssh-branch-imports for the gross hacks involved
<lamont> nice
<lamont> this is an NDA'ed CVS repo that 'git cvsimport' has a history of sometimes not liking
<cjwatson> lamont: and http://bzr.debian.org/loggerhead/pkg-ssh/openssh/trunk/annotate/head:/debian/README.source? documents how to drive it.
<cjwatson> lamont: oh, if cscvs hasn't already been involved, you might keep your sanity better by not involving it
<lamont> it doesn't help that someone (and not me this time) has felt sufficiently of-clue to do manual surgery on the ,v files from time to time
<cjwatson> that never helps
<lamont> cvsps
<cjwatson> my normal preference is to use something that spits out fast-import streams (like cvs2svn/cvs2git/whateveryoucallit), since they're hackable
<lamont> one question that I might get an answer to (assuming it finishes): does cvs2git create consistent commit hashes?  or will two imports of the same tree not give the same git tree?  (ditto for cvs2bzr...)
<cjwatson> there's no "cvs2bzr" AFAIK, it's more like cvs2git | bzr fast-import
<lamont> cvs2svn: /usr/bin/cvs2bzr
<lamont> beg differ
<cjwatson> huh, so there is
<cjwatson> wasn't last I looked. :)
<lamont> gotta love these works in progress.
<lamont> 375MB cvs tree -> 2.5GB and counting blob file
<lamont> meanwhile, git cvsimport: WARNING: Invalid PatchSet 7114, Tag v9_0_base:
<cjwatson> anyway, cvs2bzr is just slightly tweaked output versus cvs2git, it still requires use of bzr fast-import
<lamont> and given that upstream is cvs, and I have my git tree for debian/ubuntu, and the whole tree is totally NDA, I'm inclined to leave it in git for the moment, and then play with it in bzr and make sure cvs2bzr is doing the right thing.
<cjwatson> and bzr fast-import doesn't guarantee consistent revision-ids
<lamont> maxb: cvs2bzr would be far more useful to me if it could do a delta addon to an existing previous result from cvs2bzr
<cjwatson> I don't know about cvs2git | git fast-import
<maxb> lamont: So say many people, but converting from CVS doesn't lend itself to that
<lamont> well, running 2 copies of cvs2git now, just to see what it does.
<cjwatson> however, to amend my previous comment
<cjwatson> bzr fast-import permits storage of "fastimport-id-map" in the .bzr/repository
<maxb> cjwatson: Well I've worked out what the bug in bzr rebase-foreign is, but I don't know how to fix is :-/
<cjwatson> if you do that, then successive imports into the same repository will be idempotent
<lamont> maxb: so I've told upstream.  in the end, I got rsync access to the ,v files, and "CVS has worked for us so far, no reason to change" by way of an answer about joining the current VCS world
<cjwatson> so it *is* possible to do delta imports, that way
<cjwatson> in fact I do that myself with debian-policy
<lamont> cjwatson: awesome
<cjwatson> rebasing will break it
<lamont> that's because rebase always breaks things
<cjwatson> http://paste.ubuntu.com/359284/ is the script I use to update my debian-policy bzr import
<cjwatson> should switch to bzr-git one of these days
<maxb> I don't think fastimport storing a map file will work to allow delta imports from cvs2bzr
<maxb> Perturbation in the cvs repository could cause cvs2bzr to resolve changesets differently
<cjwatson> depends on level of branch complexity
<cjwatson> if there's weirdness regarding default branches, then possibly
<lamont> "This is a necessary workaround for the fact that CVS tags are fundamentally different than git tags.)" <-- no, it's because CVS tags are fundamentally b0rked
<cjwatson> you could also manually chop off the dump file before a certain timestamp, and hack it to start from a given revision
<cjwatson> fast-import lends itself to that kind of hackery if you're sufficiently desperate
<cjwatson> though generally once I fast-import from CVS I throw away the original as fast as humanly possible, admittedly
<lamont> but for me, for whatever reason, the commit IDs turn out different every time I import. <-- sigh
<lamont> I think it might be time to reopen the discussion with upstream...
<maxb> Hmm, I wish jelmer was around.
<lamont> WARNING: in '....' branch '...' already has name 'foo', cannot also have name 'bar', ignoring the latter
<lamont> I wonder if that means they assigned a branch 2 names
<lamont> cjwatson: I
<lamont> d pay cash money to get the original CVS thrown away in this case.... just not enough money to convince upstream, yet.
<lamont> of course, there'd be more negotiability if the repo weren't so private
#bzr 2010-01-20
<maxb> hmm, I wonder how long it takes to rebase 1500 revisions
<maxb> this is one scenario when bzr's speed is a bit lacking
<maxb> Gaaaaah
<maxb> I bet rebase-foreign is picking the file-ids from the wrong side
<maxb> cjwatson: What's the aim with the debian-cd branches? End up with the ubuntu branch retrofitted with debian file ids and on top of the debian history?
<cjwatson> maxb: Debian used to use svn and now uses git; I want to rebase/merge/whatever across that change
<cjwatson> the Ubuntu branch was created when it used svn (or maybe even CVS, but I think it was svn)
<maxb> hmm... how come both branches have arch-style revids?
<lifeless> cscvs to tla
<cjwatson> cancel "rebase/merge/whatever", I specifically want to merge forward, but I'm happy to use something rebase-like to pretend that my history was always based on git
<maxb> But lp:debian-cd is still a svn import
<maxb> urgh, it died again
<maxb> that's immensely irritating. the rebase died 4 revisions short of finishing
<lamont> maxb: but only one or two more bugs to fix, right?
<maxb> I'll let you know when it finishes another attempt :-)
<cjwatson> maxb: hmm, I think I mean "Debian used to use cvs and now uses svn", then
<cjwatson> maxb: so the current Ubuntu branch was created when it used cvs
<cjwatson> apologies for that confusion
<cjwatson> the change was years ago
<maxb> assuming it doesn't explode again, I'll push some results in 10 mins or so
<maxb> although given how confusing I found the code, you probably want jelmer to review my hacks to bzr-rewrite before you trust its output
<maxb> lp:~maxb/bzr-rewrite/ubuntu-debian-cd-rebase-foreign succeeds in the rebase. I can't push my rebased branch because grrrrrr I did it in a shared repo and now have different rich-root errors
<lamont> so these blob files... how big do they get?
<maxb> huuuuuuge
<maxb> As they store the literal content of every revision of every file
<lamont> is it basically a concatenation of every single output-format commit ever?
<lamont> 375MB cvs tree, 4.7GB of blob and counting
<maxb> yup
<lamont> oh rapture.
<maxb> disk is cheap, right?
<lamont> now, where _are_ my scissors.
<lamont> ....
<maxb> It gets worse - if you pass the data on stdin to fast-import, it caches the blobs in memory!
<lamont> git and bzr? or is bzr the only thing silly enough to do that?
<lamont> svn being in the "totally do not care" category
<maxb> I'm assuming just bzr
<maxb> It's really silly, it could just keep track of a revid+fileid and get the content back that way if it needed it again later
<Phil_Bordelon> Hello there.
<maxb> and pushed: lp:~maxb/debian-cd/ubuntu-rebased
<Phil_Bordelon> Does anyone know if there's an equivalent to svndumpfilter available for bzr?
<maxb> There's bzr fast-import-filter
<cjwatson> maxb: cool, thanks!  I'll have a look ..
<Phil_Bordelon> Awesome.  Just what I needed.  Thanks, maxb.
<Phil_Bordelon> I'm a writer, and I have stuff in an 'incubator' repo in bzr that I occasionally want to split off into its own repo.  This'll do just that. :)
<Phil_Bordelon> (same with code.)
<Phil_Bordelon> <3  You and Ian C. made my evening.
<mtaylor> abentley: didn't you say that there was a ppa that had bzr 2.1beta in it?
<abentley> mtaylor: Sure, and either the beta ppa or the nightly ppa should.  They don't?
<mtaylor> abentley: I don't see them on the ~bzr page...
<abentley> mtaylor: They were started before a user could have multiple ppas, so they have different users.
<maxb> the beta ppa is rather out of date. It has versions older that the ~bzr ppa
<maxb> *than
<abentley> mtaylor: https://launchpad.net/~bzr-beta-ppa/+archive
<abentley> mtaylor: https://launchpad.net/~bzr-nightly-ppa/+archive
<mtaylor> abentley: AWESOME
<mtaylor> abentley: thankx
<jml> abentley, you know what would make me like remerge a whole lot more?
 * igc lunch
<lifeless> jml: what would
<jml> lifeless, oh, I spoke w/ abentley IRL
<jml> lifeless, a way of seeing what it actually changed, especially wrt files that used to conflict.
<lifeless> vila: https://code.edge.launchpad.net/~vila/subunit/gtk-filter-fixes can you mark this as obsolete?
<abentley> lifeless: ping
<vila> lifeless: it's already marked as merged, anything more needed ?
<vila> hi all ! (by the way :)
<GaryvdM> Hi vila.
<vila>  hey GaryvdM !
<vila> That was short...
<vila>  hey GaryvdM ! (Was I saying when your client quit :)
<bialix> heya bzr
<bialix> igc here?
<bialix> hi garyvdm
<garyvdm> hmm - something wrong with my keyboard config and xchat. when I press "q" it takes it as ctrl + q
<garyvdm> hi bialix
<vila> hey garyvdm ! (Third time :)
<bialix> vila and gary meet each other. finally
<bialix> hi vila!
<vila> hey bialix :-D
 * vila LOLs :)
<bialix> :-D
<garyvdm> vila: just wanted to say: I've replied to your question about the qbzr test suit,
<vila> garyvdm: now that's timely :D Thanks a lot
<vila> garyvdm: hmm, I already spend far too much time administering my zoo, but it's good to know it will go away soon
<bialix> garyvdm: just info: I will be unable to work on qbzr till February
<garyvdm> bialix: Ok - np
<vila> garyvdm: at worst the test can be tagged as requiring pyqt-4.6.1...
<vila> s/test/tests/
<vila> garyvdm: but waiting for a karmic upgrade is good enough for me
<garyvdm> vila: that is a good idea.
<garyvdm> or a known failer
<vila> garyvdm: know failure will be harder, skip may be good enough
<garyvdm> ok
<vila> bialix, garyvdm : Congrats for the qbzr-0.18 release by the way !
<garyvdm> :-)
<bialix> vila: thanks, I'm appreciate the congrats
<vila> garyvdm: since you're there, are you still working on the unicode-bom-detect stuff ?
<garyvdm> Not for the moment, but I will get back to it.
<vila> garyvdm: I was thinking that since you can't do that unconditionally (as abentley pointed out) you may think about implementing the feature in some read-only mode as a first step
<bialix> vila: can I ask about bzr itself?
<vila> bialix: don't ask to ask, ask :D
<garyvdm> vila: " some read-only mode" == command line paramater?
<vila> garyvdm: no, at the API level
<garyvdm> Ok
<vila> AIUI you need this patch for read-only operations (diff, cat, etc)
<vila> there may be a way to have additional methods that these read-operations can use and avoid the problems mentioned by abentley
<vila> garyvdm: I haven't look in detail so take the suggestion with a grain of salt
<garyvdm> vila: I also need to go into some details
<vila> garyvdm: ok
<bialix> vila: any ideas about https://bugs.launchpad.net/bzr/+bug/244291
<ubottu> Ubuntu bug 244291 in bzr "NoSuchRevision error from "bzr info -v"" [Medium,Confirmed]
<bialix> I've offered to provide the repo where this bug present
<bialix> is it needed?
<bialix> or I should not ask to ask?
<bialix> I'm worrying a bit because this repo is no more actively using by me: I'm switching to use colo
<bialix> so I can delete it one day accidentaly
 * vila reading
<vila> bialix: hmm, this looks like a plain branch, how did you end up with an out-of-date working tree ?
<bialix> this branch was used as master for light checkout
<bialix> it was easy
 * garyvdm -> work
<vila> bialix: so the bialix@ukr.net-20091128210111-wlxjvzkuj72ze9mi revisions is not in the repo yet the branch references it, how weird... DId you implement some gc without telling us ? :-D
<vila> bialix: more seriously do you use some stacked branches ?
<bialix> I'm sure this revision in the repo
<bialix> because qlog works without errors
 * vila blinks
<bialix> I don't made gc
<bialix> and don't use stacked
<bialix> (stacked seems evil for me)
<vila> hmm, let me guess, that revision is in the branch history but *not* a mainline revision ?
<vila> qlog should show you that quite easily :D
<vila> bialix: hmm or somehow that revision went completely out of the branch history after some 'uncommit' or 'push --overwrite'... but let's check if it's still in the branch history first
<Anteru> Hi
<Anteru> I've just switched a repository from SVN to Bzr (using bzr svn-import), and we're running into weird issues. First of all, a bzr check told us that we have 250 broken parents or so
<Anteru> This could be fixed by using bzr reconcile
<Anteru> Unfortunately, diff's regularly fail with NoSuchRevision ...
<vila> Anteru: hmm, bzr-svn is the recommended way for that AFAIK, but for context, what versions are you using ?
<Anteru> Commit works, but diff fails (before/after the commit)
<Anteru> Running bzr 2.0.3
<Anteru> (latest stable)
<Anteru> Server is running bzr 2.0.3 as well, and we're publishing right now using sftp due to issues with bzr serve/fastcgi
<Anteru> basically, the problem is that when we try to diff, we get "bzr: ERROR: bzrlib.errors.NoSuchRevision: CHKInventoryRepository('file:///V:/proj/.bzr/repository/') has no revision dev@anteru.net-20100109162623-iqh9at1lxqx8n38p"
<bialix> vila: this revision is the revision of working tree
 * bialix preparing screenshot!
<vila> Anteru: try bzr reconcile first
<Anteru> We did reconcile
<Anteru> It's also not for all files, for some, diff works perfectly, but for some, we get the error above
<vila> bialix: yes (because most probably info -v starts from the actual tip), but the wt is out-of-date and it seems that doesn't play well here
<vila> Anteru: weird, is 'bzr check' happy now ?
<Anteru> 20 ghost revisions, let me run it again just to get the output
<bialix> vila: http://launchpadlibrarian.net/38124517/qlog-bug-244291.png
 * bialix -> work
<vila> bialix: great, so it *is* in the branch ancestry, that narrows down the problem
<Anteru> (this will take some while, 2.6k revisions)
<Anteru> OT: Is check going to become faster some day?
<vila> bialix: and I presume that the error goes away if you run 'bzr update' ?
<bialix> maybe, I did not try
<vila> Anteru: for some value of some, yes. There are plans to implement more options to allow finer-grained checks
<bialix> vila: tried in the copy: yes, error go away after up
<Anteru> vila: check output: http://pastebin.ca/1758667
<vila> bialix: that would help the diagnosis (I'll need to write the test otherwise :-)... YES !
<bialix> added to bug comments
<bialix> thanks
<vila> bialix:  me too :)
<vila> bialix: lol, we added nearly the same comments :)
<vila> Anteru: yeah, ghosts...
<Anteru> Any way to get rid of those, if they're causing these issues?
<Anteru> I have no problem to fiddle around with the repository, as long as no information gets lost (as we have already some commits in there)
<vila> I'm pretty sure it's related to svn-import/bzr-svn then, but you need someone more experienced than me with the svn conversions then, try to find jelmer or better file a bug on lp or write an email to the bazaar list
<vila> Anteru: if you go away from svn, these ghosts need to filled
<vila> s/to filled/to be filled/
<Anteru> Any idea how/where to start?
<vila> AnMaster: A ghost is a revision that exists but bzr is not aware of its content
<vila> Anteru: not really, that sounds like a genuine svn-import bug to me though
<Anteru> Which sounds like a very serious issue to me, as we can't go back to svn that easily now :/
<vila> Anteru: that's why I said it's a bug
<Anteru> I'll try the mailing list and cross my fingers that the repository/history can be rescued. Damn, I wonder why we didn't run earlier into this.
<Anteru> Just now, after fully switching :/
<vila> Anteru: the first thing is to get the list of the ghosts revisions, look into .bzr.log or re-run 'bzr check -v' and look again
<vila> from there you'lll have to find out what theses revisions are.... and inject them into the repo (how to do that with svn-import is a different story...)
<vila> Anteru: did you use bzr-svn before switching ?
<Anteru> Yes
<vila> Anteru: Do you use shared repos ?
<Anteru> I used it locally for some time (200 revisions?), but we finally decided to fully move and started from scratch (i.e. ran svn-import on the server, and branched from there)
<Anteru> bzr.log contains loads of errors: http://pastebin.ca/1758676
<vila> All the 'Unable to open' errors should be harmless as long as you don't see them in the console (I'm pretty sure that's bzr-svn trying to find an svn repo in wrong places and failing)
<Anteru> That is, the usage previously was that one developer (me) who used bzr locally, by doing svn-import, binding to svn, and branching/merging locally. The other dev was using SVN (but I think it was only like 2-3 commits)
<Anteru> Now we scrapped all local bzr copies, and simply ran import again, and I branched off the new repository.
<vila> argh !
<Anteru> ?
<Anteru> We should have done everything differently?
<vila> I was hoping to find the ghosts in your previous bzr branches !
<Anteru> IIRC, I had some ghosts revisions in my first local import (i.e. the first time I ran svn-import)
<vila> Anteru: you could have started with your bzr branch instead which was presumably complete instead of re-running svn-import
<Anteru> The original branch already had these ghost revisions (and I think, even the same number -- I was asking here if this is normal that I'm like 10 revisions behind the SVN, and I was told yeah.)
<Anteru> Running bzr check -v now
<vila> Anteru: Then I'm a bit lost... AFAIK bzr-svn create ghosts only for bzr revisions that can't be exported to svn, so you need at least two people using it to encounter the problem...
<vila> or two branches that don't share a repo
<Anteru> Well, I didn bzr svn-import on two machines
<Anteru> Which would solve that issue
<Anteru> I.e. explain how the ghost revisions appeared, but as I said, I had them right away
<Anteru> The first time I did svn-import, I was 10 or 20 revisions behind, with some ghosts.
<vila> Anteru: I confused svn-import (which *is* part of bzr-svn) and svn2bzr. You definitely needs jelmer here
<Anteru> bzr check -v gives the ghost revision ids
<vila> AnMaster: and you lamost certainly needs the bzr repos where the ghosts were created
<lifeless> vila: it has unmerged changes that won't be merged. it needs to be marked obseleted or whatever. its showing up in branch listing.
<lifeless> abentley: pog
<lifeless> abentley: pong
<vila> from there, branching from the repo that contains the revisions into the repo where they are ghosts should filled them
<Anteru> Great, as we don't have them :/
<abentley> lifeless: I couldn't remember whether we were doing code review for bzr-pqm or just pushing.  In the end, I requested a review.
<Anteru> Ah well, something is always going wrong. I wonder where they came from as we did a fresh svn-import
<lifeless> abentley: ok, I shall review in the morning if thats ok
<abentley> lifeless: That's fine.
<Anteru> vila: Yeah, looks like the merges are the culprit (i.e. local bzr getting merged into SVN)
<vila> Anteru: yes, that create ghosts because svn can't represent them so bzr-svn store the revids in some svn property to be able to roundtrip safely
<Anteru> (at least, I count 17 merges, and some might have 2 or 3 revisions)
<Anteru> Gosh, I would be happy to get rid of them (i.e. I don't worry if the fact that it was a merge is lost)
<Anteru> and just treat them as normal commits to the trunk
<vila> Anteru: then there should be a way but that requires some voodoo knowledge of bzr-svn internals, file a bug
<Anteru> Ok. Any idea if there is a way to get it fixed on the bzr repository directly :) ?
<lifeless> night
<vila> Anteru: Hopefully yes, but whether it's only deleting them from the parent list or if more is required, I can't say
<vila> lifeless: done
<vila> lifeless: g'night
<Anteru> Ok, cool. I'm going to write a _long_ writeup to the mailing list.
<Anteru> I.e. explain all the problems we created ;)
<vila> Anteru: too bad you didn't keep the bzr repos around for a while, are you sure you don't have a backup somewhere ?
<Anteru> Pretty sure, unfortunately, as I had like 10 repos during testing, and got rid of them all at once.
<Anteru> (testing means only locally to check performance etc.)
<Anteru> Sent
<Anteru> Let's see if someone has an idea (fingers crossed)
<Anteru> vila: Thanks!
<vila> Anteru: you're welcome! Your experience should at least help us better document the process so those ghosts don't get lost the next time :-/
<vila> Anteru: Another way to fix the problem *may* be to try bzr-replay and see if it can cope with the ghosts
<Anteru> Yeah, I'm also going to blog about this, in the hope that it will help other people to migrate from SVN to Bzr (because I'm really happy with Bzr)
<vila> Anteru: you will end up with a repo with *different* revids though, so be prepared to resynchronize every people involved
<Anteru> That's no problem
<Anteru> I can simply delete the repository on the server, recreate it, and tell everyone to branch again :)
<Anteru> Trying bzr replay of all revisions, let's see if/when this finishes ... doesn't look too fast (pegging one core @ 100% and reading like 2 KiB/s)
<l2m> hi ^^
<l2m> could anyone help me to understand why the bzr commit does not works with the --fixes switch ?
<l2m> i've added in the config file the line trac_mysite_url = http://www.mysite.com/trac
<l2m> and nothing seems to happend when i do a bzr commit --verbose  --fixes mysite:106 -m'test___'
<bialix> if you run qlog you'll see it there
<bialix> what you expect actually?
<l2m> qlog ?
<bialix> qlog is the part of qbzr plugin
<bialix> it's wonderful gui
<bialix> --fixes store special metadata attached to committed revision
<bialix> it's not quite visible
<bialix> qlog makes it clearly visible
<l2m> but why is --fixes not calling trac ?
<bialix> --fixes does not change the status of actual bug
<l2m> i can't see anything in trac
<l2m> ok :)
<bialix> it's just metadata inside bzr
<l2m> not possible to fix in trac an opened bug ?
<bialix> trac-bzr plugin does not process such metadata yet
<bialix> in theory it's possible to close bug in trac via post-commit hook
<bialix> there is special API in trac for this, xml-rpc IIRC
<bialix> but in practice nobody wrote such hook yet
<l2m> hehe ... :)
<bialix> yep
<l2m> ok so where looking for this guy ;)
<l2m> we are sorry
<bialix> imagine if you commit locally without access to trac
<bialix> what should bzr do?
<bialix> I mean offline
<l2m> yep .. but in our case, we have all in local network
<bialix> yes, but bzr don;t know this ;-)
<l2m> so, many thanks for help bialix ... we gonna look for an other solution
<bialix> if you find it, I'd like to know too
<bialix> we're using trac at work too
<l2m> wel .. so the fixes switch work well with launchpad or bugzilla .. or same limitations ?
<bialix> lp don't change status of the bug
<bialix> it just link the branch to the bug
<bialix> so in lp this info used just as flag: here is branch where possible fix exists
<bialix> as you can imagine the fix can be wrong or incomplete
<bialix> that's basicall y main reason why bzr don't try to change the status of the bug
<Anteru> hm, I cannot get bzr replay to work, complains about no WorkingTree
<Anteru> vila: replay fails with conflicts?!?
<vila> Anteru: for the merges ? Are they the same conflicts that you did resolve at that point in the past ?
<Anteru> it fails on revision 40 or so
<Anteru> that's in 2004, when we were using svn 1.0 or so
 * vila summons quicksilver that played a lot with bzr-replay lately :-)
<Anteru> I don't think we had conflicts back in that day :)
<quicksilver> all I have to offer about bzr replay is that I could only make it replay simple revisions
<quicksilver> that is, no merge involved.
<vila> Anteru: may be you don't use bzr-replay with the right starting branch (don't start from origin but maybe just before the first merge)
<maxb> yeah, no support for merges
<quicksilver> if there is a way to make it do something sensible with merges I didn't find it.
<quicksilver> I must finish that long email I was writing to the bzr list though
<maxb> actually most of bzr-rewrite fares poorly if you ask it to rewrite a merge
<Anteru> hm
<Anteru> Seems my repository is totally hosed
<vila> quicksilver: oh, finishing that mail ? Good idea :)
<Anteru> It's not only ghost revisions that are missing. Just sent again to the ML :/
<Anteru> Bah, that's a migration :(
 * vila lunch time, bbl
<jam> morning all
<jam> hopefully irc will get sorted out...
<vila> morning jam !
<Lo-lan-do> Hi all :-)
<rubbs> hello
<Lo-lan-do> Question about bzr switch.  I have a lightweight checkout of ~/repo/branch, which is bound to bzr+ssh://remote/blabla/branch
<Lo-lan-do> Is there a way to have "bzr switch otherbranch" switch to ~/repo/otherbranch rather than bzr+ssh://remote/blabla/otherbranch?
<rubbs> I don't think so, the only way is to type out the whole path... on the other hand, I seem to remember reading something about intents...
 * rubbs runs of to the documentation...
<rubbs> mmm... seems like intents are more for shortcutting authorization to branch locations rather than shortcuting the branch locations themselves.
<rubbs> you could make an alias...
<rubbs> bzr alias otherbranch="~/repo/otherbranch"
<rubbs> that way when you do your switch bzr will expand your path for you.
<Lo-lan-do> Hm, yes, that would work if I had only one repo.
<rubbs> ah.
<rubbs> not sure what the best solution is.
<Lo-lan-do> I have several branches named similarly, in the same repo, too.
<Lo-lan-do> fusionforge/patches/$client1/fixes, fusionforge/patches/$client2/fixes, and so on.
<rubbs> that makes sense. Does bzr switch ../otherbranch work?
<Lo-lan-do> bzr: ERROR: Not a branch: "bzr+ssh://remote/blabla/otherbranch/".
<Lo-lan-do> So, no.  But nice try :-)
<Lo-lan-do> Uh, it's even worse, actually, it's bzr+ssh://remote/bla/otherbranch/ , with bla being blabla/.. (blabla's parent dir)
<rubbs> mmm...
<Lo-lan-do> I'm fetching the source, I'll see if I can add a parameter to change the default behaviour.
<rubbs> that might work.
<rubbs> I'm out of ideas other than that.
<rubbs> unless someone like jam or vila have an idea.
<jam> Lo-lan-do: bug #506177
<ubottu> Launchpad bug 506177 in bzr "switch sibling should check for lightweight checkout first" [Medium,Confirmed] https://launchpad.net/bugs/506177
<jam> basically, while 'bzr switch $PATH" defaults to switching the lightweight checkout before the bound branch the "bzr switch local" lookup does the bound branch lookup first
<jam> for now
<jam> use bzr switch ~/repo/otherbranch
<Lo-lan-do> I see.  Thanks for the pointer.
<Lo-lan-do> Oooh, colocated branches now!
<Glenjamin_> hi guys, is there any plan for a os x 10.5 installer for the newer versions of bzr?
<Glenjamin_> or, a more relevant question - how do i use bzr-keychain?
<Glenjamin_> it appears to have installed correctly and is in the plugins list
<Glenjamin_> but i have no idea how to make it prompt for keychain access
<Lo-lan-do> Does "bzr help keychain" say anything?
<Glenjamin_> "Use the Mac OS X keychain as a credential store for authentication.conf."
<Glenjamin_> bzr 2.0.1 btw
<Lo-lan-do> Glenjamin_: No idea from me, actually.  I'm not a Mac user, I was just suggesting.
<Glenjamin_> no worries
<Glenjamin_> bzr-svn can read plaintext stores from svn fine - but doesnt seem to be able to read from the svn keychain store :s
<vila> Glenjamin_: I think jfroy know about bzr-keychain, let's try to summon him
<Glenjamin_> i'm guessing jfroy is the bzr-svn guy?
<vila> jam: can you review https://code.edge.launchpad.net/~vila/bzr/per-file-merge-hook/+merge/17754 ?
<vila> Glenjamin_: no, it's the bzr-keychain guy :)
<Glenjamin_> oh
<Glenjamin_> thats works too :)
<jam> vila: I'll try to take a look at it today
<vila> jam: thanks, unless you object, it would be nice to include it in rc1 since there seems to be agreement that it's low risk
<vila> jam: but I will *not* push more since it needed to be completed at the last minute by the pp instead of the original author...
<vila> jam: hmpf, passport, damn
<jam> vila: already approved
<jam> yeah passport thing is just strange
<jam> for whatever reason neither of us connected the dots until it was in the mail
<jam> anyway, I'm going to head to a coffee shop for a while, I'll see if I have net access there
<vila> jam: small error big consequences... :-/ We will miss you if you can't make it :-/
<vila> jam: huh ? What about your expresso machine ?
<Lo-lan-do> I was going to ask what's new in 2.1, but reading the release notes, I'm sold already.
<Lo-lan-do> "bzr unshelve --preview" is something I've wished for quite some time :-)
<Glenjamin_> anyone around who works on bzr-svn? i'm looking at the authentication code, and it appears to have hooks into all the subverpy auth providers, but not use any of them in the Credential Store implmentation
<AnMaster_> <vila> AnMaster: A ghost is a revision that exists but bzr is not aware of its content <-- wrong nick?
<vila> AnMaster_: yeah, sorry about that
 * vila lectures Xchat: see ? Can't you check which nick you propose !
<AnMaster_> vila, for xchat iirc you can set "most recently to speak completed first" kind of thing
<vila> which I did AFAIR, let me check
<vila> here we go, lost setting...
<vila> AnMaster_: thks for the heads-up
<AnMaster_> vila, if you use /set iirc you have to save it by some other command
<AnMaster_> was a while ago I used xchat last
<vila> AnMaster_: I track changes on the  xchat.conf file.... at least I was but somehow my setup has been broken :-/
<AnMaster> mhm
<vila> ha, got it, xchat creates a new xchat.conf when some pref is modified which breaks my tracking :-/
<Tak> what happens when one bzr unbinds a lightweight checkout?
<fullermd_> One doesn't; the operation doesn't make sense.
<fullermd_> unbind operates on a branch, not a checkout.  So what would happen would be that it would perform that operation on the branch you have a lightweight checkout of, which is statistically probably not bound in the first place.
<Tak> ok
<Tak> that's what I figured
<Tak> although I kind of hoped that it would create an alternate universe where magical unicorns would keep track of my local revisions until it was time to rebind
<keithy> hi
<keithy> How can I debug a bzr+ssh connection
<keithy> the sftp connection works
<Tak> is bzr installed on the remote side?
<keithy> yes
<fullermd> Tak: Magical unicorns were going to be in 2.1, but the patch was rejected for not having tests   :(
<Tak> meh, I'm still running 2.0.3 anyway
<Tak> keithy: what kind of error are you getting?
<keithy> if I ssh to the mc, I can run bzr
<keithy> bash: bzr: command not found
<keithy> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<mwhudson> keithy: where is bzr on the remote machine?
<mwhudson> if it's not in /usr/bin, /bin or just a very few other places you might have to set BZR_REMOTE_PATH
<keithy> hmm
<keithy> doesnt the Mac os x installer do the right thing?
<mwhudson> no idea!
<mwhudson> log in and 'which bzr'
<keithy> its in /usr/local/bin/bzr
<mwhudson> yeah, that's probably not in the default path from ssh
<mwhudson> you can set the path as an environment variable or in the config
<keithy> but if I use ssh manually it is
<mwhudson> it's probably in some file your shell executes
<keithy> k
<mwhudson> there's no shell involved if you run ssh $host bzr
<keithy> ok Ill try that
<mwhudson> if bzr+ssh fails, that will fail
<keithy> yep bingo
<Tak> sweet, I'm up to 1g memory used for a lightweight checkout
<Tak> I hope it's over 50% done...
<keithy> ok so... someone needs to tell the mac os x installer people that their move doesnt work
<keithy> it used to be in /usr/bin/bzr
<fullermd> Er.  Yes there is a shell involved...
<fullermd> bash will read different rc files for an interactive vs. non session though, so you may need to set $PATH somewhere else.
 * Tak Out of memory - terminating application.
 * Tak cry
<keithy> ouch
<lifeless> Tak: what bzr version ?
<Tak> 2.0.3
<lifeless> hi jam
<jam> hi lifeless
<jam> you seem to be up early
<lifeless> I'm in NZ
<jam> is LCA in a differnt T?
<jam> ah
<lifeless> abentley: could you link the branch to review, I can't find it in mail./
<abentley> lifeless: https://code.edge.launchpad.net/~abentley/bzr-pqm/lpland/
<jam> lifeless: you seem to be having a good time at LCA
<igc> morning
<keithy> hi
<keithy> how to you set access rights to a repo
<keithy> or make it read only?
<keithy> for checking out only
<Lo-lan-do> keithy: I usually stick it into a location accessible through HTTP.
<keithy> hmm
<keithy> is there a checkout readonly?
<Lo-lan-do> Meaning?
<keithy> if people use that then there is no chance of them accidentally checking in
<keithy> i.e. deploy
<Lo-lan-do> Well, no, the plain HTTP server only has read access to the files in the repo.
<keithy> I set up ssh
<keithy> and bzr+ssh
<keithy> setting up http is a pain.
<keithy> can I just chmod it
<Lo-lan-do> You can chmod -R the repo, yes.
<keithy> k, thall have to do
<Lo-lan-do> That's how I do access control on my repos: each project has its group, and the repos are chgrped+chmodded.
<Lo-lan-do> So only members of group foo can commit to repo foo.
<keithy> k
<Lo-lan-do> Others can read only, or nothing, some repos are private (and therefore rwxrws---).
<Lo-lan-do> keithy: There's an administrator's guide on the website, as I found out today, with interesting points about common problems.
<keithy> k ty
<Glenjamin_> is there something other than the -D flags i need to use to get debug information?
<Glenjamin_> "bzr -Dhttp -Dauth update" isnt giving me any additional output
<lifeless> check ~/.bzr.log
<Glenjamin_> yeah, i realised that now, unfortunately it hasn't enlightened me on the problem at all :(
#bzr 2010-01-21
<thumper> switch hurts with object files
<thumper> perhaps switch should take into account ignored files (like .o)
<lifeless> thumper: ack
<lifeless> thumper: bites me all the freaking time
<thumper> lifeless: we should come up with a plan
<lifeless> thumper: needs  amerge conflict handler/resolver
<mtaylor> lifeless: debian/changelog conflict handler/resolver!!!! :)
<lifeless> mtaylor: doneish
<lifeless> mtaylor: see the recently added merge hook
<mtaylor> lifeless: w00t
<keithy> I cant add files in a directory has 2.0 changed
<keithy> are .cs files ignored by default?
<keithy> hmm
<RAOF> keithy: No, .cs files aren't ignored by default.  What are you trying to do and what is bzr doing instead?
<keithy> ok..
<keithy> I have a directory called updates
<keithy> and when I do
<keithy> bzr add updates/
<keithy> and bzr status reports unkown:
<keithy> so even basic stuff is defeating me
<RAOF> Well, it works here.
<RAOF> Can you pastebin the full terminal output of what you're doing and what bzr says in reply?
<keithy> k
<keithy> do you have a pastebin?
 * igc lunch
<keithy> keithy pasted "Bzr" at http://paste.lisp.org/display/93674
<RAOF> paste.ubuntu.com works.
<RAOF> keithy: Have you actually run âbzr add updates/â?  I don't see that in your terminal log, and that works for me.
<keithy> yes
<keithy> it does nothing
<keithy> and there are 300 files in there that I expected to be added
<RAOF> I guess another option would be âbzr add updates/*â, but I'm not sure why it hasn't worked already.
<keithy> no that didnt work weither
<keithy> ok I started again
<keithy> it worked this time
<RAOF> Heh.
<RAOF> I wonder what was wrong, though.
<meoblast> i pulled from another repo into mine and got http://sortedbits.ath.cx/bzr/nitrobot.bzr is permanently redirected to http://sortedbits.ath.cx/bzr/nitrobot.bzr/
<meoblast> is that a problem?
<meoblast> and should i be using merge instead?
<AfC> Not a problem
<meoblast> i'm trying to bring in someone's commit from his tree
<meoblast> into the main tree
<AfC> It's just saying you didn't have a trailing '/'
<meoblast> i did have a trailing / but ok
<AfC> [oh]
<meoblast> but i suppose that's not a problem
<AfC> no
<meoblast> is pull the correct function to use to bring commits from someone else's branch into the main branch?
<meoblast> merge doesn't do the job
<meoblast> my commit log looks like this if i do, 1, 2, 3,  4, 5, 6, 7, 1, 2, 3 ,4 ,5 ,6 ,7 ,8
<mwhudson> meoblast: merge is for combining lines of development, yes
<meoblast> mwhudson: so why does it duplicate commits 1 - 7?
<mwhudson> meoblast: it doesn't usually...
<meoblast> mwhudson: ok, fixed
<meoblast> when merging, do modified files in the merge come up as "modified:" as well?
<mwhudson> meoblast: yes
<meoblast> ok, thanks
<mwhudson> lifeless: can i object mildly to bzrlib.tests monkeypatching traceback?
<lifeless> mwhudson: you can object to traceback being brokeb.
 * igc dinner
<Ddorda> hey, Im trying to make a new branch, but for some reasons it says I don't have pernissions for that
<Ddorda> Ive done bzr init; bzr add; bzr push lp:~ddorda/gezer/po
<Ddorda> $ bzr push lp:~ddorda/gezer/po
<Ddorda> Permission denied (publickey).
<Ddorda> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<michaelis> Hi. Is there any way to show swedish letters in bzr-explorer in windows. Or at least space character. As it is now there's a % sign and some number afterwards.
<michaelis> Anyone?
<keithy> ahh! I made it
<keithy> ok...
<keithy> its taken me so long to get here I cant remember what my question was
<keithy> oh yes
<keithy> is there an automatic directory contents tracking feature yey
<keithy> yet
<keithy> so you can add a directory and all its contents
<keithy> non-manually
<keithy> bzr add-and-track-contents somedirectorywherepeopleputstuff
<michaelis> Why does bzr-explorer in win xp show %20 instead of a space character?
<keithy> it looks like add doesnt have this option arg
<mzz> keithy: err, using what tool? "bzr add directory" works for me...
<mzz> I must be misunderstanding your question
<mzz> bzr add --no-recurse directory for just the directory
<keithy> but what if someone adds a file after you have done bzr add directory/
<keithy> it is not managed is it
<maxb> No, and this is intentional
<NET||abuse> hey guys.
<NET||abuse> just trying to add files to a repo on a webserver, so i can download the site through bzr.
<NET||abuse> i am on the ssh root
<NET||abuse> on the ssh shell as the website owners user, not root, sorry
<NET||abuse> i have a web/ dir and a bzrsrc diri i've made
<NET||abuse> i did bzr init on the bzrsrc
<NET||abuse> then i copy in all the files under web
<NET||abuse> then bzr add *
<NET||abuse> then i try to bzr ci      it rolls through tons and eventually gets to a pdf, and hangs.
<mzz> if anything in there is huge it may just be slow
<NET||abuse> i can ctrl+c outa the commit action, but of course i'm scared that'll ruin something.
<NET||abuse> it's only 5.4MB
<NET||abuse> just sitting there.
<mzz> fishy
<NET||abuse> how can i debug this/
<NET||abuse> ?
<mzz> I'd consider strace-ing the process to see what it's doing
<NET||abuse> strace-ing?
<mzz> assuming that server runs linux
<mzz> from your description it sounds like you're doing something quite normal and the only reason I can think of for a hang would be disk io being slow for some reason
<NET||abuse> it's ubuntu dapper.
<NET||abuse> sorry, ubuntu hardy.
<NET||abuse> 8.04.3
<NET||abuse> so how do i run this strace
<NET||abuse> ?
<NET||abuse> still sitting there for the last 4 minutes.
<NET||abuse> ahhhhh, finished!!!!!! crap
<NET||abuse> woah, splity
<jam> morning all
<vila> morning jam !
 * vila almost miss the message in the storm....
<vila> s/miss/missed/
<michaelis> Hi everyone.
<michaelis> I could use some help.
<rubbs> what do you need michaelis
<michaelis> If a have an old revision and update it with bzr update, then my local changes still remain intact and I have to bzr commit to update the working tree. But after running bzr update, is there a way to see what the differences are between my local tree and the tree on the server?
<michaelis> Maybe it works as a shell command but it most certainly doesn't work in bzr-explorer.
<rubbs> not sure if this will work but try doing "bzr diff 'Path-to-remote-branch'"
<rubbs> oh, bzr-explorer... um. just a sec. I'll check
<michaelis> There are possibilties to define aliases in bzr-explorer but how do I run them in the explorer?
 * mzz wonders what RAOF is doing
<rubbs> michaelis: I"m not sure about either of those questions :( I'm sorry. I wish igc was up.
<rubbs> vila: do you know anything about bzr-explorer or know of anyone who does? michaelis has some advance usage questions.
<vila> rubbs: sry, my front-end is emacs :-/
<vila> michaelis: after an update, your working tree will be like the remote tree *plus* your local changes
<rubbs> np... just thought I'd ask. Better to ask and be wrong rather than not ask and loose out on an opertunity for help
<vila> michaelis: so doing 'bzr diff' will be enough
<vila> rubbs: you're welcome, I appreciate your efforts !
<vila> gee this IRC storm is worse every minute
<michaelis> Wait a minute.
<vila> ubottu: behave please, that's not how a good bot stands in a channel, your programmer will be ashamed
<rubbs> lol
<michaelis> But the problem is that the diff button in the explorer doesn't show the difference between two versions.
<michaelis> But there are possibilities to define aliases. How do I run them in the explorer?
<vila> michaelis: no idea about bzr-explorer
<vila> michaelis: 'bzr diff' will compare your branch tip to your working tree content, there is no need to specify anything
<vila> michaelis: just after a 'bzr update' you branch tip is the last revision commit on the remote branch, so this seems to be exactly what you want
<vila> s/you branch/your branch/
<michaelis> Thanks. I will try it out.
<keithy> hi
<keithy> sure its intendional, but its not the behaviour I need
<keithy> maxb:
<mzz> keithy: you may be interested in the --strict switch to commit, iirc
<keithy> ?
<keithy> hmm
<keithy> I just want to tell people to do a commit
<keithy> other tools are producing the files
<mzz> tell them to do a commit when?
<keithy> they work in their tools the tools product files
<mzz> bzr isn't some background process that monitors your dir for new files
<keithy> and at the end of the day they commit and or push
<mzz> there are a couple of operations (like bzr st, bzr ci, etc) that look at the working tree and will notice any new files
<keithy> well it has the notion of a directory
<keithy> do you need to tell bzr which lines of a flie to commit?
<keithy> bzr has directories as first class objects
<mzz> did you actually look at the --strict switch to commit I just mentioned?
<keithy> yes
<mzz> ok
<keithy> so the response form commit is to tell me to go and add files manually
<mzz> it's probably not hard to add a commit-like command or another switch to commit that just has it add any unknown files before committing
<mzz> would that actually do what you want?
<keithy> I guess I want a
<keithy> bzr add --auto blah/
<mzz> of course simply calling "bzr add; bzr commit" where you're currently running "bzr commit" would work too, in that case.
<mzz> adding some extra metadata to tracked directories that tells bzr they should get this automagic behavior seems like a hassle
<michaelis> Hi again.
<michaelis> When I select a branch in the repository I in the bottom window of the explorer that the text "no parent location selected yet" is showing. What does this mean and how do I fix it?
<michaelis> repository I in = repository I see in
<michaelis> I'll come back tomorrow and ask the same question. Bye.
<NET||abuse> ok, bzr crash on trying to check out a large repo, 3.1GB, probably due to backup files being included.
<NET||abuse> data files in forms of documents and in form of uploaded mp3'aac's and other audio files. etc
<NET||abuse> maybe i should cut them
<keithy> mzz: hassle? it seems obvious to me
<keithy> its hassle not having it
<mzz> keithy: please don't enable it for me, I'd end up accidentally checking in backup files and having to uncommit them a countless number of times
<keithy> k
<keithy> np I wont
<idnar> I'm surprised there isn't a bzr commit --add or somesuch
<quicksilver> I use bzr add `bzr unknown` quite often
<quicksilver> and sometimes bzr add `bzr unknown | grep -v no_not_that`
<keithy> ooo interesting
<quicksilver> keithy: typo, by the way. the command is unknowns, with an s on the end :)
<NET||abuse> aghghh
<NET||abuse> getting bzr: ERROR: zlib.error: Error -3 while decompressing: incorrect data check
<jam> vila: today is the day to cut 2.0.4 and 2.1.0rc1, do you know of anything pending that needs looking at?
<vila> jam: plain and simple: no, I'm pretty sure we landed everything timely
<vila> jam: if you need a nudge to land your autopack fix in rc1 I can do that for you :)
<jam> vila: its in pqm now
<jam> the ignore exceptions is something I'd like to land
<vila> jam: AIUI you're waiting for some feedback on perfs
<jam> they are correct enough for rc1, perf improvements can happen for 2.1.0 final
<jam> as a feature change, I think 2.1 is either all-or-nothing
<jam> Whitley didn't seem to respond to my last message, so I might pick that up myself
<maxb> Ooi, is it likely that 2.1.0rc1 will enter ~bzr-beta-ppa? That ppa is looking a bit unmaintained at the moment
<jam> maxb: afaik it is unmaintained
<bialix> interesting... merging 3 times with default merge algorithm, --weave and --lca produce 9, 9, and 11 conflicts
<jam> I certainly would like it to...
<bialix> is it normal that --lca produce extra conflicts?
<bialix> hi jam
<jam> bialix: as always "it depends" but I do know of cases where --lca conflicts and --weave doesn't
<jam> and IME it conflicts more than weave
<bialix> rarely I saw --lca produce less conflicts than --weave
<bialix> but very rarely
<bialix> as you say it depends
<bialix> but in most cases weave rules
<bialix> but today there is no criss-cross
<maxb> jam: Hmm.... if I was interested in helping it becoming maintained, how would I proceed?
<jam> maxb: as in, you personally maintaining it?
<maxb> I'm not sure I'd have the time to cover all the plugins on my own, but I'd certainly be interested in doing bzr and bzrtools
<jam> maxb: I believe we have some documentation on how to build, etc bzr for the ppa in 'doc/developers/ppa.txt'
<jam> with possibly some other needed info in 'releasing.txt', etc.
<jam> IIRC, johnf (who maintains ~bzr ppa) actually uses a slightly different methodology
<jam> but hasn't had time to update the documentation, etc.
<maxb> Perhaps the best way would be for me to set up a personal ~maxb/bzr ppa, do some packaging, and then find someone with ~bzr-beta-ppa upload permissions to review?
<jam> (using autoppa to handle releasing for many different platforms, etc.)
<jam> maxb: that would work
<jam> it would also let you experiment and get it right before we start having you send it on to others :)
<jam> btw, I have permissions
<jam> as do all core devs, I believe
<NET||abuse> hmm, when you branch do you use a command like   #> bzr branch bzr+ssh://user@ipaddr/var/www/webxyz/bzrsrc ./localdir
<NET||abuse> as i tried that and it was throwing libgz errors
<maxb> jam: If the PPA is known currently unmaintained, it would be useful to users if you could edit its description to declare that, for now
<jam> NET||abuse: that looks approximately correct. If you are getting libgz errors that normally indicates disk corruption
<NET||abuse> jam, wasn't at all, if i leave out the localdir location it works fine.
<jam> NET||abuse: that would indicate that the corruption is in "localdir"
<NET||abuse> localdir didn't exist
<jam> NET||abuse: if "bzr branch $SOURCE" works but "bzr branch $SOURCE ./target" doesn't, then something is pretty odd
<NET||abuse> yup,,
<vila> transient network error ?
<NET||abuse> if i try ./target when the dir exists, i get the already exists error
<NET||abuse> so i know i have to specify a non existant directory
<NET||abuse> transient: i'm on heanet, nation education authority network, very reliable,, no way it screwed up 3 times in a row.
<jam> NET||abuse: just as a strawman, try "bzr branch $SOURCE bzrsrc" which should be the default target
<jam> alternatively... what does 'bzr info' in the local dir say?
<NET||abuse> jam, well i've already downloaded it so what can i do..
<NET||abuse> trying again
<NET||abuse> the localdir says standalone tree( format: 2a) branch root: .   Related branches: parent branch: bzr+ssh://user@ipaddr/var/www/webxyz/bzrsrc
<NET||abuse> and that's after trying to branch and failing.
<jam> NET||abuse: it is possible that creating the branch succeeded but building the working tree failed
<jam> in the localdir, you could try
<jam> rm -rf .bzr/checkout; bzr co
<NET||abuse> http://paste.pocoo.org/show/168068
<NET||abuse> that's the crash log.
<NET||abuse> jam, that sounds right.
<NET||abuse> jam, did that, immediately again it tries to export the update and gets the error
<jam> NET||abuse: so I don't quite understand why it would not fail if you did not supply a target
<jam> understanding the difference may be the key
<NET||abuse> yeh i know, i've no idea why,
<jam> because *that* traceback clearly indicates garbage data
<NET||abuse> but every time i specify a locadir rather than letting it default to bzrsrc?
<jam> NET||abuse: is there a 'bzrsrc' already?
<NET||abuse> it's really weird behaviour.
<NET||abuse> nope
<NET||abuse> bzrsrc is only on remote
<jam> (note you can also always do "bzr branch ...; mv bzrsrc localdir"
<NET||abuse> yeh, i've done that already.
<NET||abuse> i have /home/me/development/projectxyz
<NET||abuse> so i've about 20 projectxyz's on the go in there
<NET||abuse> for different sites, bits of code work i do,
<NET||abuse> and my normal method of working on a site is in the user dir for the site admin, which usually has a www or web dir adjacent, is to create bzrsrc on all hosts i work on, then i can just copy the web dir's out of bzrsrc WT on the server to live serving location.
<gerard> anyone already wrote a testcase for bug #113809?
<ubottu> Launchpad bug 113809 in bzr "update performs two merges" [High,Confirmed] https://launchpad.net/bugs/113809
<gerard> otherwise I'm going to do that now
<jam> gerard: are you talking about the discussion from here: https://code.edge.launchpad.net/~craighewetson/bzr/update_with_local_commit/+merge/10320
<jam> AFAIK, nobody has stepped up to complete it
<gerard_> davidstrauss: I'm looking at bug #113809 and I've got some questions
<ubottu> Launchpad bug 113809 in bzr "update performs two merges" [High,Confirmed] https://launchpad.net/bugs/113809
<gerard_> you wrote the original patch right?
<davidstrauss> gerard_: yes
<gerard_> I made some minor changes, and wrote a blackbox test script
<gerard_> but I'm wondering what bzr is supposed to do for the test_smoke_update_checkout_bound_branch_local_commits test
<gerard_> because my patched version now give the error that there are both uncommitted changes and local commits, and that seems right
<gerard_> I'm a little confused about the situation there.... its a lightweight checkout of a branch (and a master)
<gerard_> and it does 1 commit to the master and 1 to the branch
<gerard_> then it makes some changes in the lightweight checkout
<gerard_> after that, it runs bzr update
<gerard_> I'd expect it to only get the changes from the branch
<gerard_> but it seems the smoke test (and current implementation) also expects the commit on master to show up
<gerard_> davidstrauss: any ideas?
<davidstrauss> gerard_: My fix does not affect lightweight checkouts
<davidstrauss> gerard_: Lightweight checkouts cannot handle local commits
<davidstrauss> gerard_: Nor did I write that test :-)
<gerard_> bzr blame to the rescue ;)
<gerard_> vila: you there?
<gerard_> davidstrauss: it seems my adaptation of your fix does affect lightweight checkouts :p
<davidstrauss> gerard_: Nor should it. My fix is irrelevant to lightweight checkouts.
<gerard_> yeah, it should be
<NfNitLoo`> Hrmm.
<NfNitLoo`> can I not rebase in a bound branch?
<NfNitLoo`> bzr: ERROR: Bound branch BzrBranch7('file:///home/codyc/bzr/smartbear/wc/') is out of date with master branch BzrBranch7('file:///home/codyc/bzr/smartbear/dynreport-newcols/').
<NfNitLoo`> I start with a clean checkout.  then try to rebase.
<NfNitLoo`> then I get the above error and get a working-tree with an odd state.
<NfNitLoo`> I'll try it in a standalone branch.
<NfNitLoo`> yeah, seems to be working much better w/o the bound branch.
<NfNitLoo`> maybe it should warn you about that?  ;)
<gerard_> how can I check I'm in a lightweight checkout?
<NfNitLoop> gerard_: gerard_ bzr info, I think.
 * NfNitLoop checks.
<NfNitLoop> yep, the Location: will say "light checkout root: <rootdir>"
<gerard_> this looks like the check it is using: if (tree is not None and tree.bzrdir.root_transport.base != branch.bzrdir.root_transport.base)
<gerard_> hmmm
<gerard_> gmbl
<gerard_> the real problem here seems to be that bzr update will happily do a string of merges, even if there are conflicts along the way
<gerard_> so if you update, it will merge with the branch you bound to, and then with the branch that branch is bound to etc etc
<fm_> just found an easily reproducable bug in bzr-gtk see https://bugzilla.redhat.com/show_bug.cgi?id=557573
<ubottu> bugzilla.redhat.com bug 557573 in bzr-gtk "[abrt] crash in bzr-gtk-0.97.0-2.fc12" [Medium,New]
<gerard_> is Robert Collins around?
<jam> gerard_his handle is lifeless
<jam> and he pretty much always lurks :)
<jam> I think he is at LCA this week, so I don't know if will be around to answer right away
<gerard_> ok
<gerard_> currently bzr update will keep on merging as long as it encounters a bound branch that is not up to date
<gerard_> I think it should stop after one merge and notify the user
<gerard_> because the way it currently is causes a mess with local changes and bound branches
<gerard_> even when there are no local changes but just conflicts between commits on the chain from master to bound branch to bound branch to bound branch
<gerard_> I found a comment in the code wondering if it is such a wise Idea to allow binding to an already bound branch
<Glenjamin> jfroy: are you around at all? i'm having some problems getting bzr-keychain to do anything
<NfNitLoop> gerard_: whoah, I never even thought of doing that.
<NfNitLoop> (binding to a bound branch.)
<Glenjamin> does that chain?
<gerard_> I think so....
<gerard_> but you can get conflicts in the conflicts in the conflicts currently
<jam> Glenjamin, gerard_: no, commit will stop if it sees a bound branch of a bound branch
<gerard_> so you can end up with a file.moved.moved etc
<jam> gerard_: the update you are talking about is different
<gerard_> jam: commit will, but update wont
<jam> and has to do with local commits + local changes + remote ones
<jam> gerard_: I'm not positive, but i'm pretty sure it only looks at 1 master
<gerard_> jam: really?
<gerard_> hmm
<jam> gerard_: yep, but in a heavyweight checkout you have
<jam> 1) the current revision of the working tree
<jam> 2) local modifications to the working tree
<jam> 3) the current revision of the local branch
<jam> 4) the current revision of the master branh
<jam> branch
<jam> and 'update' is currently designed to "smush" that so that
<jam> 1 == 3 == 4
<gerard_> and we can only do a 3 way merge
<gerard_> forcing people to do a local commit first isn't going to work
<kbrown> hi, I'm in the process of installing the latest Bazaar on OS X 10.6.2, found I had a previous v 1.3 installed apparently. Is there an uninstaller for 1.3 somewhere? Or what do I need to do to get rid of it?
<gerard_> because there are lightweight commits
<gerard_> so we should just do one of the merges (3,1,2)
<gerard_> and then push
<zsquareplusc> hmm, the fist time a package fails to install... and it's the bzr upgrade in karmic..
<gerard_> hmmm
<gerard_> this is hard
<gerard_> for a lightweight 1 == 3 right?
<gerard_> ah, it doesn't have to
<NfNitLoop> kbrown: I generally just run the installer and it will overwrite the old version.
<NfNitLoop> kbrown: if you want to be paranoid, you could find the bzrlib directory in your python libraries and delete it.
<kbrown> the one issue I discovered was bzr was in /usr/bin before and now is in /usr/local/bin, when I did bzr from Terminal it does not pick up the correct one it seems
<NfNitLoop> kbrown: aah, yep.  Delete the old one.
<NfNitLoop> kbrown: I have also wished for an uninstaller, but I don't think there is on. :/
<NfNitLoop> one*
<kbrown> did that, I suppose the bzrlib is ok then after the new install?
<NfNitLoop> kbrown: Yep.  the bzr executable will complain otherwise.
<NfNitLoop> (It'll tell you that the exe and library versions differ.)
<gerard_> bzr log doesn't show revision 0?
<fullermd> No, rev0 doesn't exactly exist.
<gerard_> aww
<gerard_> that's the classic vcs problem
<lifeless> revision 0 is a theoetical thing
<fullermd> It got caught in flagrante delicto with rev -1, so we banned it for life.
<gerard_> so I can have a theoretical thing with a date and a commit message?
<gerard_> doesn't sound too theoretical to me
<kbrown> NfNitLoop: thx
<gerard_> lifeless: anyway, I wanted to ask you something
<gerard_> about the double merge that bzr update sometimes does
<gerard_> if the first step has a conflict things get seriously messed up
* jam changed the topic of #bzr to: Bazaar version control  | try https://answers.launchpad.net/bzr for more help | http://bazaar.canonical.com/ | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.0rc1 and 2.0.4 have gone gold
<gerard_> I did quite some bzr annotate and it seems you were the one to add that second merge
<lifeless> yes
<lifeless> so bzr should just stop there
<gerard_> that's my current assumption
<gerard_> but I'm not too sure
<lifeless> I've checked with abentley who wrote the main merge code and he still thinks stopping there would be good
<gerard_> does the rest of the code allow a commit after the merge stops at that point?
<gerard_> something in the situation has to change, otherwise rerunning merge will not have any effect
<gerard_> ehm, rerunning update*
<lifeless> fix the conflict, run update again.
<lifeless> should work f ine in the postulated situation.
<lifeless> bbiab, fooding
<gerard_> so only stop when there is a conflict?
<gerard_> because it seems the policy of bzr to always explicitly commit after a merge
<lifeless> yes, that should be fine here.
<lifeless> you won't need to commit after the first merge in this situation.
<lifeless> because its an update.
<Kilroo> I keep feeling like I've almost found the silver bullet, and then realizing I skipped a step.
<Kilroo> A lot of the stuff I deal with at work is still on raw FTP with no source control, despite a very slow process that has been under way for several months now to try to move everything to svn (and the stuff that is on svn so far is doing it wrong).
<Kilroo> I was trying to figure out a way that I could still use bzr to make my own life easier, but I keep running up against the fact that in order for it to work, either everyone else would have to stop doing direct ftp, or I'd have to be able to install bzr on the server.
<Kilroo> Oh well.
<NfNitLoop> Kilroo: sounds like a good time to look for a new job? :p
<fullermd> I was thinking that a silver (or other metal) bullet would be a useful tool to stop the direct FTP   8-}
<NfNitLoop> Seriously.  If you're at a company that's seriously doing development via ftp in 2010... run.
<Kilroo> Yeah, well, if I can get them to stop dumping major database projects on me for a little while, I'm going to try to do something to change that.
<Ddorda> can anyone help me? bzr doesn't want to upload my new branch. Ive done init and add, but it says I don't have permissions when it gets to push...
<Kilroo> Unfortunately my campaign is going to involve going up against a systems administrator who is leery of DVCS (and I think might actually like cvs better than svn) and thinks fusionforge is good stuff, and two levels of supervisors who are going to be very hard to sell on using something like Redmine instead of the VIP Task Manager program we're using now...
<Kilroo> I've been reading through some stuff about the differences between git and bzr lately. It can get pretty interesting.
<gerard_> lifeless: not performing the second merge loses your uncommitted changes
<gerard_> it's the first that needs skipping
<Kilroo> One sentence I thought was pretty apt in a lot of ways was something along the lines of how git focuses more on the code and bzr focuses more on the developer.
<gerard_> Kilroo: I like the power of git, but I'm pleasantly surprised by the versatility and code quality of bzr
<gerard_> M1->M2  M1->B2 M1->(uncommitted changes)
<NfNitLoop> Ddorda: Did you forget a 'bzr commit' step?   also, bzr push *will* fail if you don't have write permission.  What type of location are you pushing to?
<gerard_> first step: M1->M2 M1->B2->(uncommitted changes) M1->B2->(uncommitted changes)
<gerard_> second step: M1->B2->M2->(uncommitted changes) ... ...
<gerard_> seems the most logical to me
<Kilroo> In some ways it seems to me that the way git evolved is (very) roughly analogous to coming up with the 2a format and then building bzr to interact with it
<gerard_> yeah
<gerard_> and building it using mostly shell scripts
<gerard_> but still, it works quite well for such a big hack
<Kilroo> One of the assertions made a few years ago by a git advocate regarding whether bzr is truly distributed also led me to thinking that one of the key differences in philosophy between the two is that git is sort of distributed from the ground up, whereas bzr is distributed more as the logical extremity of starting from the centralized mindset and decentralizing it.
<lifeless> gerard_: uh
<gerard_> hehe
<lifeless> gerard_: I don't quite follow, but I'm tired after a week of conference
<lifeless> put it in the bug please, so I can mull on it. Note that *both merges are needed*. But we can choose to do one later.
<gerard_> what I mean if that a checkout has local changes, those need to go to the bound branch first, and only with the second update + commit they go to the master
<gerard_> I'm tired too, it's getting late
<gerard_> I'll attach what I have now to the bug
<Kilroo> Or to put it another way, git is (to put it in git terms) a content-addressable file system with version control built on top of it and collaboration built on top of that, whereas bzr is a version control system that is largely designed for collaboration but works quite well for solo work anyhow.
<Kilroo> I think I'll stop making vague comments about stuff I halfway understand now. At least for a little while.
<Kilroo> I still think it's funny that bzr can do a better (or at least easier) job of fixing the wrong way we're using subversion than subversion can though. Even without switching to bzr.
<Kilroo> ...in case you're curious...for some strange reason, the projects that have already been moved to subversion have a production repository and a development repository, instead of branches. It's basically like having plain ftp with a production server and a dev server, except with history and accountability.
<Kilroo> But it does still beat having ONE server with a lot of files named things like index_v2_test4.php
<igc> morning
<Kilroo> maurng.
<gerard_> Kilroo: some people clearly don't understand the idea of version control
<gerard_> but well, sometimes I don't either
<gerard_> confusing stuff
<Kilroo> gerard_: I think part of the issue is that for a while the development team was either small enough or having enough turnover that nobody even thought about how good an idea version control would be long enough to do anything about it
<gerard_> when I started at my job a few months ago they weren't using any vcs ;)
<gerard_> I am the 4 developer so it isn't that big of a team
<Kilroo> To be honest, at first I wouldn't even have understood the problem with the way we're using svn.
<Kilroo> The only source control I'd used before was VSS with a max of four developers (two most of the time I was there).
<Kilroo> I actually came across bzr specifically because of its ability to use an ftp dumb server, and branched out to learn about git and hg and darcs and so forth from there.
<Kilroo> I keep meaning to sit down and write out a thorough explanation of how awesome a DVCS would be and how svn would be inferior and try to push for adoption.
<Kilroo> I have to admit, though, that despite how much I like bzr, I'm tempted to try out the other alternatives and make my final recommendation based primarily on which one has the best eclipse plugin. Which I suspect at the moment might be Mercurial.
<mzz> Kilroo: I'm not a heavy svn user, but afaik the idea is for bzr to be a *superset* of svn, not just an alternative. So other than various kinds of inertia (learning slightly different tools, converting repos, etc) bzr is imho a better choice than svn
<Kilroo> mzz: I agree. Matter of fact, now that the latest beta of bzr seems not to choke on our svn repositories, I am hoping to find time to set up so that I am at least using bzr as an svn superclient and for local branching, even if I can't sway the powers that be on the main choice.
<mlh> svn is a worse choice than bzr,git,hg in every aspect except unfortunately where it matters: mind share and tool/system/ide integration
<Kilroo> From what I've gathered, while some things I've read seem to imply that git-svn has had the shortest cumulative duration of not working due to new releases of one side of it or the other, bzr works more seamlessly with svn than any of the other DVCS bridges.
<ronny> mlh: well, my ide has better hg/git/bzr inregration than svn integration :P
<mlh> er, change 'matters' for 'sometimes matters for organisations in a corporationy way'
<mlh> ronny: NICE!
<gerard_> lifeless: attached a patch to prevent update when there are local changes + local commits
<mlh> what ide .. emacs?
<ronny> mlh: pida
<gerard_> might have some time to look at stopping after the first merge this weekend
<ronny> mlh: well,, partial reason is - i coded the current vcs integration, and svn just sucked
<ronny> even worse than git
<Kilroo> I also haven't really gotten the impression that any of the other DVCSes besides bzr are particularly interested in working on two-way integration with the other tools. Imports, yes. Exports, maybe. Use X to work directly with repositories of Y...bzr seems to be the only one pushing for it much.
<ronny> bzr/hg works best, but i strongly prefer hg cause its api works like my mind ticks
<ronny> Kilroo: there is hg-git, hg-svn, and jelmer pushes for a hg-bzr based on bzr-hg
<ronny> and git is kind of lost, cause it lacks custom metadata
<Kilroo> ronny: I think I'd noticed hg-bzr but hadn't come across hg-git. And I'd almost be inclined to consider that to be bzr pushing for hg-bzr more than hg pushing for it, 'coz I mostly know of jelmer for his bzr work.
<ronny> Kilroo: jelmer is a bzr core dev
<ronny> well, and it is based on bzr-hg
<ronny> there is a certain metadata gap, cause hg handles file-histories different than bzr
<Kilroo> He could have just been a casual contributor and that would still be what I knew him for. The only dev whose name I've really latched onto for any of the others is, uh, Torvalds.
<ronny> yes, that borderline nut with too much media pressence :P
#bzr 2010-01-22
<ronny> to the logs: ignore the lie above :P
<Kilroo> I hope Eclipse fixes whatever bug bzr 2.1.0b4 causes bzr-eclipse to expose in Helios.
<Kilroo> Assuming that the guy who responded to my question about it by saying it's an eclipse bug is right.
<Kilroo> I need to capture some logs and figure out how to report it. And where.
<EdWyse_Office> if I didn't know what I was doing and "mv /foo1/branch /foo2/branch" and now it says, 'bzr: ERROR: No repository present: "file:///foo2/branch"', how do I fix that?
<Kilroo> How much else have you done since?
<EdWyse_Office> That's it.
<EdWyse_Office> I just needed to get the branch off that nfs mount.
<Kilroo> Would "mv /foo2/branch /foo1/branch & bzr mv /foo1/branch /foo2/branch" work then?
<Kilroo> Oh wait.
<Kilroo> Don't you need a repo on top of it?
<EdWyse_Office> Oh! Right! I forgot I made /foo1 a repo!
<EdWyse_Office> Thanks.
<Kilroo> I mostly mess around with shared repositories so far so sometimes the other way of doing it muddles me
<Kilroo> Given the use case you're talking about, would bzr branch /foo1/branch /foo2/branch be preferable, though?
<Kilroo> I'm a noob, so if it wouldn't, I just don't understand why yet.
 * igc food
<lifeless> EdWyse_Office: move it back, then do 'bzr branch /foo1/branch /foo2/branch
<jfroy> Glenjamin: hey
<chromakode> is it possible to change committer names/emails on old commits?
<Peng> chromakode: No.
<Peng> Well.
<chromakode> I'm aware of some voodoo to do it in git
<chromakode> was wondering if there's an equivalent in bzr-land
<Peng> chromakode: bzr-fastimport can do it -- quite easily, too -- but you'd wind up with new revision IDs, so unless you put the nuclear launch codes in your email address, it's usually not worth it.
<chromakode> right, yep
<chromakode> I understand that issue
<chromakode> not worth it :)
<chromakode> is doing this technically impossible with bzr (does it mess up hashes?)
<Peng> Like I said, you can do it with bzr-fastimport.
<Peng> I dunno if it changes the hashes.
<chromakode> understood. please excuse my ignorance of bzr internals, but is the committer info hashed?
<chromakode> okay
<Peng> Still, bzr is not designed to go changin' stuff. :P
<chromakode> thanks, just a matter of curiosity!
<Peng> :)
<chromakode> altering history never works out
<chromakode> I learned that watching 90s cartoons
<Peng> You can find a few "@mylaptop" commits in the history of Bazaar itself. :D
<chromakode> haha
<chromakode> it's hard for me to let go of the ideal commit log
<mwhudson> bzr also has a commit with revid 'A' in it's history :-)
<mwhudson> -' grrr
<chromakode> huh! what happened there?
<Peng> The hypothesis I've heard is that a unit test accidentally committed to the real history, and the developer apparently didn't catch it in time.
<chromakode> ha!
<Peng> The commit message is "silly commit" and it adds a file called "b". :D
<chromakode> that's a wonderful piece of trivia
<lifeless> it is a unit test
<lifeless> its still in the tree
<SamB_XP_> but it somehow went awry?
<lifeless> early unit tests weren't as isolated
<chromakode> haha.
<chromakode> someone clearly ran a unit test on their dev tree
<lifeless> how else would you test?
<chromakode> ;)
<Peng> That revision also suffers from the "@mylaptop" committer ID problem. :D
<chromakode> hmm
<chromakode> maybe that could be avoided if there was an "Are you sure?" prompt if you try to commit with an unset email/username
<lifeless> chromakode: no, because the test suite runs with a null UI
<lifeless> chromakode: the /commit/ is what the test suite wanted
<chromakode> I realize that won't help for the test suite
<chromakode> but it might help me from being stupid when I'm branching on a laptop
<lifeless> if you're interested, its revno: 0.2.1
<chromakode> the tree is still downloading :/
<Peng> You can also do "bzr log -r revid:A".
<chromakode> is there any reason bzr requires the -r argument?
<lifeless> Peng: the machine name is valid btw, not really a problem :P
<lifeless> chromakode: because bzr log FOO logs the branch FOO
<Peng> Or the file FOO.
<chromakode> is it ambiguous if there's a colon in there and no file?
<Peng> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/0.2.1 :D
<lifeless> its easier to tell people 'to control the revision use -r'
<chromakode> sorry if this is annoying, I've just always been curious about these things
<lifeless> than to say 'if you pass a revision that is not a branch or a file it will work, and when you want a branch or file *and* a revision use -r'
<chromakode> ah, good point
<chromakode> it's just kind of odd to me when I only want a rev, not a file
<Peng> It's more consistent with other commands, too.
<chromakode> yeah, it's definitely more consistent
<Peng> For example, "bzr branch -r 123 some_location"
<Peng> chromakode: It's not annoying. :) Besides, I've asked lifeless far more weird questions than you have. :P
<chromakode> yes, I should just develop the semantic association that -r is always revision
<chromakode> okay, I have one more question, regarding workflow
<chromakode> do you create lots of new branches when you need to work in multiple directions at one? do you branch when you're fixing a bug? how do you manage the directory structure of your branches?
<chromakode> or do bzr users tend to shelve and unshelve more?
<Peng> I just create lots of branches.
<chromakode> I realize they're separate commands with different purposes, but I wonder what the dominant context-switch approach is
<Peng> Some people create multiple branches but just use one working tree, "bzr switch"ing to the branch they want.
<chromakode> Peng: how do you structure your directories? a bunch of branches inside a repo?
<Peng> I think there are some plugins for making this easier.
<Peng> chromakode: Yeah.
<chromakode> ah, is bzr switch relatively new?
<Peng> No.
<chromakode> okay. I thought I'd read about it somewhere
<Peng> chromakode: I know one of Bazaar's developers creates a subdirectory for each version. I don't, but I don't create a lot of branches either. :P
<chromakode> cool. thanks for answering my questions :)
<Peng> :)
<wolter> does bash use bash programmable completion?
<wolter> bzr
<wolter> *
<Kamping_Kaiser> does for me, i'm guessing most packages of it would
<Kamping_Kaiser> at leats, if i understand correctly ;)
<wolter> yeah, but i mean does it do it through bash? I don't see nothing about bzr in /etc/bash_completion
<Kamping_Kaiser> i have /etc/bash_completion.d/bzr{,.simple}
<wolter> oh
<wolter> nice
<wolter> i didn't know about that dir, but its awesome that exists
<chromakode> yeah!
<Kamping_Kaiser> :)
<vila> hi all
<EdWyse_Mobile> When I decided to add our pdfs and graphics for our web site to the local branch, then push to the remote repo (a little over a gig) using the windows gui, it gets to "fetching revisions:inserting stream", the status bar at 50%, and stops. 20 minutes and counting so far. Is that expected behavior?
 * igc dinner
<gerard_> hey all
<Glenjamin> jfroy: still around? i've installed keychain but i just get the command line prompt when i try and access a protected branch
<Raim> Glenjamin: did you add the relevant key to ssh-agent? (either with ssh-add or keychain)
<Glenjamin> it's a username/password auth which i'm trying to get handled by bzr-keychain on mac os x
<Raim> ah, sorry. just made a guess :)
<starenka_> can sbdy tell me how to run bzr serve via ssh? i tried  bzr serve --allow-writes --inet --protocol=ssh, but no avail. there'sno help about the protocols :(
 * GaryvdM waves at bialix
<bialix> heya Gary!
 * bialix waves back :-D
<bialix> GaryvdM: what you think about pyqt 4.7?
<GaryvdM> bialix: I have not installed it, so I don't really know. It's good though that they have installers for more versions of python.
<bialix> yes
<bialix> I fear that will continue to ignore 2.5, but apparently it's not
<GaryvdM> I think for the windows installers, we should upgrade only early in the next cycle.
<GaryvdM> not now, which is what i think jam is going to do.
<GaryvdM> I'm installing bzr onto a clients mac atm.
<GaryvdM> And it is working :-)
<bialix> cool!
<GaryvdM> bialix: It's not that hard. Did you know that we have an installer that includes pyqt (but not qt.) I did not.
<bialix> for Mac?
<GaryvdM> Yip
<bialix> there is some advice on bazaar.canonical.com/QBzr
<GaryvdM> http://wiki.bazaar.canonical.com/MacOSXDownloads
 * bialix has no mac to play with, alas
<bialix> that's really cool
<bialix> GaryvdM: should we update our page then? http://wiki.bazaar.canonical.com/QBzr ?
<bialix> it said: NOTE: OSX users will also need to install PyQt. Instructions are available from Installation of PyQt on Mac OS X.
<GaryvdM> Yes, we can just point them to http://wiki.bazaar.canonical.com/MacOSXDownloads
<bialix> I trust your experience :-)
<GaryvdM> I'm trying to use the bzr packaging scripts to update the qbzr ppa for the first time.
<GaryvdM> I'm getting an error with update-changelogs.sh
<GaryvdM> see http://paste.ubuntu.com/360630/
 * bialix waiting for jam and 2.1.0rc1 bzr.exe installer
<bialix> GaryvdM: maybe it searching case-insensitive?
<bialix> err, sensitive I mean
<bialix> strange
<bialix> really
<GaryvdM> dch can't find changelog when run from the script, but if I run dch manually, it works?
<GaryvdM> Hmm - I removed the "-c changelog" from line 30 of update-changelogs.sh. Not sure how it works normally
<GaryvdM> I don't think so, maybe the bzr packaging branches have a different layout.
<GaryvdM> ah, that is the case.
<jam> bialix: I'm waiting for information about how to get tbzr 0.5.0 built
<jam> naoki added i18n, but I don't have the .mo files he wanted bundled
<bialix> hi jam
<bialix> ok
<GaryvdM> Hi jam
<jam> I haven't gotten a response from him, so I don't really know
<jam> hi GaryvdM
<jam> morning all
<vila> morning jam
<GaryvdM> jam: For qbzr, we have to do >python setup.py build_mo -f
<GaryvdM> maybe it is the sameqQ
<GaryvdM> ?
<jam> GaryvdM: could be. I do see a build_mo in setup.py
<jam> He didn't add any such step to the release process when he updated the installers
<jam> but I bet he wasn't sure how the process went, and probably had already done certain steps manually
 * bialix looks
<GaryvdM> bialix: I'm thinking we should do our releases as follows: 0.19b1  0.19b2 ... 0.19bn  0.19rc1*  0.19rc2 0.19.0 0.19.1
<GaryvdM> Like bzr core.
<bialix> to be in sync with bzr?
<bialix> this is for 2.2?
<GaryvdM> Yes
<bialix> interesting idea
<bialix> why not
<bialix> jam should be happy
<GaryvdM> The betas don't have to be in sync, but the rest should.
<jam> GaryvdM: you can certainly do that, but are you sure you're going to release in sync? Especially for stable releases...
<bialix> jam: tbzr uses the same code as qbzr for i18n
<bialix> jam: python setup.py build_mo actually builds mo
<bialix> they are in locale
<bialix> can I help you with installer?
<GaryvdM> jam: True, we would probably have less stable releases than bzr.
<bialix> rats, naoki pushed loom branch to lp
<bialix> bzr produce not very nice error for this
<bialix> !pastebin
<ubottu> For posting multi-line texts into the channel, please use http://ubuntu.pastebin.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from  command line | Make sure you give us the URL for your paste - see also the channel topic
<bialix> http://ubuntu.pastebin.com/m5c1d1aca
<jam> bialix: If you want. For now I have to update the build process to add "build_mo" into the tbzr build steps
<jam> and currently that is blocked on getting "msgfmt" installed
<jam> which is blocked on cygwin upgrading from 1.5 to 1.7...
<bialix> jam: how you're handle qbzr then?
<bialix> it uses the same stuff
<jam> bialix: you version qbzr
<jam> qbzr's .mo
<bialix> and explorer too
<bialix> no
<jam> I believe
<bialix> we don't version mo
<jam> *shrug* the build works
<jam> running build_mo manually says 'no msgfmt' fonud
<jam> fonud
<jam> found
<bialix> they are present in tar.gz
<jam> and I don't see it on my system
<bialix> no, sorry
<bialix> mo is purely build time files
<bialix> can you install them for windows not cygwin?
<bialix> running build_mo manually -- maybe something wrong with your path?
<jam> bialix: it is possible, running 'c:\Python25\python setup.py build_mo' doesn't work in tbzr or qbzr
<jam> are you sure the .mo files are in the installers?
<bialix> I can test you 2.0.4 if you want
<bialix> but naoki patch for installers is wrong re iss.cog
<bialix> he's added line: ;     cog.outl('Source: "%s\\locale\\*.mo"; DestDir: "{app}\\doc\\tbzr"; Flags: createallsubdirs ignoreversion recursesubdirs; Components: tortoise' % os.environ['TBZR'])
<jam> I see the .mo files for one of the older builds
<bialix> should be:
<jam> (2.0.3 here)
<bialix> oops
<bialix> jam: for c:\Python25\python setup.py build_mo' you need not cygwin msgfmt. you can install gettext from gnuwin32.sf.net
<jam> bialix: I *can* but I don't want to do my own dependency tracking if I can avoid it
<jam> setting up a build host is already a huge pain
<bialix> I have some free time today
<bialix> I can help
<jam> I needed to install gettext-devel
<jam> and msgfmt is found
<jam> oddly, I don't know how the .mo files would be in 2.0.3...
<jam> running python setup.py build will happily skip creating .mo files
<jam> it issues a warning to the terminal, but doesn't stop the build process
<jam> might want to look closer at that
<bialix> jam: it seems absent msgfmt was the main reason
<bialix> because you only need setup.py build to build both mo and other tbzr stuff
<bialix> there is used such trick as: build.sub_commands.insert(0, ('build_mo', None))
<jam> bialix: missing msgfmt, but I didn't notice because when build_mo failed it didn't stop the build
<bialix> it may be my fault
<bialix> I did not return anything from build mo
<jam> however, what is your thoughts on the changes to the iss script?
<bialix> they seems a bit wrong
<bialix> based on the code in tbzrlib/i18n.py it should be locale dir right along bzr.exe
<bialix> jam: I think that line should be ;     cog.outl('Source: "%s\\locale\\*.mo"; DestDir: "{app}\\locale"; Flags: createallsubdirs ignoreversion recursesubdirs; Components: tortoise' % os.environ['TBZR'])
<bialix> ; cog.outl('Source: "%s\\locale\\*.mo"; DestDir: "{app}\\locale"; Flags: createallsubdirs ignoreversion recursesubdirs; Components: tortoise' % os.environ['TBZR'])
<bialix> jam: do you see where to add that line?
<jam> I understand where that would go
<jam> I'd just like confirmation that it does the right thing
<jam> bialix: so I can confirm that 2.0.4-1 does *not* have the .mo files
<bialix> jam: based on the code in tbzr:
<bialix> def _get_locale_dir():
<bialix>     if hasattr(sys, 'frozen'):
<bialix>         base = os.path.dirname(unicode(sys.executable, sys.getfilesystemencoding()))
<bialix>         return os.path.join(base, u'locale')
<bialix> sys.executable is the bzr.exe path? I guess
<bialix> or other tbzr exe binary
<bialix> jam: do you remember how to get exit code of other program in windows shell?
<bialix> found
<jam> %ERRORCODE% or %ERRORLEVEL% ?
<bialix> jam: about build_mo exit code: that's seems intended behavior: http://ubuntu.pastebin.com/d137823cd
<bialix> I can change this if you think it's desirable
<bialix> do you think?
<jam> bialix: so doing that means that when I don't have msgfmt installed it fails to build but doesn't stop the build process
<bialix> or I can produce error if --force flag is used...
<jam> I would think that you would want to fail if you can't build the i18n files
<jam> at least for building the official installers
<bialix> yes, for official installer it makes many sense
<bialix> I can change this for qbzr
<jam> I'm not a big fan of building the installer and having users tell me it is broken
<jam> though it seems to happen often enough
<bialix> why for users then? ;-)
<jam> well, I wouldn't care except they expect me to do something about it
<bialix> :-)
<jam> and spending an hour building yet-another installer isn't my ideal time sink
<bialix> except - expect. nice
<bialix> like a palindromne
<bialix> jam: my guess about iss.cog was correct
<jam> yeah, looks like
<bialix> based on naoki answer
<jam> ok, the build at least succeeds this time
<bialix> great
<jam> now to sort out the installed location issues
<bialix> at least we found problem with build_mo
<bialix> I will update the builders for qbzr, explorer and MP for tbzr
<smartgpx> Greetings. I have a query about 'bzr revert' not acting as I expected.
<smartgpx> I thought in general terms it aligned the files in a WT to correspond to the state of the tip revision.
<smartgpx> but that's not happening.
<smartgpx> Tried with 2.1.0b4 on WinXP and 2.1.0b1 on linux with same result
<bialix> smartgpx: it does
<smartgpx> bialix: not for me. but maybe I am misunderstanding. can I email you a noddy script to look at?
<bialix> you can pastebin it
<bialix> or email
<GaryvdM> smartgpx: it brings it to the state of the branches tip
<GaryvdM> smartgpx: not the bound branch
<GaryvdM> *not the bound branch's tip
<smartgpx> does 'inventory' report on the branches tip? [this is simple personal stuff, no bound branches involved.]
<BusMaster> I wish to get a branch from several commits ago. How should i do that?
<GaryvdM> smartgpx: no - bzr inventory --help -> Purpose: Show inventory of the *current working copy* or a revision.
<GaryvdM> for branch tip:   bzr inventory -r -1
<vila> BusMaster: bzr branch -r -4 ../new-branch
<vila> err
<vila> BusMaster: bzr branch -r -4 old-branch new-branch
<BusMaster> vila, old-branch can be something like lp:~sagar/+junk/sarathi ?
<BusMaster> vila, or is that the repository ?
<vila> BusMaster: sure, can be any valid branch URL
<bialix> heya vila!
<BusMaster> vila, ok thanks
<vila> hey bialix !
<smartgpx> regarding revert - see http://pastebin.com/d5b917d0c
<smartgpx> I expected to get back to a working directory with only the one committed file in it.
 * GaryvdM looks
<vila> smartgpx: there is no changes so revert is a no-op
<GaryvdM> smartgpx: bzr does not touch unversioned files
<vila> yeah, no changes on versioned files
<GaryvdM> If you did bzr add, and then bzr revert, "two" would be deleted.
<GaryvdM> You may find clean-tree helpfull here
<smartgpx> add and revert not sucessful - http://pastebin.com/d79a6bb18
<GaryvdM> sorry - I guess I was wrong about that then.
<smartgpx> bzr help revert says "Any files that have been newly added since that revision will be deleted" so it doesn't seem to be working right?
<smartgpx> This makes providing a 'clean' reply to ANSWER:98183 a bit complicated?
<smartgpx> No, actually it doesn't if you are prepared to Branch from an old revision rather than 'winding back' the tree you currently have.
<jam> vila: are you still around?
<jam> I was wondering if you've seen http://code.google.com/p/python-ntlm/
<jam> for handling NTLM auth proxies for bzr
<vila> jam: hmm, interesting
<jam> in the short term, there also seems to be: http://sourceforge.net/projects/ntlmaps/
<vila> jam: if it's done as AuthHandler as it seems, it may be easy to integrate
<jam> which seems to run a local app
<jam> that you proxy through, which then proxies via NTLM for you
<jam> hard for *me* to test, as I don't have an NTLM proxy :)
<vila> jam: but keep in mind that most NTLM proxies also accept Basic so we have yet to find people really blocked by the lack of NTLM support
<jam> and I'm guessing neither do you
<vila> jam: you guess right :-/
<jam> well, bug 363019 is blocking someone...
<ubottu> Launchpad bug 363019 in bzr "bzr fails to do proxy authentication" [Low,Confirmed] https://launchpad.net/bugs/363019
<jam> as is bug 244879
<ubottu> Launchpad bug 244879 in bzr "http urllib implementation doesn't support NTLM auth scheme" [Medium,Confirmed] https://launchpad.net/bugs/244879
<jam> at least gareth white claims so
<jam> he says he used a different intermediate proxy for it
<vila> jam: I *am* looking at it, but it seems the problem in 363019 is that we can't even ping code.lp.net
<vila> Gareth found a workaround so he isn't blocked :D
<jam> vila: so for 363019 the don't even know if there is a route to c.lp.net?
<jam> couldn't they use a browseR?
<vila> jam: I asked if he can ping
<jam> vila: looking at the last traceback:ConnectionError: Connection error: Couldn't resolve host 'code.launchpad.net' (11001, 'getaddrinfo failed')
<jam> doesn't look like it has anything to do with proxies
<jam> unless they are proxying DNS requests...
<vila> I seem to remember David Cornoupeau talking about a config where the DNS was proxied, but I didn't make sense (to me) at the time
<jam> I've heard of using DNS as a secret proxy
<jam> you make request for certain 'well-formed' IP addresses, and it proxies the actual http responses, etc.
<jam> http://thomer.com/howtos/nstx.html
<jam> wow. even has "IP-over-ICMP"
<jam> so you use ping packets to get your data...
<vila> jam: I don't want to hear more about that :D
<vila> jam: hmm, looking at http://code.google.com/p/python-ntlm/, it's doing far too much to be re-used directly (at least the handler part),
<vila> http://code.google.com/p/python-ntlm/source/browse/trunk/python26/ntlm/ntlm.py seems to be the needed part, but it makes my eyes bleed :-/
<jam> vila: it doesn't seem that bad, just foolish
<jam> rather than using code comments
<jam> they use variables
<jam> like calling struct.pack 20 times
<vila> and assert
<jam> rather than 1 pack with 20 args
<vila> jam: I didn't say bad :)
<vila> Or I would have said: it makes my *heart* bleed :)
<jam> I think it is ~ reasonable when you are debugging, but for an actual implementation, it seems it could be made a lot better
<vila> +1
<vila> jam: and no tests :-{
<jam> in this case, running against a real server is probably the best test
<vila> s/best/first/
<vila> :D
<vila> jam: anyway, thanks for the pointer, that can at least be a starting poijnt
<jam> vila: no, *best* test (most authoritative)
<vila> jam: no, *first* test, *one* server, we're talking MSoft here, do you really think a single server will be enough ?
<jam> vila: it is enough if you're the guy stuck behind that particular proxy :)
<vila> yeah, but I'm the guy maintaining the code ;D
<bialix> jam: can I download new installer, or you're not finished it?
<jam> bialix: I'm rebuilding 2.0 right now, and I'll be doing 2.1 next
<bialix> ah, ok
<bialix> so, I'll check tomorrow
 * bialix waves bye
<Ddorda> hey. Im trying to make a new branch, done init and add, but when I push it says I don't have permissions for some reasons :S
<Ddorda> what might be the problem?
<jam> \o/ my passport just arrived
<vila> YES
<vila> pfew
<jam> igc: what are you doing awake... :)
<vila> jam: we use KnownGraph to caluclate revnos for pack-0.92 too right ?
<jam> vila: yeah, I don't think reading from the index is fast-pathed
<jam> but we should still use KG
<vila> jam: so loading the graph for say, mysql, took how long ? I have 1sec in mind but it may be for bzr itself
<jam> vila: mysql is now in 1.9 format
<jam> so gets btree indices
<jam> which have the faster path
<vila> jam: the log code says: "generating the merge graph can take 30-60 seconds" that's not true anymore I think
<vila> jam: even better then
<jam> vila: so for their 6.0 branch, doing:
<jam> time py -c "from bzrlib import branch; b = branch.Branch.open('.'); b.get_revision_id_to_revno_map()"
<jam> takes 2.2s
<jam> with 68.8k revisions
<jam> for emacs with 106,080 k revisions, I see it taking 4.2s
<jam> well 106,080 or 106k :)
<vila> good, thanks, I'm not there yet but I'm pretty sure I understand what happen for that bug: 1) we fail to find the rev in the ancestry and display garbage instead, but 2) we just shouldn't *force* that a rev be in the direct ancestry when dealing with arbitrary revids or should we....
<jam> vila: which bug?
<jam> the log not-in-ancestry stuff?
<vila> yup
<newz2000> can I use bzr to manage code that's in a CVS repository? i.e. bzr co cvs:something
<jam> newz2000: unfortunately no
<jam> it is too hard to get stable revisions out of cvs, so you have to go through a converter
<newz2000> ok, thanks jam
<jam> newz2000: I believe there is a 'bzr cvsserve' which lets people checkout a bzr branch as though it were cvs, though :)
<newz2000> I'll suffer through some how. :-)
<jam> vila: this seems like a slow week for 3rd-party submissions, did it seem like that for you?
<vila> jam: yes, on the other hand, we have an rc coming out so people should know there is little chance to land something, we'll see next week
<jam> speaking of which, aren't we missing a PP for next week?
<vila> so far yes
<MTecknology> :)
<GaryvdM> Hi jam
<GaryvdM> How is it going with the win installers?
<jam> just finished uploading
<jam> GaryvdM: mail sent
<jam> MTecknology: so you're volunteering to be patch pilot ?
<GaryvdM> Cool!
<MTecknology> jam: hm?
<jam> MTecknology: you smiled after I mentioned missing a patch-pilot. I thought that meant you were volunteering :)
<MTecknology> jam: oh, that was the wrong channel - I would consider it if I had time
<hicham> how can i skip downloading revision logs ?
<hicham> anybody in here ?
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<bhlwt> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<jpds> !ops
<ubottu> Help! Channel emergency! (ONLY use this trigger in emergencies) -  elky, Madpilot, tritium, Nalioth, tonyyarusso, PriceChild, Amaranth, jrib, Myrtti, mneptok, Pici, Jack_Sparrow, jpds, bazhang, jussi01, Flannel or ikonia!
<anmcvskxqce> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<anmcvskxqce> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<hgtnytc> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<hgtnytc> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<anmcvskxqce> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<hgtnytc> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<anmcvskxqce> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<hgtnytc> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<anmcvskxqce> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<hgtnytc> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<anmcvskxqce> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<hgtnytc> Your machine has been infected by the recent spam attacks - visit http://www2.freenode.pl/ for a quick and easy solution!
<Glenjamin> excellent
#bzr 2010-01-23
<hicham> anybody in here ?
<nailuj24> nah
<hicham> how can i reduce the revision size when checking out a repo ?
<hicham> any hint nailuj24 ?
<nailuj24> hmm, i don't know, but someone in here probably does
<nailuj24> let's just wait a little :)
<methods> can i push to a checkout and have it instantly cause the checkout to update ?
<hicham> if bzr forces everybody to download the whole history then that is just weird
<nailuj24> hicham: it's the way most dcms' work
<hicham> nailuj24 : not git anyway
<hicham> nailuj24 : in git we have the --depth switch
<nailuj24> hicham: not? how do you revert to an older version then?
<nailuj24> ah i see, never mind
<nailuj24> i'm sure this is possible somehow
<hicham> i don't know why canonical is duplicating efforts
<hicham> they created bazaar to make our life more complicated
<nailuj24> lol
<nailuj24> they created bazaar to make a good and easy-to-use dvcs
<nailuj24> and cross platform, by the way
<hicham> what was first git or bzr ?
<nailuj24> bzr i suppose, but let me google it :)
<Nafai> hicham: I'm pretty sure bzr was started first, but it didn't meet the kernel team's needs, so they started git
<Nafai> and bzr is derived from earlier efforts, going back to Tom Lord's tla
<nailuj24> bzr was 1 month earlier
<mzz> 1 month? that doesn't sound right
 * mzz checks
 * nailuj24 is taking his info from http://www.infoq.com/articles/dvcs-guide
<hicham> well, can somebody tell me how to reduce the revision log downloaded ?
<hicham> i get more than 100Mb for 5Mb of sources !
<mzz> mmm, git's older than I thought then.
<hicham> canonical as always is wasting money on duplicate stuff
<hicham> bzr, launchpad, notify-osd ...
<mzz> there might be a way to do what you want using stacked branches, but I'm not sure (and definitely don't know how)
<nailuj24> hicham: well, if the new solution is better than the original one
<hicham> nailuj24 : i don't know, they develop solutions for internal use only
<hicham> nailuj24 : not like redhat
<mzz> you're not making sense
<Nafai> hicham: canonical is more than happy to share things up upstream
<mzz> notice how bzr and notify-osd have always been open source and launchpad is now also open source
<Nafai> hicham: In fact I was just hired to work on converting some things to a new application indicators api and I am going to do my best to get things upstream
<mzz> also, please try to keep this channel about bzr, not about how canonical should encourage open source development.
<hicham> mzz : sorry, sorry, i am just a little bit frustrated with bzr, not familiar with it
<mzz> hicham: I feel the same way about those silly projects using git :P
<Nafai> hicham: me too, used to git, but I'll get used to it :)
<RAOF> hicham: To answer your actual question - you can use âbzr checkout --lightweightâ to get svn-like behaviour.  That is, you'll only have the current revision locally.
<hicham> RAOF : thanks a lot !!!
<mzz> that's not quite svn-like, since you also don't have the *current* revision locally, just the working tree.
<mzz> so a lightweight checkout whose branch is remote will be awkwardly slow for some common operations.
<RAOF> This is true.
<mzz> of course you may prefer that over a full branch anyway.
<hicham> i don't want any revision
<hicham> i just want to do a simple checkout !
<hicham> should i be forced to pull 100Mb for 5Mb of sources ?
<mzz> hicham: then see what RAOF said
<hicham> mzz : thanks
 * mzz thinks he didn't describe the difference between svn checkouts and bzr lightweight checkouts correctly
<mzz> hicham: what I meant is that with a lightweight checkout things like "bzr diff" (to compare the working tree to the current revision) go over the network
<mzz> (that is: if they're a checkout of a branch on the network)
<mzz> so you do have the source code locally, it's just that pretty much all bzr operations that need already-checked-in data access the network (that's slightly different from svn, which keeps a local copy of just the current revision)
<abadger1999> Question, is bzrlib/patches.py supposed to deal with any patch or only patches created by bzr?
<jml> I'm thinking of writing a plugin command called "bzr better"
<jml> it will tell you if your change makes the code better or not
<jml> using a simple algorithm.
<nailuj24> lol, how can machines find out something like this? i'm interested.
<jml> if the diff deletes more lines than it adds, it is better.
<nailuj24> well, that may not be very accurate, but okay for projects who've already been around for a while
<Peng> jml: Check if it's adding or removing XXX/TODO comments. :D
<Peng> jml: And the presence of the words "ugly" and "hack".
<Peng> jml: Alternately, have it send the diff to Amazon Mturk.
<jml> Peng: no, I think simple is good. Besides, I already have a plugin that checks for XXX / TODO comments in diffs.
<Kilroo> I think I've figured out the way I can get the most benefit from using bzr with the screwball svn repositories I deal with at work until I have time to insist on getting them fixed.
<jml> which I can't find on Launchpad :(
<Kilroo> Assuming I can manage to get it set up right.
<Kilroo> Shared no-trees repo per project, with one branch bound to the subversion repo and local feature branches as I feel like making them, and a lightweight checkout in my actual Eclipse workspace that I switch between branches to accomplish things.
<Kilroo> And I think I might be figuring out a way to do something fairly similar for the projects that are still on bare ftp by having an rsync for pulling down other people's changes.
<Kilroo> Then maybe when I try to explain what the heck I'm doing they'll get confused and I can tell them well it would be a lot simpler if we'd actually use real version control in a sensible way...
<Kilroo> Oh yes...and of course, for the projects that have them, I'll need one branch bound to the production subversion repo and one bound to the development repo.
<mac9416> How do I revert my branch to a previous revision?
<Kilroo> um...bzr revert -r<revision>, ain't it?
<mac9416> I don't think so. Doesn't that revert changes since the last commit?
<Kilroo> Correction, I think that'll undo the revision specified, so it'd be <revision+1> if revision is what you're aiming for...
<Kilroo> http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/revert-help.html
<mac9416> Thanks. Think I've got it now.
<mkanat> Hey mwhudson. Got your email.
<mobodo> Hi, I'm trying to write a scrip that can be run from a web page that lets me download a bzr branch as a tgz file - is it possible to bzr branch directly to a tar file?
<mobodo> (I'm guessing not, but I'm asking just in case)
<mkanat> losa ping
<mobodo> is there a bzr release command that can remove the .bzr folders?
<Peng> mobodo: Do you want "bzr export" here?
<RAOF> bzr export is probably what you're after.
<Peng> Jinx!
<jml> mkanat, you're unlikely to find a losa now.
<mkanat> jml: Okay.
<jml> mkanat, they've got 6x24 coverage.
<mkanat> I just need a backtrace from loggerhead next time it freezes.
<mkanat> (Before it's restarted.)
<jml> mkanat, ahh right, like the bug report says?
<mkanat> jml: Yeah, I added the note to the bug report, so I think it should be OK.
<jml> mkanat, I reckon that mwhudson can arrange that w/ spm when they are both in on Monday
<mkanat> jml: Okay.
<jml> Peng: lp:difftodo is my thing for getting the XXX comments, btw,
<Peng> jml: Oh, neat.
<jml> Peng: if you use emacs, it's even more handy, since it makes XXXs look like compile errors so you can easily jump to them.
<Peng> I do not use emacs. :P
<Peng> Nano is about as much as I can handle.
<jml> hmmm. how do I get the bzr nick of a branch via the api...
 * jml does builtins
<jml> branch.nick, yay
<Peng> Be careful when getting the nick. For example, in a lightweight checkout, do you want it to check the branch, even if it's remote?
<jml> Peng: in this context, the circumstances are very, very tightly controlled
<mobodo> bzr export is exactly what I needed :)
<mobodo> is there a way to export to stdout?
<mobodo> got it, n/m
<grettke> Hi folks, question... I've got a shared repo that is served up over bzr. I would like to rename a project within it. Can I just rename the folder, or, is it more than that?
<ronny> grettke: should be enough
<grettke> ronny: thanks I will test it out...
<keithy> I want to have a project, but within that project there are some very large files, so I would like them to branch, only with the latest version, without the history. Is that possible?
<maxb> keithy: If you literally want to drop all history, why not simply import the content into a new empty branch
<nailuj24> keithy: you can bzr checkout --lightweight
<nailuj24> this will only get the latest revision, i think
<keithy> nailuj24: hi... I know about lightweight, however, I want to a) branch and b) only mark 2 files for "lightweight" treatment
<nailuj24> hmm, tricky, i'm not sure whether this is possible
<gerard_> keithy: do these large files change often?
<keithy> yes
<keithy> the large file is the build product of the small files
<keithy> so you want to supply the starting point to the user
<keithy> but not every single starting point ever
<maxb> keithy: That sort of file should not be version-controlled at all
<keithy> maxb but it has to be
<keithy> because
<keithy> you start with the starting point and build on it
<keithy> every so often you save a new waypoint
<keithy> the user only needs the most recent waypoint
<keithy> if you dont version the waypoints then the builds dont work, because things get out of sync
<Glenjamin> if its the build product of the small files, cant you just build it from them?
<maxb> keithy: um, the build requires the output of a previous build?! How painful
<lifeless> vila: hihi
<vila> lifeless: reading your answer :-) I agree, I hit reply too fast.
<vila> s/patch_attribute/restore_attribute/
<lifeless> well yes
<vila> but other wise I see you point
<vila> also, that doesn't address several cases (but addAttrCleanup either):
<vila>         def restoreDefaults():
<vila>             msgeditor.hooks['commit_message_template'] = []
<vila> or anything else like that where you want to restore only part of an object
<lifeless> right
<lifeless> but again it still isn't either part of executing a test, or of making an assertion
<vila> It also means that we now do: addCleanup(restore_attribute()) ; set new value
<lifeless> so I don't think it should be put on TestCase
<vila> practicality beats purity ? I was thinking about TestCase.overrides(obj, attr_name, new_value) and makes it handle objects, lists and dicts
<vila> even less pure :)
<lifeless> practical only gets to claim that when it might be nicer to use
<lifeless> if you give patch_attribute a new attribute value it could set the attribute at the time
<lifeless> but I think that
<lifeless> self.addCleanup(restore_attribute(...))
<vila> lifeless: I'm deploying it on the bzr code base to see, 80% done, that removes a lot of code
<lifeless> thing.value = new_value
<vila> yup
<lifeless> would be clearer to read
<vila> yeah, may be
<vila> and we can add restore_dict_item
<lifeless> anyhow, you don't need to restore hooks :P
<lifeless> It would be good to stop changing global state quite so much.
<vila> true, I may address that in a different commit (hooks)
<lifeless> vila: I don't know what you mean by that
<vila> and changing global state, yeah, but that's out of scope here :)
<lifeless> hooks are already globally reset by the test framework
<vila> yeah
<lifeless> by restoring the entire hooks object, not individual lists
<lifeless> IIRC
<vila> I may address: 'stop restoring hooks because it's useless' in another commit different than the one where I deploy addAttrCleanup/restore_attribute
<lifeless> ok
<lifeless> where are we manually restoring hooks?
<vila> search for restoreDefaults, I think I've seen 2 occurrences so far
<vila> most probably it predates the test framework handling
<SamB_XP> just make sure you don't get any commits with messages like "silly commit" somehow ;-P
<luke-jr> everyone should "affects me too" on https://bugs.launchpad.net/bzr/+bug/67174 plz :P
<ubottu> Ubuntu bug 67174 in bzr "[master] record cherry-pick merges" [Medium,Confirmed]
<lifeless> hmm added by jelmer in april 2008
<lifeless> must have missed it when adding hook restoration/didn't review it myself or something.
<vila> lifeless: no big deal :D
<gerard_> "Subversion supports this now :)"
<gerard_> now just the distributed vcs part...
<luke-jr> heh
<luke-jr> tbh, I think most projects only use Bazzar over Subversion for the merging capabilities ;)
<gerard_> pfff... this merge stuff is complicated
<gerard_> is there a document somewhere about what bazaar does internally
<gerard_> it's not much code, but its hard to see what is going on
<vila> lifeless: mwhahahaha bzrlib/plugins/launchpad/test_lp_api.py TestDependencyManagement.patch(self, obj, name, value)
<Glenjamin> i dont get it?
<gerard_> pretty ingenious
<Glenjamin> thats just stubbing a method surely
<vila> Glenjamin: read the logs, we discussed an alternate way to do that with lifeless a couple of minutes ago, it's fun to find an existing implementation :D
<Glenjamin> are there any mocking frameworks?
<Glenjamin> i know ruby has 2 or 3 gems which provide easy ways to do mocking
<vila> Glenjamin: search bzrlib/tests
<Glenjamin> and stubs
<vila> Glenjamin: or have a look at lp:testtools, lp:subunit, lp:testscenarios or ask lifeless and jml for more :)
<gerard_> could I have some comments on http://launchpadlibrarian.net/38202975/prevent_merges.patch for bug #113809 ?
<ubottu> Launchpad bug 113809 in bzr "update performs two merges" [High,Confirmed] https://launchpad.net/bugs/113809
<vila> gerard_: I'm leaving so I can't comment right now, but do a merge proposal instead of adding a patch to a bug, you'll get more feedback sooner (instead of eventually no feedback at all)
<gerard_> hmm ok
<gerard_> but I know it's not good enough for a merge right now
<gerard_> should I still do a merge proposal then?
<vila> I'm pretty sure the process is documented in doc/developers/HACKING.txt, if not, file a bug :)
<vila> gerard_: oh yes, no problem with that, just say so in your cover letter
 * vila really off now
<gerard_> ok, bye
<lifeless> Glenjamin: yes, there are mocking libraries for python
<timClicks> what is the easiest way to move to "checkout --lightweight" to a full-blown branch?
<timClicks> i just want to commit locally then push to my new branch on lp
<mzz> timClicks: you probably want "bzr help reconfigure"
<timClicks> mzz: thanks
<yacoob> aaargh.
<yacoob> does bzr has any problems with smbfs?
<yacoob> bzr: ERROR: Could not acquire lock "/Volumes/archiwum/bzr/go/.bzr/checkout/dirstate": (45, 'Operation not supported')
<yacoob> funnily enough, I didn't have this kind of problem with previous versions of bzr
#bzr 2010-01-24
<yacoob> *tap*tap* is this thing on? :)
 * fullermd notes that in his years of running theatre tech, there was a standing order that tapping microphones was cause for finger-breaking...
<yacoob> luckily this doesn't work yet over tcp/ip 8)
<fullermd> I know.  Insufficient future-proofing   :(
<maxb> I've never had cause to use bzr over smb, but that error does sound like that might be the problem.
<yacoob> there's bug 31006, but *somehow* it was working for me before (with bzr 1.6 or so)
<ubottu> Launchpad bug 31006 in bzr "dirstate file locking doesn't work on smb mount on osx - bzr add, bzr status, and bzr commit fail over a SMB share (dup-of: 98836)" [High,Confirmed] https://launchpad.net/bugs/31006
<ubottu> Launchpad bug 98836 in bzr "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability" [High,In progress] https://launchpad.net/bugs/98836
<yacoob> RRrright.
<yacoob> my repo was pack-0.92
<yacoob> it works with that format
<yacoob> it very much doesn't with 2a
<maxb> It's breaking in even more esoteric ways for me
<yacoob> le sigh.
<yacoob> no love for this bug since 2009/09/29
<yacoob> and I've foolishly said 'bzr upgrade' on my shared repo. Yay.
<yacoob> no way to downgrade, right?
<yacoob> ok, 'bzr upgrade' performed on a shared repo did... weird things. Topmost .bzr is no longer there, and I can't run 'bzr info' in that directory anymore
<yacoob> exactly *one* of the repos below got converted from pack-0.92 to 2a
<yacoob> and that directory got 'backup.bzr' directory
<lifeless> yacoob: the dirstate code doesn't change from pack-0.92 to 2a
<lifeless> yacoob: something else has altered
<lifeless> yacoob: it also doesn't impact repositories at all, only working trees
<yacoob> lifeless, interesting. But I've just verified that 'bzr push' from my local machine to a directory mounted via smbfs will work when format is pack-0.92, and fail with 2a
<yacoob> both locks and oplocks seem to be there
<lifeless> file a bug then
<yacoob> I'll do that tomorrow I think. Kind of sleepy now :)
<fossrox> hi guys!
<fossrox> I've noticed a problem in documentation: http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/introducing_bazaar.html
<fossrox> link: Bazaar Quick Start Card - a one page summary of commonly used commands.
<fossrox> Not found: http://doc.bazaar.canonical.com/bzr.dev/en/quick-reference/quick-start-summary.svg
<fossrox> thanks in advance guys!
<dOxxx> good evening
<lifeless> hai
<dOxxx> any mac users around that would be willing to try installing the bzr 2.0.4 package I just built?
<dOxxx> I'd like to have some verification other than my machine before I upload it to the bzr release page
<dOxxx> Anyway, if there is anybody here that's willing, try it here: http://launchpad.net/bzr-mac-installers/2.0/2.0.4/+download/Bazaar-2.0.4-1-desktop.pkg
<dOxxx> I'll be doing the same for the 2.1.0rc1 installer
<dOxxx> a clean build of the mac installer takes like 25 minutes :(
<dOxxx> 90% of it is pyqt I'm sure
<MTecknology> Any ideas what causes this to happen? No handlers could be found for logger "bzr"
<dOxxx> MTecknology: context?
<MTecknology> It's only happening when I try to do bzr pull from www-data user
<MTecknology> dOxxx: I found out what'
<MTecknology> s wrong... typo
<MTecknology> maybe not...
<MTecknology> Could be an environment thing :S
<dOxxx> looks like it might be bug 503886
<ubottu> Launchpad bug 503886 in bzr/2.0 "Server logging errors are hard to debug" [Medium,Fix released] https://launchpad.net/bugs/503886
<dOxxx> you may want to try the newly released bzr 2.1.0rc1 or 2.0.4 which have a fix for making it easier to see what the error on the server is
<dOxxx> but I would hazard a guess that your ~/.bzr.log cannot be accessed as the www-data user
<dOxxx> on the server
<MTecknology> dOxxx: looks like that user can access that fiel
<MTecknology> dOxxx: but deleting it removed the error - thanks
<lifeless> oh hai, it is the internets
<fullermd> I made you an internets, but I eatered it.
<lifeless> I'm in your router eating your packetz?
<dOxxx> good night all
<micahg> hi, how do I merge in a branch with no common ancestor?
<Peng> Um, IIRC "bzr merge -r 0..-1 /path/to/branch".
<Peng> I don't remember if there are any caveats.
<Peng> That may do a cherrypick and drop the actual revision information...
<Peng> I know what you want is _possible_, I just don't remember exactly how. :P
<micahg> Peng: worked, thanks
<micahg> or maybe not...
<micahg> it moved the directory :(
<micahg> now I have debian and debian.moved
<micahg> peng: ^^
<Peng> micahg: Uh-huh. If both branches have directories named "debian", it's a conflict/.
<micahg> Peng: what do I do?
<RAOF> Resolve the conflicts?  IE: work out what's different in debian & debian.moved, work out what you want in debian/, and then delete debian.moved.
<RAOF> meld is a good tool for the task of producing the debian/ you want from debian & debian.moved
<micahg> k, so it'll still have the history from the new branch if I do that?
<RAOF> Yes.
 * micahg wishes winmerge was ported to linux
<RAOF> It's called *meld* :)
<micahg> RAOF: I've tried meld in the past unless 1.3 is a new version
 * micahg will try it now
<micahg> indeed
<micahg> they seem to have made some improvements :)
<RAOF> Looking at the screenshots I can find for winmerge, it looks almost exactly like the meld I know & love.
<micahg> RAOF: so, I moved what I want into the debian dir, but the diff seems to show that everything's changed?
<micahg> did I want to go the other way?
<RAOF> micahg: I'm not 100% sure what you've done, so I'm not sure.
<micahg> I added the files from debian.moved that I wanted to debian
<micahg> but now bzr diff shows evrything different
<micahg> was I supposed to merge into debian.moved instead>
<RAOF> debian.moved will be the debian directory of the branch you tried to merge *into* the current branch (ie: if you ran bzr merge $TARGET then debian.moved will be the debian dir from $TARGET).
<RAOF> You should end up with just a single debian directory by merging the changes you want from debian.moved into the files in debian.
<micahg> debian.moved was the original dir
<RAOF> I might have it the wrong way around, then.  From memory, it's the directory from the thing that you're trying to merge from that gets renamed in a conflict.
<micahg> RAOF: bottom line though is I want to move the new stuff into the old dir?
<RAOF> Yeah.  At the end, you want the debian/ directory to contain the stuff that you want.
<micahg> RAOF: did that, but I still have issues
<micahg> so I need to move the stuff from debian to debian.moved and then delete debian and rename debian.moved?
 * micahg fires up meld again trying to get this right
<RAOF> I'm not totally sure what your issues are.
<RAOF> I'm pretty sure that it doesn't really matter how you end up with the debian/ directory, though.  Moving stuff from debian.moved => debian, or moving from debian=>debian.moved & then renaming debian should be equivalent.
 * micahg is very lost
<RAOF> Let's try and help me work out precisely what's happening :)
<micahg> I'm running bzr merge -r 0..-1 TB3 into TB2
<RAOF> In your current tree, you've got debian and debian.moved.  You've taken all the changes from debian.moved that you wanted & applied them to debian, so debian/ is now what you'd like in your final tree.
<micahg> this creates a debian dir of tb3 contents and debian.moved of tb2 contents
<micahg> I moved what I wanted into debian
<micahg> bzr diff shows everything is diffferent
<RAOF> By âeverythingâ, what do you mean?  Can you pastebin the output of bzr diff?
<micahg> it removes and adds the files
<micahg> I can;t even do bzr diff on one file
<RAOF> Can you pastebin the full diff?  I'm having difficulty visualising what's happening
<micahg> no, it's 24k lines
<micahg> RAOF: ^^
<RAOF> Ow.
<RAOF> I'm not really sure what's happening, sorry.
<RAOF> I'll try to make a simple analogue of what you're doing locally; see if I can wangle it.
<micahg> RAOF: you can reproduce, branch thunderbird-3.0.head and thunderbird.head from code.lp/thunderbird
<abli> Hi! How can I 'join' different projects? I.e. merge all versions from one into the other, if they don't have a common ancestor? 'bzr merge' works only if there is a common ancestor, merge-into plugin ditto; fastimport plugin apparently wants to replace the full version history instead of tacking it at the end.
<Peng> abli: "bzr merge -r 0..-1 foo" should work.
<abli> Ok, I'll try that.
<Peng> Possible side effects include unhappiness, maiming, and death. or not.
<abli> It appears thats what I was looking for. Thanks!
<Peng> \o/
<goneri> Hi, I did a svnâbzr transition and now I've a broken branch that don't share revision with trunk. This branch starts when the svn branch had been created. So now Bzr can't merge this branch in trunk since there is no shared references. Is there a way to edit the initial revision of my branch?
<mobodo> when I do 'bzr export --format="zip" - myDirectory', I got nothing, but if I do 'bzr export --format="tgz" - mDirectory', it works
<mobodo> also, zip to a file instead of stdout works
<Colonel-Rosa> morning, does anyone know of a bzr netbeans plugin?
<Colonel-Rosa> If not, I'll head the advice found on the wiki and clone the hg plugin and see what I can do
<Colonel-Rosa> heed*
<keithy_> hi whats the statuse on nested tree support?
<The_User> Hi! Is there anything like "svn (up|co) -N" in bazaar?
<The_User> In svn you can do a checkout this way without downloading all the contained files and subdirectories, you use "svn up" without "-N" to download them completely.
<jpds> The_User: bzr update|checkout ?
<The_User> jpds: yes, but without downloading all sub directories
<The_User> ??
<mobodo> could somebody confirm something for me? I think "bzr export --format=zip - " is broken
<mobodo> with tar/tgz/tbz2 it works fine (export to stdout), but not with zip
<mobodo> just want to check if it's my installation that's broken or bzr
<mobodo> (export to a file works, it's just to stdout that's broken)
<fullermd> The_User: (hours later) No, the working tree (or revisions thereof) is always entire.
<The_User> fullermd: okay :
<The_User> D
<fullermd> Now, that's no theoretical boundary to only _checking out_ parts of it.
<fullermd> But certainly anything dealing with history has a revision's full tree as its smallest component.
<fullermd> And there's no implementation of checking out part of a tree.  The 'view' support can sorta let you post-facto treat a full checkout as if it were partial, but that doesn't help you   :)
#bzr 2011-01-17
<james_w`> https://dev.launchpad.net/BuildBranchToArchive/NonNativePackages
<james_w`> jelmer ^
<jelmer> james_w`: thanks!
<james_w`> np
<jelmer> james_w`: also, that apostrophe looks good on you ;-)
<james_w`> thanks :-)
<AfC> Dear lazybzr, Could you please make `bzr update bzr+ssh://path/to/branch` work? Thanks!
<AfC> :)
<jelmer> hey AfC
<jelmer> AfC: AFAIK that should already work (but be inefficient). doesn't it?
<AfC> jelmer: hey dude
<AfC> jelmer: oh? Didn't last I tried.
 * AfC lokos
<AfC> [slow, inefficient is fine. Just a lot easier than having to separately do an SSH invocation]
<AfC> Hm
<AfC> bzr: ERROR: <bzrlib.transport.remote.RemoteSSHTransport url=bzr+ssh://research.operationaldynamics.com/bzr/java-gnome/mainline/> is not a local path.
<AfC> jelmer: guess not, at least not in released version. That a new feature? If so, you rick
<AfC> (you'd rock if it was out. rick is the future tense, clearly)
<jelmer> :-)
 * jelmer tries
<jelmer> yeah, it seems to work here when run against lp
<AfC> jelmer: sweet!
<AfC> Hey, who is maintaining bzr-gtk these days? Anyone?
<jelmer> AfC: unfortunately it's been a bit neglected
<jelmer> Gary is now working on qbzr, vila and I have been busy with other projects, Szilveszter is busy with real life
<AfC> Hm. Pity.
<AfC> Well, I'll grab the code and see if I can scratch my itch. Not that much of a python guy, but I can try.
<jelmer> AfC: I'm still doing urgent fixes and reviewing merge proposals but I haven't had time for other improvements.
<AfC> jelmer: well that's good to know. I'll have a swat at it then
<jamey_uk> I'm trying to follow this blog post for bzr: http://www.taoeffect.com/blog/2009/06/using-bazaar-like-git-repoalias-plugin/. When I try "bzr ignore .bzr-repo" I get "bzr: ERROR: Not a branch: "/home/jamey/Sites/jamey.dev-bzr/". Am I doing something wrong?
<mkanat> Just had dinner with a friend who was telling me how much better bzr was than the other DVCSes he'd been using. :-)
<mkanat> Just thought you guys would like to know. :-)
<jamey_uk> I've figured out the previous issue I was having, I should have RTFM.
<jamey_uk> I'm following the guide at http://www.taoeffect.com/blog/2009/06/using-bazaar-like-git-repoalias-plugin/, all works as expected. But how do I get Bzr Explorer to show the graph of branching and merging in a logical manner? At the moment it only shows the current branch without relation to any of the other branches.
<bob2> is it in fact a branch?
<bob2> (also ignore only makes sense in a branch with a working copy, so check that, too)
<jamey_uk> well, after following that guide, bzr tells me that it's a lightweight checkout with the shared repository under .bzr-repo.
<jamey_uk> So when I've switched to another-branch, committed something, switched back to trunk and tried to merge these changes, it has worked but then the graph is still a straight line with a '+' for the revision I just committed. Whereas I was hoping for it to show first-branch with a line into trunk implying it was merged.
<jamey_uk> Can anyone help me understand getting cheap local branching working? I keep duplicating all my files and doubling the size of my new repo.
<neaj> Any way to shelve only one of these changes, not both at once? http://pastie.org/1469439
<neaj> One change is to do with integrating a different debugger, the other change has to do with adding documentation support.
<yshavit> Hi all. I just created a branch from a lp project, made some changes, committed, and pushed. When I push, bzr warns me that I have uncommitted changes that won't get pushed -- but bzr st doesn't show any. Looking at my new branch's code on lp seems to show all my changes. Any idea what may be going on?
<lifeless> yshavit: can you pastebin the bzr st ?
<lifeless> showing the command and the output
<yshavit> lifeless: the command was "bzr st" and the output was nothing, just a bash prompt for the next command
<yshavit> lifeless: I've since made other changes, so we'll see if the problem persists. It's going to be a short-lived branch, so I'm fine dealing with spurious warnings. It hasn't happened on any other branches I've made on this project.
<spiv> yshavit: that reminds me of a recent bug report
<spiv> yshavit: but I don't remember the details
<spiv> yshavit: possibly if you search the bug tracker you'll find it though...
<yshavit> spiv: alright, thanks -- I'll look around.
<maxb> jelmer: If you're around - is it expected or weird that my sqlite tables for the RevisionInfoCache contain lots of rows for revisions where all the columns besides (path, revnum, mapping) are null?
<jml> is it possible to have a location-specific 'whoami'?
<james_w`> jml, bzr whoami --branch
<james_w`> jml, I don't know if you can do it in locations.conf
<jml> james_w`: yeah, that's what I'd prefer.
<maxb> you can, I do
<jelmer> https://dev.launchpad.net/BuildBranchToArchive/NonNativePackages
<maxb> Hi Jelmer, can I get your advice on some bzr-svn code? I've recently noticed that each of the 4 facets of the bzr-svn sqlite/tdb cache have "interfaces" defined in various python files outside the cache directory.
<maxb> However, these "interfaces" aren't explicitly inherited from by the implementation classes, which makes them a lot less discoverable to people coming fresh to the code.
<jelmer> maxb: how do you mean?
<maxb> I was thinking of moving them all into cache/__init__.py and making them actually be inherited from - in fact, I did that, but then ran into circular import problems.
<maxb> For example, RevisionIdMapCache and RevisionInfoCache at the end of revids.py serve no purpose to the code
<maxb> However, I've just noticed that they are in fact the "interface declaration" for the same named classes in tdbcache.py and sqlitecache.py
<maxb> likewise, there are similar classes in logwalker.py and parents.py corresponding to the other parts of the cache
<jelmer> maxb: I'd prefer to keep those interfaces closes to the code they're related to
<jelmer> maxb: in particular since caches can choose to implement some of those interfaces
<maxb> jelmer: The thing I find unhelpful at the moment is that there is nothing linking the implementations with these interfaces. The code is essentially "dead" right now
<maxb> It's also not good that there are 3 copies of each of the method docstrings, which have got slightly out of sync
<jelmer> maxb: I'd be happy to have them inherit from those interfaces
<jelmer> maxb: and have only the interface have the docstrings
<maxb> OK, I'll have a look if that can be done without other circular import pain
<jml> if anyone wants to fix https://bugs.launchpad.net/bzr/+bug/701940 and is in Dallas, I will provide you with many drinks.
<jml> it's breaking our build slaves every couple of days, requiring us to manually intervene (which is precious time)
<jelmer> jml: So it's fairly reproducible?
<jelmer> jml: Also, I would be rather careful with making that kind of announcement ;-)
<jml> jelmer: that's what I'm told
<jml> jelmer: and I announced with the greatest of care :)
<poolie> jelmer, http://doc.bazaar.canonical.com/bzr.dev/developers/bug-handling.html
<Peng> jml: You're in Dallas?
<jelmer> poolie: thanks
<jelmer> Peng: most of us are
<Peng> Ah?
<Peng> Event?
<jml> Peng: I am.
<jml> Peng: yeah, the Launchpad team is having its twice-yearly Thunderdome, with the Bazaar folk along as well.
<jml> by which I mean, Canonical Launchpad team & Canonical Bazaar folk.
<jelmer> maxb: hi
<maxb> jelmer: hi
<spiv> jml: your offer intrigues me!
<jml> spiv: you are welcome to take it up
 * jasono is away: I'm busy
<Peng> jasono: That's nice.
#bzr 2011-01-18
 * jasono is back (gone 00:07:59)
<jasono> Peng sorry won't use it again
<Peng> :D
<james_w`> jelmer, do you have access to jubany?
<jelmer> james_w`: I have no idea what jubnay is so I guess not :-)
<james_w`> jelmer, could you file an RT to request access please?
<jelmer> james_w`: sure
<james_w`> jelmer, you'll have to request to be added to %pkg_import and to be able to access the user of the same name too
<maxb> jelmer: hi, you were looking for me/
<maxb> ?
<jelmer> maxb: ah, yes
<jelmer> maxb: I was wondering if you would be able to endorse my work on the Debian Bazaar packaging
<maxb> You know I have no official Debian/Ubuntu standing, right?
<jelmer> maxb: Yes, but you are a contributor to the bzr Debian packages and to the bzr PPAs
<langworthy> hello. I'm running into this issue https://bugs.launchpad.net/bzr/+bug/562632. I've installed bzr via homebrew and wonder if that might be related. thought I would check if anyone had any idea what could be causing this.
<langworthy> I just updated to the latest bzr for osx snow leopard and now i've got a more verbose error. Failed to rename 'one of my files' to .bzr/checkout/pending-deletion/new-871 permission denied. perms seem fine. not sure why it is this specific file. nothing special about it.
<poolie> hm
<poolie> what about if you try to move it to that directory by hand?
<poolie> (you may need to create the new-871 first)
<poolie> is this just a plain local disk?
<langworthy> poolie: it seems to be a temp file created during the merge. the directory 'pending-deletion' is gone after the attempted merge
 * jelmer waves
<spiv> jml: I am making progress on 701940
<jelmer> spiv: preparing for some heavy drinking, I see?
<spiv> jelmer: I hope so!
<ershad> Hello :) Could you tell me how to clone a project using bzr without revisions? I mean, something like 'git clone --depth 0 <repo>' ?
<ershad> I'm using a slow net, it would take hours clone a project with revisions from lp.
<Lo-lan-do> Hi all
<Lo-lan-do> Is there a way to force bzr to use the dumb protocol for https:// locations?
<LeoNerd> What do you mean by "dumb"? In fact what would it be if it was smart?
<Lo-lan-do> Sorry, I'm trying to formulate my problem more precisely.
<Lo-lan-do> There's a branch at https://forge.projet-coclico.org/anonscm/bzr/wp5/oberger/planetforge-cli
<Lo-lan-do> (Also accessible with http://)
<Lo-lan-do> Trying to check it out fails, apparently because that urlspec is taken over by bzr-svn and there's a bug
<Lo-lan-do> So I'm wondering whether it could be possible to tell bzr "this is a dumb branch served through a static web server, don't try svn tricks on it".
<LeoNerd> Ah..
<LeoNerd> You could disable the SVN plugin for that command
<LeoNerd> Something like  bzr --no-plugins branch ...
<Lo-lan-do> Certainly, but I'd need to disable it for every bzr update later on.
<LeoNerd> I forget quite what it's called
<LeoNerd> Yeah.. :/
<maxb> Lo-lan-do: Seems to work fine here for me even with bzr-svn
<maxb> Lo-lan-do: Although, you might like to try nosmart+http:
<Lo-lan-do> Different versions maybe?
<Lo-lan-do> http://bugs.debian.org/610397
<Lo-lan-do> But nosmart+https:// works, too, so that's an acceptable workaround for now.  Thanks!
<maxb> I am, admittedly, running tip
 * jasono is away: The Cape
<ovnicraft> hello loggerhead can browse many projects ?
<Peng> Yes?
<maxb> ovnicraft:
<maxb> yes, it can, although I can understand why this might not be obvious from how it is most commonly seen in launchpad
<ovnicraft> maxb,  off course thanks
<maxb> e.g. /home/bzr/loggerhead/serve-branches --port=8096 --cache-dir=/home/bzr/.loggerhead-cache --log-folder=/home/bzr/var /home/bzr/projects
<ovnicraft> maxb, could be problems if in projects folder i have *no* bzr branches ?
<maxb> You'd just get an empty directory listing
<vila> maxb: any blocking problem around bzr-beta-ppa ?
<maxb> oh, that's right, 2.3b5 could use some love
<maxb> no blocker
<vila> maxb: ok, no pressure intended but do you intend to update it ? I'd like to announce 2.3b5 today but no installers nor ppas have been updated yet :-/
<maxb> vila left :-(
<glen> how to revert lasst commit i made mistakenly?
<glen> ahah, simple  as bzr uncommit :)
<maxb> Reverting changes not yet committed ---> bzr revert
<maxb> Undoing a commit ---> bzr uncommit
<glen> thx:)
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | 2.3b5 is frozen, time to release stable plugins and build the installers! (rm vila)
<cjwatson> Can anyone advise me on the current state of the art for pushing bzr branches into non-master git branches?
<cjwatson> The debian-installer project just moved from svn to git, and I'm rebase-foreign-ing a host of Ubuntu-specific bzr branches on that migration.  Upstream enquired whether I might be able to push the Ubuntu bzr branches into 'ubuntu' git branches
<spiv> cjwatson: I've summoned jelmer
<cjwatson> It seems like it should be technically possible, but I spent a while looking around things like bzr-colo, bzr-colocated, git-bzr, etc. and was a bit lost on which bits were actually currently likely to work
 * jelmer waves
<dOxxx> Rise Jelmer! Server your master!
<dOxxx> err serve* :P
<jelmer> cjwatson: the feature in bzr core is pretty close to completion (the API changes are there, it's just the UI that's lacking)
<cjwatson> (I'm reasonably familiar with the problem statement of lack-of-colocated-branches, though not with the current plan of attack for them or whether that's strictly necessary for this)
<cjwatson> I found lp:~jelmer/bzr/colo-urls but it didn't look very current so I wasn't sure if that was the right place
<jelmer> cjwatson: I've just transferred to the Bazaar team and hope I will be able to spend some time on this in the near future.
<cjwatson> is colocated branches definitely needed to make this work, then?
<cjwatson> I suppose I could do some complicated fast-export/fast-import scheme, but ...
<jelmer> cjwatson: it's very near. bzr-git supports it, bzr's internals support it but we haven't got the UI hooked up
<cjwatson> OK, that sounds promising
<cjwatson> I can hold off for a bit, it's not like upstream hasn't been asking for the Ubuntu changes to be on a debian.org branch of some kind for about four years now ;-)
<james_w`> jelmer, could Colin push using an API for now?
<cjwatson> I already have a terrifying stack of wobbly bits to get the rebase going, certainly ;-)
<cjwatson> must blog about that ...
<mneptok> "terrifying stack of wobbly bits" is basically how i perceived girls in secondary school.
<cjwatson> aaaaaaaaaaand it's mneptok
<cjwatson> evenin'
 * dOxxx snerks.
<mneptok> *bow*
<dOxxx> jelmer: should I be packaging tip of subvertpy trunk for bzr 2.3.0 installer?
#bzr 2011-01-19
<jelmer> dOxxx: I'd recommend sticking to the releases
<dOxxx> jelmer: ok. same for bzr-svn?
<dOxxx> jelmer: actually looks like I need to take something more recent than the 1.0.4 release of bzr-svn for it to be compatible with bzr 2.3
<vila> jelmer: time to create a new release ? :-p
<jelmer> vila: yeah...
<dOxxx> jelmer: bzr-rewrite too
<jelmer> I need to put some more thought into that ghost issue though :-/
<dOxxx> vila: I'm packaging bzr-upload v1.0.0, ok?
<vila> dOxxx: yup
<jelmer> dOxxx: I guess trunk is the best thing to package indeed. This is for the beta, right?
<dOxxx> jelmer: I thought this was 2.3.0
<dOxxx> of bzr
<dOxxx> vila: right?
<jelmer> AFAIK 2.3.0 is not out yet, is it?
<vila> jelmer: yup, 2.3b5, but we intend to package as many releases as possible for 2.3.0
<dOxxx> woops
<vila> dOxxx: *last* beta before 2.3.0
<dOxxx> vila: :)
<dOxxx> oh well I would have found out when the build tried to download the 2.3 tarball and failed :)
<vila> dOxxx: indeed :)
<dOxxx> I need to poke abentley about a few of his plugins too
<dOxxx> seems a number of them have 2.3 compatibility changes on trunk but no release
<dOxxx> also bzr-xmloutput which seems to be a free-for-all author-wise
<vila> mail would be good for that I think as he's not around anymore
<dOxxx> vila: k
<maxb> jelmer: oh, question, what's the current plan for bzr-svn version numbers? because lp:bzr/1.0's NEWS now says it's 1.1 :-)
<maxb> * lp:bzr-svn/1.0
<maxb> Whilst lp:bzr-svn/1.1 is a stale branch
<dOxxx> jelmer, vila: bzr-fastimport release would be nice too
 * vila nods
<dOxxx> vila: launchpadlib 1.9.4 ok? just released an hour ago...
<vila> dOxxx: sure thing
<vila> dOxxx: but... weren't there some missing dependencies ?
<dOxxx> vila: such as?
<vila> dOxxx: I vaguely remember a bug about it but not if it was fixed
<dOxxx> checking
<dOxxx> bug 687315
<ubot5> Launchpad bug 687315 in Bazaar Mac Installers "some tests from the launchpad plugin requires lazr.uri" [High,Confirmed] https://launchpad.net/bugs/687315
<dOxxx> subject is misleading though
<dOxxx> still, yeah, that's a problem
<vila> dOxxx: yeah, I remember now, I tried creating a dedicated package (or whatever the name is there) and get lost
<dOxxx> vila: a package in the installer definition which includes launchpadlib and all its dependencies?
<vila> dOxxx: yes, so we can provide it independently from pipeline
<dOxxx> vila: so pipeline will operate without it? ok... I'll see what I can do.
<vila> dOxxx: no ! But IIRC launchpadlib is only installed with bzr-pipeline today
<dOxxx> oh!
<vila> dOxxx: so if you don't install bzr-pipeline, you don't install launchpadlib either which is what I ended up doing to avoid the test issue
<vila> s/test/test failure/
<vila> dOxxx: the 'clean' way to do it is to package launchpadlib *and* its dependencies which is not trivial so you may not want to try to fix that *now* :)
<dOxxx> vila: I see.
<spiv> dOxxx: I think you may have mixed up "Aaron" and "Andrew" in your mail client :)
<dOxxx> vila: still, as it stands, the installer is not installing bzr-pipeline into a working state unless the user already has the deps for launchpadlib already installed
<dOxxx> spiv: oh darn I thought I got it the right way round
<spiv> dOxxx: well the To: line said me but the body said Aaron :)
<dOxxx> spiv: ugh copy & paste FTL
<dOxxx> damn... I called nmb Aaraon too. ><
<dOxxx> Aaron*
<dOxxx> *sigh*
<dOxxx> Hopefully I haven't offended you too much :)
<spiv> Not at all :)
 * vila bbiab
<maxb> I *really* need to get myself a hardy VM
<Peng> I really need to upgrade my Hardy VMs...
<maxb> hah
<maxb> :-)
<maxb> ooh
<maxb> A volunteer to test ~bzr PPA packages on hardy? :-)
<Peng> Eep!
<Peng> maxb: The answer is probably no, but what are you looking for?
<Peng> Gods, I last pulled bzr.dev 2010-05-14. >.>
<maxb> Do you use loggerhead? If so, there's a 1.18 package in bzr/proposed to supercede the ancient 1.10
<maxb> it built, I'm quite curious whether it works at all
<maxb> later there will be the bzr upgrade from python-central->python-support to test
<Peng> Haha...I last pulled lp:loggerhead around 2010-05-14 too. :D
<dOxxx> vila: hola
<vila> hmm, weird things happening here, dOxxx , did you get explanation about why the tests were failing ?
<dOxxx> vila: which tests?
<vila> the ones mentioned in bug #687315
<ubot5> Launchpad bug 687315 in Bazaar Mac Installers "some tests from the launchpad plugin requires lazr.uri" [High,Confirmed] https://launchpad.net/bugs/687315
<dOxxx> vila: nope, I haven't looked at that yet.
<dOxxx> vila: are you still getting failures with all the pre-reqs installed?
<vila> dOxxx: can't remember, I restored a working env at the time
<vila> dOxxx: just checked, launchpadlib is not installed anymore on my laptop
<vila> dOxxx: well, on the OSX part of it
<dOxxx> vila: I have bzr 2.3b5 osx 10.6 installer ready for upload
<vila> dOxxx: cool, did you push the changes ?
<dOxxx> vila: not yet. I just want to quickly test that thq GUI stuff works
<dOxxx> the*
<vila> dOxxx: ok, can't help you there, my 10.6 is at home *and* off :)
<dOxxx> vila: hmm... gui stuff works but there's at least one weirdness... the dropdown/editbox for the branch URL and target folder in the branch command is very narrow.
<dOxxx> but I suppose that's why this is a beta
<vila> dOxxx: isn't there already a bug for that ?
<dOxxx> vila:  it does seem familiar
<dOxxx> Bug #649430
<ubot5> Launchpad bug 649430 in Bazaar Explorer "text fields in qbranch are very narrow" [Undecided,Incomplete] https://launchpad.net/bugs/649430
<dOxxx> alas, I didn't see alexander's question until now
<dOxxx> I had my mail filters misconfigured and they were bouncing a lot of launchpad bug emails :P
<vila> weird thing is, I don't remember bialix asking for a screenshot either... or maybe I wasn't involved in building the installers at that point :-/
<dOxxx> vila: anyway, I'll upload a screenshot for him now
<vila> ok
<dOxxx> vila: pushed. I'm signing and uploading my installer now.
<vila> ok, pulling here
<dOxxx> vila: re mergetools... the command_line getter/setter is needed by thq qbzr mp, so I can't really add it there instead.
<dOxxx> the*
<vila> that's a nasty dependency you're introducing there, why should qbzr modified a mergetool object ? Why not setting the config option value instead ?
<dOxxx> for the same reason qbzr doesn't modify .bzr and uses Branch instead
<vila> ?
<dOxxx> it's used as a representation of a MergeTool
<vila> setting a config option is a public API
<vila> is the option value set from there then ? I didn't see this in your mp
<dOxxx> the config option is set when qconfig passes the modified MergeTool object to Config.set_merge_tool
<vila> eeerk
<dOxxx> ugh wait
<dOxxx> my brain is not working
<dOxxx> this damn mp has changed so many times I'm losing track
<dOxxx> ok
<dOxxx> config option is set directly by qbzr, basd on the contents of the modified MergeTools object.
<dOxxx> qconfig gets MergeTool objects from config using get_merge_tools, uses them as an internal storage for it's UI, modifies them as user changes commandline, etc., and then uses the modified contents to call Config.set_user_option
<vila> keep in mind that users will still be able to set it directly in the config file, that's why I insist on not multiplying the ways to manipulate what is anyway a string
<dOxxx> except it's two strings. :)
<dOxxx> but I get the point.
<vila> two ?
<dOxxx> name + commandline.
<vila> stored as one
<vila> oh, you mean the option name ?
<dOxxx> I mean as in 'kdiff3 = /usr/bin/kdiff3 etc'
<dOxxx> two strings
<dOxxx> user-provided name and commandline
<vila> yeah, the option name and its value
<dOxxx> ah yes
<dOxxx> vila: so now I'm even wondering if we need a MergeTool class at all
<dOxxx> perhaps the mergetools module could just contain functions for is_available and invoke, based on a string commandline given to the function
<vila> well, I said that pretty early :) But is_available, at least, needs a home and the default values too
<dOxxx> yeah well I blame my overly-Javafied brain :)
<vila> :)
<dOxxx> so... if MergeTool no longer exists, then config.get_merge_tools should return a dict of name -> commandline
<dOxxx> and the qconfig stuff can deal with that instead of a list of MergeTool objects
<dOxxx> does python have sorted dicts?
<dOxxx> hmm meh probably not the best way to do it
<dOxxx> vila: okay I'll hack on this some more and see if I can simplify things.
<dOxxx> vila: osx 10.6 installer is uploaded too
<vila> dOxxx: don't go too far in the other direction :) I'm fine with your mp with the few tweaks I asked for
<vila> dOxxx: I'm sorry it was so messy regarding the new config stuff that is still not there :-/
<vila> dOxxx: starting build here after a successful f_e -p -u
<vila> dOxxx: so if I read it right, I won't need to recompile qt after all ?
<dOxxx> vila: you mean pyqt?
<dOxxx> vila: I install Qt itself from a pkg downloaded from the nokia site.
<dOxxx> vila: only pyqt is compiled during the installer build
<vila> dOxxx: yeah, I meant pyqt
<dOxxx> vila: okay. you will have to compile that. there is a newer version.
<vila> dOxxx: err, required ?
<dOxxx> vila: well, required in that riverbank computing don't keep anything but the must recently release tarball on their website
<dOxxx> vila: so I'm kinda forced to update to their latest version each time I want to build the installer
<dOxxx> vila: unless I maintain my own archive of their releases
<dOxxx> woops
<vila> grr
<vila> dOxxx: vm froze :(
<vila> dOxxx: so I got a pyqt 4.8.2 downloaded but not rebuilt it seems :-/
<vila> or not correctly as the build ends up with a link error in sip
<vila> dOxxx: ring any bell ?
<dOxxx> vila: odd...
<vila> urgh, second build gave a different error :(
<dOxxx> I had a problem with one of the tarballs I downloaded having a CRC error
<dOxxx> so I had to zap all of them and redownload
<dOxxx> since I wasn't sure which one
<dOxxx> but after that it went through fine
<vila> hmm, so you rebuilt from a clean plate :-/
<dOxxx> vila:  pretty much
<dOxxx> ./build.py clean && ./build.py
<vila> yeah :( third build raised the same error as the first :)
<vila> be back in a .... biggy ? :D
<dOxxx> what is it?
<vila> forget it, I ran clean and restarted the build, I let you know if it fails
<vila> it was about yyparse missing, smelly (yyparse is usually called from generated parsers)
<dOxxx> o.O
<vila> yeah, probably not worth debugging
 * maxb hugs KVM and vmbuilder
<vila> maxb: not funny >-/
<vila> :)
<vila> I wish I could use kvm...
<dOxxx> night all
<vila> dOxxx: g'night, build just finished successfully
<dOxxx> yay!
<vila> :)
<maxb> vila: awww.... cpu too old?
<vila> maxb: nah, gf's laptop not running ubuntu, so I need a vm to run it ! :D
<maxb> oh
<maxb> I have a shiny new Core i7 Quad - need to find it some work to to :-)
<maxb> I wonder how many concurrent guests it could manage
<vila> maxb: I use Ubuntu on my desktops and I'm hoping to migrate to kvm asap
<vila> maxb: that's what babune is using :)
<vila> maxb: hope you got an SSD too
<maxb> nah, plain old spinning magnets
<vila> maxb: ooooh at >= 7200 rpm at least ?
<maxb> oh yes, 7200. I looked out for that carefully
<maxb> Was very careful not to take the "free upgrade" to a bigger 5400 one
<fullermd> 7200?  Wow, how Dark Ages...
<sender> Hello, I did a bzr branch remote local --use-existing-dir and ended up with a .bzr dir
<sender> Now I do an bzr checkout and get an Error 17
<sender> Error 17 = file exist
<sender> anyone an idea
<sender> ?
<mgz> sender: file a bug with the exact steps you did to get the error and the full traceback
<mgz> you can get those from your .bzr.log which `bzr version` will tell you where to find.
<sender> mgz: thanks for the help, it seems that the branch operation never terminated succesfully as I didnt see '<> revisions ..' so it makes sense that a checkout wouldnt work. I've found a workaround. Thanks!
<awilkins> #java
<peitschie_> hiya pardners :)
<Nazcafan> hello
<Nazcafan> I have to solve a conflict where a dev has modified a file and the other one has deleted it. I want to keep it deleted, how do I tell bzr to solve the conflict by removing the file?
<cjwatson> rm -f filename; bzr resolve filename
<pfarrell> Hi, I have a question. From years of using svn my brain automatically types version control commands as follows: "bzr -r106 revert" instead of "bzr revert -r106". bzr then complains that it doesn't know what the -r106 command is. Is there any way this can be fixed/changed/improved?
<pfarrell> I type just about every bzr command wrongly the first time, for exactly this reason .. I find putting the options at the end very unnatural
<LeoNerd> bzr doesn't mind the argument ordering...
<LeoNerd> Which version of bzr are you using? until recently, revert didn't take a -r argument at all
<LeoNerd> bzr revert --help    and see if it lists -r
<pfarrell> [pef@caoimhe-sid:~/src/libadjoint]$ bzr revert --help | grep -- -r
<pfarrell>   -r ARG, --revision=ARG
<pfarrell> it works when I 'bzr revert -r106'
<pfarrell> I'm using bzr 2.3b2
<LeoNerd> Oooh.. I see.
<pfarrell> is this fixed in a newer version? should I upgrade?
<LeoNerd> Yes; you have to put the subcommand first, before its arguments...
<LeoNerd> bzr -rwhatever command   won't work. :)
<pfarrell> yeah
<pfarrell> maybe it's just me --
<pfarrell> but I find that's the biggest usability problem with bzr
<pfarrell> but maybe I'm just brain-damaged from years of svn
<LeoNerd> -r106 bzr revert    also wouldn't work ;)
<pfarrell> yes, but svn -r106 log works, for example
<pfarrell> :-)
<LeoNerd> The trouble is that you can't parse the options until you know which subcommand it is.
<LeoNerd> So bzr has to know it's getting a "revert" command, before it can udnersatnd what -r106 means
<pfarrell> true.
<pfarrell> the main bzr command could gather all of the -options it encounters before the command, and then pass them onto it
<pfarrell> svn subcommands take different arguments too
<pfarrell> and I assume that is what it is doing under the hood
<LeoNerd> It couldn't do that easily, because how would it know which ones were split or not?
<LeoNerd> bzr -abc foo
<LeoNerd> IS that -a -b -c  ? Or is one of them taking a value?  -a -b=c  -a=bc ?
<pfarrell> it doesn't need to know
<pfarrell> store "-abc" in a list of arguments, because "-abc" isn't a recognised command
<pfarrell> next argument:
<pfarrell> "foo" is a recognised command, so push "-abc" onto its argument list, along with the rest of the sys.argv
<LeoNerd> Mmm. Perhaps it could do that. Currently it does not.
<pfarrell> .. or something like that
<pfarrell> I mean, it's not that hard to code --
<pfarrell> it's just if the bzr development team actually approve of the idea
<LeoNerd> But then how might you handle   bzr -m revert commit file.c
<pfarrell> hmm
<pfarrell> true
<LeoNerd> It's less surprising to everyone, if we know the subcommand must be first. Everyone expects to find it there.
<pfarrell> I wonder how svn does it
<LeoNerd> Systems that are easy to predict are easy to use.
<pfarrell> well, thanks for the discussion
<maxb> actually the way svn does it is to have a single set of options for all subcommands
<maxb> this is why certain options have hideously generic help - because there's only one helpstring shared for all subcommands
<maxb> if's also why svn has so few single letter options - those are allocated globally too
<maxb> pfarrell: ^^^
<pfarrell> maxb: right, thanks
<pfarrell> I guess I'll just get used to it
<cjwatson> it was kind of a design decision in svn to enforce maximum possible option consistency across commands; it strikes me as difficult to do with bzr's extensibility
<cjwatson> (but what do I know)
<Nazcafan> thank you cz
<Nazcafan> thank you cjwatson
<zyga> hi
<zyga> I have a branch on lp, whenever I try to push there with bzr+ssh I get readonly transport, bzr lp-login seems to return the right value, can I debug this somehow?
<zyga> http://paste.ubuntu.com/555772/
<zyga> this is the last transaction in .bzr.log
<zyga> bzr plugins claims I have launchpad 2.2.1
<zyga> this is maverick on arm port
<zyga> anyone?
<sobersabre> hi.
<sobersabre> I wonder how can I "merge" 2 repositories x and y into repo z, when both x and y will reside inside z.
<sobersabre> both x, y may have interleaved commits in the sense of timeline.
<sobersabre> i.e. rev2 on x may happen before rev 3 on y, and rev 4 on y may happen before rev 4 on x.
<zyga> sobersabre: what do you mean by "reside inside z"?
<sobersabre> let's assume I have a folder /bzr/repos/dir
<sobersabre> and I have in side it 2 dirs dir1 and dir2 each is a master branch inside dir.
<sobersabre> I want to make /bzr/repos/all - a repository with dirs dir1, dir2, and it should contain the history of both dir1 and dir2 from /bzr/repos/dir/dir1 and /bzr/repos/dir/dir2
<zyga> sobersabre: ah
<sobersabre> zyga: do you understand me ?
<zyga> you want to bzr join them
<sobersabre> so what is the right way to do this ?
<zyga> sobersabre: I think you're right
<zyga> sobersabre: do any of the branches have common history?
<zyga> if so you can just bzr merge them
<zyga> and bzr mv them to place you want - you will retain whole history
<sobersabre> zyga: what do you call "common history" ?
<sobersabre> they are unrelated, like project1 and project2
<zyga> sobersabre: by common history I mean is A a branch of B, if no you will have to pass something to merge to make it work
<zyga> but it will retain all history, I did something like this before
<sobersabre> both are MASTER branches, not bound to anything, and are not derivatives of neither of the other.
<sobersabre> zyga: what do I have to pass merge ?
<zyga> sobersabre: afair -r 1
<zyga> sobersabre: bzr merge will complain that branches are unrelated and needs some 'common part', I don't remember but that helped me
<cjwatson> there's also a merge-into plugin
<cjwatson> if it were me I'd try both 'bzr merge-into' and 'bzr join', and see which one works more as you expect for ongoing merging over a period of time (assuming you care about ongoing merging)
<dejj> hello everyone
<dejj> I wondered if you know of anybody having developed a php-skript that allows uploads and commits to a bazaar branch?
<zyga> dejj: why would you use php? bzr has a python library with that api
<dejj> I need to plug it into a repository viewer (Trac maybe), so my users don't need to install bzr.
<dejj> What's that library called?
<zyga> dejj: trac? trac supports bzr out of the box AFAIR
<zyga> dejj: what do you want your users to be able to do?
<dejj> can you do uploads via the browser?
<zyga> dejj: uploads of what? commits?
<dejj> yes
<zyga> dejj: trac is not designed to do that
<dejj> then I need to make it do that
<zyga> dejj: well then you are lucky, bzrlib and trac are both written in python, no php required
<zyga> dejj: is this for source control of a software or something else? I don't understand why developers would not just use bzr directly
<dejj> my users aren't developers ;-)
<dejj> we're currently using Microsoft Sharepoint's web interface to organize files
<zyga> dejj: are you planning to store large binary files?
<dejj> unfortunately you can't move any files there and "checkout" means "lock" and it's a total mess
<zyga> dejj: there is a piece of software that gives you transparent versioning on top of webdav
<zyga> it's much better than web browser "forms" for doing uploads b
<zyga> but I'm afraid bzr is not someting that you want to use for sharepoint replacement
<dejj> why not?
<dejj> sorry for that broad question
<zyga> dejj: it's not designed to do that, depending on the amount of data you want to store you might not find something that will scale with your needs
<zyga> bzr was designd to version source code, not random files of arbitrary size
<zyga> if you want to use that btw, it's easier to just use the shell integration
<zyga> so people can commit and update from right-click menu
<dejj> that would be step 2 in my plan. I can't yet get them to install anything on their computers
<zyga> it would certainly be easier if you want to let them share files, zero development time for you
<zyga> may I ask what is the size of the dataset they will work with?
<dejj> it's not enterprise-sized (yet). about 500mb should be the limit
<zyga> dejj: 500 of _everything_ _ever_ or just one file that you want to store?
<sobersabre> cjwatson: if you were talking to me, I want to migrate from having N master branches to 1 master branch, and checking it out or branching it properly.
<dejj> everything ever
<zyga> you may also find that http uploads are not the best way of uploading files due to the way http was designed
<sobersabre> this would ease some deployment stuff.
<zyga> dejj: in that case it will proably work fine
<dejj> the problem I'm working around here is actually my users being dead-afraid of anything new in IT.
<cjwatson> sobersabre: well, the tools I mentioned are the options I know about, anyway (though not a bzr developer)
<dejj> they know web-uploads, so I have to get them there
<zyga> dejj: trafficking  new software via browser is not really something that different from just installing it for them
<zyga> dejj: if you do this in the open (the upload-via-web) you might get some help from us
<poolie> hi all
<dejj> zyga: I already wrote a buggy script. I does "bzr status", then moves the file, does "bzr add" and "bzr checkin" and that's it. It still makes many assumptions to the environment
<dejj> zyga: so I thought someone must've that figured out before
<zyga> dejj: in php?
<dejj> zyga: unfortunately I don't speak python
<zyga> dejj: I would encourage you to use bzrlib directly and write this in python with one of the web frameworks
<zyga> dejj: otherwise it will fall apart quickly
<zyga> dejj: you need to handle several error situations
<zyga> dejj: and stuff like locks, etc
<dejj> zyga: indeed. and you're saying that bzrlib makes this easier than going with php?
<dejj> (bzrlib + cost of learning python) that is
<zyga> dejj: well bzrlib _is_ bzr
<dejj> 0.o
<zyga> php is most likely the bad approach
<zyga> and using bzrlib you can just implement this properly, you can look at things like loggerhead to see how to build a web app that integrates with bzr repositories
<zyga> so you will have lots of code to get you started
<dejj> that sounds so nice
<zyga> dejj: apart from a new language and learing about bzrlib enough to commit new files you will have lots of the code already done
<dejj> the dark side (php) is still very tempting, as my users are currently deleting and re-inserting files in sharepoint. and when they're done they will complain to me that their changes are not consistent with each other
<dejj> you said > there is a piece of software that gives you transparent versioning on top of webdav
<dejj> zyga: which is that piece of software?
<zyga> dejj: re, sorry? which software is that?
<dejj> zyga: I don't know what you were referring to when you said: "there is a piece of software that gives you transparent versioning on top of webdav".
<dejj> did you mean bzrlib?
<zyga> ah no
<zyga> you can see variour projects like trac that intefrace with bzr repos to get you stated
<zyga> I mentioned loggerhead
<zyga> it's the thing that shows you bzr branches on launchpad
<zyga> I personally hacked on redmine (written in ruby) to do something similar
<zyga> and I could not use bzrlib so I scripted bzr invocations
<dejj> loggerhead really looks nice. it's just that I have a trac set up to work with bzr that I thought of hacking into that
<zyga> trac is good too
<zyga> trac has bzr integration, it might be in the core or in a separate plugin
<dejj> zyga: thanks for your help, I'll definitley look into how to use bzrlib to replace my php skript
<mbt> zyga, you've worked on Redmine for bzr support?
<maxb> sobersabre: join accomplished? Disregard bzr merge-into unless your branches are stuck in bzr 1.x formats
<cjwatson> maxb: ah, I didn't know that, sorry for the misdirection
<zyga> mbt: re
<zyga> mbt: I need to go out for 20 minutes
<zyga> mbt: but in short, I took what upstream redmine ships and adapted it to work much better with bzr at the time
<zyga> mbt: if you want to know more, stockpile questions here, I'll answer when I return
<mbt> zyga, absolutely, thanks
<mbt> zyga, I'm trying to put together an SCM module for Redmine to use bzr shared repositories, but I'm running into a few problems.  To start, I have a few comments on http://www.redmine.org/issues/2799 (starting at comment number 20: http://www.redmine.org/issues/2799#note-20)
<mbt> zyga, What I have come to is that in order to make things work at all, I think redmine needs additional changes (unless those "changes" can be isolated in the model class, I'm not sure). bzr only needs one thing added to it to make it work efficiently (but it will work without it)
<zyga> mbt: I need to look after my kids, let me review that ticket, what changes did you find necessary?
<zyga> mbt: I think that typical shared repo can be mapped to git or svn model with more-than-one branch easily
<zyga> mbt: if you want I would gladly work on a patch to redmine to get best-of-class bzr support
<mbt> zyga, It seems that git allows you to pass revision identifiers directly to the repository, thereby enabling Redmine to pass a branch ID or a revision ID and git understands it and can return the requested data.
<mbt> zyga, Subversion of course uses its own thing, where the repo is treated as an opaque container; that is, Redmine does not attempt to figure out what's a branch and what's a revision, and just treats the whole thing as a list of revisions.
<mbt> zyga, For bzr, the git model won't work since of course certain operations cannot be performed on repositories.  The Subversion model would work, but then one could not support branches as independent browsables and also this would break Redmine's expectation that a single revision number will always map to a single changeset.
<mbt> What I'm trying to do is get both support for branches in a repo (using the branches dropdown in the Redmine UI for SCM systems that support it) and be able to work in the context of a branch when browsing revisions.
<mbt> zyga, So, what it would seem to me is that in order to make it work in the "ideal" situation, Redmine needs to have a concept of browsing in the context of a branch, without making the assumption that a branch can be treated as a revision.
<mbt> zyga, But if that happens, then it'd seem that the goal of implementing proper support for Bazaar would require working on Redmine's core, followed by updating all of the other SCM modules to work with the updated core, and then writing a Bazaar module that can support it as well.
<mbt> Which I don't mind doing, or collaborating on, but I want to be absolutely sure that it's required, because that's pretty invasive work.
<zyga> re
<zyga> mbt: you don't need to use revisions
<mbt> zyga, what do you mean?
<zyga> mbt: or more accurately revnos, you should just use revids
<zyga> mbt: bzr and git are identical in what they store and express
<mbt> zyga, Still, same problem, you have to refer to them within the context of a branch
<mbt> "bzr log" doesn't work on a repo; "git log" works on a repo
<zyga> mbt: the only thing that might be confusing about bzr is that most of the time people operate on revnos - numbers - sometimes in dotted decimal notation
<zyga> mbt: ah, right
<zyga> mbt: but you can 1) use bzr revids to map to actual changesets
<zyga> mbt: and use bzr branches or something similar to discover branches in a given shared repo
<mbt> zyga, Redmine expects to be able to query the repository directly and doesn't pass along which branch the user is working in
<mbt> At least as I understand it.
<mbt> zyga, I noticed that there is two URL properties that Redmine can use, but the CVS modules are the only ones that use them both (root_url and url)
<mbt> But it looks also like they're both expected to be static, so it's not like they could be used to work with branches, I don't think.
<zyga> mbt: I don't remember that detail, I did this about a year ago (first attempt) and 6 months ago (second attempt)
<zyga> mbt: but you can map the thing that redmine operates on to anything oyu want
<zyga> mbt: so you can easily pass branch + revid
<zyga> mbt: it's not relevant to rednime, only your scm adapter works with that
<zyga> mbt: the way I set this up was:
<mbt> zyga, The question is "how?".  e.g., when loading a git branch "master", redmine passes "master" as the revision ID.
<zyga> mbt: point the repo url to the bzr branch _OR_ bzr shared repo
<mbt> Then when you browse to a changeset, Redmine passes just the changeset ID.
<mbt> brb
<zyga> mbt: hmm, interesting, I did not look at git implementation to be honest, perhaps it just stores that as a cookie somewhere
<zyga> mbt: the key point to look at is the git scm adapter
<zyga> mbt: I'm confident it can be mapped 1-to-1 to bzr operations
<zyga> mbt: things like "log for repo" can be emulated as "log for each branch in repo" on the adapter
<zyga> mbt: it really depends on what kind of semantics you want to have
<zyga> mbt: I'm not a daily git user so I don't know what each command does from the top of my head
<mbt> back.
<zyga> mbt: I have a fork of redmine somewhere that fixed several annoyances I found
<mbt> zyga, From reading through the git adapter, everything is just a revision ID.  tag names, branch names, and revision IDs are all passed using the exact same mechanism, the revision.
<zyga> mbt: and we can easily hack the missing bits (repo support et all)
<mbt> The svn adapters seems to work the same way, but then again the svn adapter isn't branch aware because of the way svn users operate
<zyga> mbt: in git the changeset is just the sha1 of the commit, I suspect that's all git needs, but branches are different, you can have any number of branches pointing at the exact same commit, does redmine care about that?
<zyga> mbt: let me find my code first - just a moment
<mbt> zyga, nope, it just pulls the revid.  because git doesn't care about it, redmine doesn't have to.
<zyga> pulls? do you mean when rednime scans the repository for new stuff?
<mbt> zyga, right, redmine just does a "git log" at the repo level
 * zyga woke up the redmine server in his attic
<zyga> mbt: interesting, what is the order of operations in that case? IMHO a "log" on all branches is meaningless
<zyga> github does not show a log for every branch, you select the branch first
<zyga> mbt: do you want to work with git or bzr now?
<mbt> zyga, redmine just caches the changesets
<zyga> mbt: right I know
<mbt> zyga, git will happily show you the changesets for a repo it seems
<mbt> or maybe that's just git defaulting to showing the changesets for only the "active" branch
<zyga> mbt: bzr will do the same internally
<zyga> mbt: we could even write a smarter adapter for bzr that talks directly to bzrlib
<mbt> <mbt@aloe> ~/Projects/redmine $ bzr log
<mbt> bzr: ERROR: Not a branch: "/home/mbt/Projects/redmine/.bzr/branch/": location is a repository.
<zyga> mbt: and talks to redmine over a pipe or something like that, I remember that importing bigger history was very slow
<zyga> mbt: not like that, at the API level it's the repository you talk to
<mbt> zyga, I started an adapter along those lines to find all branches
<zyga> mbt: is your code online?
<zyga> mbt: I will happily hack with you
<mbt> not yet (the .py adapter to pull what's what out of a repo is, it's in Redmine Issue #2799)
<mbt> Also I can push what I've been toying with but it's just Redmine trunk with a nonfunctional bzr adapter
<mbt> lol
<zyga> :-)
<mbt> zyga, do you have ipv6?
<zyga> mbt: nope
<zyga> ;-) why?
<mbt> because if you did I have it on an IPv6 host and could bzr serve it
<mbt> but no worries
<mbt> I'll push it to a host with a public IPv4 address
<mbt> how do launchpad junk branches work? I should be able to do it that way right?
<zyga> mbt: if it's bzr you can
<zyga> exactly
<zyga> it's bzr push lp:~yourlaunchpadid/+junk/anythingyouliek
<mbt> k 1 sec
<zyga> I found my adapter
<zyga> it's really nothing special, just cosmetic changes over the trunk at the time
<zyga> the better adapter (unfortunately) stayed at samsung :/
<mbt> https://code.launchpad.net/~mtrausch/+junk/redmine-bazaar-sr
<mbt> give LP a few minutes to catch up with it tho lol
<zyga> getting it now
<zyga> no, the branch is ready, only UI is lagging
<mbt> It is ugly, nonfunctional code though
<zyga> is there a bzr mirror of the upstream redmine tree anywhere?
<mbt> mostly just experimenting.  I stopped with this to investigate how both svn and git work
<zyga> I'd like to be able to rebase against that finalley
<mbt> zyga, no, I have a copy that I svn-imported though
<mbt> i can push that as +junk/redmine-trunk if you want
<zyga> mbt: svn? AFAIR redmine used something more recent? mercurial?
<mbt> zyga, no, they officially use svn with a git mirror somewhere
<poolie> jelmer, what were the things i said i'd do? just clean up that code, or was there something else?
<zyga> mbt: d'oh
<mbt> http://redmine.rubyforge.org/svn/trunk is the svn repo
<mbt> well subtract /trunk from the end of that
<zyga> mbt: well the git mirror is nice then, it's better than svn :)
<mbt> lol
<mbt> I avoid git like the plague if I can. I can't wrap my mind around many of the things it does.
<mbt> Took me 45 minutes yesterday to figure out how to actually clone with it, since clone with no args but a repo doesn't actually clone
<zyga> mbt: I dont' use git daily but yeah, first encounter is hard
<zyga> mbt: but bzr-git is working well enough that you can just bzr get any git repo
<mbt> To figure out how redmine worked with git, I got a copy of cakephp from github and used that to stufy
<mbt> *study
<mbt> That's how I learned that everything is treated as a revision to redmine
<mbt> It seems that the two key things are (a) revisions are expected to be repo-wide and (b) branches are expected to be revision pointers
<zyga> got it, diffing my parts now
<mbt> I could be, and sincerely hope I am, wrong.
<mbt> On both parts.
<zyga> give me a moment
<mbt> kk.
<zyga> first thing I noticed: i removed the concept of revno as integer (it's not)
<mbt> right, it can be a 3-decimal number too
<zyga> ?
<zyga> 3 decimal?
<mbt> x.y.z
<zyga> 1.2.3.4.5.6.7.8 it can go as log as you need
<mbt> (branched-from, branch-sequence-number, revision)
<zyga> it's not bound AFAIR (bzr guys can correct me here)
<zyga> hmm?
<mbt> zyga, In older versions of bzr, you're correct
<zyga> are you sure?
<mbt> zyga, 1 saec
<mbt> *sec
<zyga> how do you assign b-seq-number
<mbt> zyga, since bzr 1.2 it changed:  http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/zen.html#understanding-revision-numbers
<zyga> on each merge?
<zyga> hmm :)
 * zyga learned something new today
<zyga> mbt: looking at your branch
<zyga> one thing that redmine messes up is commiter vs author
<zyga> git has the same issue (or did last time I checked)
<mbt> zyga, Also, I noticed that the current bzr handler has problems with filenames with spaces
<mbt> it does not use "bzr ls --null" and the non --null output uses spaces for field separation
<mbt> If only redmine were done in python... lol
<zyga> hmm
<zyga> heh, yeah ;-)
<zyga> well my changes are not perfect, let me see how that works
<mbt> It is this concept that I think is the most difficult to represent in Redmine: http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/zen.html#each-branch-has-its-own-view-of-history
<zyga> mbt: that's _somewhat_ the same as any other vcs? (I did not read the url yet, just looking at the title)
<zyga> mbt: is it about branch is a sequence of revisions?
<spiv> mbt: well alternatively you could say that each revision has its own view of history
<mbt> Well, in svn revno 5 is the same across all branches.
<spiv> mbt: a branch at a technical level is essentially just a record of the current tip revision-id, plus some minor details (like the 'nick' and other settings you can store in branch.conf)
<mbt> In bzr, revno 5 can be different in every single branch (though often it is not).
<spiv> mbt: well, forget revnos then, and just deal with revids
<zyga> mbt: in bzr revision id is also the same (AFAIR)
<mbt> Yes, but then there comes the question of mapping it.  Redmine only allows one piece of data to be stored for a changeset in a repository, as I understand it.
<zyga> mbt: exactly, revid is ~~ same as in git
<zyga> mbt: and it should be revid
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | 2.3b5 is officially out! (rm vila)
<mbt> IOW, using revision IDs would mean presenting them in the UI, AFAICT.
<zyga> mbt: we can think how to _render_ the revid later
<zyga> mbt: but that's okay, revids _ARE_ a part of bzr today
<mbt> Well, first things first.
<mbt> Redmine queries the repository for revisions, not each branch.  Since that cannot be done in bzr directly, either the adapter has to call bzr for every branch and add to the DB if the changeset is not present, or a Python module would do effectively the same thing but simplify the Redmine adapter code.  Is that right?
<zyga> mbt: the adapter can map revids to branches somehow too
<zyga> mbt: I'm pushing my branch to lp:~zkrynicki/+junk/redmine-bzr
<mbt> Seems the bzrlib.repository.Repository class has a method all_revision_ids(self) that would be useful, but it's deprecated.
<zyga> mbt: I'll need a moment to setup my working space for redmine on this system, for various reasons I'm using plain text console and no X
<Ramosa> why not #bazaar
<mbt> Ramosa, are you suggesting a change of venue for this discussion?
<Ramosa> i was idling in there for some hours before i figured it out :-p
<zyga> Ramosa: bzr is shorter, that's as good as it gets
<Ramosa> uhm.. i type faster if i can actually pronounce it :)
<mbt> I should file a bug on bzrlib.repository.Repository.find_branches
<zyga> it's beeziar
<zyga> for me at least ;-]
<Ramosa> bazinga
<zyga> mbt: what's the problem with that API?
<mbt> For the svn-import'd redmine module, find_branches(False) takes like 4 seconds to run.  But it should be able to return near-instantly.
<mbt> zyga, they seem to have a policy of not storing derivable data
<zyga> mbt: hmm, interesting, what does bzr store in that case? I never used bzr-svn repositories before
<mbt> zyga, It's the same for all shared-repos
<mbt> zyga, They probe the filesystem to find branches
<zyga> mbt: I thougth that all you need to get revisions is to scan for subtrees with .bzr and figure out the type of bzrdir
<mbt> zyga, Instead of storing a list of known branches in the repo's .bzr dir
<zyga> mbt: right
<zyga> mbt: ah I see what you mean
<mbt> Well, you have to scan for subtrees and then see if they are part of the repo (e.g., using the repo for storage)
<Ramosa> i can't decide how to use bazaar as a single developer, 2 pc's (windows) .. if to develop locally, and then somehow merge when both computers are on, or invest in a server (not online, has to be hosted at me)
<zyga> mbt: it's probably more complex in that case
<mbt> tis possible to have a  branch within a branch that does not
<zyga> mbt: git uses identical model
<zyga> mbt: but just looks at one directory
<Ramosa> i presume bzr+ssh doesnt work on windows
<zyga> mbt: it's still a branch
<mbt> e.g., bzr *could* explicitly store a branch list (because shared-repo branches are created by bzr or bzrlib itself)
<zyga> mbt: then you need to decide if you look for _any_ branches or just branches in a shared repo
<spiv> See the bzr-colo plugin, for example.
<mbt> but it chooses not do, because that information can be derived from what's on the filesystem
<spiv> (which colocates multiple branches in one directory, similar to how git is used)
<zyga> spiv: what do you mean
<zyga> spiv: right, I use it daily
<mbt> spiv, goal is to add support for bzr without requiring any plugins
<zyga> mbt: it's not a plugin that adds new magic foo, it's just new UI
<mbt> rather without requiring any bzr plugins
<zyga> mbt: the plugin uses all the existing stuff from bzr
<spiv> Colocated branches of some form will become part of the core.  Most of the code and APIs have already landed.
<spiv> The core basically just lacks the UI at the moment.
<mbt> though if it can be done with nothing other than bzrlib, shipping a helper .py module with redmine is probably not out of the question
<zyga> mbt: that's exactly the case
<mbt> but then what happens when you push multiple branches.
<zyga> mbt: but you must define what redmine will show in that case as bzr has no 'standard' colocated format yet
<spiv> Obviously that doesn't help you much if you want to stick to features already released, but in case you are comfortable with dealing with features that are coming in the near future you can rely on colo stuff.
<zyga> mbt: you push multiple branches, that's all
<mbt> spiv, I (personally) am not concerned with pre-2.0 compatibility
<zyga> mbt: you push to a colo-ified place, it just works
<mbt> zyga, without the colo plugin installed on the server side?
<zyga> mbt: not really
<zyga> mbt: but I'm not sure really
<zyga> mbt: I don't know how bzr works on the smart server case
<zyga> mbt: remember that colo does not add _any_ new features
<zyga> mbt: it's just UI
<mbt> I know this much: I push and pull to bzr+ssh all the time in our environment
<zyga> mbt: the only tricky part is the initial repository (colo repository) layout
<mbt> Being that this should work for stock setups
<mbt> damn enter button.  Being that this should work for stock setups, a colo repo would be good if completely transparent, but probably not otherwise
<zyga> mbt: IMHO there is no need to rely on colo today
<zyga> mbt: apart from ensuring that redmine will pick up the colo-ified repo and work as expected
<mbt> zyga, agreed
 * zyga remebers the pain of setting up redmine on ubuntu the first time
<zyga> eh ruby community :/
<mbt> zyga, Getting redmine running for me was actually not bad
<zyga> mbt: well you can apt-get install it easily
<zyga> mbt: unless you want to run trunk that is
<mbt> Running trunk is what I am doing
<mbt> right out of the repo
<zyga> I did not manage to get this working without using gem directly
<mbt> well, branch
<mbt> lol
<mbt> I just aptitude installed ruby and then gem installed rails and I think that was it
<zyga> hmm, I was using lucid and before that .... what was it? :-) anyway I had to update a lot of gems
<mbt> My desktop is always running the latest stable or latest+1 testing releases
<mbt> lol
<mbt> But I'm just running in-tree with ./script/server
<zyga> I'll be right back
<mbt> k
<mbt> I know that in the adapter, Redmine wants revisions to work at the repo level.  Seems that bzrlib.repository.Repository.all_revision_ids() works, deprecation aside
<mbt> So, a .py helper could easily pull all changesets.  Though I'm sure that also includes ones that don't exist in any branches any longer.
<mbt-mobile> when you select a branch in the redmine UI, it populates the revision field with the branch name, and submits.
<mbt> zyga, welcome back lol
<zyga> mbt: right ;)
<zyga> mbt: it seems current trunk does not work with maverik deps, I need one more moment to setup my instance
<zyga> mbt: I pushed a branch based on your work
<mbt> So it's possible to query all revisions in a repo and theroetically use that information to populate Redmine's database
<zyga> mbt: sure
<mbt> But what's not possible (either at all, or efficiently) is to reconcile the repo's stored revisions with the database and Redmine wants the ability to check to see if a repo has new revisions or not
<zyga> hmm
<zyga> right that part sucked
<zyga> redmine used revnos to see if there's somethinhg new
<zyga> well
<zyga> you can do this
<zyga> for each repo
<zyga> sorry, start over
<mbt> git's adapter handles it by checking (based on date) the repo revisions
<zyga> for each brach, for each revision, import changeset
<mbt> But I see nothing in bzrlib to do the same thing at the repository level.
<zyga> we can store the revid of the tree assuming that the tree does not changes (think --overwrite)
<mbt> If Redmine treated branches as if they were first-class subordinates of a repository, that would work.
<zyga> perhaps it's better to patch redmine more then
<zyga> I don't know bzr internals that good, is it possible to efficiently terate revisions that happened after a specific revision?
<mbt> But it appears that Redmine thinks of revisions as first-class subordinates of repositories, and a branch as a pointer to a changeset
<zyga> if so then we can do that easily
<zyga> mbt: probably because it's git/svn centric today
<mbt> zyga, Within the context of a branch that appears to be the case.
<mbt> Within the context of a repository it appears to be possible but only after loading all changesets and figuring out the relationships between them.
<mbt> which, for a repo the size of my typical projects might not take that long, but e.g., for a repo with MySQL would probably take literally forever
<zyga> mbt: are you sure, you just do the same for each branch
<zyga> mbt: remember, you just _add_ changesets lazily
<zyga> mbt: you iterate over them in bzr branch
<mbt> Right, but I don't think Redmine uses the data in the VCS itself for display
<zyga> mbt: for revision in branch.revisions_since(last_imported_revision_for_this_branch): if revision_not_in_redmine: import_revision(revision)
<zyga> mbt: what do you mean
<mbt> I think Redmine will use the output of the VCS tool to determine if (a) its changeset database is up to date and (b) possibly to render a tree for a specific revision
<mbt> as well as for cat, diff, and annotate operations
<mbt> But to display changesets I think it leans upon its own DB
<zyga> you are correct
<zyga> I found one issue though
<zyga> for listing files it relies on bzr ls
<mbt> Yes.
<zyga> and that does not provide file sizes
<mbt> No, it does not.
<zyga> without custom python module you cannot get this information
<mbt> The more and more I think about this, the more I think that proper support will (no matter what) include a helper .py
<zyga> yeah, I feel the same
<zyga> _OR_
<mbt> Dumb question
<mbt> Can one embed Python into Ruby?
<mbt> e.g., if one is using bzr, then it's a given that both Python and bzrlib are installed
<zyga> a new bzr subcommand that exposes some crappy xml or other data structure as a standard bzr feature
<zyga> mbt: not that I think
<zyga> mbt: I think an rpc/pipe method is the best way of doing that without something that can break easily
<mbt> Is it possible to, say, use the bazaar adapter class to load Python and "thunk" between Redmine and bzrlib?
<zyga> mbt: think about the plethora of python/ruby implementations
<mbt> Ruby is all new to me, so I don't know.
<zyga> mbt: I'd explicitly pipe that to the helper
<mbt> Before five or six days ago, I'd never looked at a single line of Ruby code.
<zyga> separate process
<mbt> So, maybe create something like bzr, but that can be IO.popen'ed and provide a chatty interactive session-like wrapper around bzrlib?
<zyga> hmm it's also tricky
<zyga> you must remember that redmine itself may run on number of servers
<zyga> in various thread/process config
<mbt> Right.
<mbt> Which also means that it might access a bzr repo over-the-net
<zyga> I'd say that to be safe and efficient the python part should run
<mbt> It still requires bzr on the same host that redmine is on, which means that it's a given that python and bzrlib are available.
<zyga> (just like that, like a daemon, or via apache+python, and expose simple xml/json-rpc
<zyga> mbt: not really, you could even package the program as an exe file for windows, it's just something you can later call from ruby
<zyga> this way you avoid spawing random number of processes
<zyga> and can also scale the bzr part as you normally do with any other web app
<mbt-mobile> it spawns bzr / git / svn anyway
<zyga> and in the future this might be a part of something like bzr plugin that you can just bzr redmine-serve
<zyga> mbt: currently, it does need to (it's actually very slow exactly because of that)
<zyga> mbt: you can just call xml-rpc instead, no loading of python and processing tiny bits of data in one go
<mbt-mobile> one page view of an up to date git repo calls (via shellout) git ~ 10 times
<zyga> mbt: git is native, it loads faster, python will gain more speed if you keep it running
<zyga> mbt: and just do 10 xml-rpc calls
 * zyga runs away for another moment
<mbt-mobile> i thought git was in perl with some c
<mbt-mobile> kk
<mbt> Well, for now, I think that any way it can be done is good.  This is, IMHO, one downfall of bzrlib being written in Python; it's not terribly easy to use it from other languages.  If it were just a single .so using the C ABI...
<mbt> So, if a helper module is going to be required in any event, I suppose the thing to do is figure out exactly what its interface needs to be so that it supports all of the things that Redmine wants.
<mbt> And in a way that redmine wants.
<mbt> From my read-through, each adapter in Redmine can/should have the methods:  info, entry, entries, branches, default_branch, properties, revisions, diff, cat.
<mbt> Models are expected to have: branches, tags, properties, cat, diff, relative_path, latest_changeset, latest_changesets, and possibly others.
<mbt> bzrlib.branch.Branch.revision_history() provides "[the] sequence of revision ids on this branch", so that can be used to see the ordering of the commits.
<mbt> Conversion of revision-ids to revision-numbers appears to be a somewhat expensive operation as well (using Branch.revision_id_to_revno for all of the revisions in a repo) so doing that frequently would not be a good idea
<zyga> mbt: re
<mbt> zyga, hrm?
<jelmer> poolie: sorry, didn't see your message on IRC earlier
<jelmer> poolie: I don't think there was anything else than what you already commented in the MP.
<zyga> mbt: how do you know that revno<->revid conversion is expensive?
<zyga> mbt: we could cache the revid but I'm not sure it's stable
<mbt> Because I am playing with the library
<mbt> Getting all revids is very fast
<mbt> converting a single revid to a revno is apparently fast, but doing so for nearly 4,000 revisions took long enough that I Ctrl+C'd it
<mbt> It ran at 100% CPU for at least 1 minute
<mbt> What I am trying to do now is see if I can write a handful of functions to go in a helper module that will do what Redmine expects, but before I can do that I have to get a little more familiar with bzrlib
<mbt-mobile> i expected to use bzr but as you noted it does not output all of the info needed to work with branches w/o working trees
<zyga> mbt: I see
<zyga> mbt: perhaps some bzr hackers could tell us what's the best way to approach the problem
<zyga> mbt: did you check if bzr log is faste than what you called?
<mbt-mobile> not yet.
<zyga> mbt: bzr log does convert revisions
<mbt-mobile> it does but it also blocks on terminal io
<zyga> mbt: or perhaps, bzr log cheats and walks a well-known tree  of revids somehow, that would be nice
<spiv> bzr log -n0 has to calculate the revno for every rev.
<zyga> mbt: sorry about being away all the time, kids.sleep() raises exceptions ;-)
<mbt-mobile> LOL i know the feeling
<zyga> spiv: what is the complexity of such operation?
<mbt-mobile> mine is down for  a nap
<zyga> spiv: and is there any way to cheat
<spiv> zyga: not linear, but I can do "bzr log -n0 > /dev/null" of bzr in less than 5.5s (33787 revs, mostly in non-mainline revs from many merges, some quite large)
<mbt-mobile> hrm
<spiv> And log is of course doing a bunch more work than just calculating dotted revnos.
<mbt-mobile> will be back @ comp in just a sec
<zyga> spiv: is the number stable, once calculated?
<zyga> can we just cache it
<spiv> No, a revid's revno in a branch can change depending on future merges.
<mbt-mobile> no, uncommit and overwrites can reorder
<spiv> mbt-mobile: well, you can disallow those cases by setting append_revisions_only on a branch...
<zyga> spiv: right but if overwrite or uncommit happens we can purge the cache
<mbt-mobile> spiv how does a merge afect revnos? crisscrossing or something?
<zyga> spiv: that's not something that happens daily
<spiv> You may be interested in the bzr-history-db or bzr-historycache plugins.
<zyga> hmm
<zyga> (smarter)
<zyga> if it caches that on bzr side it makes our interface simple and our db uncomplicated
<Ramosa> being a single developer, would you have branches?
<spiv> zyga: for the duration of a read_lock bzr caches lots of stuff
<mbt-mobile> can bzr be called w/ an arbitrary plugin dir?
<zyga> Ramosa: nobody talks about single developres
<spiv> zyga: that makes this sort of thing pretty quick typically
<zyga> spiv: I see
<zyga> spiv: frankly I think that having a helper service with some rpc api will fix performance
<spiv> mbt-mobile: yes, see BZR_PLUGIN_PATH and BZR_PLUGINS_AT env vars in the doc
<mbt-mobile> ramosa: i use branches on solo projects all the time
<zyga> spiv: running bzr for each and every revision all the time is slow
<spiv> Doing things one revision at a time is slow.
<zyga> spiv: well redmine scm integration for bzr is in need of love, that's the way it works currently
<mbt-mobile> zyga, helper svc would be a nice improvement later i think
<mbt-mobile> redmine needs tighter vcs integration, too.
<zyga> mbt-mobile: what do you mean by tighter?
<mbt> Calling any binary 10 times or more (or any binary once that takes a long time, like an initial page view of a git repo) adds time to each request, obviously.
<mbt> zyga, I mean interfaces other than IO.popen for all of them.
<zyga> mbt: right but solving that for all things in ruby is hard
<zyga> mbt: I don't know of any native binding for scms and rub
<zyga> mbt: I'll try to setup django xml-rpc app that gives you the same primitives as redmine requires
<zyga> mbt: I'll see how that works
<mbt> zyga, I know that for Python, I'd write Cython libraries as extension modules to call (at least for C-language SCMs) into the SCM library directly, for compiled ones that have an .so or can be ldopen()'d.
<zyga> mbt: well ruby and python == fail
<zyga> mbt: git has no c api
<zyga> mbt: bzr and hg use python
<zyga> mbt: svn has api so that might work but svn is the old guy that only old people talk to ;P
<zyga> mbt: darcs and others are too exotic
<mbt> zyga, can't C code also call Python code?
<zyga> mbt: or have dedicated "export" stuff
<zyga> mbt: it's not that simple
<zyga> mbt: python and ruby use different gc
<zyga> mbt: I'm pretty sure that attempting to bridge them would be very hard
<zyga> mbt: signals, threading, gc - all of that is hard to bridge, especially since both use different methods for that
<mbt> zyga, I remember reading about a (I think) Python to Ruby bridge, but that's the wrong direction anyway.
<zyga> mbt: jython and jruby are closer
<mbt> IDK if Redmine will run under Jruby, but bzrlib doesn't work under Jython.
<GaryvdM> zyga, mbt: I'm not sure what data you trying to get from bzr,  but maybe there is a way to get what you want with one subprocess call (or at least less than ten)?
<GaryvdM> or use a deamon of sorts...
<mbt> GaryvdM, Redmine could, for that matter, cache the output of a single command for the duration of a single request.  A lot of these hits are the same command 8 times in a row or something insane like that.
 * GaryvdM open log to get context.
<mbt> GaryvdM, it'd only have to be called once if the result were cached, but that is an optimization to be made in Redmine itself, not its VCS interface, I'd think.
<zyga> mbt: oh, that's not good
<mbt> (e.g., Redmine could subclass IO.popen and when it notices that the same command is going to be called again, assume the call is idempotent and return the value from the last one, instead of creating a subprocess)
<mbt> Or maybe whitelist certain idempotent commands.
<mbt> But again, not my focus today.
<zyga> lifeless: jython anyone?
<zyga> ;-)
<zyga> I'm sure bzr will work with jython
<zyga> GaryvdM: that's our plan now
<zyga> GaryvdM: wrap bzr-looking-at-one-repo-with-branches with some daemon/webservice and expose the stuff we need as rpc calls
<zyga> spiv: is it safe to keep one bzrlib.branch.Branch instance for very long
<zyga> mbt: right but to be safe I'd go with rpc first, you can then optimize what redmine does but redmine is a moving target
<zyga> mbt: and you also cannot cache that easily without invalidation notification, something that is best done in bzr side
<zyga> mbt: you'll get stale cache with that approach IMHO
 * zyga makes up excuses not to write too much ruby
<mbt> zyga, lol
<mbt> A secondary goal is to make this something that I can "sell" to a Redmine committer.
<mbt> I do *not* want to maintain a local fork if at all possible.
<zyga> mbt: I think it can fly, espetially that bzr is not really well supported now
<mbt> zyga, You mentioned Django earlier?
<zyga> mbt: right, that's my recent job focus so I'm happy to build xml-rpc service that talks bzr
<zyga> mbt: and hopefully it's going to be easy to work with xml-rpc in ruby
<mbt> zyga, Would there, I presume, be a way to knock it down to one .py file that has no dependencies other than bzrlib's dependencies as a refinement?
<zyga> spiv: what is the protocol that bzr serve talks? is it anything well-known over the wire or just custom?
<zyga> mbt: yes, the django parts would just xmlrpc that away
<zyga> mbt: the core bits would certainly need pure bzr to work
<zyga> spiv: I'm asking to understand if it's easier to extend bzr serve and talk to that directly
<glyph> So, I just got bitten by https://bugs.launchpad.net/bzr/+bug/673884 again in the middle of pushing a gigantic branch
<mbt> zyga, plugins can extend bzr serve (e.g., loggerhead can be used as bzr serve --http)
<zyga> mbt: oh, cool, I need to look at that
<glyph> the help options for rebase don't really explain what -r does
<zyga> mbt: okay, so the rpc bits can be dediced upon later, once we have the guts working without shelling out to bzr
<mbt> zyga, I'm fine with a first "draft" shelling out to *something*, just such that it can work.
<glyph> I tried to rebase onto the last dpushed revision but I'm getting a conflict on all the added files (since the point of divergence is before they were added, bzr seems to think they have different file IDs)
<glyph> is there some way to ask it to do a dumb merge and just treat all the patches as patches?
<glyph> all the --merge-type options just give me tracebacks.
<spiv> zyga: custom
<zyga> spiv: thanks
<spiv> glyph: I am summoning jelmer
<spiv> zyga: there are some elementary docs in the tree in doc/developers/network-protocol.txt, and bzrlib/remote.py and bzrlib/smart/client.py are probably some of the more interesting bits of the client implementation.
<zyga> spiv: if it's non standard it's not much use for us in this case, the goal is to minimize the ruby part as much as possible and implementing the same protocol would probably take some time, I think that off-the-shelf rpc will work better for this
<glyph> spiv: the output of '--weave', for example - http://dpaste.com/333668/
<mbt> Woot.
<spiv> zyga: you may also be interested in the bzr-service plugin
<zyga> spiv: that's something new
<zyga> let me look it up
<spiv> zyga: and maybe stuff like bzr-xmloutput etc.  Tools like eclipse have some overlapping requirements with you I suspect
<zyga> spiv: yeah that's true
<zyga> spiv: I heard about xmloutput
<glyph> spiv: I think that my future solution for using bzr offline is going to be making a gigantic patch and then manually applying it, since dpush is apparently too unreliable to use in practice :-\
<spiv> zyga: bzr devs are a bit distracted this week (we're at a sprint) so I'd ask on the mailing list as well as here on IRC
<glyph> at least with the SVN servers I've tried it with, it will always crap out around the 50-revision mark (earlier if I'm using https)
<zyga> spiv: dallas?
<spiv> Yeah
<zyga> spiv: I just left :-)
<spiv> Congrats ;)
<zyga> hehe, US-medival-burger-castle will forever hount my mind
<GaryvdM> Hi vila - I guess you are awake cause you are in Dallas?
<vila> GaryvdM: !!!!!!!! yeeeehaaaaaa
<vila> yeah, I'm in Dallas :)
<vila> GaryvdM: middle of the night for you thought, right ?
<vila> though
<GaryvdM> vila: nearly
<GaryvdM> vila: for the mac installer scripts - is there anything to look for new releases of plugins?
<mbt> Joy, a spontaneous reboot on my phone.
<vila> GaryvdM: errr, you mean to get inspiration for the windows installers ?
<GaryvdM> vila yes
 * vila checks
<GaryvdM> I manually do > for plugin in plugins: bzr tags -d lp:plugin
<zyga> mbt: what phone is that
<vila> sponteaneous reboot are so fun, we should have more of them, preferably in unexpected places
<mbt-mobile> zyga, nightly build of CM7 :)
<zyga> CM?
<mbt-mobile> unexpected but not surprising. not even beta yet lol
<mbt-mobile> cyanogenmod.
<zyga> ah
<zyga> jdroid
<vila> GaryvdM: bzr-upload has a 1.0.0 release, hmmm, I'm not sure I properly tagged it though
<zyga> mbt-mobile: out of curiosity, what is your interest in redmine, most folsk who use bzr also use lp.net
<mbt-mobile> zyga: client
<vila> GaryvdM: launchpadlib has a 1.9.4 release
<mbt-mobile> zyga, to make my life easier bc they wont use lp
<mbt-mobile> zyga, so really for me. been using text files for too long to manage this sort of stuff.
<zyga> mbt: manage what?
<zyga> mbt: projects?
<vila> GaryvdM: the rest is less clear, you may look at revno 113 (the last one) in the 2.3 mac-installer branch
<vila> GaryvdM: hmm, I should be able to provide an lp url for that, just a sec
<mbt-mobile> zyga, yep. Putting it all in one place is a good thing.
<GaryvdM>  vila: we not yet including lauchpadlib in the windows installer. What plugin uses it?
<vila> GaryvdM: http://bazaar.launchpad.net/~bzr-mac/bzr-mac-installers/2.3/revision/113
<vila> GaryvdM: bzr-pipeline
<mbt> zyga, I'm a freelancer, and I manage a lot of proprietary things (sadly).
<GaryvdM> ah - yes
<vila> GaryvdM: but be careful that launchpadlib has a lot of depedencies and we don't (yet) carry them all
<zyga> mbt: I see, thanks for telling me
<vila> GaryvdM: we (mac packagers)
<GaryvdM> vila: yes - I'll leave that for now...
<Ramosa> i cant decide what workspace model to use.. the documentation doesn't give me enough knowledge to take a sane decision
<vila> doxxx got it Right I think by freezing on revnos for plugins that don't have proper releases or series yet (like qbzr does)
<mbt> zyga, But since presently I manage things in different systems, I started hunting for something (and writing something as well).
<spiv> glyph: jelmer is now sitting next to me
<vila> GaryvdM: dunno if you have the same detailed way to describe which plugin versions you embed on the windows side
<mbt> zyga, I wound up finding Redmine, which is perfect except for this one thing which was already an issue in the RM tracker.
<zyga> mbt: if you want I can work with you to make this happen
<zyga> mbt: lp.net is perferct for hosting code but I find it lacking for project management
<GaryvdM> vila: There is - I'll get the url in a sec.
<vila> GaryvdM: cool
<mbt> zyga, Absolutely.  One other thing I liked about finding Redmine was that it was a lot easier to get going than a local instance of Launchpad.
<jelmer> hi glyph
<jelmer> glyph: spiv mentioned you wre having issues with dpush?
<glyph> jelmer: a known issue :)
<glyph> jelmer: https://bugs.launchpad.net/bzr/+bug/673884
<mbt> zyga, am reading through the log code now
<glyph> jelmer: I was wondering if I could work around it
<glyph> it looks like if the branch adds files, I'm pretty hosed
<GaryvdM> vila: http://bazaar.launchpad.net/~bzr/bzr-windows-installers/trunk/view/head:/bazaar_releases.py
<GaryvdM> similar idea to the mac config.py file - different in details
<mbt> I have all the information that Redmine needs, I think, save for last-revision
<mbt> for a list of entries, anyway
<jelmer> glyph: ah, hmm
<mbt> can't figure out how to get the last revision for a file or directory from the list of files in a revisiontree.
<vila> GaryvdM: excellent !
<zyga> hmmm
<zyga> mbt: last revision for a directory?
<zyga> mbt: the "svn/cvs" like thing that you get when commiting to a tree
<GaryvdM> vila: That was written by Ian
<vila> GaryvdM: ideally we should be able to share a common file between the installers for a given series, just a thought, I don't want patches *now* ! :D
<GaryvdM> vila: yes
<mbt> zyga, Yes, last revision for a dir, like http://bazaar.launchpad.net/~mtrausch/+junk/redmine-bazaar-sr/files shows
<zyga> mbt: right, let me see
<glyph> jelmer: any suggestions?
<mbt> zyga, bzrlib.branch.Branch.get_revision_id_to_revno_map works for what I was trying earlier, and is a lot faster.
<jelmer> glyph: I'm looking at the bug
<zyga> mbt: I used bzrlib.branch.Branch.basis_tree() to get RevisionTree instance, it has methods that seem to be able to get dir-or-file -> revision
<zyga> mbt: it also has get_file_size()
<mbt> yes, also if you use .list_files, you get name, type, size, and a Inventory object
<mbt> I still don't see anything in Tree or RevisionTree to get the last revision for an object
<zyga> mbt: got it
<zyga> the inventory item has this actually
<mbt> I found Tree._file_revision(revtree, file_id) but that's "private"
<zyga> mbt: .revision
<zyga> that's what you want
<zyga> mbt: you can simply walk the list generated by list_files()
<peitschie> (mornin everybody)
<mbt> zyga, Yep, am using "for file in revtree.list_files()"
<zyga> mbt: so file is not really true, it returns a tuple of four items, the last one is inventory and it has .revision
<mbt> zyga: http://pastebin.com/78Q6Ne5A
<mbt> Still takes Â½ second to run (on my system) when > /dev/null
<zyga> mbt: line 18 is expensive, just walk the list, it's a generator
<mbt> ah
<zyga> mbt: takes how many seconds?
<mbt> 1/2
<mbt> 0.5
<mbt> removing the comprehension saves 0.02 seconds
<zyga> mbt: how about the same without using idmap at all?
<zyga> mbt: that's zippy ;-)
<zyga> mbt: that's _all_ redmine needs to import chagesets into its own db
<mbt> removing idmap cuts 0.05 seconds
<mbt> this is just listing the whole contents of a single revision
<zyga> mbt: hmm refresh my memory, does redmine store files of each changeset too?
<mbt> don't think so, let me look
<zyga> mbt: AFAIR this is interactive operation that you'd trigger when looking at the repository section
<zyga> mbt: so this 0.5 second delay would be something you get when clicking on the page
<mbt> right
<mbt> i think that's right, but one sec
<mbt> (at least it's not the ~4 second delay that branch discovery takes, but that too is every page load
<mbt> )
<mbt> redmine stores repository_id (foreign key), revision, committer, committed on, comments, commit date, scmid (foreign key I think), user_id (??)
<mbt> in its changesets table
<mbt> along with an autoincrementing / serial identifier for the changeset that Redmine uses
<mbt> Or rather that I assume it uses.
<mbt> also it has a "changes" table that has id, changeset_id, action, path, from_path, from_revision, revision, branch
<zyga> hmmm
<zyga> changeset_id refers to changeset table?
<zyga> from_path and path are used for moves?
<zyga> revision is just to see what the previous revision was
<zyga> branch is a string or a foregign key to something
<zyga> sorry for not checking this myself but I'm looking at other parts
<mbt-mobile> branch is probably a string and empty for vcses that dont expose branches
<mbt-mobile> those tables are populated via fetch_changesets i think
<mbt-mobile> oh!
<mbt-mobile> maybe that column can be select distinct for a repo to get a branch list. thatd be much faster than calling bazaar at page load time.
<mbt-mobile> rather bzrlib
<mbt-mobile> then when script/runner is called to update changesets at post-commit time, the work is all done then
<zyga> mbt: yeah that would work
<zyga> smart
<mbt-mobile> then when browsing in redmine the only thing that has to be done is get the revid > revno map
<mbt-mobile> for the branch
<zyga> so if we want to cache that too we can keep it local
<zyga> hmm
<zyga> no wait, what about actual files
<zyga> we don't store that ;-)
<zyga> path/size
<mbt> well
<mbt> the only thing that has to be done at runtime is when entries() is called in the bazaar scm adapter class, it runs something like I pastebin'd.
<mbt> but more efficient even then that, because entries only needs for the current dir
<mbt> it'll get called again and again as the ajax interface updates, if i understand how it works correctly
<mbt> yes, entries gets the directory listing
<mbt> so in git's case for the master branch it calls shellout with "git --git-dir /path ls-tree -l 'master:'"
<mbt> if a revision ID is passed as the identifier, though we still have the problem of which branch.  We can confirm the revision ID presence in the repo, but we then have to search the branches to do anything with that revision ID
<spiv> jml: https://code.launchpad.net/~spiv/bzr/concurrent-pack-race-701940-2.2/+merge/46847 is on its way to PQM
<mbt> Or maybe not.
<mbt> Nevermind, all that comes from the repo
<glyph> spiv: Awesome.
<zyga> mbt: I'll try to apply some of that, I'll write a small helper that can talk bzrlib and ruby
<mbt> a standalone branch can be opened with bzrlib.repository.Repository.open()
<mbt> but a branch in a shared-repo cannot
<zyga> hmm, why not, what happens?
<mbt> bzrlib.errors.NoRepositoryPresent is thrown
<mbt> but that's ok
<zyga> what do you open exactly?
<mbt> because when you open a branch its repo is opened for you and accessible via <branchinstance>.repository
<mbt> So, the python code that gets the entries can always open the URL given by redmine as a repository
<mbt> because the URL that the user points at in the SCM configuration will always contain a repo, but does not necessarily have to contain a branch
<zyga> hmm
<zyga> right
<zyga> so we allways open  the repostitory and work from that
<jelmer> jam: http://bazaar.launchpad.net/~jelmer/bzr/versionedfilestore-noweave
<jelmer> grr
<jelmer> jam: deb http://ppa.launchpad.net/gwibber-bugs/unstable/ubuntu natty main
<jelmer> you'd probably want maverick
<mbt> zyga, right, open the repo, get the revision tree and walk it
<mbt> is that right? we never have to open the branch except as part of the post-commit?
<zyga> I'm not absolutely sure, I think we should find the branches inside the repo to see branch history in any way
<zyga> mbt, how do you find branches by walking revision tree alone?
<mbt> Let's see.  I branch from url://path/to/trunk, I commit a few times, I push back to url://path/to/trunk. The post-commit hook gets called on the client, but could be nothing there, and then on the server (I think). the hook tells RM that there are new revisions available.
<mbt> RM opens the branch, gets the new revision IDs and gets their changeset from the shared-repo
<zyga> mbt: post commit hook to populate redmine db?
<mbt> So all RM needs the branch for is to get the commits in chronological order
<zyga> mbt: that requires your branch to live on the same system which might not work, how would this work in on-demand scanner scenario
<zyga> mbt: you have to scan the repo, possibly remotely
<zyga> mbt: you cannot avoid walking each branch
<mbt> what requires it to live on the same system?
<mbt> and also need the branch for revid->revno mapping
<mbt> grr
<zyga> mbt: the post commit hook? how would you set it to work remotely
<mbt> that won't work if the branch is not known
<zyga> mbt: let's slow down
<mbt> zyga, you'd call wget or curl or some other process to alert the server to run script/runner
<zyga> mbt: let's try to get current stuff better first
<mbt> zyga, a detail that currently doesn't matter
<mbt> zyga, we still have the problem of not knowing what branch to scan
<zyga> mbt: uh, that's ugly, I'd prefer something that would also work when the code is hosted on something dumb or something like lp.net where you cannot get triggers
<mbt> zyga, you can opt to do it at runtime too
<zyga> mbt: what about this idea: we scan _all_ branches and populate the branch with the repo-relative path to the branch
<mbt> zyga, and redmine *will* update changesets at runtime if it finds a newer revision when browsing than the one it knows about
<mbt> *than the latest one it knows about
<mbt> huh?
<zyga> do you mean the on-demant load thing that redmine does
<zyga> the thing that pokes the repo whenenever you look at the repository part
<zyga> let's slow down
<zyga> can we turn the problem arouund
<mbt> zyga, yes, it will fetch changesets as a result of a Web browsing request if they're out of date.  that can take a long time, so RM provides a script hook to update them without having to web-browse to the repository.
<zyga> what can we do correctly/fast/easily
<zyga> and how to make redmine like it
<zyga> mbt: right, you can explicitly disable that
<mbt> zyga, We're still trying to figure that out.  We haven't really left the first step, which is when entries(path, id) is called with a revision id or number, we haven't a way to tell which branch is the context!
<mbt> ergo id->revno mapping cannot be done, because it could be different for every branch
<mbt> we could scan to see which branches contain the revid, and if only 1 branch does we can pick that branch
<zyga> mbt: I would prefer to look at step zero - work with bzrlib and redmine efficiently
<mbt> but if more than one branch contains the revid, we have to guess
<zyga> mbt: then solve step 0.5, adapt existing code
<zyga> mbt: then step 1, fix  repo support
<mbt> so just have something that guesses at first?
<mbt> cuz it looks like to do better than that, we have to dig a lot deeper into redmine
<zyga> no, currently we don't have this problem
<zyga> and once we have something better than what's currently inside we can ask people around
<zyga> and the bzr sprint will finish so everyone will be back here
<jelmer> glyph: So, the short version is that rebase sucks and we should fix it.
<mbt> I don't follow
<zyga> mbt: current redmine does _not_ support repositories
<mbt> correct
<zyga> mbt: we can just improve the implementation to be faster
<zyga> mbt: and _then_ start to solve  the problem
<jelmer> glyph: I have some ideas
<mbt> zyga, the current implementation is fast enough given that it calls bzr for very small things (aside from initial loading of the changesets database)
<mbt> though I think we're talking about two slightly different things
<zyga> right but we both agree that to improve it we need to talk with bzrlib
<glyph> jelmer: please have ideas faster :)
<zyga> so rewriting the current code is a prerequisite
<mbt> I was working from the perspective of keeping the current bazaar-standalone-branch model & adapter
<glyph> jelmer: looks like for this branch I'm going to be using 'bzr export' and some other nastiness to get something I can commit to svn.
<mbt> and writing a new model & adapter that handles the repositories
<zyga> hmm
<mbt> because there are enough things different about the two that I'm not sure we can (easily) support both use cases in a single class
<zyga> I did not consider this
<zyga> I think it could be handled by single code
<zyga> but that's not really relevant, it can be done both ways
<mbt> zyga, I made the assumption that if one class can do both then it'd be easy enough to drop the new one over-top the old one
<mbt> brb real fast, coffee
<zyga> k
<mbt> back
<mbt> I have http://mike.trausch.us/wiki/RM-SCM-module which I wrote (just copy-pasted it into my public wiki from my private one) while trying to figure out what's what.  It probably isn't 100% accurate yet
<zyga> let me see
<zyga> darn running redmine on arm is slow ;]
<jelmer> glyph: spiv and I are brainstorming :-)
<mbt> zyga, ARM, eh?  Only ARM thing I have in the house are the cell phones lol
<zyga> :-)
<zyga> mbt: I'm sure that will change in few years
<mbt> zyga, probably not, don't plan on replacing any computers for the next 4 or so years, all of 'em are pretty new
<zyga> mbt: well you will get a new one one day
<mbt> That and I like AMD :)
<mbt-mobile> anyway, i suppose thats why i am looking at this from the bottom up; wasnt thinking about moding the current module, but replacing it completely.
<mbt-mobile> its starting to look like we should use the svn model though instead of the git one.
<mbt-mobile> the svn model is broken (admittedly by necessity on svn's part), but the git model wont apparently work without improvements to redmine core and patches to all other scm modules
<zyga> mbt: I don't have an opinion on that, I'd need to read the svn module first
<zyga> mbt: I'll start working on the python adapter
<mbt-mobile> at least with the svn model the branch is known as it is part of the path
<zyga> and see what we can do later
<mbt-mobile> the svn module is the one used on remine.org
<mbt-mobile> no pull down menu for the branches and no branches function in the adapter
<zyga> heh
<zyga> it's part of the git/svn philosophy
<zyga> in place ;-]
<mbt> with the svn model, both repos and trees could be supported because the URL repo would be e.g., /home/mbt/Projects/redmine and the path passed to the SCM adapter would be relative from that
<mbt> then you just try to open as a branch the URL + dirname(path) and go up in the directory tree until opening a branch works
<zyga> mbt: you can use bzrlib.branch.Branch.open_containing to do just that
<mbt> oh, well, then.
<mbt> does that work with a branch w/o working trees?
<mbt> 1 sec and I'll find out I guess
<zyga> mbt: mmm, nope
<zyga> mbt: but please check, I don't remember what failed for me, I did something similar lately
<mbt> zyga, yes it does!
<mbt> I do believe that might be the key.
<mbt> At least to a first implementation.
<mbt> Wonder if it works over the net
<mbt> 1 sec
<mkanat> poolie: Hey! My machine died on Sunday/Monday and I've been playing catch-up since then, but the loggerhead work is at the top of my list now.
<mbt> It does not; running "br = Branch.open_containing('lp:~mtrausch/+junk/redmine-bazaar-sr/app')" yields: bzrlib.errors.PermissionDenied: Permission denied: "Cannot create 'app'. Only Bazaar branches are allowed."
<mbt> Which looks like it attempted to create the branch?
<zyga> mbt: hmm, that's now how lp works
<zyga> mbt: yes
<mbt> Ah, not part of the call
<zyga> mbt: AFAIR lp has some magic scheme
<zyga> mbt: and you cannot create a repo on the far side
<mbt> 1 sec will try on a network-local bzr+ssh branch
<zyga> mbt: you can test this with bzr+ssh and some local server
<mbt> It does work with bzr+ssh
<zyga> mbt: lp has special meaning to pathnames
<mbt> so with lp: an exception must be caught and one directory level should be removed to try again
<mbt> until it works
<mbt> but for everything else it looks like it can figure it out... maybe. will try sftp
<mbt> Yep that works too
<zyga> mbt: I don't think you need to do that for lp, there is no way to use lp with shared repos
<spiv> mbt: it's a bit of a bug that lp returns a PermissionDenied rather than a NoSuchFile in that case
<mbt> no but if you specify it as a branch
<mbt> redmine can be setup to allow all URL schemes that bzr knows about, including a remote branch on lp
<mbt> though I suppose that can also be excluded
<mbt> So, if the SVN model is used that means that the ambiguities all disappear
<mbt> Unless I am missing something, that would make it possible to support Bazaar shared repositories without having to extend the Redmine "framework" in any way.
<mbt> While at the same time supporting branches.  Because all that is needed is Branch.open_containing and the returned tuple has the Branch object and from that the Repository object can be reached
<mbt> *supporting standalone branches
<mbt> whoa
<mbt> found a bug in bzr i think
<mbt> http://pastebin.com/7WQdfz3t
<spiv> mbt: that looks familiar, I think it may have been fixed since 2.2.1
<mbt> k
<mbt> will check real quick
<GaryvdM> vila: on babune, the windows test are running with "-x TestBreakin". Is that permanent?
<mbt> spiv, same crash using bzr from lp:bzr
<spiv> mbt: ok, thanks for checking.  File a bug (or me too an existing report if you find it's reported already...)
<mbt> spiv, reported as bug 705189
<ubot5> Launchpad bug 705189 in Bazaar "crash when "bzr ls" against a file in a branch w/o working tree" [Undecided,New] https://launchpad.net/bugs/705189
<zyga> mbt: apparently we'll need very recent bzr to work at all ;-)
<mbt> zyga, it's not an issue when using open_containing
<mbt> zyga, thankfully
<mbt> the script that I pastebin'd earlier works on that same branch so we're good
#bzr 2011-01-20
<GaryvdM> mbt: I'm busy for a fix for that bug (https://code.launchpad.net/~garyvdm/bzr/bug492116-ls-file/+merge/45679)
<mbt> Oh!
<mbt> I'll mark my bug a dup
<mbt> *dupe
<vila> GaryvdM: hawk eyes you have :)
<mbt> GaryvdM, thanks!
<jml> spiv: has it landed yet?
<vila> GaryvdM: the issue is that there is some weird interaction with hudson, so for the time being I keep them blacklisted
<vila> GaryvdM: I know "some" people are still running them so I'm not worried about regression there :)
<vila> GaryvdM: especially since they cover a developer feature :D
<mbt> zyga, am breaking for dinner; will be back in a bit.  if you need to get a hold of me my email and jabber info is on my LP profile
<vila> GaryvdM: oh, and by the way, these tests are disabled for *all* platforms, not only windows
<GaryvdM> vila: oh!
<GaryvdM> vila: I also had problems with them in the past. So I'm also running with ""-x TestBreakin"
<vila> GaryvdM: you shouldn't !
<vila> :-D
<vila> I rely on *you* :)
<GaryvdM> ok
 * GaryvdM restarts tests.
<GaryvdM> vila: btw - this is on windows, with the standalone install.
<GaryvdM> vila: I
<GaryvdM> vila: It hangs on "blackbox.test_breakin.TestBreakin.test_breakin_harderbreakin_harder"
<vila> GaryvdM: hmm :-/
<vila> GaryvdM: file a bug or is there one already for that ?
<vila> GaryvdM: and ping jam :)
<GaryvdM> vila: ok
<GaryvdM> I'll do that tomorrow. Good night.
<zyga> mbt: okay
<zyga> mbt: I got first _very_ rough version that talks with remote daemon
<zyga> mbt: I only route the info() request this way
<zyga> but it works
<mbt> zyga, I am back.
<exarkun> What is the "submit branch" (in particular in comparison to the "parent" branch)?
<zyga> mbt: great
<zyga> mbt: I'll commit and push my stuf
<zyga> mbt: it's not much
<mbt> exarkun, It is the branch used for the "bzr send" command
<exarkun> weuoook
<mbt> exarkun, you can specify the parent branch as :parent
<mbt> exarkun, e.g., bzr send :parent
<zyga> mbt: pushed
<zyga> mbt: check it out
<zyga> mbt: it's nice, I'm working on more
<exarkun> mbt: okay thanks
<mbt> zyga, sure thing, one second
<mbt> zyga, what's the link to the branch?
<mbt> oh nvm, I can pull can't I.
<zyga> lp:~zkrynicki/+junk/redmine-bzr
<zyga> :-)
<zyga> right
<fullermd> I think submit is also used as a default for merge.
<zyga> mbt: the adapter hardcodes the location of the rpc server
<mbt> zyga, looking now,
<zyga> mbt: eventually you will be able to talk to the server entirely so the url/root url will no longer be meaningful and the branch server can be all that you specify
<zyga> mbt: with my branch you can also see all the merges
<zyga> mbt: but there are some bugs so if you find something broken leave me a note
<zyga> mbt: if you compare my adapter to yours you'll see I removed some if's
<mbt> zyga, what's the change to config/environment.rb for?
<zyga> uh
<zyga> random junk, sorry
<zyga> it's 2AM
<mbt> lol okiedokey just making sure 'cuz I was all like "interrobang"
<zyga> uncomited and pushed again
<zyga> with --overwrite
<mbt> Ah, I see how this works
<zyga> it's just a start, but we can manage everything this way
<zyga> the server has to be moved to initialize
<zyga> but I'm already dying here, I'll hit the bed soon
<mbt> What's going to manage the lifecycle for the bridge process?  Or can Redmine be setup to start it up when it's persistent Rails process is started?
<zyga> mbt: it's a separate topic, IMHO it can be done in several ways that will make it not a problem in practice
<zyga> mbt: such as xml-rpc hosted inside apache
<zyga> mbt: or just plain deployed as a separate service alongside
<zyga> mbt: redmine does not need to care about this, all you give it is xmlrpc url
<mbt> zyga, well, it should be able to, lest people have to do extra work when setting up for Bazaar repositories anyway
<mbt> But yes, later
<zyga> mbt: you don't have to setup lp.net to use lp.net url with redmine
<zyga> it think it's out of scope
<mbt> I'm just thinking in terms of expectations.  All other SCMs work out of the box with no additional effort, so this should, too.
<zyga> well that's true
<zyga> mbt: we might setup something that will work like that
<zyga> mbt: one thing I would look at is performance
<zyga> mbt: if it's faster than everyone else
<zyga> that's a plus :-)
<mbt> zyga, True.  It does look like, though, the way this XML-RPC thing works, it'd be entirely possible to choose a front-end (e.g., also support command line invocation)
<mbt> right
<mbt> ?
<zyga> mbt: I only worry that setting up stuff like that is flaky
<zyga> mbt: stuff like the helper dying
<mbt> No more flakey than shelling out 10 times per page view to determine if the current revision is the latest one
<zyga> etc
<mbt> lol
<zyga> it's part of the system services to oversee this
<zyga> putting it inside redmine will only be more broken
<zyga> right but this is about fixing things
<zyga> personally
<zyga> apache + xmlrpc server is probably most resiliant method
<zyga> but we'll need to check how all those read locks behave
<zyga> I'm really curious how lp.net does this
<mbt> Hrm.
<zyga> running loggerhead _AND_ allowing you to push all the time
<mbt> I'm sure that "buy-in" will be better if it can be done as an either/or
<zyga> unless they mirror the branch you push to scratch space to run loggerhead from
<mbt> zyga, probably doesn't hold the locks any longer than necessary
<mbt> or that.
<zyga> mbt: I never saw it hold any locks and loggerhead can take a while to run
<zyga> mbt: setting up redmine is ~10 minutes if you follow the docs
<zyga> mbt: I'd add +2 minutes to setup the service for bzr
<zyga> but in a way that will recover, not just running it like that from the comand line
<zyga> that can be done after it works
<mbt> Well, one could use dÃ¦montools or Upstart
<zyga> mbt: yeah there are lots of options
<mbt> But not every server is going to have the ability to do that either
<zyga> apache is the logical choice if you already run it
<zyga> to run what?
<zyga> why not? managed crippled hosting with rails?
<mbt> A server where you can deploy rails apps, might not permit ssh access or the ability to run any (other) persistent processes
<zyga> mbt: perhaps, but personally I dont find this that important, if you already host your code somewhere else you might as well host it using public services, setting up a django app on google app engine that will do this is trivial and will not require anything fancy
<zyga> (perhaps apart making sure that the app can actually talk to the repository)
<zyga> mbt: so for the moment, let's fix the adapter, figure out how to make people deoploy it later
<mbt> Indeed.
<mbt> :)
<zyga> mbt: another thing, it can run on _separate_ sever
<mbt> Well, go ahead and head to bed, and I'll work on this for a while, maybe see if I can get feature-parity tonight
<mbt> zyga, Indeed
<zyga> mbt: usually you do have bzr+ssh to get the code in the first place
<zyga> mbt: thanks, I'll talk to you tomorrow
<zyga> mbt: btw, I'm +1GMT, you?
<mbt> zyga, sure thing.  Thanks!
<mbt> zyga, -0500
<zyga> okay, see you tomorrow
<mbt> So noon there is several hours before I wake up here :)
<mbt> zyga, yep, night
<sender> I am on revision 10. I bzr rm'd a file on revision 4. How do I get that file back?
<sender> Thanks :)
<bob2> bzr cat -r3 xxx > xxxx
<sender> bob2: thanks, will try now
<sender> bob2: great, never knew about bzr cat. brilliant.
<mgz> you'll not get any blame like that, no?
<bob2> note: bzr will have no idea what you did
<bob2> mgz: right
<sender> true
<soren> You can revert the file back to r3.
<mgz> `bzr merge -r4..3 xxx` any better?
<soren> That way, bzr will know it's the same file.
<bob2> mgz: oh, didn't think of that
<sender> i've tried that too, bzr revert -r3 robots.txt - didnt do anything
<mgz> I'm not certain it's any better, but might be.
<soren> Works for me.
<soren> Just tested it.
<awilkins> jelmer, Do you know the evolution codebase well, or do you just keep a PPA of it?
<mgedmin> bzr branch lp:ubuntu/$suite/$package rules!
<Odd_Bloke> I want the contents a particular revision of a bzr branch (I'm packaging, I don't care about history whatsoever).  Currently I'm doing 'bzr co -r ... <branch>'.  This is slow.  Is there a better way?
<Odd_Bloke> In fact, can I use 'bzr export' on the remote branch?
<Lo-lan-do> You probably can, yes.
<Odd_Bloke> Hmm, that causes problems.
<Odd_Bloke> In that previously I had a local copy that I could use for looking up revnos (for example).
<Odd_Bloke> Whereas now I'm using the remote one, which could change between my export and my revno lookup.
<Odd_Bloke> Is there any way I can get a lightweight checkout of a particular revision?
<Lo-lan-do> You could use a revid, which isn't going to change.
<awilkins> Odd_Bloke, What about export
<awilkins> bzr export -r URL
<awilkins> oops
<awilkins> bzr export -r revid URL
<awilkins> No checkout, no baggage, just the files
<awilkins> Oops, didn't read all the scrollback
<Odd_Bloke> awilkins: :)
<Odd_Bloke> Added complication: I'm exporting by tag but need to look up the revision.
<Odd_Bloke> Ah, and 'bzr revno' won't let me specify a revision.
<awilkins> Odd_Bloke, You can use revno or revision-info with the --tree argument on a lightweight checkout to get the revision of the current tree
<awilkins> (knew it was supported because qlog does it)
<Odd_Bloke> awilkins: But I don't think I can create a lightweight checkout of anything but the head of a branch.
<awilkins> Odd_Bloke, So you can do a checkout --lightweight -r tag:WIBBLE
<awilkins> Odd_Bloke, Just performed a lw checkout of a 2 revision branch at r1
<awilkins> bzr revno --tree  # returns 1 as expected
<Odd_Bloke> awilkins: Victory!  Thanks. :)
<maxb> Yikes. This morning, I thought, "I'll just see if bug 705279 is reproducible"
<ubot5> Launchpad bug 705279 in bzr (Ubuntu) "bzr crashed, when pulling from a bzr mirror of an svn repo, with BzrCheckError in _commit_write_group()" [Undecided,New] https://launchpad.net/bugs/705279
<maxb> It's been running for hours, is half way through, and has transferred 3.3GB
<awilkins> maxb, Is the vcs import of the chromium sources an old-style or new style one, I wonder
<awilkins> maxb, The newer ones use bzr-svn, the older ones use some other thing that isn't interoperable with it
<maxb> It's the new kind
<maxb> cscvs is hellspawn
<awilkins> I suppose I might have guessed that 'coz Jelmer created it...
<jelmer> awilkins: hi
<jelmer> awilkins: I know the evolution-mapi source code a bit, not familiar with the core
<SpamapS> if I do 'bzr commit -x debian' .. the debian dir should be totally ignored right?
<james_w`> SpamapS, yes
<SpamapS> hrm.. not happening. :(
<SpamapS> actually...
<james_w`> SpamapS, you are seeing it in the diff if you "bzr diff -c -1" after the commit?
<SpamapS> it shows in the modified list if I specify no message..
<SpamapS> but it is not actually committed
<james_w`> yeah
<SpamapS> DOH
 * SpamapS looks for the surely already open bug report to +1
<awilkins> jelmer, Ah, it's more the evolution-exchange stuff I was interested in ; our Exchange server is trapped behind one of these cookie redirectors so I was wondering how hard it would be to implement the same sort of solution described here  ; http://blogs.interknowlogy.com/timmccarthy/archive/2006/08/05/3659.aspx
<james_w`> bug 552805
<ubot5> Launchpad bug 552805 in Bazaar "Commit message template does not exclude files" [Medium,Confirmed] https://launchpad.net/bugs/552805
<SpamapS> james_w`: I'm not sure what to make of the fact that you know the bug # by heart ;)
<james_w`> SpamapS, only google knows that
<glyph> possibly this should not be an internal error: http://buildbot.twistedmatrix.com/builders/debian64-py2.4-select/builds/894/steps/bzr/logs/stdio
<spiv> glyph: I agree.  jelmer?
<spiv> glyph: jelmer says that may already be fixed in current bzr-svn
<spiv> glyph: inspection of the code suggests yes
<spiv> glyph: interactive testing however suggests no!
<spiv> glyph: investigations continue
<spiv> (Apparently this is not ERR_UNKNOWN_HOSTNAME?)
<glyph> spiv: I don't know man, I don't even work here
<mbt> Dumb question, I can't find this in the docs it seems: given a branch and a file_id, how do I get the last revision that modified the file_id?
<GaryvdM> jelmer: please can I ask you do advise me on bug 704840
<ubot5> Launchpad bug 704840 in QBzr "qlog crashes on svn working copy" [High,Confirmed] https://launchpad.net/bugs/704840
<GaryvdM> I posted a question in the bug.
<vila> GaryvdM: thanks for the installers !
<GaryvdM> vila: It's a pleasure :-)
<GaryvdM> vila: I got the test suit to finish for the first time (with the standalone installer.) I had to exclude a bunch of https that were causing the test suit to fail.
<GaryvdM> s/fail/hang/
<vila> GaryvdM: fail
<vila> GaryvdM: grr, file a bug with as much relevant  -s xxx you can think of and I'll try to give you more instrucitions
<vila> to better localize the problem
<GaryvdM> Ok will do. I'm going to slowly work at.
<vila> GaryvdM: by the way, 2.2.3 in the pipe... :)
<GaryvdM> vila: Ok
<jelmer> GaryvdM: hmm
<jelmer> GaryvdM: I think we should fix the bzr-svn config
<jelmer> GaryvdM: but I'm also a bit surprised by the actual implementation in bzr.dev
<GaryvdM> jelmer: ok
<GaryvdM> I battling to grok the "increasing the python requirement " thread in ml. Where any decisions made?
<jelmer> I'm not sure, I had the same problem :-)
<spiv> GaryvdM: "stick with 2.4 for now" is the short answer
<GaryvdM> spiv: Thanks
<spiv> GaryvdM: with some interest in playing with 2to3 etc sometime soon to see how hard it would be to run on 3.x
<mythril> how do I eliminate a specific revision?
 * mbt 's ears perk up
<mbt> Python 3.x?  Yes?  Yes?  :)
<spiv> mbt: I wouldn't hold your breath...
<mbt> lol, yeah, that seems to be the general consensus in most major python systems
<mbt> spiv, You wouldn't know how to answer my ? from earlier, would ya?  I'm still stuck; I seem to be barking up all the wrong trees
<mbt> ha, ha, that was an awful pun
<GaryvdM> mythril: if there are no revisions after the revision you want to eliminate, then you can do a bzr uncommit
<mbt> mythril, Do you need to eliminate it from the history, or would reverting it be sufficient?
<GaryvdM> mythril: if there are revisions after, you could do a reverse cherry pick to revert the changes made by that revision, but the revision would still be in the history..
<mbt> Should be possible also, in theory, to make a new branch, then on the old one, uncommit repeatedly to back way up, and then merge from the new branch as a cherry pick.  Then only the dead revision has to be pruned, right?
<jam> mbt: this is also something that bzr-rewrite was developed to help with
<jam> I don't know the specific invocations, though
<jam> (something like "bzr rebase")
<jam> but there have been complaints that rebase doesn't work very well with a single branch, etc.
<GaryvdM> mbt: re you question about getting the revision that last modified a file
<GaryvdM> If you get the inventory item for the file, you can call item.revision to get the revid.
<GaryvdM> You will then need to get a revno for the revid.
<mbt> I _think_ I found a way, using iter_entries_by_dir from RevisionTree
<GaryvdM> I'm not sure how you are iterating the files, and hence what is the easiest for you to get the inventory item
<GaryvdM> That will do.
<GaryvdM> mbt: shout if you need help to go from a revid to a revno
<mbt> GaryvdM, That I think I have; but whether or not the way I am doing things is going to be efficient is yet to be determined.
<GaryvdM> mbt: is this for a web server?
<mbt> Yeah, I'm workign on getting Redmine (a Ruby on Rails application) to try to support shared bzr repositories.
<mbt> But the way that the bzr command line tool works, and the way that Redmine works, well, they don't have the same conceptual model of things.
<mbt> Unless I am missing something in bzr or bzrlib, without a branch context a lot of operations are impossible.  But Redmine does not give you the branch context if you tell it that the revision system supports branches; instead it treats branches as a reference to a revision number (as if it were a tag in reality), and path information won't include the branch in that instance.
<mbt> So instead, I'm trying to use the approach that it uses for subversion, which is to pass the repository as the URL; the URL may or may not be a branch, and if it is not a standalone branch, then the branch will have to be found from the relative path information
<mbt> That seems to be working, but then I am left with breaking apart the branch information to find the relative path for the directory being browsed
<mbt> And the odd thing is that since that comes from the RevisionTree, which comes from the repository, I can get a whole tree, but then I have to get into the branch context again to map the revision IDs to branch-local revision numbers.
<mbt> What I am trying to figure out now is the most direct way of finding a path in the revision tree
<GaryvdM> mbt: Ah - the api is like that, because the calculation of revision numbers is dependent on knowing branch tip
<mbt> I get the why, but I don't understand why Redmine doesn't pass (branch, rel_path) to the VCS
<mbt> That would make live a lot easier, and would make the bridge between bzr and Redmine a lot less ugy
<mbt> *ugly
<GaryvdM> I see
<GaryvdM> if you can guess the branch tip, and are willing to go down a api level, you could calculate the revnumbers with out a branch ref
<mbt> Only other thing is: can I get a path without kicking off the generator? Something like revisiontree.get_file_inventory(file_id) some how or another?
<mbt> Oh?
<mbt> (Or for that matter, just get the inventory for the root directory of a working tree, since the inventory apparently has references to all of its children)
<GaryvdM> Yes
<mbt> I see get_root_id in revisiontree, but I don't see a way to get its inventory without a generator somewhere.  For that matter, I'm not even sure that I'm hunting in the right place in the API
<GaryvdM> revision_tree.inventory[file_id]
<mbt> Oh?
<mbt> Oh, well, sheesh.
<mbt> Why didn't I see that like three hours ago lol
<GaryvdM> I'm not sure if that is abusing the api a bit. Maybe one of the core devs can comment on that.
<mbt> I don't know but it eliminates a function or two from my own code
<mbt> so that isn't bad
<zyga-efika> mbt: hi
<zyga-efika> mbt: I'm still busy today but I looked at your changes
<zyga-efika> mbt: I'll try to rewrite the single-branch model first
<zyga-efika> mbt: and see how that works
<zyga-efika> mbt: but it seems this will work
<mbt> zyga-efika, I am looking at single branch ATM but I think it will transparently work for both.
<mbt> I can commit my WIP in a sec
<mbt> I have a very unhappy Entries list lol
<zyga-efika> unhappy?
<mbt> It loads without crashing, but with empty fields
<mbt> it's what I'm working on right this sec
<mbt> it's up
<mbt> I think it's unhappy because I have not yet taught it fetch_changesets
<mbt> which is I think what I need to do next
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | 2.2.3 is frozen, time to build the installers ! (rm vila)
<zyga-efika> mbt: I'm still occupied with my daily job, I need to finish some of the stuff in my backlog
<mbt> zyga-efika, no biggie
<mbt> am going to bind my branch so i don't forget to push
<zyga-efika> mbt: thanks
<mbt> zyga-efika, np... thank you
<GaryvdM> abentley: I can't see 1.1 in lp:bzr-pipeline. Maybe you forgot to push?
<poolie> thanks for the windows builds gary
<GaryvdM> Hi poolie.  np :-)
<GaryvdM> poolie: it feels good to be able to get back in to the swing of things :-)
<poolie> it's great to have you back
<abentley> GaryvdM, the 1.1 release is on the stable branch, not the trunk.
<GaryvdM> abentley: oh - ok
<lifeless> mkanat: hi
<mkanat> Hey lifeless.
<lifeless> I was talking to poolie
<lifeless> about loggerhead & branches and launchpad
<lifeless> uhm
<lifeless> so you know that we've reorged the Launchpad team, right ?
<mkanat> lifeless: Don't know anything about it, no.
<lifeless> ah
<lifeless> so http://blog.launchpad.net/general/changing-how-we-track-launchpads-bugs-questions-and-blueprints references a mail from me
<mkanat> lifeless: Okay. But that wouldn't apply to loggerhead, since it's a separate product that's used elsewhere in addition to being used by LP.
<mkanat> (Much like bzr itself wouldn't become part of launchpad.)
<lifeless> thats true
<lifeless> what is concretely means is that we're less siloed
<lifeless> so we are more likely to fix things that are important rather than things that are important in one area
<mkanat> lifeless: Although I'd think that it will also mean that your design will become more haphazard in the individual pieces, if the same people aren't always working on them. But that's more of a side note.
<mkanat> Perhaps though the overall design will become more cohesive. Hard to say.
<lifeless> one way to find out :)
<lifeless> also its kindof my job, and jml's job to keep the technical and user stories cohesive
<mkanat> lifeless: Sure, I just would be concerned that this will shift *all* design work onto you.
<mkanat> Instead of allowing you to have sub-designers for the individual pieces.
<lifeless> mkanat: nah, I chase after rather than being a bottleneck
<lifeless> I like being able to sleep
<mkanat> lifeless: Haha. :-)
<lifeless> anyhow
<lifeless> so - I'm worried that with the separate trunk + for-lp branch that we'll end up diverging, if trunk stays unsuitable for lp for extended periods
<mkanat> lifeless: Oh, that is a temporary situation.
<lifeless> and AIUI you may be spending less (no?) time on loggerhead
<lifeless> what are your medium term plans vis-a-vis loggerhead?
<mkanat> lifeless: Whether or not I'll still be working on loggerhead depends on administrative details at Canonical, so it's hard to say.
<mkanat> lifeless: The only thing I'll be able to complete in the time that Canonical has currently allotted is bug 567729.
<ubot5> Launchpad bug 567729 in loggerhead "loggerhead could mark all pages cacheable" [Medium,Confirmed] https://launchpad.net/bugs/567729
<lifeless> mkanat: will this leave trunk unsuitable for lp ?
<lifeless> or is it currently suitable?
<mkanat> lifeless: It will leave trunk unsuitable. I had a plan to make trunk suitable for LP, but it was not approved.
<mkanat> lifeless: The disapproval was not technical, it had to do with contracting.
<lifeless> ok, I'll talk with poolie and flacoste about that
<GaryvdM> Hi jam.
<lifeless> how much work has landed since the point it became unsuitable?
<mkanat> lifeless: Well, I can't be sure that history_db itself is unsuitable.
<mkanat> lifeless: But /raw/ is definitely not suitable.
<mkanat> lifeless: Although we could just hack out /raw/ easily, for LP.
<mkanat> s/unsuitable/suitable/
<GaryvdM> jam: I'm running into a bzr bug when building the win installer. The bzr on the ec2 instance is quite old.
<lifeless> poolie: btw, that all pages cachable thing isn't useful for lp
<poolie> oh, because?
<lifeless> poolie: we can just tell squid to do that in ~2 minutes
<poolie> ah, true
<GaryvdM> jam: Admin is needed to install a new version. Please could you do that for me.
<mkanat> lifeless: BTW, the CSS for loggerhead on LP seems to be wrong.
<mkanat> lifeless: This page, for example, does not have the right CSS: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/annotate/head:/.bzrignore
<lifeless> the raw controller has a knob overriding it though?
<mkanat> lifeless: It doesn't, but it would just involve commenting out a few lines.
<lifeless> ok
<mkanat> lifeless: The only think LP needs for it to work properly is the token thing, because of the private branches.
<mkanat> lifeless: I'd be totally thrilled to do the work to make trunk stable and on LP though.
<lifeless> :)
<poolie> jam, GaryvdM, i'd like to sometime migrate the windows vm to use an ebs-based root partition
<poolie> then it'll be easier to save the state
<poolie> lifeless, will you comment on that squid bug or shall i?
<lifeless> I will
<GaryvdM> poolie: I'm only using the ec2 instance for 2.2 builds. For 2.3, I'm hoping I'll be able to get a 64 bit build done, so I'm using a local 64bit vm.
<poolie> ah, ok
<GaryvdM> poolie: having my own local vm allows me freedom to changes things, but I guess it's not good if I need to hand over to someone else.
<mkanat> lifeless, jam: Is there some plan for how storing and updating history_db would work for LP?
<jam> mkanat: hand-wavingly every project would get its own sqlite db file
<jam> which gets updated on demand
<jam> and we would pre-seed projects like emacs
<mkanat> jam: Okay. Does history_db do incremental updates now?
<jam> always has
<mkanat> jam: Okay, cool. I thought so, just wanted to check.
<jam> just that the *first* update is faster if you do it manually
 * mkanat nods.
<jam> plus, it means that someone hitting the website isn't the one waiting for it to complete
<mkanat> Yeah, for sure.
<mkanat> In an ideal world we'd update it asynchronously every time somebody changed the tip.
<jam> mkanat: it actually wouldn't be a lot of overhead from that, at least my timings showed it to be quite feasible to run it as a post-commit hook in bzr
<mkanat> jam: That'd be great if we could do that. Would require instrumentation and changes on codehosting, of course.
<jam> at least once it has the first 100k revisions completed :)
<mkanat> Right. :-)
<jam> mkanat: yeah, some sort of job-task that triggers when a branch is updated
 * mkanat nods.
<jam> we already have the branch scanner which does similar work
<jam> and we've been talking a bit about changing some of the postgres tables to use the history-db-like layout
<jam> since BranchRevision currently is something like 0.5Billion rows
<mkanat> Wow.
<jam> anyway, when we poke at that, loggerhead could just use the production tables (possibly via an intermediate db, rather than the actual live one, etc)
<jam> abentley: didn't you write up a LEP on this?
<mkanat> Right. That'd be even simpler if we had history_db use an ORM.
<abentley> jam, not quite a LEP, but: https://dev.launchpad.net/Code/BranchRevisions
<jam> abentley: thanks. I wanted to point mkanat at the idea that we were looking at that sort of thing.
<jam> mkanat: well, it is pretty generic sql, using python dbapi2
<jam> so you could do it to pretty much any SQL backend
<mkanat> jam: True.
<jam> some of the create syntax is sqlite specific
<mkanat> abentley: I wonder about the "use loggerhead" proposal, there. It's possible we could make it fast enough.
<jam> (PRIMARY KEY AUTOINCREMENT vs using SERIAL in postgres)
<abentley> mkanat, it's not a complete solution.
<mkanat> abentley: Okay. Because you need to JOIN that table against other things in SQL?
<mkanat> jam: Yeah, this would seem like a good reason to abstract history-db out into a plugin, again, reading this BranchRevisions proposal.
<GaryvdM> jam: Thanks - the upgrade fixed the bug.
<jam> mkanat: it is a plugin
<abentley> mkanat, it would not address "Finding the most relevant branch for any given revision" "Allocating revision karma" or "Merge detection in the scanner "
<jam> we pulled it into loggerhead to avoid having a weird plugin dependency
<mkanat> jam: Ahhh.
<jam> for people that want an easy way to set up loggerhead
<jam> the history is synced up, though, so loggerhead can merge updates from the plugin, and you can cherrypick loggerhead changes back to the plugin
<mkanat> jam: Oh, okay. Are there changes that I should pull in, now?
<jam> mkanat: nothing I know of
<mkanat> jam: Okay.
<lifeless> mkanat: ok, I has spoken with poolie and flacoste
<lifeless> mkanat: what we propose to do is:
<Erimos_Wolf> Hi at all, i have a question considering the behavior of the bazaar plugin for eclipse. Iam not sure if this is the right channel
<lifeless>  - push the history-db & raw stuff to a experimental/future branch and push stable to trunk
<lifeless>  - have the launchpad team adopt the loggerhead project, so we'll do bug triage & code review
<GaryvdM> Erimos_Wolf: ask away
<lifeless> mkanat: does that sound sensible to you?
<mkanat> lifeless: Ah, that doesn't quite make sense.
<mkanat> lifeless: history_db is already on trunk.
<mkanat> lifeless: As is raw.
<mkanat> lifeless: stable is well behind trunk.
<mkanat> lifeless: Pushing stable to trunk wouldn't make any sense.
<Erimos_Wolf> I followed the instructions and installed bazaar on my local machine. In eclipse i have under Project->Team all bazaar instructions. But when i try to commit it says every time "nothing to commit". A look at the bazaar explorer says different. There i can commit. Is this normal?
<mkanat> lifeless: trunk is the experimental and future branch.
<mkanat> lifeless: The launchpad branch of loggerhead has many important things from trunk that aren't on stable.
<lifeless> mkanat: yes, thats my understanding; we want to get trunk stabilised and this seems the most robust way to do it
<jam> mkanat: he wants to turn that around
<jam> make trunk stable
<jam> and start and experimental branch
<jam> by "resetting" trunk
<mkanat> lifeless: Right, I want to make trunk stable as well.
<mkanat> jam: I'm not sure that makes sense at this point.
<mkanat> Why not just do the work to stabilize what's on trunk now?
<mkanat> It would be a few weeks of work at the most, I think.
<mkanat> lifeless: Also, I'm not sure that having only the launchpad team work on loggerhead will be the best for the non-launchpad users of loggerhead.
<GaryvdM> Erimos_Wolf: I guess that's not normal. verterok?
<mkanat> lifeless, jam: Also, it's not possible to extract the unstable parts of trunk, for the most part--they involved a lot of refactoring and then what comes after is built on that refactoring.
<mkanat> It would probably be almost as much work to "reset" trunk as it would to actually make trunk stable.
<lifeless> sorry, local interrupt
<Erimos_Wolf> is there a log file to digg through?
<lifeless> mkanat: so the bzr team is focusing on udd
<GaryvdM> Erimos_Wolf: ~/.bzr.log
<GaryvdM> My Document\.bzr.log on windows
<lifeless> mkanat: which means that AFAIK there isn't anyone really worrying about loggerhead atm except you
<mkanat> lifeless: Yeah, although that's been true for about a year now.
<lifeless> right
<lifeless> launchpad has a vested interest in loggerhead being a solid component, and we're decent folk - we like reusable modules and components
<mkanat> lifeless: Yeah, I agree. I just want to be sure that the user experience or configuration experience doesn't degrade for people who aren't LP.
<lifeless> I am pretty sure it won't
<jam> mkanat: I think Peng is a good test subject
<jam> :)
<mkanat> jam: Okay. :-)
<lifeless> I doubt it will improve without someone interesting it making that *better* stepping up
<Erimos_Wolf> I think the plugin doesnt call bazaar in any way. It just reacts with this message. The log shows only the last actions take from the explorer.
<lifeless> Peng: yo, around?
<lifeless> mkanat: now, for the question of code stabilisation
<lifeless> mkanat: you're saying there are three branches?
<lifeless> trunk, stable and lp ?
<mkanat> lifeless: More or less, yeah.
<lifeless> ok
<lifeless> so, I think that I'm proposing
<lifeless> future, trunk and lp
<mkanat> lifeless: That was something we were forced to do because of my limited time.
<mkanat> lifeless: Honestly, I think that's just a non-standard terminology change.
<mkanat> lifeless: "trunk" should mean "future".
<mkanat> lifeless: I don't see the advantage we'd get from renaming it.
<mkanat> lifeless: The solution I'd prefer to see is that trunk become stable, then branches for 1.19, and then 1.19 and trunk are both maintained.
<mkanat> lifeless: And from that point forward, trunk releases frequently in new stable releases.
<lifeless> so, because of limited resources
<lifeless> I'd rather not maintain multiple branches
<mkanat> lifeless: There are just as many branches as in your solution. In fact, there is one less.
<lifeless> in particular, having patches build on history db when its not production ready (whatever that means) is a bit counter productive - we'll end up being essentially forked, which is undesirable
<lifeless> mkanat: going forward, after future is integrated, it could be deleted.
<lifeless> mkanat: in my proposal
<mkanat> lifeless: Oh, that's what I'm talking about doing in any case.
<lifeless> I don't have an answer for how future would get integrated
<lifeless> so we'd just have trunk and lp
<lifeless> with trunk always stable
<mkanat> lifeless: Well....
<mkanat> lifeless: I think it would be better to have trunk and stable, and lp just runs stable.
<mkanat> Or trunk and "current stable branch".
<lifeless> what advantage does an unstable trunk offer?
<mkanat> lifeless: This is stuff I've already planned out in detail with poolie, quite a bit.
<mkanat> lifeless: The advantage is in a stable branch, not in the trunk.
<mkanat> lifeless: And I'm sure you already know the advantages of a stable branch, and me explaining them to you would be redundant.
<Erimos_Wolf> no ideas?
<mkanat> Erimos_Wolf: You might want to ask whoever maintains the Eclipse Bzr integration.
<mkanat> Erimos_Wolf: bzr does keep a ~/.bzr.log
<Erimos_Wolf> ok, thank you
<GaryvdM> Erimos_Wolf: bzr-eclipse is maintained by verterok.
<GaryvdM> Erimos_Wolf: bzr-eclipse is probably looking in the wrong directory.
<GaryvdM> That might show up in the log if you look at the paths
<Erimos_Wolf> the directory for the bzr exe is setup
<Erimos_Wolf> I "shared" the project like the tutorial says.
<GaryvdM> Erimos_Wolf: maybe you have to add files before you can commit them in bzr-eclipse?
<Erimos_Wolf> There was already a "hello world" code
<Erimos_Wolf> if i do any changes, the plugin doesnt recognize them. Although the "history" is written correctly
<mkanat> lifeless: FWIW, stabilization of trunk would probably just involve some refactoring, writing some tests, and doing some tests to show that everything will work at LP scale.
<mkanat> lifeless: "writing some tests" is the longest part of that, probably.
<Erimos_Wolf> looks like verterok is not availible, idle for almost 3 hours
<GaryvdM> vila: 2.2.3 windows installers are done.
<vila> GaryvdM: hmpf ! This time you beat the osx packagers :D
<vila> GaryvdM: nice work !
<GaryvdM> :)
<dOxxx> there was a 2.2.3 release? doh
<vila> dOxxx: :D
<dOxxx> bah, you cheated. you posted while I was at work. :P
<vila> dOxxx: by the way, I'll be on the move tomorrow so I may not be able to build the 10.5 one before.... some days :)
<dOxxx> vila: just fixing up the release notes and what's new for my mergetools mp
<vila> dOxxx: ok
<dOxxx> vila: hmm ok
<dOxxx> vila: I think the 10.5 audience is smaller so it's probably not such a bad thing if it's delayed a few days
<vila> dOxxx: hmm, but you pushed that already no ?
<vila> dOxxx: and as long as it's available when we *announce* (instead of freeze), that's good enough
<dOxxx> vila: pushed release notes and then noticed in the diff that I forgot to move what's new
<vila> dOxxx: ha, ok
<dOxxx> vila: also rewording it a bit
<dOxxx> pipeline is cool :)
<GaryvdM> dOxxx: Do you think you patch will land in bzr before 2.3 final. If so, I'll push to get the qbzr side in to.
<dOxxx> although the handling of conflicts could be a little better. It would be nice if it could pre-populate the commit message, so I would just have to fix the conflicts and commit.
<dOxxx> GaryvdM: I doubt it. I'm moving my release notes to 2.4.
<GaryvdM> dOxxx: ok
<dOxxx> GaryvdM: unless vila has a sudden change of heart ;)
<GaryvdM> I've fallen a bit behind on email, so I'm not sure what the status is.
<vila> GaryvdM, dOxxx : hehe, let's make it rock in 2.4 instead of trying to shoehorn it in 2.3 :)
<dOxxx> yeah
<vila> dOxxx: my heart is behind the efforts there, I can assure you
<dOxxx> vila: oh for sure, otherwise you wouldn't have stuck with it for so long :)
<dOxxx> vila has been slowly weeding the Java OOP out of my mp ;)
<dOxxx> vila: okay, all set for review :)
<GaryvdM> jam: Do we have any documentation on how to do a bundle of  desolation?
<vila> dOxxx: ok, I'll try to review it now (~20 left), if I fail to do that... that will be tomorrow only :-/
<jam> GaryvdM: I don't think it is explicitly documented. It is go to the AWS console, and tell it to create a bundle, when that finishes, tell it to create an AMI
<dOxxx> vila: sure, no problem. thanks :)
<jam> GaryvdM: there *is* doc/developers/ec2.txt
<GaryvdM> I tried but I'm getting: NoSuchBucket(404)- The specified bucket does not exist
<jam> GaryvdM: what S3 bucket are you trying to bundle into?
<jam> do you want me to do it?
<GaryvdM> jam: I entered desolation-20110121 for the bucket name. Do I have to create it first?
<GaryvdM> jam: I would like to learn.
<jam> GaryvdM: no, but you need to set the bucket to ec2.bazaar-vcs.org
<GaryvdM> ok let me try that.
<vila> dOxxx: approved, well done, I'll pqm it
<dOxxx> vila: yay!
<jam> GaryvdM: from the web console
<jam> right click on the instance
<jam> say "bundle"
<jam> then S3 bucket name is ec2.bazaar-vcs.org
<jam> the S3 Key Name is desolation-20110121
<GaryvdM> Ok - and then shut down from rdc
<jam> GaryvdM: the bundle request should handle the shutdown
<jam> so you don't have to do it manually
<jam> (It didn't always work for me from ElasticFox, but it has always worked from the web console for me)
<jam> by having "bundle" do it, it will also bring it back up when the bundling is finished, I think
<GaryvdM> Ok - so I have to remember to come back and shut it down.
<GaryvdM> jam: thanks - it's working now.
<jam> GaryvdM: right 3% is the "it isn't shut down yet" but it should progress from there
<GaryvdM> Ok - I better go. They lock the gates for the office park at 2am . I might come on line at home.
#bzr 2011-01-21
<lifeless> mkanat: sorry, more local interrupts
<lifeless> mkanat: and we have a group dinner tonight
<lifeless> mkanat: I'll pick this up tonight or tomorrow evening - I have caught up more fully with poolie on this
<mkanat> lifeless: Okay.
<dOxxx> mmm steak. bbl.
<GaryvdM> dOxxx: I've read your finale patch. I looks very good. I think I should try make qbzr ext diff tools config similar to the new mergetool config.
<GaryvdM> jam: bundel is at 37%, so I think it working :-)
<GaryvdM> *bundle
<dOxxx> I return, steakified.
<peitschie> hi everone :)
<Peng> Haha, test subject. Whatever it was, I'm probably not a good test subject ATM. Especially since I was on the road when you were discussing it. :P
<mkanat> Peng: For loggerhead users who aren't LP.
<Peng> Oh, you're here.
<Peng> mkanat: Yeah...I kind of dropped off of the world a while back. I am back on IRC, but I'm not tinkering with Bazaar or Loggerhead again yet.
<Peng> Honestly, I'm running lp:loggerhead from May. :D
<mkanat> Peng: :-)
<Peng> Plus I've hit old age -- you know, 19 -- and I've developed an aversion to breaking things that already work. :P
<Peng> Which is not what's stopping me, but it's making me even less motivated in general. :P
<fullermd> You'll get over that in a few years.
<fullermd> Mostly, 'cuz you'll get to the age that you realize nothing ever gets as far as really 'working' anyway...
<mkanat> Peng: Hahaha. :-)
<Peng> fullermd: :(
<fullermd> It's too early to get frowny.  That was the GOOD news!
<Peng> fullermd: It's good news that nothing ever works?
<Peng> fullermd: Don't worry, I'm not frowny. I just watched Evangelion, so I'm incapable of any emotions but excitement and vague confusion.
<Peng> Woah, half an hour's gone by? Seems I'm also unable to track time properly. :P
<mkanat> Peng: Hahahaha!
<mkanat> Peng: Yes, that's pretty much like a Pan-Galactic Gargle Blaster.
<mkanat> Peng: Did you just watch the *end* of Evangelion?
<Peng> mkanat: No, 2.0! \o/
<mkanat> OMG, didn't even realize that had happened!
<spm> it ends? I got confused after about 6 or so episodes. "is there , in fact, a plot here that bears a vague resemblance to ... a plot" ;-)
<mkanat> spm: Hahahaha. There's more of one than there is for FLCL....
<mkanat> spm: Also, really, the first 12 episodes of Eva are where they're *nice* to you.
<spm> wheee
<mkanat> spm: That's where they make you like the characters so that later they can punish you for ever thinking they were good people.
<Peng> Wait, 6 or so episodes? You didn't see Asuka?
<spm> they failed then. I was starting to despise them all.
<mkanat> spm: lol
<spm> don't recall, this would ahve been 10 ish years ago?
<mkanat> Anyhow, I'm off to the land of Hulu.
<Peng> spm: It has a plot. Only Hideaki ANNO knows what that plot is, but we're pretty sure there is one. Anyway, who cares about that? Watch it for the crazy symbolism, psychological problems and cool fight scenes!
<spm> heh. the cool fight scenes, sure. but he teenage angst. urgh.
<spm> s/he/the/
<Peng> Heh.
<Peng> mkanat: Speaking of FLCL, FUNimation's DVD and Blu-ray release comes out in a month.
<mkanat> Sweet. 1080p of total nonsense. :-D
<Peng> Upscaled, tho.
<Peng> spm: Not a fan of the teenage angst? That could be a problem, yes...
<mkanat> Okay, for reals now, though. Off to TV I go.
<spm> later mkanat
<mkanat> Later! :-)
<spm> Peng: I wasn't a fan of it when I was a teenager. so... ;-)
<Peng> Heh
<Peng> spm: It's got adult angst too, you know. :D
<Peng> Immature adults, but... :P
<spm> that's not winning me over!
<Peng> Hmm...
<Erimos_Wolf> Morning @ all, verterok, are you there?
<jdobrien> ssh: connect to host bazaar.launchpad.net port 22: Connection refused
<verterok> Erimos_Wolf: Hi
<Erimos_Wolf> hi
<Erimos_Wolf> sorry for bothering you but i cannot explain the behavior of the eclipse plugin on my machine
<verterok> Erimos_Wolf: np, I just wokeup :)
<Erimos_Wolf> good morning :-)
<verterok> Erimos_Wolf: do you have the latest version of bzr-xmloutput installed?
<Erimos_Wolf> 0.8.6
<verterok> Erimos_Wolf: and bzr version?
<Erimos_Wolf> 2.2.2
<Erimos_Wolf> got all that info from the bazaar manager
<verterok> Erimos_Wolf: ok, so. I think the behaviour you'r seeing is caused by an old version of xmloutput (IN the nead future, bzr-eclipse will bundle a xmloutput version to avoid this kind of errors)
<verterok> Erimos_Wolf: to use bzr-2.2.2, you need the latest trunk of bzr-xmloutput
<verterok> Erimos_Wolf: is this windows?
<Erimos_Wolf> jupp
<Erimos_Wolf> i mean yes
<Erimos_Wolf> :-)
<verterok> Erimos_Wolf: sadly, I didn't make a release of xmloutput, so there is no installer for trunk
<Erimos_Wolf> so iam not too dump to use the software ?
<Erimos_Wolf> meant dumb
<verterok> Erimos_Wolf: let me try to build one, as an alternative you can branch lp:bzr-xmloutput and replace the installed one with it
<verterok> huh?
<Erimos_Wolf> thx
<verterok> Erimos_Wolf: it will take a while to build the installed, need to update my windows vm :/
<Erimos_Wolf> non prob
<Erimos_Wolf> take breakfast and a good cup of coffee
<Erimos_Wolf> is this considered as a bug?
<verterok> Erimos_Wolf: you can get a installer from trunk at: http://launchpad.net/bzr-xmloutput/trunk/trunk/+download/bzr-xmloutput-setup-0.8.7-r149.exe
<Erimos_Wolf> unbelievable! Could you explain why this happend?
<Erimos_Wolf> please
<verterok> Erimos_Wolf: your xmloutput version is very old, and isn't compatible with the bzr version
<Erimos_Wolf> ok. But i got it through the bazaar setup right?
<verterok> Erimos_Wolf: ah, no idea...it's inscluded in the bzr windows installer?
<Erimos_Wolf> jupp
<Erimos_Wolf> i just followed the tutorial of bazaar, installed the 2.2.2 win standalone
<Erimos_Wolf> got eclipse and installed your plugin (thats al i did)
<verterok> Erimos_Wolf: ok, I think this is because the last "stable" release of xmloutput is 0.8.6, but is broken with latest bzr
<verterok> Erimos_Wolf: I need to get some time to fix a few more bugs and do a release, in order to get it included in the windows installer
<Erimos_Wolf> ok i understand
<Erimos_Wolf> until that this "manual" installing of xmloutput is the best workaround?
<verterok> Erimos_Wolf: yes :(
<Erimos_Wolf> Thank you for the installer and solving my problem :-)
<Erimos_Wolf> So this is a dependency problem between the xmloutput and the plugin,which will be fix through the next release xmloutput?
<verterok> Erimos_Wolf: eclipse plugin?
<verterok> Erimos_Wolf: it's a dependency problem in the bzr windows installer
<Erimos_Wolf> oh, ok.
<verterok> Erimos_Wolf: is bzr-eclipse working as expected now?
<Erimos_Wolf> yesss :-)
<Erimos_Wolf> commiting is done without any problems (only local)
<verterok> cool
<Erimos_Wolf> before i made some changes but there weren recognized "No commits needed"
<Erimos_Wolf> the bazaar manager said the opposite
<Erimos_Wolf> this is why i came here yesterday
<catphish> what protocols can bzr use to push?
<catphish> is it just ssh or apache dav?
<Lo-lan-do> Smart server over HTTP, too, I think.
<catphish> that's what i want
<catphish> can's see any onfo on running smart server on http though
<james_w> catphish, http://doc.bazaar.canonical.com/bzr.2.2/en/admin-guide/other-setups.html#smart-server-over-http-s
<catphish> oh yeah :)
<catphish> does the smart server have an executable?
<catphish> since my webserver is not python, it will need to accept a request and pipe it to a bzr executable
<james_w> catphish, that would be the fcgi method wouldn't it?
<catphish> is there an executable provided with stdio? or will i need to wrote my own?
<james_w> the bzr command
<catphish> so does the smart protocol simply contain bzr commands?
<catphish> i'll sniff a few
<maxb> It contains a custom message format
<catphish> does that message format map to bzr CLI commands?
<catphish> or is it more complicated?
<catphish> maxb: is the http protocol documented by any chance?
<maxb> catphish: Not that I know of, but you wouldn't want to reimplement it from scratch anyway
<maxb> So, are you saying your webserver cannot do fastcgi?
<catphish> yes
<maxb> Nor has a WSGI adaptor?
<catphish> most likely not
<catphish> i will consider plugging the python in
<catphish> but i would prefer to implement it myself, purely because that's what i've done for git and hg
<catphish> rather than doing authentication then proxying, which is what i have had to do for svn
<maxb> Well, it might not perform great, but you could run the smart server WSGI app as a CGI
<maxb> plain CGI that is
<maxb> http://henry.precheur.org/python/how_to_serve_cgi
<catphish> that could work
<catphish> ideally i'd like to take the http request and map it to a bzr command
<maxb> "bzr command"?
<catphish> perhsps i should have a read of the cgi adapter and see what's involved
<maxb> "bzr command line invocation"?
<catphish> either that or a bzr pipe interface
<catphish> if there is such a thing
<catphish> the ssh interface must execute something
<maxb> erm, that's what running the smart server WSGI app as a CGI *is*
<catphish> yes i suppose it is actually
<catphish> what about the ssh smart server interface? how is that executed?
<maxb> The ssh interface executes bzr serve --init --allow-writes --root=/something
<catphish> that sounds like what i want
<catphish> in hg for example i run "hg serve --stdio"
<catphish> then map the http requests to ssh interface commands and pipe them in
<maxb> whoops, I mean bzr serve --inet --allow-writes --directory=/something
<catphish> of course, that's the raw smart server
<maxb> huh, doesn't mercurial have a http interface of its own? Why are you so determined to reimplement things?
<maxb> In fact, if you wrote a WSGI adapter for your server, you could use it for both hg and bzr :-)
<catphish> maxb: because i have a ruby web server that implements my ACLs
<catphish> and i don't want to then run apache in addition to host the repos
<catphish> and proxy to it
<catphish> you're right that i could implement a WSGI adapter, then do the authentication before passing through to that
<catphish> but i didn't
<catphish> and most SCMs have a web protocol that easily maps to their SSH protocol
<catphish> so i convert the http requests and pipe them through
<catphish> i realise i'm reinventing in places
<catphish> also, because my repositories are located on an array of storage hosts and my web server is on an array of frontend hosts, doing it this way means i can create an rpc interface between the web server and the storage server
<catphish> looking at the http protocol and the smart protocol, it looks like they might actually be identical
<catphish> which makes this very easy
<catphish> what does "No repository present" mean? (error from smart protocol)
<catphish> i am specifying a branch inside a repository, would it not be finding the parent repository for some reason?
<thumper> catphish: where is your remote branch?
<catphish> its inside a repository
<catphish> i'm specifying it to bzr serve "bzr serve --allow-writes --inet --directory=/path/to/repo/branch"
<catphish> i then issue: "bzr message 3 (bzr 1.6)\n\000\000\000\034d16:Software version5:2.1.1es\000\000\000\034l20:BzrDir.open_branchV31:.ee"
<catphish> and get back "bzr message 3 (bzr 1.6)\n\000\000\000\034d16:Software version5:2.1.1eoEs\000\000\000;l5:error47:No repository present: \"filtered-162975116:///\"ee"
<thumper> holy shit... bzr 1.6 is old
<catphish> oh yeah i didn't spot that
<catphish> i'm running bzr 2.1.1
<catphish> i wonder what's happening there
<thumper> what is the server running?
<thumper> 2.1.1 too?
<catphish> its the same machine right now so yes
<catphish> i'll look into that first!
<catphish> i guess its probably falling back to an old protocol version
<catphish> i'll try to fix that
<catphish> actually i think that is the latest version of the protocol
<catphish> it appears that my problem is that because i specified --directory to point to the branch, the client is not being allowed access to the repository above
<fullermd> Yes, --directory acts much like a chroot.
<catphish> that makes sense, but if i point the directory to the repository, the client dies because it's not a branch
<catphish> am i missing something in between?
<fullermd> The client has to supply a path below the --directory served.
<catphish> actually that seems kinda obvious now that you say it
<catphish> how would i do that over http? i enter the url as: bzr+http://localhost/repo.bzr/branch
<catphish> how does the client know that branch is the branch?
<catphish> or do i need to do something active in my webserver?
<catphish> as far as i know, the client does not specify a branch location at all right now, it just relies on --directory to put it in a branch
<maxb> catphish: --directory should be specified by your *server* to the root of the bazaar storage to which the client is allowed to see
<catphish> maxb: i understand that part
<catphish> however, what i am stuck with is how to instruct the client to select a particular branch
<catphish> quite simply, the client does not bother to do so at all
<catphish> so i am thinking that i need to inject a command
<catphish> maxb: do you happen to know the command to specify the branch?
<maxb> It is not part of the command, it is part of the protocol
<catphish> yes, but the protocol sends commands
<catphish> right now my client sends: "BzrDir.open_2.1" then "BzrDir.open_branchV3"
<catphish> no mention of *which* branch to open
<maxb> yes there is, in the parameters
<catphish> i don't see it
<catphish> it definitely doesn't send a branch
<catphish> it sends just the 2 commands i mentioned (this is over http)
<maxb> l20:BzrDir.open_branchV31:.e
<maxb> command and parameter
<catphish> oh, the parameter is just '.' ?
<catphish> that makes much more sense
<catphish>  do you know if bzr+http will even send anything other than '.'?
<catphish> *ever
<maxb> Use the source
<maxb> or stop reimplementing it :-/
<catphish> i'm not reimplementing the client :)
<catphish> but i am finding my way through some of the code
<catphish> just hoped you'd know
<catphish> sadly i'm not a native python speaker
<catphish> i can't seem to find a way to make the client differentiate between the base url and the branch name
<fullermd> There isn't one.
<catphish> so am i correct in saying that the only way to implement multiple branches in bzr+http is to have the http server rewrite the BzrDir.open_branchV3 command?
<catphish> rather than using BzrDir.open_branchV3('.') which the client always sends
<catphish> or is there a better way to tell the client what the correct base url is?
<catphish> unfortunately I can't find a repo anywhere that does this correctly
<catphish> for example "bzr clone bzr+http://pyzgoubi.bzr.sourceforge.net/bzr/pyzgoubi/branches/0.4.x"
<catphish> shows the same error on SF
<fullermd> Well, I dunno what's what on the level you're looking.  But from a client side, a URL is atomic.
<fullermd> It's all just one opaque thing.
<catphish> to summarize, the problem i have is that when using bzr+http the command that the client sends to the server is always BzrDir.open_branchV3('.')
<catphish> assuming that the branch is the root of the repository at the other end
<fullermd> Other way around.  The client doesn't care anything about a repository; that's all under the covers.
<catphish> the problem is that on the server side, I pipe the request to "bzr serve --allow-writes --inet --directory /path/to/repo/branch"
<catphish> which has the unfortunate side-effect of not allowing access to "/path/to/repo"
<catphish> whereas if i pipe it to "bzr serve --allow-writes --inet --directory /path/to/repo" then the client tries to open branch '.' which obviously fails
<catphish> the only solution i can come up with is for the web server to rewrite the "BzrDir.open_branchV3:." command to be "BzrDir.open_branchV3:branchname" based on the url
<catphish> but i wanted to know if that's the correct solution
<catphish> since i don't have sufficient python knowledge to read the python http smart server
<catphish> i was really hoping to be able to pass the http body through to the 'bzr serve' unmolested
<catphish> but i guess that's not quite going to cut it
<catphish> well i have to go now, will test some things and see
<poolie> i put up a tuolumne patch that will correctly represent 0 new bugs
<catphish> excuse my stupidity one more time, but where is bzr-smart.fcgi?
<catphish> ah got it
<cody-somerville> hmm... I'm using the bzr pipeline plugin
<cody-somerville> and the the top pipe (ie. the upstream branch I'm maintain patches against) has somehow turned into what appears to be the last pipe
<cody-somerville> or wait a tick, it looks like a bunch of stuff from different pipes has made it into it
<cody-somerville> and interesting... these revisions I see haven't been piped.
 * cody-somerville wonders if this is some sort of bug in sync-pipe
<dOxxx> cody-somerville: there's a new version of bzr-pipeline, have you tried that?
<cody-somerville> nope
<cody-somerville> is it good?
<cody-somerville> any release notes/changelog available?
<dOxxx> Changes:  - bzr pump supports --show-base, --reprocess and --merge-type.  - Pipes can no longer be accidentally named ":next", etc.  - Pipeline imposes smaller start-up cost when not used.
<dOxxx> so, from the sounds of it, may not fix your problem
<dOxxx> check if you can find a similar bug at https://bugs.edge.launchpad.net/bzr-pipeline, otherwise file a new one.
<dOxxx> you could also try posting on the bzr mailing list.
<maxb> bzr-pipeline 1.1 is ready in the proposed PPA. probably fine to promote now
<jelmer> maxb: Didn't you fix bug 622188 ?
<ubot5> Launchpad bug 622188 in subvertpy "Test failures built against Subversion 1.4 (three fail) or 1.5 (one fail)" [Low,Triaged] https://launchpad.net/bugs/622188
<maxb> I think so
 * maxb checks it got merged
<maxb> yes, in 0.7.5
<jelmer> maxb: Great, thanks for checking!
 * jelmer marks as fix released
<mkanat> Hey poolie. :-)
<maxb> jelmer: btw, what is the plan for bzr-svn version numbers now?
<maxb> lp:bzr-svn seems slightly confused about whether it is 1.0.5 or 1.1.0
<jelmer> I'll move to 1.1
<jelmer> thanks for the reminder
<maxb> This could get confusing :-)
<kire> I am trying to run a bazaar smart server over https, but when I try to push something I get an error like "ERROR: Cannot lock LockDir .... ERROR: Cannot lock LockDir"
<kire> ehm, last part is "Transport operation not possible: http does not support mkdir()"
<jelmer> kire: that suggests the smart server is not working
<kire> do you have to use bzr+https?
<jelmer> you shouldn't have to
<kire> ah, I should upgrade my server version probably, seems to be 2.0, are there any decent repositories for debian lenny?
<jelmer> I don't think there are any recent backports
<jelmer> I'm planning to do one when squeeze gets released
<kire> and the pain of terrible ubuntu support of my server provider hits me again :p
<kire> okay, I'll see if I can get something to work, thanks anyway :)
<maxb> jelmer: I have one pending MP concerning ~bzr-svn/bzr-svn/1.0, do you want it resubmitted against ~bzr-svn/bzr-svn/1.1 ?
<dOxxx> eugh... damn 2.4 compatibility.
<dOxxx> can't use str.format ><
<mgz> damn 2.5 compatibility too then.
<dOxxx> yah
<dOxxx> so now I'll have to fake it
<catphish> just in case anyone missed this earlier, and knows of an easy solution, is there any way to make "bzr serve --directory /path/to/repository/branch" work? by default it does not appear to work because it denies access to the repository directory above
<mkanat> catphish: The branch would have to be standalone.
<mkanat> catphish: You could use "bzr reconfigure" to make it standalone.
<catphish> mkanat: i'm hoping that will work as a last resort, but i'm trying to avoid it
<mkanat> catphish: I'm pretty sure there's no way to avoid it.
<catphish> i hope to serve /path/to/repository instead and have something between the client and the server prepend the branch name to requests
<catphish> unfortunately the http url scheme does not differentiate between repo and branch, it assumes the url points to the root of a branch, and always assumes the branch is '.'
<catphish> anyway, went over this earlier and i don't think there's a simple solution other than inserting the branch into the request between receiving the http request and passing it to the smart backend
#bzr 2011-01-22
<catphish> yay, i managed to append the branch name in my http frontend, all working as it should now
<jelmer> maxb: please
<nilg`> help!!! I've just done some bzr revert FILE by mistake, how can I de-revert?
<nilg`> OK, found the answer http://stackoverflow.com/questions/815933/undo-bzr-revert
<taylanub> bzr 2.2.2(-2 on arch) hangs with full CPU usage while creating the log file, if it is a symlink
<taylanub> hrmm, arch apparently applies some python2.7 compat patches
<taylanub> and it's extremely slow, but that might be the server i'm connecting to at the moment (bitlbee)
<Muscovy> I'm having some issues pushing to a new launchpad bzr branch.
<Muscovy> I keep getting this error: http://paste.ubuntu.com/556888/
<Peng> Muscovy: So, have you moved the target directory out of the way and tried again? :P
<Muscovy> That does that mean, Peng? Remaking the branch?
<Peng> Well, the specific error message is whining that a .bzr control directory exists at lp:opensearch but nothing's in it.
<Peng> And the error message suggests you remove said directory.
<Peng> Try using your favorite SFTP client, or hitchhiker, to log into lp:opensearch and remove the .bzr directory or rename it to backup.bzr (Launchpad doesn't allow you to rename it to whatever you want).
<Muscovy> Alright.
<Muscovy> ...how do I do that?
<Muscovy> I tried googling how to use hitchhiker, but it didn't help.
<Muscovy> I also tried deleting and remaking the branch, but it has the same error.
<Muscovy> I figured out how to sftp in. One of the two problem branches had a .bzr. I removed it, but that branch still gives the same error.
<Muscovy> Some repeated attempts made one of the branches work.
<Muscovy> The other branch still shows no .bzr and gives the same error.
<Muscovy> Oh, all good. :D
<Muscovy> Thanks for your help, Peng.
<maxb> SubversionException: ('Commit failed (details follow):', 200014)
<maxb> Anyone know where the details disappear to, when one of those is thrown in the bzr-svn testsuite?
#bzr 2011-01-23
<catphish> what is the fastest way to find the last commit for a particular path?
<catphish> right now i'm using: "bzr log -r ..500 -l1 path/to/file"
<catphish> but that isn't very fast, does bzr have a more efficient way to do the same thing?
<kire> log -r-1 path/to/file catphish ?
<catphish> i don't think that works
<catphish> that only finds the last commit, if that file wasnt modified in tha last commit it returns nothing
<catphish> i guess it has to traverse each commit and that takes a while
<peitschie> mornin everyone :)
#bzr 2012-01-16
* vila changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila
<vila> hi all
<fullermd> Huh?  All?  Where?!
 * fullermd looks around frantically.
<vila> hehe, don't worry, they'll come around, back from Budapest ;)
<fullermd> Eventually.  It's been pretty dead since, like, before Christmas.
<fullermd> Quiet and restful, to be sure...
<CHYC> Hi bzr, I was wondering if anyone could shed light on this stack error I'm getting on commits and pushes/pulls relating to a particular branch I have
<CHYC> http://paste.ubuntu.com/805989/
<CHYC> I've tried commands with --no-plugins with the same effect
<CHYC> BRB
<jelmer_> 'morning
<jelmer_> wgz: hi
<ChrisCauser> Hi everyone
<ChrisCauser> CHYC was me earlier
<jelmer_> hi ChrisCauser
<ChrisCauser> Hi jelmer_
<jelmer_> ChrisCauser: that error is usually caused by disk corruption of some sort (sudden power loss, etc), which causes files to be truncated
<ChrisCauser> Ah
<jelmer_> ChrisCauser: newer versions of bzr should print a saner error I think (without a traceback)
<ChrisCauser> OK.
<ChrisCauser> This is bzr 2.4
<ChrisCauser> Is there a way of fixing it?
<ChrisCauser> The only thing unusual about this repo is it is hosted on Dropbox. I guess that could cause synchronization errors
<jelmer_> yeah, that might be related
<mgz> hey all.
<jelmer_> there is a way to regenerate that index file, I'm not entirely sure how though
<jelmer_> 'mÃ¸rning mgz
<fullermd> jam wrote a plugin, vague memory says.
 * ChrisCauser looks frantically for jam's plugin
<jelmer_> ChrisCauser: an alternative is to clone the branch from elsewhere and then pull in your local changes manually
<ChrisCauser> jelmer_ Alas, I get the same error whenever I push/pull/branch it
<jelmer_> ChrisCauser: I mean, cloning not this particular branch but a copy of it that exists elsewhere
<ChrisCauser> jelmer_ Hmm, OK. I'll see if I can dig a copy out from somewhere
<jelmer_> ChrisCauser: somebody else might also remember the plugin
<jelmer_> jam: hi?
<ChrisCauser> jelmer_ Thanks. I was able to reconstruct it using fast-import/export
<jelmer_> ChrisCauser: newer versions will fsync more often, preventing this issue in most cases
<ChrisCauser> jelmer_ Thanks a lot. It all seems to work well now that I've fast-exported and imported. If there is a plugin that could handle it I would love to know though
<jelmer_> ChrisCauser: note that fast-import/fast-export changes the identity of your revisions, so if you're pushing to/pulling from other people it will break
<jam> hi jelmer_
<ChrisCauser> jelmer_ Good to know, although in this instance this is a personal project so I'm fine
<jam> for a .six file, you can probably just copy over another one
<jam> because you probably aren't actually using signatures, so the file is just the header
<jam> however, if you get it for any other files (.rix, .tix, .iix) they probably cannot be regenerated.
<jam> And yes, bzr repositories are not dropbox safe
<jam> dropbox doesn't copy files in the order we need to preserve atomic safety
<ChrisCauser> jam Thanks for the update. I'll not be keeping my repos in Dropbox then. I guess I was lucky it was a six file.
<mgz> hm, no vila? log says he was around earlier
<jelmer_> I haven't seen him yet today.
<fullermd> He was around for a minute or three anyway.
<Dan-K2VOL> Hello
<Dan-K2VOL> so is there a way to download files using bazaar without creating a launchpad ID?
<LeoNerd> bazaar is a DVCS and in no way relies on some central authority, such as LP
<Dan-K2VOL> I was instructed that this command would download the libraries I need for an app: bzr branch lp:~kicad-lib-committers/kicad/library kicad
<Dan-K2VOL> and bzr responds with: You have not informed bzr of your Launchpad ID, and you must do this to
<Dan-K2VOL> write to Launchpad or access private data.  See "bzr help launchpad-login".
<LeoNerd> Oh, -that- might in particular yes, because that's branching off launchpad.
<LeoNerd> Perhaps the project in question has a public URL though you can use instead?
<Dan-K2VOL> that would be nice, but it seems the project isn't so organized on the OSX branch yet.  It seems to be downloading the files, but the warning message seems odd if it's not relevant
<LeoNerd> It may be the LP plugin in general is complaining of a lack of information, but this particular read-only operation is happy to proceed anyway
<Dan-K2VOL> LeoNerd thank you for your time and thoughts, I think you're right
<mgz> it's just telling you that if you want to push that branch later it'll fail
<Dan-K2VOL> ahh gotcha
<mgz> providing a login and ssh key can also mean faster access
<LeoNerd> ssh faster than http?
<Dan-K2VOL> thank you, I really only needed those files for installation, word on the street this is the simplest way for this platform to get the files, at this stage of development.
<mgz> then what you did is all you need.
<Dan-K2VOL> :-)
<mgz> LeoNerd: mostly just makes a difference with big branches, and operations that don't need the whole history
<LeoNerd> Ahyes... roundtrips for smartserver
<LeoNerd> I'm just used to thinking of the ssh setup cost as reeeeally expensive
<LeoNerd> Because, hey, it involves large prime numbers. :)
<vila> 2.5b5 has been frozen (including strings for translation)
<jelmer> vila: \o/
<vila> trunk is open again, check your news entries ;)
<vila> I still need to merge 2.5 into trunk
<mgz> I'm tempted to work out what calls I need to not have to deal with the amazon interface for starting up a windows builder
<vila> the new 2.5 branch has been setup in pqm and is functional
<mgz> probably DescribeImages, StartInstances, and TerminateInstances
<vila> pfew, this release was tricky...
<youlysses> I'm wanting to learn my first VCS, it's inbetween this are Git. Reccomendations?
<bob2> pick whichever the people around you use
<bob2> failing that, bzr
<mgedmin> (if you ask in #bzr, expect bzr to be the recommendation)
<youlysses> bob2, no body I know around me even code at all... And lol mgedmin, I expected. :P
<bob2> well, whatever the projects you use/care about use
<bob2> though in 2012 you'll probably want at least a 'clone/commit/push' familiarity with git, bzr and hg
<mgedmin> amen to that
<bob2> unless you're using ruby, then you just need to use the github OS X gui thing!
<youlysses> I'm on Parabola. Most of what I'm intrested in are offical Gnu packages, but they're all seemingly using git ...
<youlysses> :P
<mgedmin> git seems to be the most popular of the three
<mgedmin> although I'm somewhat surprised to hear this about GNU -- RMS prefers GNU/Bazaar, I heard ;)
<youlysses> Well it's based of Gnu Arch... :P
<bob2> hey hey hey, let's keep it civil
<bob2> (bzr despite the name is at most partly inspired by gnu arch/tla/bazaar-the-1st)
<cjalmeida> Hello everyone.
<cjalmeida> I'm having a strange issue with bzr included in ubuntu 11.10
<cjalmeida> it hangs while printing "Fetching revisions:Inserting stream:Done 65/65"
<poolie> hi all
<poolie> cjalmeida, hangs indefinitely, like for several minutes?
<poolie> if you interrupt it you should get a traceback in ~/.bzr.log
<poolie> please pastebin that
<poolie> jelmer, mgz, hi
<jelmer> 'evening poolie
<poolie> vila, http://www.kennethreitz.com/major-progress-for-requests.html looks good
<cjalmeida> poolie, sorry for the delay.
<cjalmeida> it hangs indefinitely
<cjalmeida> here's the paste:
<cjalmeida> http://pastie.org/3198189
<cjalmeida> the thing is that I can ssh normally into the box
<cjalmeida> poolie, i've changed BZR_SSH=paramiko and same error. hang's till interrupted
<bob2> isn't the error from you ctrl-c'ing it
<cjalmeida> bob2, nah, i do it after a pretty while
<cjalmeida> just did it again, 351 seconds...
<cjalmeida> for less then 200k transfered
<cjalmeida> bob2, poolie, it seems to be ssh related. I just copied the target repo locally, tried the push and everything worked fine
<poolie> cjalmeida, i wonder if it is some kind of mtu-type problem
<poolie> you could also try bzr 2.5b4
<poolie> *b5
#bzr 2012-01-17
<cjalmeida> poolie, I tried the 2.5b2 from ppa and same issue. I'll try to check mtu. BTW, nautilus ssh connection also stopped working. however, dolphin and large scp transfers are OK.
<cjalmeida> weird...
<poolie> uh
<poolie> maybe you turned on ssh connection auto-master?
<poolie> try turning that off
<cjalmeida> presto! it was mtu.
<cjalmeida> set it to 576 and everthing worked
<cjalmeida> I had a hunch about it when firefox started dropping conns, but set it to 1400, still too large
<cjalmeida> even nautilus is working fine now
<cjalmeida> poolie, I'll see if i can find a good mtu. Canonical should put a post connect test to determine best value.
<poolie> what, in network-manager or something?
<poolie> hm
<poolie> path mtu discovery does already exist
<poolie> i don't recall why it doesn't work in some cases
<cjalmeida> poolie, for some reason, my /proc/sys/net/ipv4/tcp_mtu_probing was set to 0.
<poolie> mine too
<poolie> perhaps there is some tradeoff about having it on
<fullermd> Path MTU discover _does_ require that you not have any networks in the path run by flaming idiots who think "Oh, hey, let's block all ICMP; that way we're more secure!"
<bob2> yes
<bob2> alack
<fullermd> (I dunno if that's less of a problem now than it was a decade ago.  My cynical side says 'no'...)
<bob2> there are still people who think icmp is how teh hackers get in, but they mostly seem to be sysadmins rather than netadmins
<fullermd> Luckily, I'm buoyed up by my native optimism and happy outlook.
<poolie> i wonder if it might not be possible to do some kind of heuristic detection
<lifeless> fullermd: PTMUd can handle blackholes... just faster without them
<lifeless> cjalmeida: poolie: that sysctl is for RFC 4821 checking, which is new (2007) vs RFC 1191 checking, which is what most folk expect/need
<lifeless> cjalmeida: poolie: http://kb.pert.geant.net/PERTKB/PathMTU covers both
<lifeless> I speculate it is disabled due to newness; pehraps we should default it on
<lifeless> fullermd: 4821 doesn't need ICMP according to that wiki page
<poolie> lifeless, yes i thought perhaps there was another one
<fullermd> Ah.
<cjalmeida> poolie, lifeless, fullermd the tcp_mtu_probing setting to 1 seems to have fixed mos issues.
<cjalmeida> #openerp
<lifeless> poolie: btw - http://www.erlang.org/doc/man/dialyzer.html
<poolie> thanks
<BlindWolf8> Hey all. I have a Bazaar server where clients use ssh_path_limiter to access a repo. Am I able to pass multiple paths in my authorized_keys file?
<BlindWolf8> I want to do this so a single person doesn't need to generate a key per project
<BlindWolf8> I am using Shared repos
<BlindWolf8> Anyone?
<lifeless> BlindWolf8: just put all the repos under a common root
<lifeless> /srv/repos/A /srv/repos/B and make /srv/repos the permitted path
<BlindWolf8> but then clients would need to change their paths, right?
<BlindWolf8> for bound branches?
<lifeless> uhm, yes
<BlindWolf8> i figured
<BlindWolf8> right now it's bzr+ssh://<user>@<ip>:<port>/.bzr/branches/trunk/
<vila> hi all
 * fullermd wavels.
<vila> poolie: 'Requests' looks very good indeed, dependencies may be an issue there though
<vila> poolie: in short, too late for 2.5, worth considering for 2.6
<poolie> hi
<poolie> yeah
<jelmer> 'morning
<mgz> morning all!
<jelmer> hey mgz
<jelmer> are we hanging out?
<mgz> I need to head downstairs if so
<jelmer> mgz: are you up for that journey?
<mgz> if that's where we'll all be :)
<jelmer> vila, poolie: ^
<vila> morning guys !
<vila> oh, right !
<poolie> hi jelmer, mgz,
<poolie> yes let's try it
<wgz> hm, where is the thingy?
<jelmer> wgz: it's on http://plus.google.com/
 * wgz reloads
<jelmer> wgz: the top item should be an invite from poolie for the hangout
<vila> can't see it
<jelmer> mgz: no can hear you
<jelmer> vila: hmm, that's odd.. should be the first item in the stream
<vila> poolie is the first in the stream but I can't see any ref to an ongoing hangout :-(
<jelmer> vila: there should be a join button
<vila> yeah, that's what I remember but there is none
<vila> ha !
<tvoss> Hi all
<tvoss> I'm trying to setup a packaging recipe and hitting a problem with bzr-builder
<tvoss> apparently missing a launchpad id
<tvoss> build log is here: https://launchpadlibrarian.net/90240218/buildlog.txt.gz
<jelmer> tvoss: for now, please use the 0.3 version of recipes
<tvoss> jelmer, thx, adjusted my recipe and requested a build
<mgz> okay. enough fun
<vila> mgz: regarding the seg fault, here is the only trace I found in kernel.log: http://paste.ubuntu.com/807177/
<mgz> not very informative indeed
<vila> yeah, if I wasn't searching for it I've probably missed it
<vila> I had probably ?
<tvoss> jelmer, 0.3 version of the recipes work fine
<vila> jelmer: colocated-names reviewed, mostly questions for now but the change looks ok, I need answers to understand the impact but it seems low risk  enough to be ok
<jelmer> vila: thanks
<jelmer> vila: replied
<vila> jelmer: already reading and replying ;)
<vila> one question
<jelmer> vila: thanks for the quick followups :)
<vila> self.name = name in __init__ makes it an instance variable right ?
<vila> BzrBranch.__init__ that is
<vila> and great answer by the way, I smelled a bug but couldn't put my finger on it
<jelmer> vila: ah, sorry
<jelmer> vila: I missed that that code was in Branch, I was only reading the diff
<jelmer> yeah, I can see why documenting it as an instance variable makes sense
<vila> unless the line should be deleted, I see no use of it from a quick grep...
<jelmer> vila: which line, assigning to self.name ?
<vila> yeah
<vila> well, annotations say you added it so you should know ;)
<vila> damn, there *is* doc for it
<vila> sry
<vila> why did I miss it in the first place....
<jelmer> vila: it is meant to be used by things that need to display colocated branch names
<vila> fine
<vila> jelmer: approved, but watch for lp:bzr/2.5 as a target
<jelmer> vila: thanks
<jelmer> vila: I guess I should probably resubmit against 2.5?
<vila> jelmer: depends on how you submit to pqm, don't wait for another review if you resubmit on lp though ;)
<jelmer> vila: resubmitting against 2.5, would you mind re-reviewing?
<jelmer> *resubmitted
<vila> I don't mind but I just said you didn't need it ;)
<jelmer> well, that way we have the review record right.. I don't like reviewing my own stuff :)
<vila> jelmer: done, one last time: check news entry ;)
<jelmer> vila: huh, wha ? :-P
 * jelmer RUNS
<vila> I knew, trap activated as planned
<vila> jelmer: jokes aside, if you still encounter news merge issues on pqm, let me know ;)
<jelmer> vila: will do
<zyga> hi
<zyga> is the author of lp:bzr-interactive around?
<mgz> oo larstiq magic
<LarstiQ> mgz: oh oh, I hoped it wasn't too magical :)
<mgz> approved, but you probably want to do some shuffling to get it on 2.5 which branched yesterday
<mgz> may just be able to branch lp:bzr/2.5, merge your change into that (and --fixes) then add news and repropose
 * LarstiQ looks for a corresponding bug
<mgz> bug 881142
<ubot5> Launchpad bug 881142 in Bazaar "AssertionError: unversioned parent while creating working tree using pypy" [Medium,In progress] https://launchpad.net/bugs/881142
<mgz> really good job tracking that down, gets us down to a sensible number of failures on pypy I take it?
<LarstiQ> mgz: not entirely sure
<mgz> I'll do a run later this evening and report back.
<LarstiQ> mgz: while running test_http.TestBadStatusServer.test_http_get bzr hangs for a long time and then: zsh: alarm      ../pypy-1.7/bin/pypy ./bzr selftest
<LarstiQ> reading around that can happen when a signal handler isn't properly set when the signal arrives
<LarstiQ> but looking at the code I couldn't figure it out
<jelmer> LarstiQ: we register an alarm handler to kill hanging tests
 * LarstiQ nods
<LarstiQ> jelmer: "something" goes wrong there :)
<jelmer> LarstiQ: so most likely this is a hanging test, rather than anything to do with the signal handler
<LarstiQ> jelmer: my understanding is that the signal handler doesn't run and it passes down to zsh
 * LarstiQ might be wrong
<jelmer> LarstiQ: I don't think we register a signal handler at all, (intentionally?)
<LarstiQ> jelmer: possibly, I didn't quite follow the code. One _exists_ at least.
<LarstiQ> vila might know more
<jelmer> LarstIQ: At least, if I have hanging tests on cpython it dies the same way
<LarstiQ> jelmer: ah ok
<jelmer> so it might be that the signal handler isn't being called, but at least it's consistent across the various python implementations :)
<vila> LarstiQ: hey !
<LarstiQ> vila: heya :)
<vila> AFAIK, we don't use signals in tests *expect* SIGALRM to kill hanging tests (based on selftests.timeout defaulting to... 60s I think)
<vila> except not expect
<LarstiQ> vila: who is supposed to handle that signal, bzr or the shell?
<vila> err... dunno :)
<mgz> see <https://code.launchpad.net/~mbp/bzr/test-timeout/+merge/83559>
<vila> I think we just arm a timer
<vila> so yeah, we never try to catch it
<LarstiQ> ok, so then the only question is why it times out
<vila> LarstiQ: you run with -v ?
<vila> LarstiQ: said otherwise: are you sure the hanging tests is TestBadStatusServer ?
<mgz> it tracking it down to one test that hangs (semi) reliably would be a good start
<LarstiQ> vila: good point
 * LarstiQ tries a run with just that test
<mgz> can set that conf value to less than 60 for less patient alarm timeout while trying test subsets
<vila> ... or to more than 60 if you need to debug ;)
<mgz> that's true, breaking in poking thread states can be useful
<mgz> +and
<LarstiQ> after which point would the alarm kick in? It's not giving any progress info (while with -v) for more than a minute already
<mgz> it should just be 60s after test start
<mgz> otherwise try ctrl+\ and see where you land
<LarstiQ> http://paste.debian.net/152579/
<mgz> TestBadStatusServer.test_http_has it is.
<LarstiQ> the following completes in 21 seconds: ../pypy-1.7/bin/pypy ./bzr selftest -v -s bt.test_http -x test_http.TestBadStatusServer.test_http_has -x test_http.TestBadStatusServer.test_http_get -x test_http.TestPost.test_post_body_is_received -x test_http.TestRecordingServer.test_send_receive_bytes
<vila> ./bzr selftest -s bt.test_http.TestBadStatus -v would be simpler to start with
 * LarstiQ has to run now
<LarstiQ> I'll be back tomorrow
<mgz> thanks LarstiQ!
<vila> k
<vila> thanks for digging  !
<LarstiQ> mgz: then I'll also have some questions about proper NEWS entry writing
 * LarstiQ off
<mgz> actually, could just merge to 2.5 and add news for LarstiQ, will do that later unless pp gets there first
<vila> LarstiQ: in case your read the log, I suspect you're re-trying a request that failed, we want the first failure as the server is not supposed to receive more than one request which is probably why it's hanging
<vila> mgz: I'll do
<vila> mgz: I did
<mgz> vila: ta!
<mgz> ha, okay, fixed eucatools proxying signature checking
<mgz> ...and that was the wrong channel this time.
<jelmer> mgz!
<BlindWolf8> Hello. Is bzr_path_limiter able to traverse soft links? I'm getting a "not a repo" error
<BlindWolf8> Actually, it's "No repository present"
<BlindWolf8> Is it because I'm pointing it towards a branch and not a repo?
<jelmer> BlindWolf8: yeah, it won't be able to browse down towards the repo in that case
<BlindWolf8> Is tehre a way to remove the ugly "/.bzr/branches/trunk/" from URLs without making symlinks or is that just the way it's going to be?
<jelmer> BlindWolf8: huh, why would you need symlinks to that?
<BlindWolf8> Just was trying to make my URLs for team members easier to pop in/look less ugly, but Iif they have to look like bzr+ssh://<user>@<ip>:<port>/<project_name>/.bzr/branches/trunk/ then that's the way it's going to be
<beuno> so, couldn't you register a shortcut like lp: has?
<BlindWolf8> the project isn't on lp
<beuno> no, I mean "lp:" is probably registered in the launchpad plugin
<beuno> maybe you could have a plugin to register "something:"
<jelmer> BlindWolf8: why not just bzr+ssh://<user>@<ip>:<port>/<project_name>/trunk ?
<mgedmin> there's a bookmarks plugin, iirc
<mgedmin> http://doc.bazaar.canonical.com/plugins/en/bookmarks-plugin.html
<BlindWolf8> I don't think bzr+ssh://<user>@<ip>:<port>/<project_name>/trunk works. That would be the ideal solution, I think
<BlindWolf8> I'm using colocated branches...the project only really needs a trunk
<jelmer> BlindWolf8: ah
<jelmer> BlindWolf8: so this is very specific to bzr-colo
<BlindWolf8> I'm not using that plugin
<BlindWolf8> at least on the server
<BlindWolf8> I think the Windows installer version of bzr comes with that though
<jelmer> BlindWolf8: you should be able to just push to your desired location of bzr+ssh://<user>@<ip>:<port>/<project_name>/trunk
<BlindWolf8> want me to try and report back?
<BlindWolf8> Fails with "not a branch" error
<glyph> I notice that there's no 'qmissing' in bzr
<glyph> erm qbzr
<glyph> is there a thing that's similar?
<jelmer> BlindWolf8: when you're pushing?
<BlindWolf8> when I'm pulling
<jelmer> BlindWolf8: you'd have to push to that location first (and ditch the .bzr/branches/ bit from bzr-colo)
<BlindWolf8> why? would that create it on the server?
<BlindWolf8> just an FYI: everyone's using colo'd bound branches...no checkouts or master branch
<jelmer> BlindWolf8: yes, that should create it on the server
<BlindWolf8> just a single branch, nothing fancy
<jelmer> BlindWolf8: you're complaining about colocated branches on the server
<BlindWolf8> server doesn't have any fiels on it...every else has those files though
<BlindWolf8> only dir on the server is the .bzr dir
<jelmer> BlindWolf8: right, that's fine - the server just has to have the branch, not the working tree
<BlindWolf8> but isn't the branch technically in the .bzr dir already...?
<jelmer> BlindWolf8: it is, but it lives in a special location which is a bit of a hack used by bzr-colo
<jelmer> BlindWolf8: that's why you have to specify /.bzr/branches/foo rather than just /foo
<BlindWolf8> I'm assuming it's going to be awhile until that's fixed :-)
<jelmer> BlindWolf8: bzr 2.5 will have proper colocated branch support, different from bzr-colo
<BlindWolf8> what's the ETA on that?
<jelmer> BlindWolf8: 2.5.0 is due out in a month I think
<BlindWolf8> what's the upgrade path for old repos with the old colo format?
<jelmer> BlindWolf8: no idea; I think Neil (the author of bzr-colo) had some ideas but I've only been involved with the colo support in the core
<BlindWolf8> gotcha...the new version sounds like it's even more friendly
<BlindWolf8> just thought about my folder layout and I think I'm goign to need to make symlinks on a per user basis for security reasosns
<BlindWolf8> so epeople can't get into other projects
<BlindWolf8> since I can only pass one directory with ssh_path_limiter
 * jelmer has to head out, sorry
<jelmer> back later tonight
<BlindWolf8> see ya! thanks!
<poolie> hi all
<GRiD> hi poolie, how's it going
<poolie> hi grid, pretty good, how are you?
#bzr 2012-01-18
<GRiD> good, thanks
<GRiD> question, how much processing does a "bzr branch" do, as opposed to essentially transporting files and unpacking?
<poolie> hm
<poolie> well, --lsprof-file will tell you quantitatively 'how much'
<poolie> it does, for instance, look at the revisions and trees you're pulling across to identify which file texts to send
<GRiD> ok thanks cool i'll check lsprof. i was also looking for a way to validate a repo, bzr check seems to do this...
<GRiD> poolie, lsprof is perfect, thanks
<BlindWolf8> Hello all. When I do "bzr new --colocated-branches --format 2a" from the Windows GUI client to initialize a new repo, it faisl, but it works via a command line on the server (Linux)
<AuroraBorealis> is the version bazaar explorer is using matches the one that the cli one is using?
<BlindWolf8> Bazaar Explorer is 1.2.1
<AuroraBorealis> check the about thingy
<AuroraBorealis> and see what version of bzr
<BlindWolf8> bzrlib 2.4.2
<BlindWolf8> this is all on the client
<AuroraBorealis> whats the other version
<AuroraBorealis> and i THINK that colocated branches
<AuroraBorealis> doesn't exist until bzr 2.5
<AuroraBorealis> and the one you are using is from the bzr-colo plugin
<BlindWolf8> the bzr about windows says...
<BlindWolf8> Bazaar Explorer 1.2.1...QBzr 0.21.1, bzrlib 2.4.2, PyQt 4.8.4, Qt 4.7.2, Python 2.6.6
<AuroraBorealis> so both are 2.4.2
<AuroraBorealis> im not sure why its not working, but i know i was messing with colocated stuff and its not 'offically' supported yet
<AuroraBorealis> bazaar explorer is just using the bzr colo plugin
<BlindWolf8> gotcha
<AuroraBorealis> basically what it is right now is just a lightweight checkout
<AuroraBorealis> that points to a branch/repo inside .bzr
<BlindWolf8> i am lookign in the logs and I think the first line is:
<BlindWolf8>   File "bzrlib\commands.pyo", line 946, in exception_to_return_code
<AuroraBorealis> last line is the most recent call
<AuroraBorealis> paste that
<BlindWolf8> last line before a generic syntax error is....
<BlindWolf8>   File "C:/Program Files (x86)/Bazaar/plugins\explorer\lib\workspace_models.py", line 287, in build
<BlindWolf8> helpful?
<AuroraBorealis> not really haha
<AuroraBorealis> that command works for me on windows
<BlindWolf8> just doing it througn bzr explorer?
<AuroraBorealis> command line
<BlindWolf8> I'm doing it through bzr explorer using bzr+ssh connecting to a remote server
<BlindWolf8> which is on my LAN
<AuroraBorealis> that works for me too on bzr explorer
<BlindWolf8> I'm doing it through bzr explorer using bzr+ssh connecting to a remote server
<BlindWolf8> using Pageant for authing to the server
<AuroraBorealis> i dont know why its not working, its working for me :<
<AuroraBorealis> and bzr+ssh shouldn't affect it. i do that all the time
<BlindWolf8> do you want me to pastebin some stuff?
<AuroraBorealis> sure
<BlindWolf8> Still here?
<BlindWolf8> I made a paste but I dunno if you can view it if I set it to private
<BlindWolf8> http://pastebin.com/bumhufUb
<AuroraBorealis> i can see it
<AuroraBorealis>   File "C:/Program Files (x86)/Bazaar/plugins\explorer\lib\workspace_models.py", line 287, in build
<AuroraBorealis> WindowsError: [Error 123] The filename, directory name, or volume label syntax is incorrect: u'bzr+ssh://wolf@10.8.31.188:8888/sopa/.bzr'
<AuroraBorealis> it seems to be working but it is failing on a directory
<AuroraBorealis> like it cant find the file or something
<BlindWolf8> it's really weird
<AuroraBorealis> might actually be a bug, i dunno if any of the developers are on atm
<BlindWolf8> by what it spits out, it's looking for the .bzr directory, but it has yet to create it as that's what that command does
<AuroraBorealis> or something, its trying to access the directory but it says the url is invalid
<BlindWolf8> if I run that command directly on the server it works though
<BlindWolf8> "cd sopa" then
<BlindWolf8> bzr new --colocated-branches --format 2a
<AuroraBorealis> yeah, it might be a bug then >.>
<BlindWolf8> thanks! see ya!
<AuroraBorealis> does nayone know how to make the list of locations in bazaar explorer more..useful? then just "trunk" 20 times
<thomi> Hi - I've just upgraded my second machine to precise, and bzr is completely broken for me - i.e.- I get ConnectionReset whenever I try and do anything that involves talking to launchpad.
<thomi> I'd submit a bug to LP, but it seems like I must have done something wrong, otherwise someone else would have found this already - any ideas?
<fullermd> Try ssh/sftp'ing manually and see what happens.
<thomi> for example: http://pastebin.com/X5y5AXPF
<thomi> fullermd: I'll try that....
<fullermd> Permission denied (publickey).  is the tipoff.
<fullermd> Means you don't have the ssh key LP is expecting.
<thomi> I thought Bazaar used theanonymous transport when that happened?
<thomi> as in: it would fall back to anonymous transport?'
<fullermd> No, at that point there's nothing to fall back on.
<fullermd> When you haven't lp-login'd, it uses http instead of bzr+ssh.  But once you have, it does.
<thomi> ahh, and there's no 'lp-logout'
<fullermd> Don't think so, no.
<thomi> cool - that works now, I had the wrong key in my LP account. Thanks for your help.
<vila> hi all !
<fullermd> Oh, figures.  I solve the problem, _then_ vila appears.  Typical.
<vila> hehe
<vila> lp-logout is spelled: 'bzr config --scope bazaar --remove launchpad_username'
<vila> for recent enough bzr versions
<vila> but yeah, the best way to debug this sort of issues is 'ssh -vv'
 * fullermd gets a little crosseyed.
<fullermd> Are you sure the first word of that command isn't "git"?
<vila> yup, what makes you think otherwise ?
<vila> too complex ?
<fullermd> Oh, no.  I'm sure it'll be perfectly clear after a weekend course and an hour or two of meditation.
<sbarcteam> hi guys.
<AuroraBorealis> haha.
<sbarcteam> I have a checkout of a repository from box A  at box B
<sbarcteam> I want to run uncommit on box A.
<sbarcteam> what do I need to do on box B so they are in sync ?
<sbarcteam> a pull or an update ?
<vila> fullermd: one hour in the morning and one hour in the evening, best results guaranteed !
<vila> sbarcteam: it's hard to talk about 'sync' when one side has uncommitted changes in the tree
<vila> sbarcteam: it's easier to commit on one side and then pull from the other side with --overwrite if needed
<sbarcteam> vila, since uncommitted changes are local, and by "sync" I mean update/pull I think the question is well defined.
<sbarcteam> if the answer is not well defined, this means: either there is a bug in bzr behaviour, or the answer is wrong :)
<sbarcteam> since if I am doing an uncommit, bzr branch knows it is bound.
<sbarcteam> and if I am doing update from a bound location, it should be in sync to the latest (or what I specified)
<sbarcteam> I experienced another behaviour.
<sbarcteam> that the checked out repo had remainders of the uncommitted revisions.
<vila> wow, no offense intended, but thanks for mentioning you're using a bound branch
<sbarcteam> yep.
<sbarcteam> sorry.
<fullermd> Oh look, another round of bound checkouts screwing things up.
<fullermd> He said 'checkout' right at the start...
<sbarcteam> So, what I am saying here:
<vila> fullermd: I know and couldn't resolve the inherent ambiguity :-/
<sbarcteam> IS the branch that has been checked out NOT supposed to be doing "uncommit" ?
<vila> sbarcteam: so, you have a working tree on both sides ?
<sbarcteam> if by working tree you mean files except .bzr, then yes.
<vila> and the working tree on the other side not being updated is what you're not expecting ?
<fullermd> sbarcteam: The issue is that after the uncommit, your local branch is 'ahead' of the remote.  And bzr has no way of knowing whether that's because something is supposed to be backed out, or you did something locally that hasn't made it to the remote yet.
<fullermd> (the latter is assumed)
<sbarcteam> fullermd, you mean: when I am running update against the branch I checked out, and I'm ahead of it ?
<fullermd> Right.
<sbarcteam> and that my bzr doesn't know if this has been committed with --local.
<fullermd> (technically, "I have something the remote doesn't"; 'ahead' is technically imprecise, but colloquially useful)
<sbarcteam> yes, but in that case I'd expect MERGE behaviour to reproduce, or a statement "man, you've got some stuff we don't... beware the jabberwack!"
<fullermd> You presumably got the "standard" behavior, of the commit you have locally turning into a pending merge.
<sbarcteam> fullermd, I had the pending merge. I then ran merge, but was missing files.
<sbarcteam> as a result, I got panicked, got back to the checkout branch, ran uncommit there, then re-did the merge again, and then committed. the missing files appeared.
<vila> ouch
<sbarcteam> As you can imagine, finding out the files were missing was not much fun.
<sbarcteam> Up to now our uncommit attempts did not render such a heart attack.
<vila> sry for that, but when you have pending merges, you should either commit or revert, doing a merge there is... asking for trouble unless you really know what you're doing (bzr should tell you to use merge --force in this case, didn't it ?)
<sbarcteam> fullermd, is there a way to know the changelist is coming from a remote checkout branch ?
<sbarcteam> (I mean within python code of bzrlib)
<vila> yes, a 'master branch' is involved in this case (from the bound branch side of course)
<vila> from the remote side, no
<sbarcteam> so it would be "nice to have" a message BEFORE doing the change stating: this uncommit has changes from non-master branches. you better run uncommit on the specific branch it was added at
<sbarcteam> does this make any sense ?
<vila> not sure. Can you elaborate on 'change' and 'specific branch' ? (remote/local ?)
<sbarcteam> (maybe the message should be phrased otherwise, but suggesting to run uncommit on the committing branch seems to me a good idea of having less gray hair)
<sbarcteam> ok, in terms of A and B.
<sbarcteam> A has a master branch.
<sbarcteam> B is a checkout branch
<sbarcteam> I want to uncommit something.
<vila> :-/ uncommitting a shared branch is always tricky if you don't control who has already copied the revision you're about to remove from a branch history
<sbarcteam> vila, uncommit command doesn'
<vila> all users will need to 'pull --overwrite' at some point
<sbarcteam> t say it is tricky.
<vila> true
<sbarcteam> and pull --overwrite can do even more damage. but that's another story.
<sbarcteam> I say it is easier to have a simple paragraph in uncommit help, than to add code to change the behaviour.
<sbarcteam> Also, take into the account, the person doing the uncommit, is not always aware of everything in question.
<sbarcteam> and ALL the aspects.
<sbarcteam> A tool would be a more robust tool if it prevented the user from wrongdoing by instruction....
<sbarcteam> anyway, I had to rant a bit.
<vila> right, so you want a big flashing warning when uncommit is ran right ?
<vila> sbarcteam: care to file a bug about it ?
<sbarcteam> where to ?
<vila> https://bugs.launchpad.net/bzr/+filebug
<mgz> morning
<vila> mgz: morning !
<mgz> hey vila
<mgz> lp fdt alwasy comes just when I need something
<mgz> done, let's try again
<Merwin> Hi! I'm blocking on : bzr: ERROR: Connection closed: Connection lost while sending request. 5/36719
<Merwin> Whil doing a pull, always at 5/, that's strange
<mgz> against what sever?
<mgz> *server
<mgz> running with the debug flags for the protocol used set then looking at .bzr.log may help
<Merwin> On launchpad
<Merwin> response = self.retry_or_raise(http_class, request, first_try)
<Merwin> ConnectionReset: Connection closed: Connection lost while sending request.
<Merwin> Hum, seems to be launchpad which have problems ?
<mgz> they had fdt and were back up at 10:04
<mgz> and also a few issues before then
<mgz> if the timestamp on your disconnect is after that, they'll probably be interested
<wgz> couple of pypy windows specific issues cause a lot of failures <http://float.endofinternet.org/xmlbin/pypy_non_per_FAIL>
<vila> "An operation was attempted on something that is not a socket" ... EBADF ftw
<mgz> any ideas on that one? the listdir+unicode one is just the pypy _os module isn't very good
<vila> which one ?
<vila> EBADF not being raised ?
<vila> most probably pypy should be fixed to raise it instead of the windows immoral equivalent
<mgz> ah, er... so all those large number of failing tests expect EBADF and the error is just escaping?
<vila> alternatively we may recognize 10038 as meaning EBADF everywhere we catch EBADF but.... will be invasive and risky
<vila> yup
<vila> well, I'm 99% sure
<vila> but the message itself pretty much describes what EBADF is about: the object has been a socket, it's not anymore
<vila> well, not a 100% accurate description but in all cases I've encounter EBADF the object was a socket and the socket has been closed (which in Cpython implementation means the methods are re-bound and raise this exception)
<LeoNerd> EBADF means the kernel doesn't think what you have is a file descriptor at all
 * vila nods
<wgz> yup, looks possible
<vila> the Cpython implementation uses this for _closedsocket() objects
<wgz> sock.fileno() here is -1
<vila> see socket.py line ~170
<wgz> and it got past self.ignored_exceptions
<vila> right, you can add it there but that won't cover the client side
<vila> EBADF is part of ignored_exceptions right ?
<wgz> errno.WSAEBADF is 10009
<wgz> we have errno.WSAENOTSOCK
<vila> O_o and what is 10038 then ?
<wgz> adding that gets the test through to a ValueError on select because -1 is invalid
<vila> remove the select
<vila> :)
<wgz> seems like something fundamental has gone wrong earlier though
<vila> I was half joking though, mixing explicit blocking ops and select....
<wgz> we shouldn't be trying things on invalid sockets
<vila> we can't know if the socket is valid until we try
<vila> there will always be a race
<wgz> -1 is always invalid
<vila> getting EBADF is expected though
<vila> IIRC when you call shutdown() one side is already blocked and will receive EBADF
<vila> wgz: what is 10038 ?
<wgz> WSAENOTSOCK, it's what gets raised if the fileno is -1
<wgz> it's possible this is basically a refcount bug
<wgz> adding it to the ignored list at least gets some tests further through or with different errors
<vila> wow, ENOTSOCK exists... never seen it before
<LeoNerd> It's what you get for socket-only calls like send/recv/setsockopt/... on valid file descriptors that aren't sockets.
<LeoNerd> Because they're still valid FDs, EBADF isn't appropriate
<vila> hmm, thanks LeoNerd
<vila> wgz: we should not encounter this at all, may be something bad happened earlier
 * vila suggests comparing socket implementations or failing tests between python and pypy
<vila> python tests that is, not bzr tests
<wgz> with the code added to ignored ones: <http://float.endofinternet.org/xmlbin/pypy_ignore_notsock_test.http_FAIL>
<vila> modified-2.7 ?
<wgz> note, still hangs, and still has some failures
<wgz> ^pypy change the stdlib a bit
<vila> ...
<wgz> but I don't see why their socket module gets a _sock object that contains a bzrlib.transport.http._urllib2_wrappers.Response instance
<wgz> which is what's blowing up there
<vila> other way around
<vila> the response reads the body from a socket
<vila> through a makefile() object for that matter
<vila> the AttributeError message has it all wrong it appears
<wgz> pdb agrees with the diagnosis
<wgz> but that doesn't really help with the cause
<vila> pdb says what ?
<wgz> -> self._sock._decref_socketios()
<wgz> (Pdb) self
<wgz> <socket._fileobject object at 0x03221220>
<wgz> (Pdb) self._sock
<wgz> <bzrlib.transport.http._urllib2_wrappers.Response instance at 0x033e89d0>
<vila> (diagnosis is ? self._sock is a Response or AttributeError message is borked ?)
<vila> O_O
<vila> ._.
<vila> serious breakage
<wgz> I suspect their changes to urllib2 and the _urllib2_wrappers need serious looking at
<wgz> will probably resolve the http hangs though
<vila> they changed that too ???
<vila> and httplib also ?
<wgz> yup, though we're not really ones to complain
<vila> I don't follow
<vila> understand
<wgz> we also modified the stdlib in pretty invasive ways
<vila> naaah
<vila> :)
<vila> I don't think we monkey patch anything in socket or urllib2, we use them and derive a lot though :)
<wgz> WSAECONNABORTED also gets propogated by a few tests.
<vila> hmm
<wgz> anyway, enough fun, I'll do another reduced run and see how far it gets before hanging, and get back to other things
<wgz> the memory usage is pretty appalling
<vila> wgz: don't you think you should separate windows specific issues from the rest ? Or are all the tests already passing on ubuntu with pypy ?
<wgz> http was hanging, but there's no way I can run the suite under pypy on my nix boxes
<vila> :-/
<wgz> certainly there are fewer issues on nix, but the hang looks cross-platform :)
<jelmer> . o O (perhaps related to the hang we were seeing with https?)
<vila> the one LarstiQ mentioned yesterday wasn't diagnosed properly, the traceback he pasted hinted that the first request failed for a reason I'd like to know
<vila> jelmer: nah, that one is yet another cause (but also involves retry_or_raised though)
<vila> i.e. first request failed, second request (same) retried by retry_or_raised hangs because the server doesn't expect another request
<vila> that's crystal clear for LarstiQ case, less clear for the https case, but we already know that in the https case the first request failed because the cert couldn't be verified (which is certainly not the case for LarstiQ )
 * vila should get rid of all the self._debug stuff and use the debug http flag instead for retry_and_raise, seriously
<vila> wgz: in the mean time, you could set DEBUG to >= 2 in _urllib2_wrappers and get more details
<wgz> issue is we don't get the log from hung tests
<wgz> any more.
<wgz> because it just goes to a StringIO on the case, not to disk
<wgz> it's probably possible to break in and poke it, on nix at least
<vila> DEBUG relies on 'print'
<vila> which is why I wanted to use debug.flags instead, but it would harm you there ;)
<wgz> to stdout?
<vila> bare print, so yes
<wgz> hm, may be helpful then.
<vila> no flush() though
<wgz> okay, that bigger run completed, and is greener <http://float.endofinternet.org/xmlbin/pypy_ignore_notsock_non_per_FAIL>
<vila> looks a lot like random failures no ?
<vila> (I looked at the test_http ones and there is no clear pattern)
<vila> 'Terminated due to possible deadlock' sounds... weird, what do you mean by 'possible' ? Either you see a deadlock or you don't, if you're not sure, let it go ;)
<wgz> it's a timeout.
<vila> pypy adds a watchdog thread ?
<wgz> the parent process gives the child a limited amount of time before killing it off
<wgz> it's in my test runner.
<vila> ha
<vila> for each test ?
<wgz> with DEBUG=2, hang looks like <http://paste.ubuntu.com/808712/>
<wgz> ^yup
<wgz> seems odd that the problem test gets the status line but then no headers
<wgz> could be a flush issue I guess, but stdout should be, and looks, line buffered
<wgz> yup, same thing again
<vila> hmm
<vila> so, debug output is splitted between self._debuglevel (from DEBUG) and http in debug.flags
<vila> if you want the full monty you need to set both, I mentioned DEBUG for the retry_or_raise specific output, sry I was unclear
<vila> but retry_or_raise doesn't seem to be involved in your case
<vila> which means you're not on the same track than LarstiQ yesterday ?
<wgz> possibly not, the cases are different at least
<wgz> may still have an underlying cause alike
<vila> yeah, having makefile() suddenly get a Response instead of socket strongly suggest that sockets can get out of sync between server and client, from there hangs are bound to happen
<jelmer> vila: still there?
<vila> enough but by much ;)
<vila> meh, s//not/ :)
<jelmer> vila: we seem to be relying on bzrlib.initialize being called again
<vila> really ?
<vila> where ??
<jelmer> vila: e.g. clouddeck fails to start here, because:
<jelmer> exceptions.AttributeError: 'NoneType' object has no attribute 'cmdline_overrides'
<vila> meh
<jelmer> tarmac seems to be hitting the same
<vila> complete traceback ?
<vila> bzr version ?
<jelmer> the only relevant bit from bzr is:
<jelmer>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 1074, in run_bzr
<jelmer>     bzrlib.global_state.cmdline_overrides._from_cmdline(override_config)
<jelmer> vila: bzr.dev, 6440
<vila> same in lp:bzr/2.5 :-/
<vila> most probably a code path we haven't encountered yet
<niemeyer> Yo
<jelmer> Hey Gustavo
<niemeyer> Quickie: is there an easy way to tell the revision of a tree, without bzr | grep | sed?
<jelmer> niemeyer: of a tree specifically, or of a branch?
<niemeyer> jelmer: A branch should work too
<niemeyer> jelmer: It's for juju's charm store
<niemeyer> jelmer: I have to import a bunch of branches from lp onto a db
<niemeyer> jelmer: and tag them with their respective revids
<jelmer> niemeyer: that should be really easy with bzrlib - are you doing this from Python?
<niemeyer> jelmer: No, from Go/cmdline
<jelmer> niemeyer: ah
<niemeyer> jelmer: But.. python -c is not too hard either :)
<niemeyer> jelmer: I'd prefer a command line, but happy with python -c too if there's no easier way
<jelmer> niemeyer: 'from bzrlib.branch import Branch; Branch.open(url).last_revision()' is the python way
<niemeyer> jelmer: Hah, brilliant, thanks!
<jelmer> niemeyer: otherwise, cut -d " " -f 2 .bzr/branch/last-revision
<niemeyer> jelmer: Ohhh.. that sounds nice too
<niemeyer> jelmer: Since I can bring the logic into the code itself
<jelmer> niemeyer: (-f 1 for the revno)
<jelmer> niemeyer: the only issue with that is that it's less robust against format changes
<niemeyer> jelmer: I'll follow up with the python -c trick since I'm doing a spike/experiment at the moment, but probably introspect the rev file down the road
<jelmer> niemeyer: not that changes in this particular bit of the format are likely
<niemeyer> jelmer: Yeah, understood
<niemeyer> jelmer: Hmm.. breaks with lightweight checkouts too, of course..
<jelmer> niemeyer: yeah, though you could look at the tree revision instead. That's in .bzr/checkout/dirstate and a bit harder to extract
<vila> jelmer: the fix for bug #863401 missed this case, if you can file a bug with the failing script (probably import bzrlib; run_bzr(...))that would be nice
<ubot5> Launchpad bug 863401 in Bazaar "library state will require explicit initialisation (but not yet)" [Critical,Fix released] https://launchpad.net/bugs/863401
<jelmer> vila: ok
<niemeyer> jelmer: Cool, I'll probably stick to the Python stuff for now
<niemeyer> jelmer: Future generations will likely thank me for that ;)
<mgz> why is `bzr revno --tree` not the right thing?
<jelmer> niemeyer: :)
<niemeyer> mgz: That's a revno, not a revid
<niemeyer> mgz: That said, you have a point there.. this is a pretty fundamental piece of information. Having "bzr revid" would be nice
<vila> worth adding a --show-ids param there (I'm gone for good now ;)
<jelmer> niemeyer: there is 'bzr revision-info', but that shows the revno too
<niemeyer> vila: +1
<jelmer> niemeyer: so 'bzr revision-info | cut -d ' ' -f 2' will work
<niemeyer> jelmer: Oh, that sounds good
<niemeyer> jelmer: I'll go with that.. I can easily do the cut part with code
<niemeyer> jelmer: Thanks!
<jelmer> vila: hmm, it seems pretty hard to fix this properly
<jelmer> vila: I think we'll have to require library state in order to run run_bzr
<vila> jelmer: the best way to cover all cases may be to call bzrlib.initialize(setup_ui=False) unconditionally ? Not sure about the fallouts but I'd rather fix them once and for all, document it and see if the import load is tolerable
<vila> jelmer: (but I should really go now ;)
<mgz> manual rebasing time..
<Noldorin_> hi jelmer, poolie
<jelmer> hi Noldorin_
<Noldorin_> how's it going? :-)
<Noldorin_> jelmer, ^
<jelmer> Noldorin_: alright, how are you?
<Noldorin_> good thanks
<Noldorin_> jelmer, been doing much bzr work lately?
<cody-somerville> So if bzr blame says a change occurred in rev 96.4.29... how do I see what revision the change *actually* occurred in?
<jelmer> Noldorin_: some - mostly related to colocated branches and HPSS
<jelmer> cody-somerville: you mean, what mainline revision?
<cody-somerville> jelmer, aye
<Noldorin_> jelmer, ah ok cool
<Noldorin_> jelmer, so when can i next pester you to fix the bzr-git bug? ;-)
<jelmer> cody-somerville: use -rmainline:96.4.29
<jelmer> cody-somerville: e.g. "bzr revno -rmainline:6037.1.4"
<jelmer> cody-somerville: or if you care about the commit message, "bzr log -rmainline:6037.1.4"
<jelmer> Noldorin_: heh
<jelmer> Noldorin_: same as always, it's on my todo list but I haven't gotten to it yet
<Noldorin_> heh okay
<Noldorin_> yeah, it's a blocking issue for me but otherwise low priority :-(
<Noldorin_> jelmer, do i have to create loads of fake user accounts and report as blocking issue? ;-)
<BlindWolf8> Hello all. Found a bug in Bazaar I think. Thorws the wrong kind of error: http://pastebin.com/feLzywii
<BlindWolf8> The issue was that I forgot to load my private key so it couldn't connect, but it threw something else
<BlindWolf8>   File "bzrlib\smart\medium.pyo", line 968, in __init__ TooManyConcurrentRequests: The medium 'SmartSSHClientMedium(bzr+ssh://wolf@10.8.31.188:8888/)' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.
<BlindWolf8> that happened when trying to commit
<jelmer> BlindWolf8: hi
<BlindWolf8> hey again!
<jelmer> BlindWolf8: that does indeed look odd - can you file a bug?
<BlindWolf8> I'll have to file one later as I'm in the middle of some things...doing a SOPA Game Jam :-)
<jelmer> heh, ok
<cody-somerville> jelmer, cool, thanks.
<SpamapS> This might be more a launchpad problem, but I want to delete this branch: https://code.launchpad.net/~clint-fewbar/charm/oneiric/nova-cloud-controller/trunk .. but it says there are 3 branches using its revisions. Is there a way I can redirect their stacking elsewhere?
<lifeless> delete them
<lifeless> or use bzr reconfigure
<lifeless> why do you want to delete the branch ?
<SpamapS> lifeless: the charm store wants to take any branch named 'trunk' and expose it.. perhaps we should use the Abandoned state as a clue not to expose it though
<lifeless> yes
<lifeless> honouring branch metadata is a good idea
<lifeless> 'development' and 'mature' are probably the only states you want
<nickoe> Hey people. How can I see which revision I am working on, like I can with 'svn info'?
<mgedmin> well, there's bzr revno
<nickoe> mgedmin, does that shou the head revision, or the one chekec out?
<nickoe> *show
<mgedmin> uhh suddenly I'm not sure
 * mgedmin did a 'bzr help revno' and saw the "--tree      Show revno of working tree" option
<fullermd> Hm.  The list archives cut off long messages?
#bzr 2012-01-19
<poolie> hi all
 * fullermd waves.
<wallyworld_> poolie: why isn't --forward the default for bzr log? normally one wants to see the last revisions and it's easier if the earlier ones scroll off the top of one's terminal and the latest ones are what's seen
<poolie> i guess normally people run it with |less
<poolie> or --limit
<poolie> it would be a waste to print the whole history just so you see the last few bits, i suppose
<wallyworld_> sure, valid points. but log is fast and for files with shortish histories, it's easier OOTB to just 'bzr log' rather than bzr log|less or bzr log --limit xx and the like
<fullermd> Backward through less makes it easy to go as far as you need back without knowing in advance how far that is.
<fullermd> 's also why every other VCS back to RCS and probably beyond runs that way.
<wallyworld_> fullermd: using less i can see how it is better. running without less in a terminal it is easier by far to use forward. so i just use an alias :-)
<wallyworld_> trouble with using less through is that when you quit out, all the logs also disappear
<wallyworld_> so you are forced to run log again to look at something else if you need to
<wallyworld_> eg i often want to log at the log and use info from there to run another bzr command. but it's harder to do if i am forced to use less since i can't start typing the command and then look back at the log
<fullermd> Only if you're on Linux, or some other system with broken termcap   ;p
<wallyworld_> them there are fighting words :-)
<wallyworld_> i would have thought the vast majority of bzr users are on linux anyway :-)
<fullermd> Yeah, that's kinda what I do   8-}
<wallyworld_> i am surprised that more folks on linux don't have the same issues as me with using less and bzr log
<fullermd> In fairness, I should note that I often use my 'flog' alias.
<wallyworld_> yeah, it's easy to set up an alias; i just would have thought that the OOTB defaults would make the majority use case, and given the issues with less, i would have thought --forward would be the most desirable
<fullermd> Generally, it's only useful when you're specifying a -r anyway.  Otherwise you sit a long time watching 5 year old revs fly by.
<fullermd> (or 20 year old revs, depending on the project...)
<wallyworld_> true. i normally want to use it with -r
<wallyworld_> but that's what --limit is for
<wallyworld_> and my brain prefers to look upwards to see earlier revs
<fullermd> You could setup an alias to make log use --forward, and then have a blog alias or something to switch to backward.
<fullermd> (my flog actually has --forward and --short)
<wallyworld_> yeah, i've got all the aliases set up for me. i was just musing as to why the defaults are the way they are
<wallyworld_> after all, anyone who doesn't work like me is clearly wrong :-P
<fullermd> Oh, so YOU'RE the one who stole my line.
<wallyworld_> yep :-)
<fullermd> Right.  That does it.  You're on my list.
<fullermd> Not the top, sadly.  But I can slot you in right behind "the entire western hermisphere".
<wallyworld_> where you from?
<fullermd> Well.  The western hemisphere.
<wallyworld_> hah
<fullermd> That just makes it convenient, see.  No long travelling   :)
<wallyworld_> i like travel
<wallyworld_> although it took 50 hours door-door to get home from budapest this week
<fullermd> Anyway.  I don't think there was every any long public discussion about default direction.  But the (AFAIK, exceptionless) universality of future->past in every VCS suggests it's largely approved of.
<wallyworld_> well they are all clearly doing it wrongly :-)
<fullermd> In general, of course.  But not in this case, 'cuz I'm happy with it   ;p
<wallyworld_> well at least it can be easily configured to suit one's tastes, unlike certain other products that shall remain nameless
<fullermd> Pfui.  Other products are easier to configure.  You don't need to mess with aliases, you just write a simple little kernel module, and...
<ISK> Hey
<ISK> I want translate the doc "Bazaar in five minutes". Who should I contact?
<wallyworld_> poolie:  can you help? ^^^^^^^
<astraljava> Hi guys. I've got a problem with a src tree I copied over from another machine. It's stuck on an older revision, when I do `bzr up`, it says it's up-to-date with rev. 1280, but on LP, I see that the repo is already up to rev. 1300. What do I need to change so that it sees the correct location?
<fullermd> If it's an independent branch, wouldn't you want to use 'pull' to update it relative to the branch on LP?
<astraljava> fullermd: Yes, you are correct. That did the job. Thanks a lot!
<wgz> pre-morning all
<vila> hola people
<mgz> morning all!
<LarstiQ> mgz: morning
<LarstiQ> vila: thanks for merging!
<vila> LarstiQ: my pleasure !
<LarstiQ> vila: do you have any hints on how to dig deeper into the hanging http requests?
<vila> yup, let me scollback
<fullermd> No, he only handles the htpp requests...
<vila> tsk tsk hhtp
<vila> LarstiQ: in case your read the log, I suspect you're re-trying a request that failed, we want the first failure as the server is not supposed to receive more than one request which is probably why it's hanging
<vila> LarstiQ: but talk to wgz/mgz too who did some experiments yesterday
<mgz> I could suggest a few things, if you start by getting a minimal set of tests you can get the hang with,
<mgz> then we can do some of the debugging things vila tried with me yesterday
<vila> mgz: any issues with the windows installer for 2,5b5 ?
<vila> s/,/./
<mgz> not tried it yet
<mgz> need to find out how/if bzr-svn is borked
<LarstiQ> mgz: -Dhttp / setting DEBUG in _urllib2_wrappers?
<LarstiQ> mgz, vila: I did a full run excluding a couple of tests, and that completed (failures=54, errors=8476, known_failure_count=28)
<LarstiQ> next thing is to see if running those excluded tests by themselves hang all the time
<vila> IIRC, you identified a single tests that was hanging when retrying a request. The BadStatus server expects a single request so we know why it hangs. Why the first request failed is the interesting bit
<LarstiQ> right
<mgz> LarstiQ: so, something like `./bzr -Oselftest.timeout=0 selftest -s bt.test_http` with the debug stuff set, then breaking in and getting the test log may be useful
<mgz> also, if you kept the log of that full run and have a few classes of failure/error from it, file bugs tagged pypy
<mgz> I had a couple of commonly occuring ones yesterday
 * LarstiQ nods
<LarstiQ> mgz: I have some select(-1) too
<LarstiQ> mgz: but the vast majority seem to hit the limit for amount of open files
<mgz> right, I get that too, so it's worth a bug
<vila> jelmer: Are you working on #917733 or can I steal it ? I think I have a low-risk simple fix for 2.5 and I'm working in this area for trunk anyway ?
<vila> s/?$//
<mgz> hm... fd limits... I got massive mem usage, so we may need to check trunk to see if test cleanup is still working
<LarstiQ> hrmf
<mgz> another option is to hack in a gc.collect() after each test and see if that helps
<mgz> bzr has too many cyclic objects
<LarstiQ> switching DEBUG from 0 to 2 lets it complete
<LarstiQ> at least, when I run only TestBadStatusServer.test_http_has
<mgz> probably just slows it down enough to avoid a race
<mgz> try with -s bt.test_http.
<vila> which would imply that pypy introduced a new one :-(
<mgz> or that refcounting saves us from other issues
<LarstiQ> mgz: now it hangs indeed
<vila> ok, I bite, why are you talking about ref counting here, pypy changed something in this area ?
<mgz> it doesn't refcount vila.
<vila> different gc algorithm ?
<LarstiQ> vila: yeah
<mgz> it has several different pluggable gcs, the main one is...
<mgz> whatever the name is for a gc that relocates objects
<LarstiQ> vila: http://doc.pypy.org/en/latest/garbage_collection.html fwiw
<vila> and you're suspecting that we run into a case where our tests succeed because an object is *not* gc'ed ???
<vila> (our: cpython)
<mgz> we have a bunch of subtle assumptions about object lifetimes still, one of these may cause this issue, or it might be something else entirely
<LarstiQ> running _just_ `../pypy-1.7/bin/pypy ./bzr -Oselftest.timeout=0 selftest -s bt.test_http bzrlib.tests.test_http.TestPost.test_post_body_is_received` hangs too
<vila> LarstiQ: set a breakpoint in retry_or_raise and check the first failure
<vila> mgz: The only part of the code matching this pattern I can think of is the smart server and its daemon threads... (Not involved here)
<LarstiQ> vila: hmm
<LarstiQ> vila: afaics it doesn't get to that point
<vila> can you get back to the BadStatus test hanging ?
<LarstiQ> vila: http://paste.debian.net/152791/ is all the output
<LarstiQ> vila: sure
<vila> DEBUG alone gives incomplete and possibly confusing output, you probably want -Dhttp and the magical thingy that allows such flags to get passed for selftest
<mgz> hm, thinking about the fd limit again, if enough tests fail, that have self.branch or similar, they all end up in a list and will be kept for the whole run, so without refcount to close fds that could run us out.
<mgz> the general testcase cleanup seems to be working, but I could fix a few more cases
<LarstiQ> mgz: iirc the last time I only looked at blackbox tests because my hardware couldn't run more than that
<LarstiQ> mgz: it looks like at least some non-blackbox tests do things like file(foo).read()
<mgz> LarstiQ: vila means `bzr -Oselftest.timeout=0 -Dhttp -Eallow_debug selftest ...`
<vila> yeah, that ! :)
<mgz> LarstiQ: right, and my change since then should have improved things somewhat
 * vila rings jelmer's alarm clock
<mgz> vila: but that only adds stuff to the testcase log, so LarstiQ would also need to break into a hung test, go up till he gets back to the test case, then print self.get_log() to some file
 * LarstiQ gives -Eallow_debug to selftest instead of bzr :)
<mgz> right, that :)
<vila> hehe, one more hint that this worked at some point in the past...
<LarstiQ> vila: it doesn't hang with DEBUG higher than 0 by itself.  Not sure having pdb break in retry_or_raise will hide the race or not
<vila> mgz: ha crap, yeah
<mgz> LarstiQ: waiting for the hang, then doing ctrl+\ and using pdb should work
<mgz> to see the log/symptoms at least, if not to observe the actual problem
<vila> LarstiQ: get rid of DEBUG then, I'm not chasing the race by itself but I'd like to know why it fails for the first request
<vila> mgz: I'm not sure you can still get enough details about the first failure by waiting for the hang
<mgz> by first failure, do you mean in a seperate test?
<mgz> the preceeding test was passing for me
<vila> no
<LarstiQ> first http request failure?
<mgz> then the request will be in the log at least, if not in enough detail
<vila> the BadStatus hang occurred when re-trying a request (when LarstiQ first talked about it), I'm talking of the first http request against the server
<vila> LarstiQ: yup
<LarstiQ> vila: breaking in on the hang, going up the stack, retry_or_raise is called with first_try=True
<vila> so, what is exc_type, exc_val, exc_tb
<fullermd> Excitement by type, excitement by value, and excitement by tuberculosis?
<LarstiQ> vila: <class 'httplib.BadStatusLine'>, 'HTTP/1.0 0 Bad status\n\r' (guessing at the whitespace), <traceback object at 0x0b8fad58>
<vila> hehe
 * vila blinks
<LarstiQ> \r\n according to the repr
<vila> ...
<mgz> yup.
<vila> httplib.BadStatusLine is caught and... calls retry_or_raise without changing first_try ? O_o
<vila> meh, scratch that
<LarstiQ> vila: well then it gets into  reuqest.connection.close(); response = self.do_open(http_class, request, False) on line 575
<vila> yeah, misread
<LarstiQ> (with a commented out pdb, so probably line 574)
<vila> right, so, my first intuition was wrong
<vila> the test *relies* on the fact that the request *is* retried
<vila> but the server asks for the connection to be closed so the second request should open a new connection ?
 * LarstiQ acts on a hunch unimpeded by knowledge of what he is doing
<fullermd> "... unencumbered by the thought process..."
<vila> LarstiQ: is there an easy way for you to try this with a bzr based on a revno < 6000 ?
<LarstiQ> vila: bzr branch -r 5999 is simple enough, sure
<LarstiQ> fullermd: "niet gehinderd door enige kennis van zaken" is the original
<bigjools> can someone check out this bzr failure in a recipe build please? https://launchpadlibrarian.net/90383865/buildlog.txt.gz
<LarstiQ> vila: backtracee seems the same
<LarstiQ> mgz, vila: so just before the breakin, it does  return self._sock.recv(buffersize, flags=flags), with buffersize=65536 and flags=0
<vila> bigjools: sounds like a known issue, but bzr-2.4.0 ?
<LarstiQ> I don't know what the semantics are supposed to be, but could it be waiting till it has enough data till it can return buffersize bytes?
<mgz> bigjools: bug 915505
<ubot5> Launchpad bug 915505 in Launchpad Auto Build System "bzr: ERROR: exceptions.AttributeError: 'cStringIO.StringI' object has no attribute 'split'" [High,Triaged] https://launchpad.net/bugs/915505
<vila> hehe, he's even faster than me asking him :)
<mgz> needs python-debian update on buildds
<bigjools> :)(
<bigjools> grar
<bigjools> thanks
<mgz> could work around in bzr-builddeb, but then we'd just need a builddeb update insteat
<vila> LarstiQ: no, most of the responses are far shorter
<bigjools> mgz: is someone working on rolling a new buildd?
<mgz> LarstiQ: that recv is fine, it returns when it gets something, rather than looping and trying to fill the buffer like higher level read calls
<mgz> bigjools: good question... probably not?
<bigjools> mgz: I've upped it to critical.  I'll help push it through if someone can tell me what needs changing
<mgz> LarstiQ: have you dumped the log from the hung test yet?
<LarstiQ> mgz: http://paste.debian.net/152798/
<mgz> bigjools: looks like we don't have an rt for updating it yet
<mgz> will check with jelmer later today and get back to you.
<mgz> LarstiQ, vila: I wonder if we can get log from the test http server too?
<mgz> LarstiQ: I think the next thing that would be useful here is to file bugs
<mgz> so we don't lose track of what we know about the issues
<LarstiQ> mgz: I'll try to do that now before lunch
<vila> jelmer, mgz: https://code.launchpad.net/~vila/bzr/917733-cmdline-overrides/+merge/89216 up for review, blocking for tarmac AIUI
<vila> tested manually with http://paste.ubuntu.com/809507/ which is a bit silly as the default ui is SilentUiFactory so no output is produced but it doesn't traceback anymore with the fix
<ggherdov> Hi all. has anybody tried to use bzr and kdiff3 in combination to preview merges, in the spirit of http://wiki.bazaar.canonical.com/qbzr/Blueprint/diffmerge ? how to do that?
<ggherdov> I mean, ok for THIS and OTHER, but I would need to get BASE too (which is computed internally by 'bzr merge') to have input to feed to kdiff3
<vila> qbzr supports external merge tools as far as I know
<vila> I don't know where this is documented though
<ggherdov> vila: yes that's what I read everywhere, but i didn't find any practical example (in the cut-and-paste sense of the term :-)
<vila> http://wiki.bazaar.canonical.com/QBzr/ExternalMerge#KDiff3
<vila> hmm, not sure it's up to date
<vila> ggherdov: what bzr/qbzr versions are you using ?
<ggherdov> vila: thx a lot. Actually interesting. How to get BASE ? bzr version: checking...
<ggherdov> 2.2.1
<ggherdov> qbzr: checking...
<vila> with versions recent enough, I think you just need to say you use kdiff3 and the command template is already included
<ggherdov> 0.19
<ggherdov> ok i'll give it a try. I am not familiar with the GUI, I always use cmd line, so maybe that's why I missed that.
<mgz> you need to update your bzr version really, a neater way of configuring was landed since then <https://code.launchpad.net/~doxxx/bzr/mergetools/+merge/40923>
<ggherdov> mgz: thx. checking that.
<vila> right, mgz is always faster ;)
<vila> but I concur with the advice, my remark is based on this proposal (and probably some later tweaks)
<ggherdov> thx guy, updating bzr. Actually this imply updating my obsolete fedora 14 to 15... gosh this issue is a fractal.
<bigjools> mgz: thanks. If a new buildd is rolled, does it just need to pick up the latest python-debian?
<ggherdov> guys*
<mgz> ggherdov: you could probably get the extmerge plugin working instead if updating bzr is hard
<mgz> bigjools: not sure, will find out.
<ggherdov> mgz: good hint. By the way, do you know the 'oldest' stable release that includes the new mergetools stuff you were pointing in lounchpad?
<ggherdov> launchpad*
<mgz> the linked bug 489915 says fixed in 2.4b1
<ubot5> Launchpad bug 489915 in QBzr "[master] external diff/merge configuration needs serious rework" [High,Fix released] https://launchpad.net/bugs/489915
<ggherdov> mgz: ok
<LarstiQ> mgz: filed bug 918624
<ubot5> Launchpad bug 918624 in Bazaar "some test_http hangs under pypy" [Undecided,New] https://launchpad.net/bugs/918624
<LarstiQ> and nwo I really need to eat something
<mgz> LarstiQ: enjoy
<ggherdov> no way , fedora 15 has bzr 2.3 . extmerge is my only way to go.
<mgz> uuu, I see, this is ugly, run_bzr really shouldn't be a public function
<vila> mgedmin: well, tarmac will cry if we remove it, just found it imports it so I confirm that's how it triggers the bug (and that my fix covers it)
<vila> it also calls ui.make_ui_for_terminal directly
<mgz> ?mg
<mgz> ha, not vi
<vila> which reinforces the idea that importint bzrlib should provides sane defaults triggering the least possible amount of IOs
<vila> s/importint/importing/
<mgz> I take it that was targetted at me vila?
<vila> xchat bad habbit of forgetting my settings for completion is really... yes, was for mgz ;)
<vila> mgz: landing on 2.5 ??
<mgz> it's not an api change :)
<mgz> seems odd to have all the new config pain for 2.5 but none of the fewer-writes benefit
<vila> hmm, strictly speaking, that's true
<mgz> I've got worse things that need to land on 2.5
<vila> the annoying bit is that it means plugins won't have a beta test period for that so 2.5.0 can be more brittle that our stable-uber-alles users may expect...
<mgz> plugins are always borked on our .0 releases anyway
 * mgz takes the cynical view :)
 * vila as RM feels he will have to accept this as a reality
<fullermd> If you release 2.5.-1 instead, things should work well with .0 a month or two later...
<vila> That's a good option and I'd love it if installers builders follow this trend but we're not fully there yet. I'll try to make it clear in the 2.5b5 announcement
<LarstiQ> mgz: regarding 'ValueError: file descriptor cannot be a negative integer (-1)', the amount of tests and the precise tests that fail varies from run to run
<LarstiQ> mgz: should I file a bug with that info, and then say "might be a race, might be exhausting filedescriptors"?
<mgz> if you can do a reduced run that fails with on select with -1 (should be possible, pick a test subset),
<mgz> I'm pretty sure that's an independant issue from the fh exhastion
<mgz> likewise, any other failures on reduced runs probably warrant bugs
<mgz> and an overall bug for running out of fds on the full testrun with pypy seems reasonable, though the exact tests that fail aren't relevent
 * LarstiQ nods
<LarstiQ> will do
<jelmer> vila: hmm, has your cmdline_overrides patch landed yet?
<vila> (almost there finishing lunch)
<vila> jelmer: yes, on 2.5, any issue with it ?
<jelmer> vila: Sorry, PEBKAC
<pfarrell> hi! I'm confused by how to specify dates in bzr cat
<pfarrell> I have two revisions that happened at these times:
<pfarrell> revision 4 @ timestamp: Thu 2012-01-19 12:40:06 +0000
<pfarrell> revision 3 @ timestamp: Wed 2012-01-18 17:58:31 +0000
<jelmer> vila: actually, there is
<jelmer> vila: line 1087 uses config, but it's never imported
<pfarrell> and I do bzr cat -r date:2012-01-19 <FILENAME>
<pfarrell> but I get revision 4, instead of revision 3!
<pfarrell> even if I do bzr cat -r date:2012-01-19,00:00:00
<pfarrell> am I doing something wrong? or is it a bug in bzr?
 * vila blinks
<vila> how on earth did my test succeeded then...
<jelmer> vila: not sure :)
<jelmer> pfarrell: that sounds like a bug
<pfarrell> ok, thanks
<jelmer> pfarrell: if you have a moment, it would be great if you could file a bug report. what version of bzr are you using?
<pfarrell> 2.2.4-0ubuntu1
<pfarrell> in natty
<pfarrell> yep, I'm just writing it now
<vila> jelmer: ok, reproducced
<jelmer> pfarrell: it might be fixed in newer versions, I can't easily reproduce it with current trunk
<pfarrell> I wonder is it related to https://bugs.launchpad.net/bzr/+bug/131273
<ubot5> Launchpad bug 131273 in Bazaar ""date" revisionspec not returning exact revision when revision time zone differs from local time zone" [Wishlist,Confirmed]
<vila> jelmer: and fixed
<pfarrell> jelmer: would you mind trying it on my specific repository, if I pm you the details?
<jelmer> pfarrell: that might indeed be relevant. Are r3 and r4 in different timezones from you?
<jelmer> pfarrell: sure
<pfarrell> er, no, it's all London time, I think
<pfarrell> but maybe the launchpad server is in another timezone ?
<jelmer> it's located in London too (but its timezone shouldn't be relevant)
<pfarrell> out of curiosity, where in London?
<jelmer> I have no idea :)
<jelmer> vila: thanks!
<vila> jelmer: will land when you leave pqm breathe ;)
<jelmer> vila: :)
<ggherdov> Hi all. About the extmerge plugin http://doc.bazaar.canonical.com/plugins/en/extmerge-plugin.html , something that wasn't clear to me at first: you run 'bzr merge /otherbranch/' and --then-- you call 'bzr extmerge /somefile/' , is that right?
<ggherdov> I thought that extmerge was somehow a substitute of the 'bzr merge' command
<vila> ggherdov: nope, the phrasing is indeed ambiguous on this page but this kind of tool just can't replace bzr merge
<vila> jelmer: progress on urllib-verifies-ssl-certs,
<vila> the http tests don't hang anymore (they needed the right ssl.ca_certs) and I've fixed some more in test_https_urllib ;)
<vila> running a full suite now
<vila> ha, more hanging tests in per_transport, of course
<ggherdov> vila: thx, i figured that out :-) Anyway: my first day with bzr extmerge + kdiff3, I am totally in love <3
<vila> \o/
<jelmer> vila: \o/
<vila> I missed handling the wrong retry_or_raise call, any cert exception should be propagated, never re-raised...
<vila> should inherit from connection error maybe ?
<jelmer> vila: it's an error that comes from the ssl module; perhaps we should just be always letting those thorugh?
<vila> yeah, both
<vila> err
<vila> waitasec
<vila> what's the purpose of match_hostname then ?
<jelmer> vila: the ssl module verifies the certificate and then returns the certificate info
<jelmer> vila: match_hostname then verifies that the certificate has the same hostname as what we connected to
<vila> ha right, sry, haven't followed the python imp closely enough, yeah, people complained in the past about the hostname not being verified
<vila> great, tests are properly failing now
<vila> SSLError: [Errno 1] _ssl.c:503: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
<vila> not super user-friendly, worth re-raising as a CertificateError instead ?
<jelmer> vila: not sure, do you have a good way of extracting a user-friendly message from the SSL error?
<jelmer> I think printing the SSL error is probably nicer than just saying "Something went wrong in the SSL handshake"
<vila> k
<vila> wfm, can be refined later, my changes so far are pretty clear so it won't be hard to find the right place back
<vila> so, the config trick is really a hack that don't work for all cases, I think we want dedicated parameters (still defaulting to the config options) for all tests and provide a test_permutation like we do for pycurl
<vila> yeah, and you already provide some context when they occur
<vila> so, 58 failures for a full test run so far
<lamont> bzr: ERROR: exceptions.AssertionError: get_next() called when there are no chars left
<lamont> what did we decide was the right answer when bzr st says that (2.3.4-0ubuntu1)
<vila> lamont: isn't it a symptom of a broken dirstate file ? (more traceback can help)
<mgz> lamont: `bzr repair-workingtree`
<lamont> vila: I can beleive that.  how do I fix it?
<lamont>  bzr repair-workingtree
<lamont> bzr: ERROR: unknown command "repair-workingtree"
<lamont> I shall see if 2.4.0 has that
<vila> https://answers.launchpad.net/bzr/+faq/940
<vila> is the shortest I can come with, repair-workingtree uses a slightly shorter implementation IIRC
<lamont> I need to make 2.4 install in my little silly world
<lamont> vila: turns out that just branching and smacking .bzr/checkout over the top of the old branch seems to be sufficient to my needs
<vila> lamont: right, and you can run 'bzr st' to refresh it
<mgz> this is nearly the exact same conversation we had last time
<jelmer> yup :)
<lamont> yeah.  it fell out of brain-cache
<vila> jelmer: more progress... the *server* was hanging too because an exception was raised about an unknown ca
<vila> so, yeah, getting details from ssl errors is hard, python seem to just rely on openssl and that's where the errors are coming
<vila> I don't quite get why the server complains about the ca... but it does so only when the client do the handshake...
<vila> it's a bit like: (client) oooh, this server is bad, (server) OMG a client said I'm bad !!
<vila> what's the point ?
<vila> anyway, down to 22 failures and no more hangs
<jelmer> vila: \o/
<jelmer> vila: what are the remaining 22 errors?
<vila> [Errno 1] _ssl.c:503: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
<vila> because the *transport* don't use the right ssl.ca_certs config option, mentioned earlier
<vila> but I wanted to fix the server hangs first (we're not supposed to encounter them anymore by the way...)
<vila> not sure I will be able to finish tonight but I know where to dig
<vila> basically the config should be used as a fallback as it requires disk resources which led to my own bazaar.conf being erased.. endless fun and some wtf moments :)
<jelmer> hehe
<vila> jelmer: gotta go, only one test still failing: bzrlib.plugins.launchpad.test_lp_directory.TestXMLRPCTransport.test_direct_request(https)
<vila> will have to inject the right server and transport there, not the default ones
 * LarstiQ grumbles at blackbox tests leaving 120 open files
<wgz> LarstiQ: I bashed all the non-test-specific ones I could find a while back
<wgz> but at that point there was no need to go through and edit tests to do file handling sensibly when refcounting works
 * LarstiQ nods
<poolie> hi all
<wgz> hey poolie
<LarstiQ> heya poolie
<wgz> LarstiQ: so, the yellow here should correspond with your issues <http://float.endofinternet.org/xmlbin/dev_r6442_non_per>
<exarkun> What kind of server-side hooks are available when not using the smart server?
<wgz> if you click on one and it says 'unclosed file' that's a likely issue on pypy
<LarstiQ> exarkun: none?
<exarkun> LarstiQ: Why the "?"?
<LarstiQ> exarkun: I'm not sure I understand the context
<wgz> exarkun: everything that's not a smart server hook, but they get run on the local machine against the remote object
<jelmer> exarkun: the nature of dumb servers make it impossible to do server side hooks
<jelmer> hi poolie, wgz, LarstiQ, exarkun
<exarkun> Say I'm developing an application in a bzr branch and I want to update the deployment of the application by pushing the branch to the deployment environment.
<exarkun> Should I achieve the effect some other way?
<LarstiQ> exarkun: ah, that way
<jelmer> exarkun: a smart server can do that for you, or you could have the client do it if you're not using a smart server
<LarstiQ> exarkun: specifically for that usecase there is bzr-upload
<LarstiQ> wgz: thanks! test_merge is not as yellow as I'd expect it
<exarkun> I don't really know anything about smart servers, except I guess there is some special software implementing at least one kind (the one launchpad uses).  It seems like maybe I'd rather avoid having to deploy one of those.
<LarstiQ> exarkun: usually it's just bzr
<exarkun> LarstiQ: Hm.  I probably need to restart a process on the server, so it uses the updated code, so I don't know if bzr-upload is sufficient.
<wgz> LarstiQ: that's useful to know, implies an actual behaviour difference, what are the files you get leaked there?
<exarkun> LarstiQ: Oh.  Maybe I misunderstood, then.  How do I know if there is a smart server or not?
<jelmer> exarkun: all a smart server over ssh needs is having bzr installed on the remote side
<jelmer> exarkun: if you're using bzr+ssh:// you're using the smart server
<LarstiQ> exarkun: if you can use bzr+ssh://
<exarkun> Oh, okay, well that's pretty easy then.
<LarstiQ> exarkun: (or well, you could do smart server over http, but bzr+ssh is the most common)
<LarstiQ> wgz: let me see about gathering that
<exarkun> So I can use the SmartServerHooks... Perhaps "server_stopped" is a good one to use for this use-case?
<wgz> exarkun: or any of the other hooks, installed server side
<exarkun> wgz: Oh
<exarkun> Any of them, really?  Like "post_push"?
<wgz> that wouldn't be relevent if the server is being pushed to.
<wgz> it would run when bzr on the server pushes to some other location though :)
<jelmer> exarkun: something like the post branch tip change hook should work
<exarkun> jelmer: Ah
<exarkun> Any reason to prefer that over server_stopped?
<exarkun> (it sounds nicer, I want to prefer but, but I don't know why)
<LarstiQ> exarkun: if nothing gets changed, no need to restart the process
<wgz> post_branch_change_tip is what's normally used
<wgz> otherwise your code runs if someone does `bzr log bzr+ssh://...`
<wgz> etc.
<exarkun> Ah, I see.
<LarstiQ> oh, that's a good reason too :)
<LarstiQ> exarkun: and it doesn't matter if it's push/pull/uncommit, same hook
<LarstiQ> with a difference between those on _where_ the hook runs
<wgz> jelmer: can you give LarstiQ any hints on debugging fd exhaustion issues?
<LarstiQ> wgz: I've got a list now
 * LarstiQ cleans it up
<wgz> heh, my check for pypy not having the pythonapi was wrong
<LarstiQ> wgz: http://paste.debian.net/152865/ gathered from running "ls /proc/`pgrep pypy`/fd" once a second
<LarstiQ> wgz: ooh, the Unclosed file: bits are really spiffy
<wgz> okay, niece fed, now it's my turn, will be back shortly
<mwhudson> jelmer: hey, you might know this
<mwhudson> jelmer: would you expect repo.revision_trees([revid, revid]) to return a 1 or 2 element list?
<jelmer> mwhudson: deux
<mwhudson> jelmer: has this changed recently?
<mwhudson> jelmer: per https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-90422eb49bf1e605dc0161ef0b9f916d
<jelmer> mwhudson: hmm, it might have actually
<jelmer> I don't think any of those changes are deployed on lp yet though
<mwhudson> indeed
<mwhudson> that would explain why i couldn't reproduce the bug though
<jelmer> I don't remember ever seeing explicit tests for that though
<jelmer> it would be nice to add something that tests that.
 * mwhudson wonders if repo.revision_trees(['null:']) still explodes
<jelmer> mwhudson: I think it's repo.get_inventory() that explodes on null, revision_trees() hasn't for as long as I can remember
<mwhudson> jelmer: my survey says BZZT: http://paste.ubuntu.com/810091/
<jelmer> mwhudson: hmm, wtf?
<jelmer> mwhudson: ah, I think it's revision_tree() that does 'null:'
<mwhudson> jelmer: ah hah
<mwhudson> yes you are possibly right
<mwhudson> i guess there shoudl be some bugs filed out of this
<exarkun> given a Branch, how do I figure out where its checkout is?
<jelmer> exarkun: branch.bzrdir.open_workingtree()
<jelmer> mwhudson: file away please :)
<lifeless> exarkun: in general you cannot, because there may be many, and they may be anonymous
<lifeless> exarkun: if its colocated, jelmer is correct. If that raises (NoWorkingTree), then it doesn't proove there is no checkout, just none colocated
<exarkun> What's a "workingtree"?
<exarkun> http://people.canonical.com/~mwh/bzrlibapi/bzrlib.html is half helpful
<lifeless> editable source code on disk + metadata
<exarkun> at least it lists what classes and methods exist
<exarkun> but it's not actually enough information to use most of the APIs
<exarkun> because I don't know what kind of object open_workingtree returns
<lifeless> bzrlib.workingtree.WorkingTree
<lifeless> (or subclasses)
<lifeless> http://people.canonical.com/~mwh/bzrlibapi/bzrlib.workingtree.WorkingTree.html
<exarkun> it would be nice to have more information in the API docs
<exarkun> So if there is no colocated checkout, then is there some way to find where the branch is?
<lifeless> hang on
<lifeless> you started with 'given a Branch'...
<lifeless> http://people.canonical.com/~mwh/bzrlibapi/bzrlib.branch.Branch.html
<lifeless> '.base'
<exarkun> well, "filtered-138970476:///~/some-path/" is /like/ a directory
<exarkun> is there an api in bzrlib that takes something like that and gives me an actual directory though?
<exarkun> I'm guessing .base[22:] is not the brightest idea
<exarkun> on the other hand maybe I don't care
<lifeless> you can poke under the hood if needed; what are you trying to accomplish ? [note that the api supports entirely in-memory branch objects and soft chroots as well
<exarkun> it might be better to just create a new checkout every time
<exarkun> There's some code in the branch, I want to run it, I'm writing a post-push hook
<exarkun> actually a post change branch tip hook I guess
<exarkun> thanks, bbl
<lifeless> so indeed
<lifeless> post-push on a server won't have a working tree at all
<lifeless> and there is no guarantee that what was committed matches what is on disk (because of partial commits)
<lifeless> so making a clean checkout will be much more repeatable
<lifeless> bbl myself
<AuroraBorealis> so
<AuroraBorealis> with the recent email about colocated branches almost being done
<poolie> hi
<AuroraBorealis> does that mean if we start using them, will we able to use them as 2a branches?
<AuroraBorealis> cause it says it has to be a different format for the time being
<poolie> we are going to turn them on a way that doesn't require a bzr-upgrade flag day
<AuroraBorealis> ok so they are basically 2a branches
<AuroraBorealis> and these colocated branches are NOT using a plugin? and should work with all the commands?
<jelmer> AuroraBorealis: yes
<jelmer> AuroraBorealis: although specifying them may still be a bit icky for some commands, because you need to specify a URL at the moment
<AuroraBorealis> will that be fixed by the time its final?
<AuroraBorealis> like doing switch trunk2 instead of .bzr/branches/trunk2 or whatever
<jelmer> AuroraBorealis: yes, that's the plan
<jelmer> AuroraBorealis: it's not .bzr/brnches/trunk2, but rather "file:,branch=trunk2"
<jelmer> AuroraBorealis: eventually it will just be 'trunk2'
<AuroraBorealis> yeah, thats how it is in the plugin right now
<AuroraBorealis> where are the branches stored?
<jelmer> AuroraBorealis: .bzr/branches
<AuroraBorealis> ah ok
<AuroraBorealis> same place
<poolie> o/ jelmer
<jelmer> AuroraBorealis: the format is different though
<jelmer> hey poolie
<AuroraBorealis> is it still a repository?
<AuroraBorealis> the branches folder or whatever
<jelmer> AuroraBorealis: how do you mean?
<jelmer> AuroraBorealis: if there is a repository, it's in .bzr/repository
<AuroraBorealis> i'm still kinda new to how these work , so you can have a folder with multiple co-located branches but no repository?
<jelmer> AuroraBorealis: just like you can currently have a folder with a branch but no repository.
<AuroraBorealis> ah. makes sense
<AuroraBorealis> will checking out a branch when your current working directory is inside a colocated branches folder, add another colocated branch?
<jelmer> AuroraBorealis: I'm not sure if I follow. each folder can only hav ea single working directory
<AuroraBorealis> yeah i know, but if you want to add another branch to your colocated branches
<AuroraBorealis> normally you just branch it and have the location be inside a shared repository, is it the same here?
<jelmer> AuroraBorealis: sure, you can do something like "bzr branch lp:... file:,branch=colocatedthing"
<AuroraBorealis> and that will put it under the 'colocatedthing' branch inside the folder?
<jelmer> yep
<AuroraBorealis> ok! thanks =)
#bzr 2012-01-20
<exarkun> is there a python import hook for importing from a bzr branch (with no working tree)?
<jelmer> exarkun: not that I'm aware of
<jelmer> that would be a cool (and fairly achievable, at least from the bzr side) thing to write though
<poolie> nice
<mwhudson> an equivalent thing would be a FUSE fs backed onto a branch i guess
<exarkun> mwhudson: or an x86 implementation in javascript on v8 running a linux installation preloaded with the contents of the branch as a normal part of an ext4 filesystem
<jelmer> mwhudson: or a Transport implementation on top of the Tree API
<mwhudson> exarkun: that sounds modestly over complicated
<mwhudson> jelmer: ... yes, i guess so
<mwhudson> jelmer: that's quite a confusing thing to think about though :)
<jelmer> mwhudson: nested trees? >-)
<exarkun> How does bzr+ssh:// figure out which bzr executable to launch?
<jelmer> exarkun: it just runs bzr, or you can set the BZR_REMOTE_PATH environment variable
<exarkun> And what are the chances I'll be able to get it to run bzr with PyPy?
<jelmer> exarkun: in other words, it leaves it to the shell on the remote machine
<jelmer> exarkun: I think there are still some open issues running bzr with pypy, LarstiQ was looking into some today.
<jelmer> https://bugs.launchpad.net/bzr/+bugs?field.tag=pypy
<exarkun> argh, always so difficult
<jelmer> exarkun: I think it's mostly tests failing, not sure how much matters in practice
<exarkun> before I even get to any of those issues, I can't use the system installed version of bzr on pypy because sys.path doesn't work that way
<exarkun> and I really don't feel like installing bzr just for pypy either
<poolie> what do you mean about sys.path?
<exarkun> "ImportError: No module named bzrlib"
<exarkun> ahhh, pointing PYTHONPATH directly into /usr/share/python-support/python-bzrlib works
<exarkun> implausible, but I'll take it
<poolie> i wonder if it's something about pypy not reading pth files
<poolie> does it work with that fixed?
<exarkun> I think pypy intentionally avoids using cpython's library, including site^Wdist-packages
<exarkun> it's pretty hard to tell what's going on
<exarkun> aha, think it's working
<exarkun> on top of a precious stack of ad hoc configuration :/
<exarkun> oh well good enough
<exarkun> okay, just one more thing I'll try tonight...
<exarkun> what's a good way to restrict a plugin to running on only one branch?
<poolie> hm
<poolie> the normal thing is to just have an option in that plugin
<poolie> .. there ought to be a builtin option though
<exarkun> what kind of option?  like, something in ~/.bazaar/config?
<poolie> there is no option for it now but there should be
<poolie> well, perhaps  in locations.conf
<poolie> but, there is a bit of a bootstrapping problem, that plugins are loaded very early on
<poolie> so that they can control how branches are opened
<poolie> you could do it from some shell scripting outside of bzr
<exarkun> hm.  I can't quite think of what that would look like.
<poolie> if [ `pwd` == /home/me/foo ]; then;  export BZR_DISABLE_PLUGINS=pqm ; fi; exec bzr "$@"
<exarkun> and the pwd is the branch being operated on?
<poolie> no, it would be just your pwd
<poolie> so it's not quite accurate
<poolie> in the fairly common case where the branch comes from one of the args
<poolie> what's the specific case?
<exarkun> I'm writing a server-side plugin that deploys an application whenever the server-side branch is pushed to
<poolie> ok..
<poolie> and you want it only to do this for some branches?
<exarkun> passingly
<exarkun> as it happens, there's only one branch I've ever pushed to this machine before
<exarkun> if I ever decided to push some totally unrelated bzr branch to it for some reason, it'd be nice to not trigger the plugin
<poolie> ok
<poolie> so i think your plugin should just load unconditionally and install its hook
<poolie> then when it gets the branch that has been changed,
<poolie> if branch.get_config_stack().get('my_deploy_plugin.enabled'): do_it
<poolie> then you can put that in the branch.conf, locations.conf, or globally
<exarkun> oh, fancy
<exarkun> that sounds just fine
<exarkun> thanks
<poolie> you're welcome
<exarkun> something I noticed while doing this, the end of the bzr output is a little mixed up:
<exarkun> Pushed up to revision 62.
<exarkun> exarkun@top:~/Projects/treeplan$ bzr: warning: some compiled extensions could not be loaded; see <https://answers.launchpad.net/bzr/+faq/703>
<exarkun> I know why the compiled extensions could not be loaded, but I don't know why I get warned about it after I've gotten my new shell prompt...
<poolie> not sure
<poolie> maybe ssh lack of synchronization between stderr/stdout
<poolie> (lunch)
<exarkun> huh, http://codepad.org/VZ85gbDu
<AuroraBorealis> is it because some extentions arn't compiled?
<exarkun> AuroraBorealis: Seems unlikely.
<jelmer> exarkun: you have a bzr older than 2.4 - use branch.get_config().get_user_option("foo")
<exarkun> ah, ok
<exarkun> Cool, seems to be working well now
<exarkun> I notice some leftover files in /tmp
<exarkun> eg bzr-index-q3bQ3p
<AuroraBorealis> isnt that the point
<AuroraBorealis> its in /tmp, who cares?
<exarkun> starting with "B+Tree Graph Index 2"
<exarkun> AuroraBorealis: I care, when I run out of disk space in 6 months
<AuroraBorealis> i dont think bazaar is going to make you run out of disk space o.o
<AuroraBorealis> espeically if you restart anytime in between said period
<jelmer> exarkun: yeah, those should be cleaned up. I wonder what creates them
<jelmer> AuroraBorealis: it's common courtesy for applications to clean up files they no longer need, even in /tmp
<AuroraBorealis> yeah. at least you have /tmp, windows they stick around forreevverrrr
<jelmer> AuroraBorealis: if nothing deletes them they can stick around forever too in /tmp..
<AuroraBorealis> doesn't it clear /tmp when you restart?
<exarkun> This machine had an uptime of 900+ days the last time it restarted
<exarkun> That's a long time for temp files to pile up
<AuroraBorealis> your kernel must BELONG IN A MUSEUM
<AuroraBorealis> </meme>
<AuroraBorealis> but yes i see your point
<exarkun> Anyway, I'm reasonably happy with this for now.  Thanks for the help, everybody.  In case you're curious, the plugin is http://bazaar.launchpad.net/~exarkun/+junk/treeplan/view/head:/generate_schedule.py
<exarkun> good night
<poolie> vila, jelmer, hi?
<vila> buongiorno a tutti !
<vila> jelmer: ping, https://code.launchpad.net/~jelmer/bzr-pqm/2.5-compat/+merge/89367 reviewed, double check my proposed tweaks but I think the end result should be good to land (tests are passing here (before you ask, 'bzr plugins -v' double-checked ;))
<vila> jelmer: and thanks for that, I discovered the issue recently and fixing it was up in my TODO list
<vila> ...
<vila> the release notes are clean, 2.5 already merged into trunk... isn't the world a beautiful place ?
<AuroraBorealis> how can i get 2.5 so i can test colocated branches?
<AuroraBorealis> oh durr wrong website
<LarstiQ> AuroraBorealis: you can download the latest beta from https://launchpad.net/bzr/+download, or bzr branch lp:bzr/2.5 if you want to track the work leading up to the final
<AuroraBorealis> kay. first thing i noticed about colocated branches, bzr switch <something> doesn't work. get "cannot switch a branch, only a checkout"
<mgz> morning all
<vila> hey mgz !
<vila> mgz: windows installers ?
<mgz> sure.
<vila> mgz: I said I'll announce today, would be nice if they were available :)
<vila> jelmer: in bzr trunk, BZR_DISABLE_PLUGINS=svn ./bzr selftest -s bzrlib.tests.test_http.SmartHTTPTunnellingTest.test_open_bzrdir pass but ./bzr selftest -s bzrlib.tests.test_http.SmartHTTPTunnellingTest.test_open_bzrdir fails
<vila> jelmer: I'm a bit lost :-/
<vila> jelmer: this may be related to probers but I can't understand why
<vila> jelmer: fails with: AssertionError: <BzrDirMeta1 at 'http+pycurl://127.0.0.1:40031/relpath/'> is an instance of <class 'bzrlib.bzrdir.BzrDirMeta1'> rather than <class 'bzrlib.remote.RemoteBzrDir'>
<vila> }}}
<vila> jelmer: hmm, could it be some pycurl internal state borking ?
<vila> jelmer: yup, found it, playing around with pycurl.CUSTOMREQUEST is the culprit, your svn prober seems to force "GET" which get in the way of the smart server trying to use POST
<vila> jelmer: pycurl is probably to blame here for providing two incompatible API (CUSTOMREQUEST vs HTTPGET/POST)
<vila> jelmer: I can hear you ask for bzr supporting OPTIONS you know ;)
<vila> jelmer: ok, I had a fix for bzr itself, but I've found a less risky one for bzr-svn instead: http://paste.ubuntu.com/810565/
<vila> jelmer: there is also an unrelated fix in this paste for the config stuff that is taking dust in my local copy
<vila> jelmer: gotta go now bbl
<mgz> ah.
<mgz> svn-lib 1.6.6
<mgz> I suspect that's... not right any more.
 * mgz gently kicks jelmer
<CaMason> Morning guys. What's the command to show the gui that shows who made what changes to a file?
<mgz> `bzr qblame FILE`
<CaMason> found it, qannotate
<CaMason> that's the same as qblame?
<mgz> that's the allenap milquetoast version of qblame
<mgz> of course, real developers add a 'qwhosucksthemost' alias and use that
 * jelmer kicks mgz  back - what's up with 1.6.6 ?
<mgz> is it the version I want?
<jelmer> mgz: possibly, it should be sufficient
<mgz> okay, thanks.
<jelmer> mgz: any recent version (prior to 1.7) should do
<mgz> ah, so, *not* 1.7?
<mgz> oo, they're up to 1.6.17 under that.
<mgz> will leave as is unless this build breaks.
<jelmer> mgz: yeah, 1.7 has a bunch of changes that break assumptions in subvertpy/bzr-svn
<mgz> what the hey, why is this deprecation warning getting through...
<mgz> that would make me feel really bad about not posting my config location finding changes for review
<mgz> but I thought release versions weren't meant to whine
<jelmer> they're not
<mgz> then why is the installer version doing it ;_;
<mgz> ah, b5!=release?
<mgz> okay, er...
<mgz> I wonder whether I should cheat and change the tip, or just put a note in saying "yes, I know I messed this up"
<mgz> I need some smallish svn repo to test against too, any suggestions?
<jelmer> mgz: svn://svn.samba.org/subvertpy/trunk ?
<mgz> works... will have to mark the bug as incomplete.
 * vila back
<vila> jelmer: seen my previous remarks about bzr-svn prober ?
<jelmer> vila: yeah, see recent lp:bzr-svn commits :)
<vila> \o/
<mgz> vila: uploading windows installers now
<vila> \o/
<vila> :)
<mgz> I had to er... adjust for a little problem I caused on trunk
<mgz> gah!
<vila> trunk ?
<mgz> complaining about password after already uploading
<vila> which trunk ?
<mgz> and the script has now broken my terminal
<vila> hpmf, lp_registration directly uses _urllib2_wrappers.Opener, makes it harder to fix the last test failure for cert validation ;_;
<vila> bingo, quick, dirty, works
<mgz> okay, I'm stuck, launchpad won't let me upload with the script
<vila> switch to manual upload ?
<mgz> either launchpad has changed, or it's no longer accepting the SSO password
<mgz> which is what I swear it was last time
<vila> I have a vague souvenir that you encountered issues last time too no ?
<mgz> it's just a pain, but I documented it and everything
<mgz> but it no longer works
<vila> nothing in  .bzr.log ?
<mgz> it's using curl to post to a webpage, there's no launchpad api
<vila> hmpf
<mgz> "Application error.  Unauthenticated user POSTing to page that requires authentication."
 * mgz growls
<vila> coockies involved ?
<mgz> it's curl.
<vila> curls supports coockies :)
<mgz> I guess lp or sso just broke it.
<vila> can't imagine why nor how
<vila> always possible but... my little daemon tells me it's unlikely
<mgz> < wgrant> That's been unsupported for about 2 years, and I removed it last week.
<wgrant> I removed basic auth.
 * vila to his little daemon: put that in your pipe
<LeoNerd> http://doc.bazaar.canonical.com/beta/en/user-reference/location-alias-help.html  <== possible to add new custom ones?
<LeoNerd> Specific per checkout, I mean
<vila> LeoNerd: I'm not sure I understand your question, do you mean locations defined in branch.conf or defined for <unspecified but not supported yet> checkout property ?
<LeoNerd> Either.
<LeoNerd> As an enduser: I want some way to  bzr diff :fred
<LeoNerd> To compare to Fred's branch, where :fred would just expand to the full URL
<vila> ok, so an already available trick then:
<vila> bzr config fred=<full URL>
<vila> bzr diff --old `bzr config fred`
<LeoNerd> Oohright
<LeoNerd> Oh.. :(
<vila> ?
<LeoNerd> I wanted it to appear as a :NAME like the others..
<fullermd> Yeah, that falls nicely into the category of "_technically_ answering the question, but"   :p
<vila> I said trick !!
<vila> :)
<fullermd> The closest answer would be bookmarks.
 * fullermd will hold out for the treat   :p
<LeoNerd> Ooh. that's probably close enough
<LeoNerd> bm:fred
<vila> yup
<fullermd> But you'll have to find a way to hire Michael Baker.
<vila> I need to implement a config: specifier some day...
<vila> ... and add an alias as c: just to confuse windows users :)
<fullermd> C:\ is the root of all evil.
 * vila receives BOFH bonus points
<fullermd> Where's my excuse calendar...
<exarkun> When I push to a file location, my locations.conf succeeds in supplying some configuration about the branch.  if I push to the same place, but via bzr+ssh, it doesn't.  what am I missing?
<vila> exarkun: the client can't resolve the aliasing between the two locations, you need to add a location for bzr+ssh
<exarkun> :O
<vila> jelmer: https://code.launchpad.net/~bzr/bzr/urllib-verifies-ssl-certs/+merge/89437 up for review on top of your proposal
<jelmer> vila: I'll have a look
<vila> jelmer: not the cleanest proposal I ever made but it does the job for now ;)
<vila> jelmer: the proposal is only the diff against yours, not sure anybody else can understand :-/
<jelmer> vila: is there a particular reason you're deferring the fetching of ca_certs from config in the HTTPSConnection, rather than doing it in the constructor?
<vila> in the transport constructor you mean ?
<jelmer> vila: no, in HTTPSConnection.
<vila> jelmer: not really
<vila> I did it there because the stack was already available
<jelmer> vila: I think it would make sense to move the configuration variable fetching to the constructor, perhaps
<vila> and since I think this should be reworked anyway it doesn't really change the issue
<jelmer> not really a big deal :)
<vila> yeah
<vila> I went for the easiest (there were enough issues to deal with ;)
<exarkun> do I just have to duplicate configuration in locations.conf in two sections, to get multiple urls for the same branch to work?
<vila> exarkun: AFAIK, yes, the only exception being stacked_on_location which you're not supposed to tweak without really understanding the fallouts ;)
<jelmer> exarkun: either that, or you can put the configuration in .bzr/branch/branch.conf
<vila> exarkun: if they are specific to the branch, jelmer's suggestion is even better
<vila> exarkun: no duplication at all
<exarkun> Does .bzr/branch/branch.conf move around with the branch?  Or is it unversioned local-only configuration?
<jelmer> exarkun: it's unversioned local-only
<jelmer> exarkun: "bzr branch" won't copy it
<mgz> okay, rewrote the upload script, seemed to work against staging, doing the real thing now, and lunch
<fullermd> Is this the wrong time to grump that locations.conf really should be called branches.conf, since it only applies to branches?   :p
<exarkun> Okay, that's working.  Not sure if I'm happy about unversioned local-only state... but we'll see.
<vila> fullermd: it will apply to repositories and working trees once they gain their associated config file :)
<vila> fullermd: unless I can convince people to introduce defaults.conf and overrides.conf and clearly document them ;)
<vila> fullermd: and I think there was a branches.conf in the past that locations.conf replaced, dunno about the rationale though, I'm too young for that
<fullermd> Any problem with 1 config file can be solved by introducing 2 config files   :p
<mgz> well, that's hillarious
<mgz> the lp api for uploading files wants the whole thing at once
<mgz> and... it OOMed on the third one
<mgz> using curl was better, it knows how to stream packets
<fullermd> Look, Taiwan is full of DRAM makers losing money.  A well-designed API will do what it can to help jump-start the economy   :p
<jelmer> vila: approved
<jelmer> vila: if you have a chance to look at my sibling-branches MP this week, that would be awesome - I hope to do some work next week based on that
<vila> jelmer: urgh, I hate it when I reviewed a proposal and somehow lost my comments because I close the tab without pushing the right button
<vila> I did review that code, I'm sure
<mgz> solution: do reviews in lynx
<fullermd> Who has room on their system for lynx once they've got emacs crammed in there?
<LarstiQ> or in pentadactyl ^I
<vila> jelmer: done
<mgz> hm, I don't have push access to lp:lptools
<vila> emacs will soon be part of the bios so this won't matter anymore
<mgz>  someone want to push a tyop fix for me?
<fullermd> Wow, I didn't know emacs was that buggy.
<vila> I didn't hear that
<mgz> jelmer: lp:~gz/lptools/trivial_content_typeo -> lp:lptools plz
<fullermd> Well, I'm pretty sure there's a law that no code is allowed into the BIOS unless it's got more bugs than an encrusted entymologic eatery.
<mgz> okay, that's my stack of stuff mostly popped, except the doc updates
<fullermd> And emacs probably runs the same on every system, so that's another strike against it in the BIOS sweeps.
<jelmer> mgz: "lptools has no active code reviews." ?
<vila> fullermd: you got that wrong, every system run the same under emacs, that's the point ;)
<mgz> it's a one-character change
<jelmer> mgz: ah, sorry
<jelmer> mgz: I thought you were asking for a review
<mgz> and launchpad doesn't actually care what you say the content type is, I was just correcting in drive-by but found out I couldn't push
<jelmer> mgz: merrrrged
<mgz> :)
<jelmer> vila: how do you want to handle the landing of the urllib-verifies-certs branch?
<vila> jelmer: almost there, finishing the 2.5b5 release, I think landing my branch should be fine no ?
<jelmer> vila: you can't land it though, because it's got a prerequisite that hasn't landed.
<vila> ? You mean feed-pqm won't list it ?
<jelmer> vila: yeah
<vila> jelmer: but we've fixed pqm-submit no ? :-D
<jelmer> vila: heh, fair 'nough
<vila> or do you mean I should approve your branch first ?
<jelmer> vila: no, but feed-pqm won't allow you to submit your branch until mine has been submitted
<jelmer> vila: and mine can't be submitted because it won't pass make check
<vila> ha right, so pqm-submit will do
<vila> jelmer: let me check pqm-submit
<vila> jelmer: ha, we agree in the end, good, I wrote my comment in a hurry :)
<vila> jelmer: you miss the (2,5,0,'beta',5) trick, I'll fix (two occurrences, luckily I had some uncommitted changes locally that conflicted)
<vila> hmm, feed-pqm appeared happy to send it...
<vila> oh wait, I may need to upgrade ? ;)
<jelmer> yeah, that's a bug...
<vila> right, it served me ;)
<vila> fullermd: does bzr requires pycurl on FreeBSD ?
<fullermd> No.
<fullermd> ('course, it'll use it if it's there, but installing bzr won't drag in pycurl)
<exarkun> bzr update elapsed time 33 mins, 20 secs :(
<fullermd> That sucks.  If it were 13 seconds longer, it'd be way more cool.
<exarkun> don't worry
<exarkun> it's still running
<exarkun> are there known performance issues on Windows 7?
<jelmer> exarkun: which version of bzr?
<exarkun> a pretty new one I hope
#bzr 2012-01-21
<LarstiQ> exarkun: generate_schedule.py looks nice. Do you run it with pypy?
<exarkun> LarstiQ: Yes
<LarstiQ> yay :)
<exarkun> indeed :)
 * LarstiQ looks at some more testsuite failures under pypy
<wgz> LarstiQ: time to fix the last bug you filed then I guess
<wgz> I don't really want to explictly check for pypy there, but if they're going to supply ctypes.pythonapi in some form I guess that's the cleanest way
<LarstiQ> wgz: is there another way of checking for the presence of a symbol than catching the ValueError?
<wgz> nope, but it's not too much worse
#bzr 2013-01-14
<\u03b5> I've got a corrupted bzr repo and I want to get a branch out; said branch's missing function still works, but branching the thing errors on a 0'd out section
<\u03b5> is there anything I can try or should I just let history be a casualty and copy the working tree to a working branch?
<LarstiQ> \u03b5: 0'd out section?
#bzr 2013-01-16
<trident_job> hey bzr users!
<trident_job> Does someone use bzr in windows ?
<gmarkall> i'm making use of bzr on an HPC system - when I load the bzr module on it, it adds the python2.6/site-packages/bzrlib folder to the PYTHONPATH. This causes issues since a few things in bzrlib have the same name as standard libraries (e.g. commands.py). Would I be correct in thinking that this is a bug in the module, and bzrlib shouldn't be on $PYTHONPATH?
<lifeless> thats correct
<lifeless> python2.6/site-packages should be on PYTHONPATH
<gmarkall> lifeless: thanks :)
#bzr 2013-01-17
<LarstiQ> lifeless: is there any web frontend for testrepository?
<jml> LarstiQ: I have vague recollections of lifeless making something along those lines.
<jelmer> you can convert to junitxml, and there is a thingy that can convert that to HTML
<LarstiQ> heh :)
<mthaddon> hi folks, is there a way for me to get all revisions since a certain date from bzr log ?
<elmo> mthaddon: yes
<elmo> mthaddon: bzr help revisionspec
<mthaddon> ah, thx
<mthaddon> elmo: am I missing something? http://paste.ubuntu.com/1541688/
<elmo> mthaddon: I think that just means there were no commits in 2013
<elmo> mthaddon: try e.g. 2012 ?
<jelmer> mthaddon: it's annoying, I think there has to be a revision that matches the date you specify
<mthaddon> jelmer: still no output from "bzr log -r date:2013-01-03.." even though the latest revision has a timestamp of Thu 2013-01-03 10:32:11 -0700
<jelmer> ah, hmm
<jelmer> not sure then, sorry
<mthaddon> interestingly, "bzr log -r date:2012-01-01.." gives me the the entire log (oldest revno is 2012-03-26)
<jelmer> Vila: do you know perhaps?
<vila> mthaddon, jelmer: out of the blue, I'd say -rdate:2013-01-03 evaluates to 2013-01-03 23:59:59 which is after the last rev ?
<mthaddon> vila: I've tried it with 2013-01-01 and it's still empty - I think it's because the merged revision is from 2012-11-30, so it's using that rather than the date it was actually merged
<jelmer> ah, hmm
<mthaddon> nope, not that either...
<mthaddon> "bzr log -r date:2012-11-29.." also empty
<mthaddon> have to go back to "bzr log -r date:2012-10-04.." to get any output
<LarstiQ> mthaddon: before:date:2012-11-29?
<LarstiQ> hmm
<xnox> what is the date of the for last commit?
<xnox> also did you add -n0 to the log command?
 * xnox thought date: resolves to the first commit after the specified date.
<mthaddon> the last commit is from "Thu 2013-01-03 10:32:11 -0700" - I'm not adding -n0
<xnox> and the one before? (forelast)
<mthaddon> Thu 2012-10-04 13:14:32 +0100
<mthaddon> it's like it's ignoring the last one for some reason
<vila> mthaddon: looks like a regression introduced in 2.5 :-( 2.4 gives the expected behavior, can you file a bug ?
<vila> mthaddon: you're using 2.5 or 2.6 right ?
<mthaddon> 2.6.0~beta2-0ubuntu1
<mthaddon> vila: will do, thanks
<mthaddon`> vila: any ideas how long it'd take to fix? - wondering whether to work around it for my use case, or if it'll just be a few days or so
<LarstiQ> vila: are you still using dvc?
 * LarstiQ is annoyed by windows jumping around
<vila> mthaddon`: no idea, get in touch with the lp team that is responsible for bzr maintenance :-/
<mthaddon`> vila: ok, thx
<vila> LarstiQ: yes, still using dvc, no window jumping here though, which windows ?
<LarstiQ> vila: I have a dvc-status and a regular file side by side. Hitting c in dvc-status throws up a log-edit buffer in the non-dvc window. ^C^C and the windows swap, now with a dvc-commit buffer in the non-dvc-status window
<LarstiQ> Hitting q there gets me back to my file
<vila> LarstiQ: wow, I never type anything in dvc-status, I'm always in dvc-diff instead
<LarstiQ> vila: maybe I need to learn that :)
<vila> LarstiQ: and I use 'bzr add RightPath' rather than adding from dvc-status (which I use only as a check)
<LarstiQ> vila: ah right, I forgot you can run a shell in emacs
<vila> LarstiQ: where else can you run a shell ? (Sorry couldn't resist)
<LarstiQ> vila: :)
<vila> LarstiQ: and by the way C-H m says that 'c' in dvc-status indeed calls dvc-log-edit, if you want to go to the file your cursor is on, just hit return
<LarstiQ> vila: ah but dvc-log-edit is what I want
<LarstiQ> or think I want :)
<vila> LarstiQ: what does dvc-log-edit ?
<LarstiQ> vila: prompt me for a commit message, and then commit
<vila> oh crap, yeah, that's what I use
<vila> meh, then I C-c C-c and that commits...
<vila> LarstiQ: sorry, I thought you were seeing a different workflow
<vila> LarstiQ: ok, I understand your concern
<vila> LarstiQ: the thing is, it's wired for me: after a commit I get the *dvc-commit* buffer, check that all went well and hit one of my shortcuts to get back to my file, I didn't even realize I was doing that
<vila> LarstiQ: i.e. I don't hit 'q' in the *dvc-commit* window which is where I lost track of your experience
<LarstiQ> vila: aha!
 * LarstiQ tries that workflow
<LarstiQ> vila: hmja, at the point I commit with ^C^C the windows already swap.
 * LarstiQ tries looking at the dvc code again.
<vila> LarstiQ: yeah, they swap here too and that's not ideal, but dvc-diff (which is lost) is one the commands I use the most so it's also bound and wired ;)
<LarstiQ> right
<vila> LarstiQ: but you're right, that's worth fixing !
<LarstiQ> vila: next question, if I'm not bothering you too much, can dvc-diff show things in ediff mode (by default)?
 * LarstiQ finds the plain emacs diff mode unreadable
<vila> LarstiQ: but ediff requires two buffers for each file plus a control one.. How would that work for a whole tree ?
<LarstiQ> vila: hmm. Wonder what magit uses then
 * LarstiQ is still quite getting to grips with emacs
<vila> LarstiQ: I may be misunderstanding again, what difference are you talking about ? ediff shows diffs *inside* the lines two, is that what you're after ?
<vila> s/two/too/ I hate that tyop more than the others ;)
<LarstiQ> vila: that, and highlighting of the hunks
 * LarstiQ has figured out how to make it stop wrapping lines
<LarstiQ> although that resets on refresh, hmm
<vila> LarstiQ: what kind of highlighting ? I have some tweaks locally, so old I had to check if they were where I thought
<vila> LarstiQ: http://paste.ubuntu.com/1541850/
<vila> LarstiQ: not ediff, but readable enough for me
<LarstiQ> vila: cheers!
<lifeless> LarstiQ: I keep threatening to make one
<lifeless> LarstiQ: but there isn't a canned one, no.
<lifeless> LarstiQ: openstack uses subunit to write html directly, their converter is on hithub
<LarstiQ> lifeless: ah, I'll tell hpk about that (he was the one asking about it)
<LarstiQ> lifeless: I'm having some trouble locating that, https://github.com/openstack-infra/nose-html-output is not quite it
<lifeless> LarstiQ: https://github.com/openstack-infra/config/blob/master/modules/jenkins/files/slave_scripts/subunit2html.py
<LarstiQ> lifeless: thanks!
<lifeless> (I had to ask in #openstack-infra :P)
<Noldorin> how do i configure the commit message editor??
<Noldorin> anyone?
<bob2> what would you guess the answer to be?
<lifeless> Noldorin: there is an environment variable you can set
<lifeless> Noldorin: its in the docs
<Noldorin> lifeless, the docs also say i can use "bzr config editor=vim" to set it
<Noldorin> but that doesn't work...
<lifeless> hmm, thats since my time, I don't know anything about the new config stuff
<bob2> export VISUAL=vim
#bzr 2013-01-18
<jaimef> how can you restore a checked out repo to prestine state?
<bob2> revert
<vila> jelmer: bug #1101206 seems to be for you ;)
<ubot5> bug 1101206 in bzr (Ubuntu) "autopkgtest failed with "No module named subunit" - missing test dependency on python-subunit" [Undecided,Triaged] https://launchpad.net/bugs/1101206
<jelmer> Vila: I'm no longer involved in the packaging of bazaar, that's all Andrew S-B these days
<atc3030> anyone able to help me with this?
<atc3030> i run
<atc3030> bar branch lp:gcc-linaro
<atc3030> and it results in  a dir named gcc-linaro but only contains a .bzr dir. nothingelse
<xnox> atc3030: well $ bzr branch lp:gcc-linaro
<xnox> atc3030: try $ bzr info
<xnox> or you can try afresh: $ bzr branch -r1 lp:gcc-linaro
<xnox> and then do incremental pulls, e.g. $ bzr pull -r 25000
<atc3030> atc3030@atc3030-buildserver:~/android/prestigix/linaro_src/gcc-linaro$ bzr info
<atc3030> Standalone tree (format: 2a)
<atc3030> Location:
<atc3030>   branch root: .
<atc3030> Related branches:
<atc3030>   parent branch: http://bazaar.launchpad.net/~linaro-toolchain-dev/gcc-linaro/4.7/
<xnox> $ bzr status?
<xnox> $ bzr status
<xnox> ?
<atc3030> that just spits out about 10000000 lines of files. lol
<atc3030> nothing else
<atc3030> i can pastebin if you like
<xnox> $ bzr revert
<xnox> ?
<xnox> and then $ ls ?
<atc3030> bar revert is thinking lol
<atc3030> bzr*
<xnox> it may take a while.
<atc3030> bzr: ERROR: Corruption while decompressing repository file, zlib: Error -3 while decompressing data: incorrect data check
<mgz> atc3030: look at your ~/.bzr.log, find the initial branch operation you did, and see if it also resulted in an error
<xnox> i'd recommend to remove .bzr; remove the dir; bzr branch the first revision only (-r 1) and then do incremental pulls (-r 20000, -r 40000, etc). The repository you are trying to clone is massive.
<xnox> if you are going to have many branches, then please do create a shared repository $ bzr init-repo linaro-gcc-trees; cd linaro-gcc-trees and then branch in there.
<mgz> wouldn't be surpised if you ran out of disk or something...
<xnox> that way all branches will share the massive history and your checkout will succeed and subsequent onces will be fast.
<atc3030> grrr. why must this be so hard to understand. lol
<atc3030> I do not know what to specifically look for but the other branches i have been able to successfully sync have not had this, but the ones I'm having problems with say "24 bytes left on http socket"
<xnox> well, I used to hack on gcc bzr trees and gcc's history is huge. hence the need to use advance tricks to speed it up or make it at least work.
<atc3030> what if i don't want the entire history? i could care less about where it all came from, i just need a snapshot of it now to use it in another project.
<mgz> download the tarball.
<atc3030> that will work i guess. i was hoping to be able to automatically pull don the new changes without chasing down a new url but that will work
<mgz> a lightweight checkout might perform okay these days too.
<mgz> not over http though, you'll want a launchpad login and to give launchpad your ssh key for that.
<vila> jelmer: Oh, I didn't know (or haven't realized maybe). Thanks, I'll try to get in touch with him ;)
<mgz> vila: while you're here and I'm thinking about it, is there a bug filed for `bzr config` not liking lp: urls?
<atc3030> THank you guys. I am just gonna download the tarball
<atc3030> thank you
<mgz> atc3030: actually, that worked really well
<xnox> no problem =)
<mgz> Fri 2013-01-18 17:58:33 +0000
<mgz> 0.045  bazaar version: 2.6b2
<mgz> 0.046  bzr arguments: [u'checkout', u'--lightweight', u'lp:~linaro-toolchain-dev/gcc-linaro/4.7/']
<vila> mgz: not that I know of, but it's more a bug in the commands that interpret the urls before saving them in the config I'd say
<mgz> ...
<mgz> 92.921  Transferred: 170293kB (1839.6kB/s r:157531kB w:12761kB)
<mgz> you'll get a slower transfer, but 150MB isn't bad
<mgz> atc3030: if you're not sure how to do the launchpad-login stuff, see the help page
<vila> mgz: at least, I've known the limitation when I started using bzr and never tried to fix it ;)
<mgz> vila: as in,
<mgz> $ bzr config -d lp:bzr --scope=branch
<mgz> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/bzrlp:bzr/".
<vila> mgz: oh ! You mean *that* command doesn't resolve the url ;-D Well '-d' handling is a far simpler thing to fix ;)
<mgz> right, it looks trivial
<mgz> just wanted to know if there's a bug for it already you know about
<vila> nope
<mgz> okay, I'll file one
<atc3030> thank you mgz
<vila> mgz: thanks, I may give it a shot
<vila> jelmer: wow, pitti already fixed it ;)
<mgz> file bug 1101320
<ubot5> bug 1101320 in Bazaar "Using bzr config with --directory and --scope fails with lp: url " [Medium,Confirmed] https://launchpad.net/bugs/1101320
<mgz> pitti is a super-monster :)
<mgz> fault:
<mgz> (Pdb) urlutils.normalize_url("lp:bzr")
<mgz> 'lp:bzrlp:bzr'
<mgz> so, doing that is not the right thing
<mgz> just killing that line might be enough, but I'm not clear why it exists
<Guest5262> Hi folks - I want to get a list of all changes to a particular file over time - how do I do that?
<mnn> just a quick question: when I've uncommited some revisions, while working. How to purge these dead revisions, so they won't clutter repository?
<Guest5262> is there anyone here who actually responds to questions? is there anyone here who can respond to questions?
<Guest5262> is there a developer online now?
<Guest5262> is there any reason why #bzr should not be shut down permanently?
<xnox> mnn: $ bzr pack; $ bzr pack --clean-obsolete-packs
<xnox> Guest5262: maybe because it's friday evening and people are away from computers?!
<xnox> anyways $ bzr log -p path/to/file
<lifeless> xnox: Guest s long gone :)
 * xnox has little hope that Guest will read http://irclogs.ubuntu.com
<mnn> xnox: thanks!
#bzr 2014-01-14
<kzard> I'm having an issue running bzr in windows "key 'explorer' already registered"
<kzard> ah lol, nevermind. Had a duplocate explorer plugin folder...
<kzard> *duplicate
<mgz> that it a little mysterious of a message for that problem :)
<kzard> lol indeed
#bzr 2014-01-15
<ochosi> hi everyone
<ochosi> sorry if what follows sounds like a rant, but i'm also trying to solve a problem
<ochosi> a collegue pushed a new rev to trunk without pulling before, so everything newer than his local status got thrown together in a single "merge-commit" and history was rewritten
<ochosi> basically 2 commits incl. commit-messages were lost that way
<ochosi> so first question: how can i resolve that? can i revert those commits somehow in the remote repo?
<ochosi> 2nd question: why is it even possible for someone else to rewrite history that easily? theoretically you can destroy all commits by going to a very early revision, changing something and then pushing it (cause everything that came after will be squeezed in one merge-commit)
<Doomtron> i'm new with bzr, but from man bzr: bzr revert [FILE...]       Reverse all changes since the last commit.
<Doomtron> ochosi:
<ochosi> does that also affect the remote repo?
<mgz> ochosi: so, he didn't lose or change any history, just changed how the graph appears
<ochosi> mgz: well, the commit messages are lost, and since one commit (formerly known as rev182) fixed a specific bug, it's not very nice imo
<mgz> ochosi: you can prevent accidents like this by setting a config 'append_revisions_only' on your master branhc
<mgz> ochosi: they are not lost
<ochosi> thanks, that sounds useful
<mgz> ochosi: to see, do `bzr log -n0 REMOTE` where REMOTE is your master branch
<ochosi> can i revert that stuff somehow?
<mgz> and fixing this is easy, do
<mgz> well two options
<mgz> the non-history rewriting way is:
<mgz> `bzr branch -r-2 REMOTE fixup_mainline; cd fixup_mainline` # get the last good mainline rev before the mistake
<mgz> `bzr merge REMOTE; bzr commit -m "Merge so and so's changes with the mainline set correctly"; bzr push`
<mgz> you can also just take the last good rev, merge his base branch properly, and push --overwrite it
<mgz> ochosi: hope that helps
<ochosi> mgz: so going back to the last good commit and doing "bzr push :parent --overwrite" will do away with whatever followed?
<ochosi> (just to be sure, i dont wanna mess things up more than they already are)
<mgz> yes, but that's the big hammer method, and you don't really need it
<mgz> just flip the mainline back to the right thing
<mgz> by getting the last mainline rev you want, and merging current tip into it and pushing
<ochosi> yeah, i can grab the commit that's there (before the merge), commit it locally and then push all that
<ochosi> thanks a lot mgz
<ochosi> last question, how do i quickly set the append_revision_only setting?
<ochosi> (sorry, usually using git, so i'm a bit new to bzr...)
<mgz> ochosi: `bzr config -d REMOTE --scope=branch append_revisions_only=True` and test it by then doing `bzr uncommit REMOTE` which should complain at you
<ochosi> will do that, thanks a bunch for the super-fast and terrific support!
<ochosi> mgz: all sorted out, thanks again!
<jelmer> hey mgz :)
<mgz> jelmer! :)
<mgz> seem zygmynt's funny plan?
<mgz> *seen
<zyga> mgz: hmm?
<mgz> zyga: wondered is jelmer had seen your announcement, as it's one of the things we discussed with vila before xmas
<mgz> (python 3)
<zyga> mgz: oh, what do you think about that then?
<zyga> mgz: I haven't touched bzr since weekend but I'm slowly inclined to go through 2.7 cleanup phase were I drop the level of flake8 noise before running 2to3 en-masse
<zyga> (I had like three different attempts so far)
<mgz> I think you worded it a little strongly initially, dropping python 2 and the whole test suite sounded silly, but there's no reason to treat this as a fork rather than bzr 3 I don't think
<mgz> zyga: that does seem like a reasonable plan
<zyga> I don't intend to drop the test suite, I certainly didn't meant that :)
<mgz> right, you did clarify that :)
<zyga> I meant that if I get to write new code I won't really go to that level of testing as bzr has now, because it's going to take even more time and I want to see if this idea can work or not faster than that
<zyga> I do intend to keep the test suite :)
<zyga> that would be pretty nutty to remove it
<zyga> mgz: so what were your ideas for python3?
<mgz> just slog through it, and don't try to maintain compat after a major release
<zyga> 2.x compat?
<mgz> there are old major releases for python 2 support
<zyga> yeah, I think thats reasonable, python3 was around for a long time now
<zyga> and it's far easier to remove various fallbacks and maybe, just maybe, use newer features
<zyga> one thing I was thinking about later was launchpad
<zyga> but since I explicitly forked launchpad can stayon bzr forever
<zyga> I don't even imagine how big launchpad porting effort would be
<rozzin> zyga: sorry, what about launchpad?
<zyga> rozzin: if bzr trunk and subsequent releases moved to 3.x, dropping 2.x support, lauchpad would be locked out
<rozzin> zyga: Ah. You meant "bzr" as opposed to "bzr3".
<jelmer> mgz: yeah, I did see the announcement!
<zyga> rozzin: yeah
<zyga> rozzin: looking at to what mgz mentioned, if bzr itself moved to python3
<jelmer> mgz, zyga: I think dropping support for older formats is a good idea
<jelmer> not really convinced of the usefulness of porting to python3 at this point
<zyga> jelmer: right, since they are obsolete and 2.6 can convert all the way to 2a
<zyga> jelmer: it's for fun really, there's is some usefulness but more for what I need
<jelmer> zyga: ah, fair enough
<zyga> looking at the code I think it's also reasonable to drop some transports
<zyga> bzr really needs, local, http and ssh
<jelmer> zyga: it really depends on what your eventual goal is
<zyga> the rest are probably dead as users anyway
<zyga> jelmer: not sure yet, I have a pipe dream of git format as native bzr format
<zyga> jelmer: immediate goal is bzrlib in python3 for my scripts / tools
<jelmer> zyga: If you're aiming for this to be a long-term project rather than an incidental hobby project, then I have other reservations too (-:
<zyga> jelmer: shoot :)
<zyga> jelmer: you never know
<jelmer> zyga: since moving it to a separate launchpad project (and dropping python2.x) would effectively split the already small community
<zyga> jelmer: I see what you mean, I'm not saying no, right now there is no community for bzr3 that isn't the existing bzr community, if this works out I'll rethink how to continue, now I need to find a moment to work on the code
<jelmer> zyga: fair enough
<rozzin> jelmer: It seems like moving to python3 may be useful as a sort of social signal, even if that's all it is: people look at bzr/python2 and think "the project isn't even being kept up to date with the current Python", which supports "bzr is a dying/dead project".
<LeoNerd> jelmer: Ah, hi there ;) LTNS
#bzr 2014-01-16
<rindolf> Hi all. How can I remove old and no-longer-needed data from .bzr? Something like "git clean -dxf" or "svn cleanup".
<zyga> rindolf: what do you mean?
<zyga> rindolf: ignored files that you don't add to the repository?
<zyga> rindolf: bzr clean-tree --help; maybe?
<rindolf> zyga: no, the junk/cruft inside the ".bzr"/dot-bzr.
<zyga> ah
<zyga> bzr pack --clean-obsolete-packs ; should do it
<rindolf> Thanks!
<rindolf> zyga: thanks, let me try.
<rindolf> zyga: OK, I did it and it was time consuming and .bzr is still 296M whereas the working copy directories are 150M.
<zyga> rindolf: well, bzr keeps all history so it's well expected that the history folder (.bzr) is larger than the working copy
<rindolf> zyga: but that's not the case for it in .git.
<zyga> rindolf: there is no other cruft to remove I'm afraid, bzr keeps the history and a few indices to find the data
<zyga> rindolf: it is
<zyga> rindolf: git keeps the history just as bzr
<rindolf> zyga: at least not usually.
<zyga> rindolf: I don't believe you are correct, unless you do "shallow" clones that ignore all the history apart from the few most recent changes
<zyga> rindolf: bzr can do that too
<zyga> rindolf: you can create a lightweight checkout of an existing branch that will *not* keep the history locally
<zyga> rindolf: depending on how you work that might be useful to you
<rindolf> zyga: OK.
<LeoNerd> Since the current state is inferred from the history that got us here, information theory states that the history is necessarily at least as large as the state itself
<zyga> rindolf: you can do a lightweight checkout with bzr checkout --lightweight URL
 * zyga thinks that sliding history window would be a nice backup feature if bzr scaled well for large binary files
<rindolf> LeoNerd: I think git compresses the history though.
<zyga> anyway, back to work
<zyga> rindolf: bzr does as well
<zyga> rindolf: you might be using an older format that has less efficient compression, you can run bzr upgrade --2a; to get the latest format; then re-do the pack command as above
<zyga> rindolf: if you had started with an older repository format this will usually save some space
<rindolf> zyga: thanks.
<rindolf> zyga: Â«The branch format Meta directory format 1 is already at the most recent format.Â»
<zyga> rindolf: then that's the best bzr can do for you now
<rindolf> zyga: OK, thanks.
<fullermd> git gc does gc unref'd revs, which bzr pack doesn't.  Usually not a huge difference, but special cases can make it bigger.
<fullermd> ('course, git clean _is_ straight analogous to bzr clean-tree; it's a WT operation, not a history one)
<zyga> fullermd: is there are way to 'git gc' in bzr from the command line?
<fullermd> The part that does repacking/recompressing/whatnot, sure, that's what bzr pack does.  The part that gc's stuff, no.
<achiang> hello, i have 2 separate trees: call them 'code' and 'tests'. i'd like to merge tests => code and have both code and tests in a single branch
<achiang> is there a way to do this while preserving the history of 'tests'
<achiang> is it as simple as a bzr merge?
<achiang> hm, no.
<achiang> maybe it's bzr join ?
<achiang> http://stackoverflow.com/questions/9849466/how-to-combine-repositories-into-a-single-one-in-bazaar
<jelmer> achiang: yep, bzr join sounds like what you are looking for
<achiang> i can't figure out the join syntax though, even after looking at the help
<achiang> https://answers.launchpad.net/bzr/+question/71563
<achiang> if i have modern bzr (post 12.04), do i need to do anything specific to get rich-root?
<achiang> uh, i have branch format 7, whatever that means
<achiang> oh, ok. and repository format 2a
<achiang> hopefully that's good enough to try join
<achiang> jelmer: any clues?
<fullermd> Plenty.  Rich root worries are mostly a pre-2.0 thing.  To use join you'd just stick one branch under another and then run the command on it.
<fullermd> And then commit it, of course.  Join is really just a bit of sugar around merge.
<jelmer> what fullermd says :)
<achiang> hm. ok
<fullermd> Well, in that case, fullermd also gets a 20 foot high pile of gold coins delivered to his front door today   ;p
<achiang> confused... :-/ http://pastebin.ubuntu.com/6764485/
<achiang> fullermd: any ideas what i did wrong above?
<SamB> zyga: often, git *does* manage to scrunch histories up enough to take less space than the working tree.  (This is obviously easier on projects with shorter histories.)
<fullermd> Do those branches have any shared history?
<achiang> fullermd: they really shouldn't
<achiang> fullermd: no, they do not have any shared history
<fullermd> Well, that says they have the same root id.  Which I guess without shared history means they're old enough to have come from pre-rich-root branches, which all have the same root.
<fullermd> So I guess your best bet is to just use merge, then mv all the files into a subdir.
<achiang> i tried that and got a different error
<fullermd> At one time there was a plugin called merge-into or something that would automate it, but I think it was abandoned when join came around, so I doubt it still works.
<fullermd> IWBNI merge had an arg that could do that...   I think a unicorn is scheduled to deliver it next week.
<achiang> oh wait
<achiang> i screwed up my cp -a before
<achiang> let me try again with fresh branches
<achiang> i bet it will work
<fullermd> You can just use 'branch' instead of cp to do it.
<fullermd> e.g., (cd trunk ; bzr branch ../tests)
<achiang> ok, will try that
<achiang> fullermd: ok, it works much better when you do not overwrite .bzr/ in the containing tree ;)
<fullermd> Oh, yes, that might have bad side effects.
<achiang> thanks
<zyga> SamB: this is true of bzr as well, both use compression
<achiang> i have a local branch that takes a long time to pull. i'd like to update this branch with the contents of another test branch that's been pushed up to LP (but not merged into trunk yet).
<achiang> is there a way to do so without introducing an actual merge in my local branch?
<achiang> maybe it's bzr merge --pull
<achiang> yay, that did it
#bzr 2014-01-17
<RyanMcCoskrie> Are there any Mageia users here? I can't clone a remote repo on that distro.
#bzr 2014-01-19
<rozzin> fullermd: apparently bzr-colo includes a "colo-clean" command that does GC.
<fullermd> Interesting.  Only applies to colo setups.  A little testing doesn't seem to clear up much though.
<fullermd> Maybe it's removing revs but not texts?
<lifeless> fullermd: or maybe compressed data is compressed
<rozzin> The logic is the _clean() function in commands.py.
<lifeless> fullermd: make sure you're excluding obsolete but not deleted packs
<fullermd> I only looked in packs/
<lifeless> k
<fullermd> Specifically, I created a fresh workspace, committed a 20 meg .mp3, then uncommitted that rev.  I had to make an empty --unchanged rev before colo-clean would do anything, but after it did it cleared up about 100 bytes from the packfile.
<rozzin> I do notice that "bzr heads --dead" no longer lists any dead heads after I run "bzr colo-clean".
<fullermd> Which seems reasonably for getting rid of the commit, but either left the text or bzr's compression has gotten *really* bad at compressing nothing.
<rozzin> Trying to repack a repository with zero commits in it?
<rozzin> I'm guessing that's a no-op?
<rozzin> Though I guess it might at least move .bzr/repository/packs/* into .bzr/repository/obsolete_packs.
<rozzin> er, .bzr/branches/.bzr/repository/... in the case of a colo-ify'd workspace....
<rozzin> Oh, no--it's that colo-clean on a workspace with no commits is a no-op.
<rozzin> "No cleaning necessary."
<rozzin> Mm. OK, colo-clean is a no-op _because_ pack() is a no-op.
<lifeless> bzr pack should delete unreferenced texts
<lifeless> ,,,
<lifeless> mmm I think
<lifeless> certainly clone will
<rozzin> having pack do gc sounds dangerous to me.
<rozzin> fullermd: Now I see what you mean. Even with a non-empty set of commits, colo-clean isn't freeing up the space used by my 94-MB file-that-no-longer-exists-in-any-commits, either.
#bzr 2015-01-14
<sparkiegeek> hi, I just got a scary traceback from bzr when trying to shelve some changes. First attempt was a selective shelve, but can reproduce it with a blanket shelve:
<sparkiegeek> http://paste.ubuntu.com/9745307/
<sparkiegeek> can anyone offer some insight/help?
<sparkiegeek> (I have previously bzr shelve'd just fine on this branch)
<fullermd> Seems like I've heard of such things when there are directories being shelved...
<fullermd> Maybe I'm thinking of something else.
<sparkiegeek> hmm, that would make sense, I did attempt to do that
<fullermd> Mmm.  In a simple test here, the problem I'm thinking of is actually blowup on unshelve, not shelve.
<fullermd> What's stat say before you try that?
<sparkiegeek> http://paste.ubuntu.com/9745431/
<sparkiegeek> (names changed to protect the innocent)
<sparkiegeek> patch_302 is the directory that I attempted to shelve (along with the files therein, and other related changes in other files)
<fullermd> Mmm.  Does it fail if you try shelving only the patch_302?
<sparkiegeek> fullermd: it does, with a slightly different error: http://paste.ubuntu.com/9745514/
 * sparkiegeek tries shelving just the files in the directory
<sparkiegeek> eek
<sparkiegeek> so I tried the shelve, just selecting the files, then rm'd and bzr rm'd the directory. THen tried to unshelve
<sparkiegeek> http://paste.ubuntu.com/9745550/
<fullermd> OK, yeah, well that first at least is expected; you're trying to shelve the dir, but not the files in it.  It should fail with a better message, but at least failure is expected.
<fullermd> The second, also, trying to unshelve files into a dir it no longer knows about, bad juju.
<fullermd> All seem not really related to your initial...
<sparkiegeek> so if I were to "unwind" my actions properly by doing something like: bzr shelve $FILES; bzr rm $DIR; rm -f $DIR; <stuff>; mkdir $DIR; bzr add $DIR; bzr unshelve
<sparkiegeek> would you expect that to work?
<fullermd> I'd tend to think not, since that second add would be a different dir from bzr's perspective (independent add == different file-id)...
<sparkiegeek> ok
<fullermd> I can't reproduce your initial.  I note that it sorts differently than those names actually do, so your real file/dir names are in a different order than those standins.
<fullermd> Which could be significant; there have been occasional ordering-dependant issues in these sort of things.
<sparkiegeek> oh, I was just bad at censoring and retaining information
<sparkiegeek> the stat output is ordered as I expect (alphabetically, within the added: and modified: groups)
 * fullermd nods.
<fullermd> Which suggests it could be something ordering dependant.
<fullermd> (which I don't reproduce here, since I get ordering consistent with those censored names)
<fullermd> Try putting together a simple test case with standin files, ordered as yours are; if we can reproduce it easily, it's probably fixable.
<sparkiegeek> ok, will try to do so
<fullermd> I can't do any more experimenting with it right now, sorry.  I need to get to sleep, the sun's about to come up   8-}
<sparkiegeek> :)
<sparkiegeek> fullermd: thanks for your help
<mark06> hi all, I need your support on this https://lists.archlinux.org/pipermail/pacman-dev/2015-January/019798.html
<mark06> tldr: no artificial check is needed to know that branch x is not a clone of y, because when we bzr pull from y into x, it would fail _anyway_, is this true?
<fullermd> If x is not a strict subset of y, then "cd x ; bzr pull y" will fail without changing anything, yes.
<fullermd> I'm not sure whether "clone" is important to the case; clone is more a mechanism of "how we got x", whereas pull will succeed fail based on "what x currently has".
<fullermd> It wouldn't help in the case that you really want to check "y is where x came from".
<fullermd> So if you're trying to guard against the case "x is really supposed to be tracking z, but currently is coincidentally a subset of y, but we really don't want to pull y over it", just doing a pull will put you in a bind.
<mark06> not sure if I understand you but "is a clone" means it's "the same" repository, but missing updates, then we update with bzr pull
<mark06> here is the origin of the problem https://projects.archlinux.org/pacman.git/commit/?id=c926c39
<mark06> then later bzr support was added by simply copying that kind of code
<mark06> how about the following problem: we branch A from web into local dir B, we later want to update B from A but for some reason bzr pull will fetch from X instead of B
<mark06> it happens to be that X is a fork of A and contains all commits of B
<mark06> result: bzr pull will succeed, but we wanted to pull from A not X, how to fix this?
<mark06> they intend to fix this with artificial, buggy checks to know whether "B is a branch of X/A"
<fullermd> I don't see how you can, programmatically.  That's a social question, and it's all kinds of fuzzy.
<fullermd> Comparing URL's gets you somewhere.  Normalizing and comparing gets you further.
<fullermd> But there can totally be multiple paths that wind up the same place.  The server can have multiple names.  There can be http vs bzr+ssh vs sftp access.  There can be multiple socially-identical mirrors in play.  And on and on...
<fullermd> Comparing normalized URL's would catch a lot of the simple cases, and maybe that's good enough for the use-case in question.  But it's always gonna just be a guess.
#bzr 2015-01-15
<mark06> https://bugs.archlinux.org/task/43448
#bzr 2015-01-16
<queso> How do I cherry pick?
<queso> Oh I think I figured it out.
<queso> Is there a way to make bazaar commands always have the effect of piping to less?
#bzr 2018-01-16
<jelmer> gour: hi
<jelmer> gour: what version of breezy/bzr-git are you using?
<gour> jelmer: morning. i've installed breezy via pip (no fedora package yet) and pulled bzr-git from the trunk
<jelmer> gour: please use breezy from trunk if you're using brz-git from trunk as well
<gour> jelmer: can i install trunk via pip?
<gour> (i know i can for git repos=
<jelmer> gour: possibly, I don't have much experience with pip
<gour> ok
<gour> let me try...
<jelmer> gour: supposedly "pip install bzr+lp:brz"
<jelmer> but I haven't tried
<gour> jelmer: ok, installed. now i'll try again with -Derror
<gour> jelmer: same thing happened - see https://paste.fedoraproject.org/paste/3FKeHUdvZW6bTX6H6PVC2A
#bzr 2018-01-17
<jelmer> hi gour
<gour> jell jelmer
<gour> *hello
<jelmer> Gour: just replied to your bug
<gour> jelmer: me too ;)
<gour> it seems that loggerhead is not very actively developed. should one be worried i nregardto brz & publishing repos on private servers?
<gour> jelmer: now i did re-run fast-import process and, indeed, /tmp was left with no space, but i wonder how is it that fast-import does consume 7.9G of space to import git repo of 20M?
<mgz> gour: probably not super worried, though loggerhead isn't great
<gour> mgz: what is recommended instead?
<mgz> there isn't, which is part of the point
<mgz> have looked at making very minimal read-only views sometimes, but it's just quite a lot of work to make a vcs web client thingy
<gour> ok
<gour> btw, what is correct scheme for fetching git repos from github with bzr-git?
<gour> (via ssh)
<gour> i get: brz: ERROR: No module named git.mapping when using something like: brz branch git://git@github.com:restic/restic.git
<mgz> have you got dulwich installed?
<gour> yes, dulwuch is installed
<gour> *dulwich
<jelmer> gour: for breezy there is lp:~jelmer/loggerhead/breezy
<jelmer> gour: but please note that all of these are still very much in flux at the moment, so expect things to be broken
<jelmer> gour: can you file a bug for the bn
<jelmer> Brz-git issue?
<gour> jelmer: i did install breezy via pip...
<jelmer> gour: that probably explains it
<gour> jelmer: should i still submit ticket?
<gour> the point is that bzr/brz brings some nice stuff in comparison with fossil - support for git format and proper pre/post hooks. it also does have simple model and great ui...hg, is, imho, plagued with the need for too many extensions and, git is, well, git
<gour> jelmer: what about fast-import using so much space?
<vila> gour: do you need fast-import vs git clone + bzr git ?
<gour> vila: i'd like to try both
<vila> gour: right. If one fails, try the other :-)
<vila> AFAIK fast-import is not maintained so I would bet less on it than on brz-git
<gour> ok, but bzr-git does not work as well considering my pip-based install. otoh, i wonder if there is some performance/feature-penalty using git format instead of the native one?
#bzr 2018-01-18
<gour> jelmer: ping
<gour> jelmer: now is see the proble, original fossil repo has size of 418M, but it achieves extreme compression-ratio of 1612.1 and the artifact-sizes from its 'dbstat' cmd shows: 8,935,093,232 total, so when i do fast-export from fossil to git, the exported size is 8.4G which, indeed, exceeds the size of the tmpfs...it seems i've picked the wrong repo for testing purposes :-)
<gour> will try now with something smaller, iow. with less compression-ration
<gour> now, with a smaller repo, i get another error: https://paste.fedoraproject.org/paste/E~5mj4bg71qo-UE5WokA5w
<jelmer> gour: is that from pip or trunk?
<jelmer> Pip is many months old at this point
<gour> jelmer: pip
<gour> what would be the most clean way to install from the trunk, or maybe i should do pip-install from the trunk
<jelmer> just 'bzr branch lp:brz; cd brz; ./setup.py install'
<gour> maybe it's from the trunk (installed with: pip2.7 install --user bzr+lp:brz), version shows: breezy (3.0.0.dev1), so how can i know?
<jelmer> I don't think it provides a good way to know if you install from pip
<gour> correct. install from the trunk shows same version...let me try the same experiment...
<gour> jelmer: same as before - see: https://paste.fedoraproject.org/paste/FacFQCy8mADdLbDiVI46ig
<Walex> oh well very happy that Breezy is a thing...
<Walex> I am compiling a table of "features" of various VCSes, and I am wondering: in the repo format "2a" how many files there are in the store? One per commit like 'git'? One per tracked files like in Mercurial? One per repo like in monotone?
<Peng> It's similar to storage using Git's pack files.
<Peng> Recent revisions will be in a pack file plus 4 index files. Older revisions will have been autocompressed into larger and larger files.
<Peng> So maybe a few dozen files, plus small metadata files.
<Peng> But it probably varies depending on repository usage patterns.
<Walex> Peng: many thanks, so it is basically per-commit, plus packing. to consolidate many commits in  a single file.
<Walex> BTW the reason why I ask is that one of the crucial features of a VCS is the storage structure. For example Mercurial creates two file per every file that ever existed in the working directory, so large projects end up with a colossal number of files, even workse than Subversion...
<Walex> BTW as a suggestion now that Canonical seems to be no longer sponsoring Bazaar, Breezy could become "GNU Breezy", which would help.
<Peng> Bazaar's storage has been pretty good for like ten years. ;-)
<Peng> Dunno what them other VCSes been up to. :D :D
<Walex> Peng: :-)
<Walex> Yes, but format 2a should have been publicized more widely
<Walex> I remember reading the blog post with the speed tests on the OpenOffice.org repo and they are quite good
<Peng> It's not exactly per revision. It's per thing-that-happened. If you pull 10 revisions, they'll be stuffed in one pack, it won't generate 10 packs simultaneously.
<Walex> Peng: ah yes, I might have veen using "revision" loosely. per commit?
<Peng> same thing
<Walex> Peng: but it is pretty good indeed, possibly better than the 'git' object store, which really really needs to be repacked...
<Walex> BTW sadly the killer feature is the ability to se the '.git' object store directly. That's amazing killer feature.
<Walex> I have watched Martin Packman's video and his point that 'bzr' has a user interface for people *and* can use '.git' (and has a competitive native format) is quite strong.
<Peng> This is kind of only of historical interest, but Bazaar went through a number of different storage formats, starting off with what might not have been very good, and ending with a good format. Git and Mercurial kind of started with pretty-good formats and have been loath to change them.
<Walex> BTW the /topic should really really be in the /topic and so J Elmer's blog post.
<Walex> Peng: I am an old timer (I started with SCCS, used it extensively) and I have followed Bazaar since the very first days. And ther others.
<Walex> BTW the video URL should really really be in the /topic and so J Elmer's blog post.
<Walex> Peng: I sould strongly dispute that the Mercurial storage format is good.
<Walex> Peng: that's a developer's point of view, for small repos. I am nowadays mostly a sysadmin and lots and lots and lots of small files are a very big problem.
<Peng> Heh. D:
<Walex> Peng: things like that are for example very, very slow to 'fsck'.
<Walex> Peng: hosting a Subversion repo, with one storage file per original file is already a pain, hosting Subversion checkouts is even worse, hosting Mercurial is horrifying.
<Walex> Developers never have to fsck or backup or index their repos and checkouts.
<Walex> Ahhhh I have another secondary question...
<Walex> a bit of too detailed perhaps...
<Walex> still on storage.
<Walex> so, a point made by the developer of 'monotone' who has switched to 'git' but who thinks that Mercurial is better, is that multiple 'monotone' checkouts can share the same storage directory '.mtn', while with 'git' the 'git' directory must be copied per checkout. What's the current story woh the '2a' format as to that.
<Peng> Bazaar supports shared repositories.
<Walex> Peng: except when they are 'git' one I guess...
<Peng> you do "bzr init-repo" in a directory, and any Bazaar branches in child directories will put their stuff in that repository, instead of maintaining their own repositories.
<Peng> It works well with Bazaar's branch-per-directory model.
 * Walex was thoroughly amazed when I could just go 'bzr log' in a 'git' cloned repo.
<Walex> Peng: yes, I had hoped so.
<Walex> BTW my very drafty draft blog post on VCSes and Breezy: http://localhost/blog/drafts2.html?180106#180106
<Walex> and my very old table of comparison that I am slowly updating: http://localhost/blog/drafts2.html?110817#110817
<Walex> very drafty draft too.
<Walex> Ah other question for my table -- how "bad" is 'bzr'/'brz' for large binary files? I guess same as 'git'...
<Walex> there is no mention of Breezy on Wikipedia yet
#bzr 2018-01-21
<marioxcc> Hello.
<marioxcc> Can I have multiple branches with a single working tree, as in Mercurial or Git?
