#bzr 2007-10-29
<spiv> igc: ping
<igc> hi spiv
<spiv> igc: I've just made a tarball for 0.92rc1
<igc> hooray
<spiv> igc: I don't have write access to escudero though... do you?  I know you've been RM in the past.
<spiv> igc: I've put it at http://people.ubuntu.com/~andrew/bzr-0.92rc1.tar.gz for now
<igc> yes
<spiv> (and there's a .sig as well)
<igc> I'll move it across
<spiv> igc: thanks!
<igc> np
<igc> few minutes ...
<igc> spiv: I have the files on esceduro now but not in the right directory :-( Permissions issue ...
<igc> Let me ping a few people
<spiv> igc: Ok.
<spiv> igc: if necessary I can just have the annoucement and download page point at people.ubuntu.com/~andrew/.  That's not great, but at least the tarball is GPG-signed so people will know that I'm definitely the guy to blame ;)
* spiv changed the topic of #bzr to: The Bazaar Version Control System | http://bazaar-vcs.org/ | Bazaar 0.92rc1 is out - http://bazaar-vcs.org/Download | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d
 * spiv -> lunch
<poolie> hello
<poolie> igc, spiv, thanks for making the release
<poolie> have a good trip when you leave
<igc> hey poolie
<poolie> things are going spiffingly here
<igc> how was your trip?
<igc> excelent
<poolie> pretty good
<poolie> i'm about to fall asleey
<poolie> asleep
<igc> sleep well
<poolie> thanks; and say thanks/well done to spiv too
 * igc food
<Peng> I know I should just RTF mailing list, but what was the most recent pack format change? Just the name?
<frogduster> The packages for bazaar are listed in ubuntu's repositories with the following warning:
<frogduster>  Unless you have a pressing reason to use bazaar you should use some other revision control system as upstream development has ceased.
<frogduster> ..this is incorrect, right?
<spiv> frogduster: the "bazaar" packages are for the old TLA-derived revision control system.  The current tool called "Bazaar" is packaged as "bzr".
<spiv> It sounds like the package description for the "bazaar" package should probably say something about the "bzr" package, which is what people are probably looking for when they find the "bazaar" package.
<frogduster> Ah.  Thank you.  :-)  If the old 'bazaar' is rarely used, it might be wise to put a disclaimer in the description for the package "bazaar" that states that it is not to be confused with the currently-developed package manager packaged as "bzr".
<frogduster> *nod*
<frogduster> Hehe.
<frogduster> Thanks for the info.
<frogduster> Should I file a bug report / wishlist item on launchpad?
<spiv> frogduster: I think so.
<spiv> frogduster: assuming it hasn't already been filed :)
<frogduster> *nod* will do.
<frogduster> :-)  natch.
<spiv> frogduster: https://bugs.edge.launchpad.net/ubuntu/+source/bazaar/+bug/143998 looks to be related
<ubotu> Launchpad bug 143998 in bazaar "rename 'bazaar' package to 'baz'" [Low,New]
<frogduster> ah.
<frogduster> You beat me to the search.. :-)  But, that's not too bad, as my system is bogged down right now, and firefox is a bit much on top of what it's already doing..
<frogduster> Nudged the existing bugreport.  :-)
<frogduster> Thanks, spiv.  :-)
<dewd__> let it be known that I just tested the new pack support of 0.92rc1 and at least for me it didn't work as well as the old one in my working environment. I hit one "lock" error during a bzr+ssh push (which can be part of multiple simultaneous requests)
<dewd__> anyway, I'e decided for now to continue to use the old format as it seems to be a little more fool proof with regards to locking in my environment.
<AfC> dewd__: if you've got time, you should send that as an email to the bazaar mailing list
<dewd__> it would be more helpful i know. but I have just reverted it back because i was testing it in "production" with a bunch of repos, not one or two.
<dewd__> so i can't even test/debug it
<AfC> Sure
<igc> night all
<mathrick> hiya
<mathrick> why does bzr.dev identify as 0.90.0?
<mathrick> it breaks my newest and greatest bzr-svn
<mathrick> ooh
<mathrick> bzrlib: /usr/lib/python2.5/site-packages/bzrlib
<mathrick> I guess that's why
<mathrick> how do I make it not use the systemwide bzrlib without uninstalling bzr?
<mathrick> (the packaged one I mean)
<Kinnison> futzing with python's module path is about all I can suggest
<fullermd> I've never had that confusion happen, and I use bzr.dev all the time on my workstation...
<mathrick> I tweaked PYTHONPATH and it appears to work
<mathrick> hmm, now it doesn't
<mathrick> bzr bzr-pokerolymp2:2101/> missing --other
<mathrick> Using last location: svn+https://beta.aimido.de/svn/src2/trunk
<mathrick> Unhandled error:
<mathrick> character mapping must return integer, None or unicode
<mathrick> humm
<mathrick> I hacked PYTHONPATH into ~/bin/bzr.dev/:$DEFAULTPATH
<mathrick> hmm, it seems it's bzr-svn that's dying
<mathrick> jelmer: poke?
<mathrick> or anyone else, any ideas what might be breaking it?
<mathrick> argh, bummer
<mathrick> I need bzr-svn working
<jelmer> mathrick: pong
<jelmer> mathrick: can you set BZR_PDB=1 and try again?
<mathrick> yes
<mathrick> I just need to switch to 0.92 again
<mathrick> jelmer: hmm, I merged that branch with upstream using r716 in the meantime, and it doesn't seem to die anymore
<mathrick> but I've got other fun
<mathrick> jelmer: http://pastebin.org/6321
<jelmer> can you print the contents of elements and existing_elements ?
<mathrick> (Pdb) p elements
<mathrick> ['mathrick', 'pokersource']
<mathrick> (Pdb) p existing_elements
<mathrick> []
<mathrick> (Pdb)
<mathrick> jelmer: there
<jelmer> hmm, but that path (/mathrick/pokersouirce) exists in the repository ?
<mathrick> jelmer: no, mathrick/ does
<mathrick> I believe
<mathrick> uh-huh
<mathrick> nope
<mathrick> I wonder why, I created it before
<jelmer> at least /mathrick will have to exist
<jelmer> the error should probably be a bit clearer...
<mathrick> indeed
<mathrick> jelmer: btw, with 716 it was uploading a lot, and then at the end died with "at least one property change failed, repository unchanged" from subversion
<mathrick> r716 I mean
<mathrick> now it did with r761 as well
<mathrick> jelmer: http://pastebin.org/6322
<jelmer> mathrick: can you run with -Dcommit and try again?
<jelmer> that should print any revision properties set to ~/.bzr.log
<mathrick> jelmer: that goes as a bzr argument?
<jelmer> yes
<mathrick> jelmer: http://pastebin.org/6323
<jelmer> ahh
<jelmer> in ~/.bazaar/subversion.conf, please look for list-QlpoOTFBWSZTWZkHsqUAAAhRgAAQABC6yR4AIAAxTAAAlRkDRtJDWcJGukaEIjw7FScqiDvxdyRThQkJkHsqUA== and change the two '=' at the end into '-'
<mathrick> oookay
<jelmer> if that doesn't help, can you please mail me the bit you just pastebinned ? pastebin seems to have a X-character limit
<mathrick> jelmer: TypeError: Incorrect padding
<mathrick> list-QlpoOTFBWSZTWZkHsqUAAAhRgAAQABC6yR4AIAAxTAAAlRkDRtJDWcJGukaEIjw7FScqiDvxdyRThQkJkHsqUA--
<mathrick> that's what it should look like?
<jelmer> whoops, that should be two dots at the end
<jelmer> sorry
<mathrick> jelmer: still the same with ..
<jelmer> can you set BZR_PDB=1 again and see where it's breaking?
<mathrick> **** entering debugger
<mathrick> > /home/mathrick/Dev/rails/bzr-pokerolymp2/base64.py(76)b64decode()
<jelmer> and "bt"?
<mathrick> http://pastebin.org/6326
<jelmer> are you sure you're running r761?
<jelmer> the source for scheme.py:133 is different here
<mathrick> lemme confirm
<mathrick> jelmer: it seems that bzr revert on a lightweight checkout will confuse bzr
<mathrick> gotta report that
<mathrick> now I've got that mapping thing again
<jelmer> mathrick: but you were actually running a different version?
<jelmer> mathrick: which mapping thing?
<mathrick> jelmer: http://pastebin.org/6329
<mathrick> jelmer: yeah, it *said* 761, but was running 716 still I guess
<jelmer> see /query
<lifeless> moin
<jelmer> hey lifeless
<jelmer> how's the UDS?
<ubotu> New bug: #158306 in bzr "Reverting a lightweight checkout confuses bzr about revision number" [Undecided,New] https://launchpad.net/bugs/158306
<lifeless> good
<lifeless> jerry is playing with packs
<mathrick> ^-- lightweight checkouts have very unclear idea of their own status
<lifeless> well, revert does not change revno
<mathrick> but you can't change revno on a lightweight checkout otherwise
<mathrick> since it doesn't have its own identity
<fullermd> Well, that's what update -r is for.  Or would be, if it existed.
<lifeless> mathrick: well, it does have it's own identity
<mathrick> lifeless: but tries very hard to hide it :)
<lifeless> revert does not change it, and is not intended to change it; as fullermd says update is the command that would be suitable for changing it
<lifeless> mathrick: uhm, not really ;)
<jelmer> lifeless: Nice :-)
<fullermd> I wish heavyweight checkouts tried harder to hide it...
<mathrick> lifeless: try rebinding a lightweight checkout for which the parent branch is inaccessible
<mathrick> it's not possible
<mathrick> it's not possible at all by default
<mathrick> but the plugin to do that fails with inaccessible parents
<lifeless> mathrick: 'bind' only applies to heavyweight checkouts; I think 'switch' is the right ui for it, but its not done yet
<lifeless> mathrick: well you have found a bug then :)
<mathrick> yeah, switch was what I was thinking about
<mathrick> I know :)
<mathrick> I thought it's been reported already
<mathrick> *think
<mathrick> jelmer: anyway, ping me when there's hot new svn love waiting for me to update :)
<jelmer> mathrick: The unicode bug should be fixed already
<jelmer> now looking into the missing prefix error
<mathrick> jelmer: ah, fine, lemme try that
<mathrick> jelmer: where do I change the branching scheme again?
<mathrick> (it doesn't think that mathrick/pokersource/ is a valid branch path)
<jelmer> mathrick: just remove ~/.bazaar/subversion.conf
<mathrick> jelmer: oh, it doesn't need the branch specs anymore?
<mathrick> crap
<jelmer> it does, but will create it again
<mathrick> I deleted bazaar.conf instead
<fullermd> Just goes to show you why you should keep ~/.bazaar in bzr   ;)
<mathrick> mathrick@hatsumi:~/Dev/rails/bzr-pokerolymp2$ BZR_PDB=1 bzr -Dcommit svn-push svn+https://beta.aimido.de/svn/src2/mathrick/pokersource/
<mathrick> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<mathrick> gah
<mathrick> jelmer: is that related to me having just deleted bazaar.conf?
<jelmer> mathrick, no, it's shouldn't be
<jelmer> mathrick, You created just mathrick?
<mathrick> yeah
<mathrick> hmm
<mathrick> but somehow pokersource/ popped up there
<mathrick> jelmer: see priv
<jelmer> mathrick: can you still reproduce bug 145171 or is that what we're looking at right now?
<ubotu> Launchpad bug 145171 in bzr-svn "Invariant break on bzr missing in bzr-svn" [Medium,Incomplete] https://launchpad.net/bugs/145171
<mathrick> jelmer: unsure, I looked at it earlier today, but I decided I can't determine if it still happens
<mathrick> it doesn't look the same
<jelmer> but you were trying to do the same thing there?
<mathrick> jelmer: no, I was trying to push to a new branch
<mathrick> jelmer: oh, you might want to know that I have a merged-into subtree in that repo
<jelmer> in the bzr repo?
<jelmer> that you're trying to push?
<mathrick> jelmer: yes
<jelmer> mathrick: also in the particular branch you're pushing?
<mathrick> jelmer: umm, unsure what you mean now
<jelmer> the pokersource branch you're trying to push, does that include a revision with subtrees?
<mathrick> the repo is plain SVN, so it doesn't have merged subbranches of course. My branch is derived from that SVN repo trunk, AND merges-into a subbranch, now I want to push the whole thing under branches/mathrick/pokersource/
<lifeless> jelmer: what will it take to get rid of bzr svn-push ?
<jelmer> lifeless: bug 121875
<ubotu> Launchpad bug 121875 in bzr "cmd_push() should abstract away transport.mkdir()" [Wishlist,New] https://launchpad.net/bugs/121875
<jelmer> lifeless: svn-push is basically a wrapper around the BzrDir.import_branch(path, source_branch) function
<lifeless> jelmer: so send a patch :)
<jelmer> lifeless: lots of other things I have to do first, I'm afraid :-/
<lifeless> jelmer: it does seem very likely to trip people up; and I don't understand why you don't just decoate the existing push command in bzr-svn as a firststep
<jelmer> lifeless: I'm focussing on fixing some of the functionality bugs in push that have come up for now
<mrevell> Hi - does anyone have a moment to answer a question about "bzr status"?
<lifeless> jelmer: fair enough
<LeoNerd> Just ask your question; don't ask to ask
<lifeless> mrevell: don't ask to ask, just ask.
 * lifeless high fives LeoNerd 
<mrevell> fair enough :)
<fullermd> Asking to ask asks for axeing.
<mrevell> I want to know what the Subversion-style status flags are but can't find a definitive list for Bazaar
<mrevell> can anyone point me in the direction of definitions?
<lifeless> bzr help st
<lifeless> ...
<lifeless> See also: diff, revert, status-flags
<mrevell> lifeless: Thanks, managed to miss that.
<jelmer> lifeless: so send a patch :-P
<lifeless> mrevell: suggestions on making it more clear solicited
<lifeless> jelmer: fixing performance for e.g. samba first :)
<mrevell> lifeless: Working on it right now.
<jelmer> lifeless: ok, I can live with that :-)
<jelmer> lifeless: Did you discuss the difference in workflow compared to git with Jerry?
<lifeless> yes somewhat
<jelmer> (one working tree per repository compared to one per branch)
<lifeless> big thing appeasrs to be our lack of 'collectionof branches' facilities
<jelmer> yeah, I blogged about that a while back
<LeoNerd> Coming from CVS, I'd say that's true
<fullermd> If only somebody could rant via email at length on that topic...
<lifeless> jelmer: I don't see blogs that often; discussion about features is really best on the list IMNSHO :)
<jelmer> Well, the problem I guess is that it's not a concrete feature request
<jelmer> more like: these things bother me about bzr at the moment and they all seem to be related to management of branches
<jelmer> *related branches
<jelmer> I can forward the blog post to the list, would htat be useful?
<jelmer> here's a link: http://jelmer.vernstok.nl/blog/archives/192-Bazaar-Need-for-a-Product-object.html
<fullermd> It was ref'd by igc in the recent thread on the topic.
<lifeless> jelmer: do you know about path_policy=append ?
<james_w> fullermd: :)
<lifeless> things
<jelmer> lifeless: no, and cna't find any reference ot it in the bzr source
<jelmer> with apologies for my bad spelling today
<lifeless> e.g.
<lifeless> public_branch:policy = appendpath
<lifeless> for instances... I have:
<lifeless> [sftp://bazaar.launchpad.net/%7Ebzr/]
<lifeless> public_branch = http://bazaar.launchpad.net/~bzr/
<lifeless> public_branch:policy = appendpath
<lifeless> create_signatures = always
<lifeless> post_commit_to = bazaar-commits@lists.ubuntu.com
<LeoNerd> Hmm.. What's that do?
<jelmer> lifeless: ah, that would at least help with the configuration bit
<jelmer> but still not allow pushing multiple related branches at once, for example
<lifeless> LeoNerd: it makes all branches unter that path be given a public location of the public_branch component plus the relative path under the sftp root
<jelmer> lifeless: also, is this settable in the repository config?
<jelmer> i don't use locations.conf because it means every time I rename a branch or one of it's parent directories I lose configuration
<gotgenes> I can checkout but not commit to an SVN repository with a self-signed certificate. The latter gives a pycurl error
<jelmer> gotgenes: what version of bzr-svn are you running?
<fullermd> I don't think we _have_ a repository config...
<gotgenes> 0.91 with v 0.34 bzr-svn
<jelmer> gotgenes: not 0.4.3 ?
<jelmer> I doubt bzr-svn 0.3.4 works with bzr 0.91
<jelmer> gotgenes: this is bug 150699, which has been fixed in bzr-svn's 0.4 branch
<ubotu> Launchpad bug 150699 in bzr-svn "Cannot commit on svn+https checkout" [Low,Fix committed] https://launchpad.net/bugs/150699
<gotgenes> jelmer: meant v 0.4.3
<gotgenes> dyslexia
<jelmer> gotgenes: ok, in that case updating to the 0.4 branch (or 0.4.4, when it's released) should fix that issue
<gotgenes> jelmer: ah, okay
<jelmer> 0.4.4 will be released later this week
<gotgenes> jelmer: should I just bzr co your branch?
<jelmer> gotgenes: Yep, just checking it out and linking ~/.bazaar/plugins/svn to it should be sufficient
<gotgenes> jelmer: great! and then it's bzr pull to update from your changes every now and then?
<jelmer> gotgenes: if you use "bzr up" if you've "bzr co" earlier
<jelmer> "bzr pull" if you used "bzr branch" earlier
<gotgenes> jelmer: ah, okay
<lifeless> jelmer: no, its locations.conf - not coupled to repo's
<jelmer> most confusing thing in the bzr UI at the moment, imho
<jroes> anyone know a workaround for bug 107593?
<ubotu> Launchpad bug 107593 in bzr "bzr unable to ask password for access over bzr+ssh:// or sftp:// when plink.exe used as SSH client" [Low,Confirmed] https://launchpad.net/bugs/107593
<jroes> I literally can't use bzr on win32 to push branches
<jroes> I'd consider it a showstopper for win32, but then again, I guess much less people use plink than I thought
<jelmer> jroes: any reason you can't use paramiko?
<jroes> well, tbh, I simply downloaded a binary dist of bzr, and I'm guessing paramiko is just bundled in there somewhere
<jroes> I don't honestly know what paramiko is besides "ssh2 for python" :)
<Peng> jroes: SSH and SFTP for Python.
<lifeless> jroes: it is a bit of a showstopper for plink users; I guess we don't have all that many, or they are using the putty agent
<jroes> plink is the putty agent?
<jroes> oh, pageant is
<jam-laptop> pageant is the putty agent
<jroes> I don't know the binary names, I just click the pretty icons :)
<jam-laptop> I think the mistake is that we use plink if we can find it, even though paramiko works better :)
<jroes> so, I guess I'm confused, I just use pageant, something else makes the decision as to whether or not to use paramiko or plink
<jroes> but I'm not the one making that decision, and I don't know how to choose :)
<jam-laptop> we see if we can find plink in the path
<jroes> ah
<jam-laptop> I don't know that we have a way to disable it ....
<jam-laptop> I guess the assumption is that if it is available you have it configured
<jroes> ah ha
<jam-laptop> certainly both paramiko and plink will talk to pageant
<jroes> ok, removing plink from path :)
<jam-laptop> that should do it :)
<jroes> yes, it sure did, awesome :)
<jroes> thank you very very much :)
<spiv> You can override the choice of SSH bzr uses with an environment variable IIRC.
<spiv> set BZR_SSH=paramiko
<spiv> I think that would do it.
<jroes> excellent.  I'd probably use that if I needed plink :)
<spiv> (It'll be fractionally faster too, because it won't need to autodetect which SSH to use)
<Peng> How much does paramiko hurt bzr's SSH performance?
<spiv> Peng: probably only slightly; I believe most of the heavy lifting is done in the PyCrypto module, which is written in C.
<Peng> Hmm, pycrypto is a good point.
<pattern> is there any way to have bzr use xxdiff to compare changes instead of the regular diff program?
<lifeless> pattern: the difftools plugin IIRC
<pattern> ok, cool
<pattern> thanks
<ubotu> New bug: #158350 in bzr-eclipse "import wizard does not display" [Undecided,New] https://launchpad.net/bugs/158350
<ubotu> New bug: #158333 in bzr "bzr-rebase-0.2 crashes with bzr-0.92rc1" [Undecided,Confirmed] https://launchpad.net/bugs/158333
<mrevell> Can anyone tell me where bzr help draws the "usage" line from?
<james_w> mrevell: it creates them by looking at attributes of the command.
<mrevell> thanks james_w.
<jam-laptop> mrevell: it generally looks at "takes_args" and "takes_options"
<jam-laptop> though takes_args is the one to generate Usage
<jam-laptop> mrevell: bzrlib.commands.Command._usage()
<mrevell> jam-laptop: Thanks.
<jam-laptop> Command.get_help_text() is what you would change
<jam-laptop> if you wanted to move the SeeAlso stuff
<jam-laptop> or bzrlib.help_topics.help_as_plain_text()
<jam-laptop> no, it is the get_help_text()
<jam-laptop> I was just confused by the if blocks
<lifeless> jam-laptop: hi. lets talk pack2
<jam-laptop> lifeless: sure
<jam-laptop> It is always fun to see you on at the same time as I am
<lifeless> :)
<lifeless> so, zlib, I think thats kinda interesting to do (but the current packs format is frozeN)
<lifeless> I'd really like to see xdelta/mutiparentdiffs/arbitrary knit diffs though
<jam-laptop> mrevell: I'll reply to you with a simple patch
<jam-laptop> lifeless: I'm curious if the 10% zlib difference would scale for first commit
<mrevell> mrevell: Thanks. I may need to ask what seem like simple questions though :)
<james_w> Is a branch allowed to have more than one root commit? (i.e. commit with no parents)
<lifeless> jam-laptop: easy enough to test; once you have it in a different format we can convert moz  to it :)
<lifeless> james_w: yes
<lifeless> mw: are you really talking to yourself?
<jam-laptop> lifeless: my branch has it in the zlib format at the moment
<jam-laptop> james_w: You can merge 2 ancestries together
<jam-laptop> so you can get two root commits
<fullermd> james_w: Sure, I do it all the time.
<mw> lifeless: what's that?
<james_w> thanks. I guess I set parent_ids to an empty list, and last_revision_info to (0, NULL_REVISION).
<jam-laptop> mw: lifeless was actually trying to point out to mrevell that he wrote "mrevell:" rather than probably replying to me
<lifeless> I'll be right back, we're grabbing foodstuffs
<mrevell> Lordy
<dato> mw: he meant to address mrevell
<mw> people confuse us all the time
<mw> (that is a lie)
<fullermd> Oh, you can't trust any of those 'm' people anyway.
<lifeless> mw: I meant mrevell
<lifeless> I'm back
<lifeless> jam-laptop: so, where is your branch? I'll convert lp to your new format
<jam-laptop> lifeless: http://bzr.arbash-meinel.com/branches/bzr/0.92-dev/knit_parents
<jam-laptop> If you prefer, I could push it to LP or something
<lifeless> thats fine
<lifeless> does it affect knitpack-experimental, or is it a new repo format ?
<mrevell> The help for bzr inventory has a line that reads, "It is also possible to restrict the list of files to a specific set. For example: bzr inventory --show-ids this/file" Can anyone explain "this/file" to me, please?
<jam-laptop> mrevell: if it is "this/" then it will only show files/directories underneath this/
<fullermd> I presume it means the path of a file/subdir in the branch...
<lifeless> mrevell: try it :). I think its just a filter on the path.
<jam-laptop> if it is "this/file" then it would only show this/file
<jam-laptop> (so I'm pretty sure it is 90% useless to give it a filename, but there are edge cases where it could be useful)
<mrevell> When I tried it I got a "paths are no versioned" message.
<mrevell> s/no/not
<fullermd> Works for me with .dev and 0.91.
<mrevell> fullermd: Me too now, I made a typo. Cheers.
<lifeless> jam-laptop: so is it a new repo format or does it alter knitpack-experimental
<jam-laptop> lifeless: it alters knitpack-experimental, but uses a different format string on disk
<jam-laptop> Which means you can't pull from a pack into a pack
<jam-laptop> but it was reasonable to experiment with
<jam-laptop> mrevell: well was "this/file" versioned?
<lifeless> ok, so I won't overwrite my devpad test branch :|
<jam-laptop> good idea :)
<mrevell> jam-laptop: In the end, yes, once I understood properly and also corrected a typo. The use of "this" threw me a bit.
<jelmer> lifeless: the argument for packs is still --knitpack-experimental, is it a good idea to upgrade yet?
<lifeless> jelmer: knitpack-experimental is frozen now
<lifeless> jelmer: however it's not suitable for uninformed use because of e.g. obsolete_packs, slow annotate[no cache], etc
<jelmer> what are the chances of corruption?
<lifeless> reconcile your knits branch before you convert
<lifeless> after that it should be fine
<lifeless> I've been dogfooding for a couple of months, no corrpution
<jelmer> I'm considering moving my Samba branches to packs, but would rather not lose any data in the process :-)
<lifeless> here is the acid test:
<jelmer> ok, I'll give it a go then. most of my code is mirrored in svn anyway
<lifeless> convert to packs, then push to a new pack branch
<lifeless> if that works (and it will if you've reconciled first), then no problems
<lifeless> read the docs :) (doc/developer/knitpack.txt)
<fullermd> 'k, here's a random thing that's bugged me for a little while...
<fullermd> Why does 'reconcile' exist?
<fullermd> Which is to say, "Why isn't there 'check --fix-broken-crap'?"
<lifeless> 'check' implies readonly in the name.
<lifeless> in terms of code, we should probably have Reconcile/Reconciler --check-only
<fullermd> Well, 'fsck' has check in the name, but nobody's surprised that it fixes what's fixable and shouts loudly about what isn't...
<lifeless> fullermd: actually, I was surprised when I first encountered that.
<Kinnison> OOI is reconcile meant to produce progress info?
<lifeless> some; patches solicited.
<Kinnison> It has been throbbing with a 0/0 message for ages now for me, after saying "Inventory ok>"
<lifeless> its throbbing
<Kinnison> :-)
<Kinnison> Fair enough
<Kinnison> Hmm, presumably it'd be telling me if it had to change anything?
<lifeless> mebbe
<Kinnison> :-)
<bialix> jam-laptop: hi
<jam-laptop> hi bialix
<bialix> do you have a chance to upload new installers to the bazaar site? or I need to ask another person?
<fullermd> %  bzr stat | wc -l
<fullermd>     1288
<fullermd> Sheesh.
 * fullermd blinks.
<lifeless> fullermd: ?
<fullermd> Didn't selftest used to have an arg to not blow away the temp dirs?
<fullermd> It's hard to experiment with the env and see what's failing in it, when it gets blown away when selftest finishs...
<jelmer> yes, --keep
<fullermd> Why was it taken out?
<jelmer>     * Remove selftest ``--clean-output``, ``--numbered-dirs`` and
<jelmer>       ``--keep-output`` options, which are obsolete now that tests
<jelmer>       are done within directories in $TMPDIR.  (Martin Pool)
<fullermd> Does that seem wrong to anybody else?
<fullermd> Seems kinda non-sequitor to me.
<fullermd> Mmm.  Looks like even before the rev that removed it, it didn't exist; keep_output just gives a warning about it doing nothing.
<fullermd> Looks like it was all poolie a few months before that.
<gotgenes> Is 0.92rc1 going to be in the bazaar Ubuntu repos soon?
<lifeless> yes, its high on my todo
<jam-laptop_> fullermd: generally you can use BZR_PDB or import pdb; pdb.set_trace() to drop into a debugger
<lifeless> in a sprint at the moment though
<jam-laptop_> which will (a) allow you to check the disk
<jam-laptop_> and (b) have you in a debugger which has more information anyway
<gotgenes> lifeless: great, I'm looking forward to it!
<bialix> jam-laptop_?
<fullermd> Mmm.  Does it need to be set to anything in particular?  '1' apparently doesn't do the trick...
<james_w> fullermd: that only triggers on exceptions I think
<jam-laptop_> james_w: correct
<fullermd> Well, the test failure is an AssertionError...
<jam-laptop> fullermd: yeah, but it needs to be caught by the main loop, and not the test suite
<jam-laptop> so you probably need import pdb; pdb.set_trace()
<fullermd> run_bzr_catch_errors().... but it's not using run_bzr_catch_errors.
<lifeless> jam-laptop: reviewed your patch
<fullermd> I put it in bzrlib/__init__.py, and it doesn't seem to change anything...
<jam-laptop> bialix: downloading now
<jam-laptop> fullermd: you need to put it at the point that the test is failing
<fullermd> OK, talk to me like I'm an idiot who doesn't know anything about python.
<fullermd> How do I point it?  pdb.set_trace(bzrlib.tests.[...])?
<jam-laptop> vi bzrlib/tests/test_file.py
<jam-laptop> :line that is failing
<jam-laptop> O (insert a line)
<jam-laptop> import pdb; pdb.set_trace()
<jam-laptop> ESC
<jam-laptop> :wq
<lifeless> jam-laptop: I like :!./bzr --no-plugins selftest $(basename % | sed -e /.py//)
<fullermd> Ah, OK.  That worked, thanks.
<fullermd> OK.  So I'm snatching a little time to work on this patch from last month to make pull do an open_containing() instead of open().
<jam-laptop> um... why?
<jam-laptop> In general you shouldn't be pulling on a filename
<jam-laptop> If there is a specific reason then maybe
<jam-laptop> but otherwise you have mistyped something
<jam-laptop> and it is generally better to fail
<jam-laptop> than to pull the wrong branch
<fullermd> Because "bzr pull --overwrite -r-5 . ; *boom* ; bzr pull --overwrite -r-5 .. ; *boom* ; bzr pull --overwrite -r-5 ../.. ; [...]" is a freakin' annoying process to go through.
<jam-laptop> hmm.. interesting thought
<lifeless> fullermd: bzr pull --overwrite -r-5 $(bzr root ..)
<jam-laptop> well, "bzr pull --overwrite ($bzr root) -r-5"
<jam-laptop> since I think he is just wanting to revert when he is inside a tree
<lifeless> jam-laptop: jinx!
<jam-laptop> lifeless:  not really, I wrote it from what you had :)
<jam-laptop> I just removed the ".."
<lifeless> oh right
<lifeless> fullermd: 'bzr update -r -5' ?
<jam-laptop> hmm, I just ran into the "cannot update in a checkout of an http branch"
<jam-laptop> I'll try to debug it
<jam-laptop> lifeless: if we had --r
<jelmer> lifeless, update doesn't support -r does it ? :-)
<fullermd> No, I really did want to pull --overwrite; change the branch head.
<jam-laptop> As I recall the patches haven't been merged
<jam-laptop> because of questions as to how -r should be evaluated
<jam-laptop> for heavyweight checkouts
<fullermd> But I meant it rather as the specific case I hit of the general "You have to point at the branch root and nowhere else"
<jam-laptop> fullermd: alternatively "bzr uncommit -r -5; bzr revert"
<jam-laptop> or if you don't want to be asked
<jam-laptop> "bzr uncommit -r -5 --force; bzr revert"
<jam-laptop> but that does weird things if you have changes
<fullermd> OK, see...   I solved the actual _problem_ wherein I triggered this case a month and a half ago   :p
<lifeless> fullermd: or uncomimt -r -5 ?
<fullermd> (and actually, it was a revision that wasn't even in the branch history that I was making the head, so uncommit would blow up last I checked)
<fullermd> Or maybe it was history, but not mainline.  Can't remember.
<lifeless> fullermd: I guess what I'm really saying, is 'do we have a better UI for this already, but possibly buggy?'
<lifeless> certainly for your example I think that bzr troot is the right way to get the source to pull from
<lifeless> hmm bzr trout
<fullermd> Well, if we were into proliferating commands, the right UI would "bzr reset --hard" or something.
<fullermd> But ISTM that I'm pulling from a branch, and bzr has ways to find the branch I'm pointing at, even if I'm pointing somewhere within it, so why the heck doesn't pull use them and make my life easier?
<fullermd> (and where were you people with your objections back in mid-September when I submitted it and it got as far as PQM before the test failure kicked it back to waiting for me to have spare time again?   :p)
<lifeless> fullermd: heh, dunno ? :)
<fullermd> So, is this a quorum saying "no, pull shouldn't do that", and I should just ditch the patch?
<lifeless> uhm
<lifeless> got a thread topic for the prior patch?
<lifeless> I'll rad up on it before sayignt that to you
<lifeless> *read*
<fullermd> [MERGE] Make pull more forgiving of its location
<lifeless> *saying*
<fullermd> Sept 11
<fullermd> Wasn't much discussion on it.
<fullermd> I mean, I don't feel THAT strongly about it.  It just feels like an overly-demanding UI to me.
<lifeless> right
<fullermd> I can see how it might confuse people who think it'll make pull somehow pull only part of a branch.
<lifeless> so there is a serious failure mode
<lifeless> projectA-branch/foo/project-B-branch
<lifeless> cd local-projectA; bzr pull /projectA-branch/foo/project-B-branch --overwrite
<fullermd> Which is roughly why the test suite croaks on it.
<lifeless> now, if I am used to having to give the exact url, I won't in scripts etc do that
<lifeless> if I don't know that the subdir is a nested tree rather than a subdir this converts projectA-branch *into* project-B-branch
<lifeless> which is really bad
<lifeless> ok, mailed to that thread.
 * fullermd nods.
<fullermd> Good 'nuff.  I'll shelve it 'till we see where that ends up.
<jam-laptop> fullermd: we could special case "."
<fullermd> That sounds hackier.
<fullermd> If we put that sorta smarts into 'pull', it'd probably be better as a --self option or something.
<jam-laptop> bialix: the files have been uploaded
<jam-laptop> it seems whoever uploaded 0.91
<jam-laptop> didn't update the MD5SUM and SHA1SUM files
<jam-laptop> nor did they fix the line-ending issue
<Peng> Is 'bzr init && bzr pull foo' slower than 'bzr branch foo' (and maybe 'bzr upgrade foo')?
<jam-laptop> Peng: well, it depends if you have to change formats
<jam-laptop> "bzr branch foo" generally creates a local branch in the same format as the remote one
<jam-laptop> "bzr init && bzr pull" will create a local branch in the default format
<jam-laptop> and then pull the revisions (converting as necessary)
<jam-laptop> Otherwise they should be equivalent
<Peng> jam-laptop: Yeah, I was changing formats.
<jam-laptop> bzr branch + bzr upgrade ....
<jam-laptop> I couldn't tell you for sure if that is faster or not
<Peng> Wow.
<jam-laptop> I've never benchmarked it.
<jam-laptop> I would guess it might be faster
<jam-laptop> because it has all the data locally already
<Peng> dirstate-tags is 212 MB, knitpack is 175.
<jam-laptop> rather than streaming the data and then converting
<jam-laptop> Peng: as judged by "du" ?
<Peng> I think branch && upgrade could be slower, since it has to go through and verify everything twice.
<jam-laptop> could be
<jam-laptop> as I said, I haven't tested it
<Peng> jam-laptop: As judged by right-clicking in a file manager, yeah.
<jam-laptop> Often that includes the wasted space
<jam-laptop> so if you have lots of small files
<jam-laptop> they all take up a "block" (usually 4k)
<jam-laptop> so 100 2k files takes up a lot more space than 1 200k file
<Peng> True.
<jam-laptop> And I believe after upgrade/pull you end up with 1 pack file
<Peng> (And there were a *lot* of files.)
<Peng> jam-laptop: Yes.
<jam-laptop> Not to mention we create 2 knit files per source file
<jam-laptop> (1 data, 1 index)
<Peng> Wait, 177 MB for packs, counting things other than the .pack file.
<jam-laptop> versus 5 files for a pack
<jam-laptop> 1 data, 4 indicies
<Peng> Mm-hmm. 7 files vs. 24,761.
<fullermd> The heck?  There's no test for Branch.open_from_transport()?
<bialix> jam-laptop: thanks, I will update wiki
<jam-laptop> does anyone remember the "bzr update" bug?
<jam-laptop> Where it would refuse to update if you had a heavy checkout
<jam-laptop> I tracked down the problem to URL escaping
<fullermd> I think I'd remember that blood pressure spike...
<jam-laptop> bound_location() == http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk/
<jam-laptop> source.base == http://bazaar.launchpad.net/%7Ebzr/bzr-gtk/trunk/
<jam-laptop> Notice that the ~ has been escaped
<jam-laptop> So it only fails some of the time
<jam-laptop> but notable for all LP urls
<fullermd> Hm.  OK, so maybe there _is_ a small upside to bzr+ssh still not supporting ~...
<Verterok> moin
<dato> % head -1 .bzr/repository/packs/e4307cb31157e6aa229b28ef2ada8346.pack
<dato> Bazaar pack format 1 (introduced in 0.18)
<dato> is that known? (the "0.18" bit)
<dato> ah
<dato> I guess it's correct.
<jam-laptop> dato: the stream/container format was introduced in 0.18
<dato> yeah, I realized one line later :)
<Peng> What's the point of having packs and indices in separate directories?
 * Peng wanders off.
<fullermd> Miscegenation preventation.
<lifeless> dato: yes, that is correct for that file.
<lifeless> Peng: bit of a yagni, but we want to makeindices optional data
<jelmer> argh, git's merge does indeed suck
<jelmer> simply tracking upstream for a project during some time causes conflicts in several unrelated pieces of the code
<Verterok> beuno: ping
<beuno> Verterok!
<beuno> :D
<Verterok> Hi
<beuno> I just updated the plugin a few minutes ago, ran into the merge bug, and you fixed it a few minutes later
<Verterok> ;)
<Verterok> same happen to me while working in bzr-eclipse
<Verterok> beuno: I need your help, are you available?
<beuno> Verterok, sure
<lifeless> jelmer: well let jerry kow :)
<lifeless> *know*
<jelmer> blogging as we speak :-)
<Verterok> beuno: I played a bit with missing --xml, in a new branch of xmloutput plugin. it change the xml structure so it is ~ "well-formed"
<jam-laptop> poolie: hi
<jam-laptop> vila: ping
<poolie> hi jam, how's it going
<Verterok> beuno: if you can take a look to the new format, and see if it's ok for the current use you giviin to it
<jam-laptop> poolie: pretty good. I ran into the "bzr update" in a checkout failure
<jam-laptop> It seems we are encoding some urls
<jam-laptop> but not all
<jam-laptop> so self.get_bound_location() != self.get_master_branch().base
<jam-laptop> If there is a ~ in it
<jam-laptop> Which is .... *all* LP urls.
<jam-laptop> Unless you did the original checkout with %7E instead of ~
<beuno> Verterok, I've got revno 41 and everything seems to have imported correctly (I cleared the DB and reimported everything(
<beuno> Verterok, ~3000 revisions from ~80 repos and over 100k of files/dirs imported correctly
<Verterok> beuno: nice!
<beuno> Verterok, indeed, seems like you've done great work
<Verterok> beuno: I changed the way we track the open/close of the tags, now it's a lot easier to handle espcial cases (like the nested merges)
<Verterok> beuno: are you using 'missing --xml' in your application?
<beuno> Verterok, not yet, no
<beuno> just using log at the moment
<Verterok> ok
<beuno> the plan was to start implementing missing and annotate as soon as everything got stable
<beuno> and it seems we're at that point now
<beuno> Verterok, you changed the was the tags where opened/closed in general, or just in merges?
<Verterok> only for <merge> and <log>, now it use some kind of stack to keep track of what tags are opened
<Verterok> beuno: about missing --xml, once you give me the OK with the new xml structure I want to merge the changes in trunk
<Verterok> and make a 0.2 release of xmloutput :)
<beuno> Verterok, doesn't missing output the same way log would?   because if that's the case, I'd rather not delay 0.2 while I implement it on my software (could take a day, could take weeks)
<beuno> I have to develope the bit that compares each of the users' repos to the main one, and outputs missing
<beuno> that will take tweaking in more then a few parts
<Verterok> beuno: the answer is yes and no, it show the logs the same way as log, but the current xml isn't "well-formed" because the root node is <missing> but th xml ends with a </log> tag
<beuno> Verterok, aaaah, right, you want me to fix that and run a few tests with mt repos?
 * beuno goes look for his python-developer hat
<Verterok> the changes i made in https://code.launchpad.net/~guillo.gonzo/bzr-xmloutput/well-formed-missing fix this issue
<Verterok> jaja
<beuno> oooh, so it's already fixed
<beuno> even better
<beuno> I'm not actually importing that yet, so it won't break anything on my side, but I'll get that and run it through a few of the messier repos
<Verterok> yes, but as you are the developer of missing --xml, I want your Ok to proceed :D
<beuno> Verterok, right, I forget, I'm less posesive of my code as I should be. I'm on it right now, I'll get back to you in a few minutes
<Verterok> beuno: thanks!
<james_w> poolie: hi, are you busy at the moment?
<poolie> yes
<poolie> i can take a quick question here though
<james_w> ah no, just wanted to say hello, it can wait.
<james_w> you're a hard man to get hold of :)
<poolie> :) i'll be out about 6 i think
<poolie> or maybe tomorrow, or dinner?
<james_w> yeah, I've no plans.
<beuno> Verterok, have you had any new thoughts on how to better integrate all this in bzrlib itself?
<beuno> Verterok, everything seems fine in the missing branch
<beuno> all tags close correctly
<beuno> and it looks pretty straight forward to parse
<Verterok> beuno: only bit's of it.  Still wondering how to could be the more clean way
<Verterok> great! proceeding to merge it with trunk for xmloutput-0.2
<beuno> the only thing that seemed a little bit wierd, is that it outputs the <?xml version="1.0" encoding="UTF-8"?> bit before it asks for my password, but that's probably my fault
<beuno> wouldn't happen locally either though
<Verterok> I never realized of it, it can be fixed without much pain..so i'm donig it right now :)
<beuno> Verterok, I didn't either, I just tested it wierder this time, local pc > ssh to server without keys
<vila> jam-laptop: pong, and thks for mentioning that url encoding bug, ran into it some weeks ago and thought *I* was at fault :)
<jam-laptop> vila: well, you are at fault, since you introduced _split_url and _unsplit_url :)
<jam-laptop> Which causes "get_transport(url).base == url" to fail
<lifeless> jam-laptop: did my review make sense ?
<lifeless> jam-laptop: are you interested in work ing on e.g. xdelta/multiparent for packs ?
<jam-laptop> for what to do moving forward for pack2 ?
<jam-laptop> yeah, it made sense
<Verterok> beuno: it should be fixed, in revno 45 (of the branch)...waiting your confirmation
<vila> jam-laptop: how can that cause an encoding problem ?
<jam-laptop> lifeless: And yes, I'm interested in doing xdelta stuff
<jam-laptop> vila: _unsplit_url() has "path = urllib.quote(path)"
<jam-laptop> Which causes "~" => "%7E"
<jam-laptop> I'm curious what it will do to "sftp://foo/~/" paths
<beuno> Verterok, works like a charm, go get 0.2 out there, I can't hold the screaming crowd anymore
<vila> hmm, the test suite did use paths that needed quoting if I recall correctly
<jam-laptop> well, >>> t = bzrlib.transport.get_transport('sftp://juju/~/.bazaar')
<jam-laptop> t.base
<jam-laptop> >>> t.base
<jam-laptop> 'sftp://juju/%7E/.bazaar/'
<jam-laptop> But it still works to get files from that location
<jam-laptop> So somehow sftp realizes it is still a relative path
<vila> nad I doubt I introduced a gratuitous quoting, more probably I inherited that from one transport and there was different paths regarding the quoting...
<vila> s/nad/and/
<jam-laptop> oh sure
<jam-laptop> I'm just blaming you to be cruel :)
<Verterok> beuno: JAJAJA!
<vila> I'm hurt, bye
<vila> kidding, but can't stay, see you tomorrow (in roughly 12 hours in TZ-independant parlance :)
<jam-laptop> k
<jam-laptop> vila: I think what you did change is that in the past
<jam-laptop> only *some* transports
<jam-laptop> used base = _unsplit(_split)
<jam-laptop> and others used
<jam-laptop> base = base
<jam-laptop> self.base = base
 * jam-laptop => heads to a coffee shop
<beuno> Verterok, a very useless thought just came to mind, with the XML structure in place, we might be able to add a --html switch to it too
<beuno> maybe it can be a different plugin
<beuno> dunno what's best
<beuno> but it might be nice to have it output a nice-ish HTML
<beuno> and it seems pretty trivial once XML is correctly generated
<Verterok> beuno: you are absolutely right, but it still need work, so we can reuse the current core of the xml generation.
<Verterok> beuno: the plugin approach seems nice, in that case the xml output should be a plugin too :)
<beuno> Verterok, :D   and that would just leave it open to add more, like CSV
<beuno> not sure if they all should be seperate plugins if we're going to go down that road though, maybe just one that outputs stuff in all kinds of formats
<Verterok> not sure about about csv.
<beuno> Verterok, I'm just thinking outloud, if the core is flexible enough, it opens up things to output any weird format that we need/get requested
<Verterok> it's easy to generate csv output, but I think it will lose a lot of information (like the merges, etc).
<beuno> Verterok, not sure it would, it can be an extra column
<Verterok> beuno: the core isn't flexible enough, al least not a this time...maybe in a few weeks ;)
<beuno> Verterok, I'm just making sure you don't have any free time  :D
<beuno> that said, I'll be glad to jump into coding a bit more in that aspect
 * Verterok have much fun with python than with Java
<Verterok> s/much/much more/
<beuno> Verterok, Java is evil
<Verterok> we should tell that to the Eclipse guys
<beuno> Verterok, we can open a bug  :D
<beuno> "Eclipse should be in Python"
 * Verterok LOL
<Verterok> back to the business, I think the html output can be added without much work
<beuno> Verterok, me too, if you work on the core bits, I can start some work on that
<beuno> I'll branch out for now, and we'll decide if it'll be a new plugin, a switch, or a new VCS all together later on
<Verterok> beuno: if you look to __open_log, __open_merge, etc and __log_revision in logxml.XMLLogFormatter, you would realize it'll only require knowledge of html
<beuno> Verterok, I've actually been peeking at it, that's why it occured to me
<Verterok> beuno: maybe a new plugin is the right choice, and when the core is ready, both plugins can be merged
<beuno> Verterok, gotcha, will take that aproach then
<beuno> if that's the case, then I'm going to look into HTML templating to be able to present it as nice as possible
<Verterok> beuno: in a second thought,  actually, you can (and maybe should) subclass XMLLogFormatter (XHTML is a subset of XML, right?) :)
<Peaker> any way to get bzr to remember URL passwords?
<lifeless> Peaker: coming very soon - see vila's auth-ring patch
<jam-laptop> ?
<Peaker> is it safe to "bzr pull" while a "bzr push" is running?
<jam-laptop> Peaker: yes
<jam-laptop> it won't pull the new stuff
<jam-laptop> but you can generally issue any 2 commands
<Peaker> won't push you mean?
<jam-laptop> and if they would conflict
<jam-laptop> one will block
<jam-laptop> If you bzr push revision 10
<jam-laptop> and while that is going
<jam-laptop> you bzr pull to revision 12
<Peaker> ok thanks
<jam-laptop> only revision 10 will be pushed
<jam-laptop> it won't push the newly pulled revisions
<Peaker> yeah ok
<Peaker> that's alright cause the push is a huge init on the remote branch
<lifeless> jam-laptop: heading to to dine.
<lifeless> jam-laptop: tomorrow I'dlike to tie down what is different in pack2
<jam-laptop> sure
 * jam-laptop => out for a while
#bzr 2007-10-30
<Peaker> bzr: ERROR: Repository KnitRepository('file:///.../.bzr/') is not compatible with repository KnitRepository3('file:///..../.bzr/')
<Peaker> Does the svnplugin make KnitRepository's instead of KnitRepository3?
<jelmer> no, it uses KnitRepository3 but standard bzr uses KnitRepository
<Peaker> oh, why is that?
<jelmer> you can upgrade a repository to the first by running 'bzr upgrade --dirstate-with-subtree'
<jelmer> forward compatibility on bzr-svn's side
<Peaker> cool, thanks
<Peaker> I love bzr! :-)
<Peaker> The horror of using svn because of googlecode.. for weeks!
<arjenAU> Peaker: so access the svn repos from bzr
<Peaker> arjenAU: What I really wanted was shared branches though, and now I hope to have that with launchpad
<Peaker> arjenAU: I want development to go into branches instead of messing up trunk all the time
<Peaker> not just by me, but by codevelopers
<Peaker> a heavy checkout is really just a repo+branch pulling/pushing from/to another branch on every commit, whereas a light checkout is really just a branch ptr, right?
<Peaker> If I just delete the working tree (when it has no uncomitted changes ofcourse), I can just restore it with update, right? So when I'm done with a branch, I can remove the working tree to save some space until I use it again, right?
<Peaker> if that is true, I think I might need/write a plugin that verifies there are no uncommitted changes, cleans up and deletes all the files it can restore later
<fullermd> You delete the working tree with remove-tree, and recreate it with checkout
<fullermd> remove-tree won't remove altered files (or non-versioned files)
<Peaker> fullermd: ah cool thanks
<Peaker> then it seems I dont have to write a plugin :-)
<Peaker> hmm, bzr hosting on launchpad seems to force me to upload the entire repo for each branch I make there. Where do you guys host your bzr branches such that creating a new hosted branch is cheap and doesn't require pushing the entire history?
<Peaker> When I C-c (SIGINT) the bzr push to launchpad, I got  TooManyConcurrentRequests: The medium '<bzrlib.smart.medium.SmartSSHClientMedium object at 0x89a680c>' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.
<Peaker> How do you run "bzr serve" over ssh? How is access control done?
<spiv> Peaker: bzr+ssh:// just connects via SSH as normal, and runs the "bzr serve" command (actually it gives it a couple of arguments).
<Peaker> spiv: oh, I thought it bzr+ssh connects to an sshd already running
<spiv> Peaker: access control is done entirely by the SSH server and filesystem; i.e. normal user accounts.
<spiv> (unless you want to write a custom sshd...)
<spiv> It's pretty similar to how svn+ssh:// works, AIUI.
<Peaker> so the path given to bzr+ssh://path-here  must be absolute, not relative, right?
<Peaker> (relative would be relative to user's home dir, I'd suppose)
<Peaker> To set up permissions of who can access my bzr repository via bzr+ssh, I'd need root access to create a group I suppose. I hate unix security...
<Peaker> do you think if I install a local copy of bzr in my homedir on the sourceforge shell server they'd be mad? :-)
<jelmer> Peaker, you can always use sftp
<jelmer> that'll be a bit slower, but won't require bzr on the remote side
<Peaker> jelmer: thanks that works :)  I wonder if that will piss them off.. heh
<Peaker> doesn't seem like shell.sf.net is a usable file host for bzr, its taking ages to do anything
<Peaker> where do you guys host your shared branches?
<jelmer> sftp is slower than bzr+ssh in any case, unless you use it with packs (new data format in 0.92)
<jelmer> I host them on my team's shared server or launchpad
<Peaker> my ubuntu is still packaged with 0.90.0
<Peaker> jelmer: but if you want to make a new branch on launchpad you have to push the entire history again
<jelmer> yes, but I only use launchpad for smaller things
<jelmer> how big is your history?
<Peaker> there's 40MB in my repository/
<Peaker> if that's a good measure
<jelmer> but what's the number of revisions?
<jelmer> this is bug 41415 in launchpad apparently
<Peaker> 452
<ubotu> Launchpad bug 41415 in launchpad-bazaar "supermirror sftp server does not support hosting bzr repositories" [Wishlist,Confirmed] https://launchpad.net/bugs/41415
<Peaker> according to the bug I can use sftp to explicitly create repositories
<jelmer> well, you can on an ordinary sftp server, but not on launchpad
<Peaker> weird, how does their sftp prevent it?
<jelmer> only allows you to create certain directories
<jelmer> to prevent you from using launchpad for general-purpose (non-bzr branches) hosting
<Peaker> I see
<Peaker> can I tell a branch to move its head back without creating a new revision that's identical to previous revisions?
<Peaker> I could create a new branch but the branch is already there and advertised as a main branch..
<Peaker> also can I decide that a bunch of changes I've been making should not commit to this branch but instead go to another branch?
<Peaker> Without bzr diff | patch in-new-branch ?
<spiv> Peaker: "cd ../new-branch; bzr merge --uncommitted ../old-branch"
<Peaker> spiv: thanks!
<Peaker> no way to get a branch to throw a bunch of the last revisions to become ghosts though?
<Peaker> well actually I made a branch that contains them now, so they wouldn't be ghosts
<Peaker> does bzr have nested checkouts? (if I want to split my repo into 3 for each of the components)
<jelmer> Peaker: partially
<jelmer> Peaker: it's somewhat supported, but still experimental
<ubotu> New bug: #158596 in bzr "`bzr info -v` is not working if WT4 is locked." [Undecided,New] https://launchpad.net/bugs/158596
<jelmer> mwhudson: ping
<mwhudson> jelmer: hi
<jelmer> mwhudson: Can you please try pushing your pydoctor branch to svn again, using the latest and greatest bzr-svn ?
<mwhudson> jelmer: ok
<mwhudson> jelmer: should i use bzr.dev?
<jelmer> I've reproduce the property bug and fixed it
<jelmer> yes, either bzr.dev or 0.92rc1 and bzr-svn's 0.4 branch
<mwhudson> what's the url of the bzr-svn branch?
<mwhudson> it seems that i haven't installed it again since my hard drive died
<jelmer> http://people.samba.org/bzr/jelmer/bzr-svn/0.4
<jelmer> or lp:bzr-svn
<mwhudson> ok
<mwhudson> ah, lovely, a segfault when i C-c-ed the fetching revision info step
<mwhudson> jelmer: hm, seems to be doing the 'finding branches' thing twice
<jelmer> hmm, it shouldn't do the finding branches more than once
<mwhudson> it's doing it a third time now
<jelmer> this is during a push or a pull?
<mwhudson> push
<jelmer> but you've never pulled this particular branch before?
<mwhudson> jelmer: not on this machine no
<mwhudson> i can do that first if you like
<mwhudson> jelmer: http://rafb.net/p/fVHbyE18.html
<mwhudson> and noe
<mwhudson> mwh@grond:pydoctor$ ~/src/bzr/bzr.dev/bzr get http://codespeak.net/svn/user/pydoctor/trunk
<mwhudson> bzr: ERROR: Not a branch: "http://codespeak.net/svn/user/pydoctor/trunk".
<mwhudson> mwh@grond:pydoctor$ ~/src/bzr/bzr.dev/bzr get svn+http://codespeak.net/svn/user/pydoctor/trunk
<mwhudson> bzr: ERROR: Not a branch: "svn+http://codespeak.net/svn/user/pydoctor/trunk".
<jelmer> what does "bzr svn-branching-scheme http://codespeak.net/svn/user/pydoctor/trunk" say?
<mwhudson> oh we
<mwhudson> er
<mwhudson> wrong svn url
<mwhudson> mwh@grond:pydoctor$ ~/src/bzr/bzr.dev/bzr svn-branching-scheme http://codespeak.net/svn/user/mwh/pydoctor/trunk
<mwhudson> bzr: ERROR: No repository present: "http://codespeak.net/svn/user/mwh/pydoctor/trunk/"
<jelmer> try:
<jelmer> bzr svn-branching-scheme http://codespeak.net/svn/
<jelmer> here it says:
<jelmer> */*/*/trunk
<jelmer> */*/*/branches/*
<jelmer> */*/*/tags/*
<mwhudson> i have one level less of */
<mwhudson> maybe this is because i fed it a bogus url to start with?
<jelmer> ah, yeah, that may've confused it if there are also branche swith just two levels of parent directories
<mwhudson> probably
<mwhudson> it's a fairly chaotic repo :)
<jelmer> simply removing "scheme = " from ~/.bazaar/subversion.conf will make it try again
<jelmer> or rather, set it to "trunk3"
<mwhudson> ok, i managed to get the branch now
<mwhudson> pushing is doing the finding branches thing again
<jelmer> more than once?
<mwhudson> not yet
<mwhudson> it's going slowly this time
<mwhudson> i guess the extra level of */ gives it a lot more locations to consider?
<mwhudson> jelmer: http://rafb.net/p/9RE7Or87.html
<jelmer> mwhudson: yeah, it's very inefficient for your sort of repository
<jelmer> mwhudson: does it break like in a reproducible way?
<mwhudson> jelmer: will let you know :)
<mwhudson> jelmer: yes, seem reproducible
<jelmer> mwhudson: ok, guess I have a new bug to work on then.. thanks!
<mwhudson> jelmer: i guess this is some kind of corruption in the repository
<mwhudson> jelmer: but it ought to be possible to ignore stuff over in other parts of the tree from where i want to work?
<jelmer> mwhudson: corruption in the svn repository you mean?
<jelmer> mwhudson: yes, bzr-svn should be able to ignore that bit but it can't yet
<mwhudson> jelmer: yes
<schierbeck> jelmer: ping
<ubotu> New bug: #158690 in bzr "ls --non-recursive PATH : no list" [Undecided,New] https://launchpad.net/bugs/158690
<jelmer> schierbeck: pong
<vila> lifeless: ping
<lifeless> vila: pong
<vila> wow :)
<vila> I saw you used transport.list_dir
<vila> Can't you avoid it ?
<lifeless> yes, in a write operation
<vila> (it's in Rev 2949: * Obsolete packs are now cleaned up by pack and autopack operations.)
<lifeless> not without more round trips than it's worth.
<lifeless> oh,  I know where it is.
<vila> that means wedav plugin will never be able to do that :-/
<lifeless> webdav supports listing
<vila> err, let me check that :-)
<lifeless> we used it on tla for writing over webdav
<lifeless> IIRC its :search
<jroes> has anyone had some weird problem with "cannot access lock file" on win32?
 * jroes forgets to just google and find bugs on launchpad
<vila> looks like an extension to RFC2518... would be far more work to marshall the request and extract the useful bits in the response... I think the sort tem answer will be to activate directory listing on the http server and lightly parse an index.html (i.e. implement an ad-hoc list_Dit) :-/
<vila> s/Dit/dir
<vila> I thought that with packs you somehow maintained the list of files created on the server, why can't it be used for obsolete ? Recovery handling ?
<vila> And the other hand webdav is happy to delete a whole tree, (i.e. the obsolete dir even if not empty)
<lifeless> we shouldn't rm the obsolete dir because that would trash permissions
<vila> gee, s/sort tem/short term/ around three lines above
<vila> permission handling is already messy when using a web server...
<vila> So far, the webdav plugin stay simple because it avoids parsing xml in any response, having to implement list_dir wil kill that, I just have no idea when or even if I will take into account
<lifeless> well packs are still experimental
<jroes> so, after reading "bzr help working-trees" I'm beginning to have trouble following the point of bzr when you are on a machine that is not running a webserver.  is this the general consensus or am I not understanding right?
<vila> Said otherwise, my question is: should I just kill webdav plugin *now* or do you think you can avoid using list_dir ?
<lifeless> the tla code for list_dir was pretty darn trivial
<vila> lifeless: pointer ? C ? python ?
<lifeless> jroes: I think you are not understanding right
<lifeless> vila: apt-get source 'bazaar' and look for pfs_http.c
<jroes> well, see, if I'm just a developer on my development machine, and I want to have my branch publically accessible for friends/colleagues/the public to branch and merge from, I need to push my changes to a separate machine via SSH
<jroes> from what I've read, unless I use a plugin, I have to login to the machine after every `bzr push` and run `bzr update`
<lifeless> jroes: you don't need to run update for other people to be able to pull from it
<jroes> well, what happens when I commit a new change in my local branch and then I run push again?
<lifeless> then bzr updates its metadata, and ifthey do a pull they will getyour commit
<jroes> ok, so then the message I am seeing when I push is just a warning, and not an error based on what I'm actually pushing at this point?
<lifeless> you're getting the warning because you have a working tree on the remote machine
<jroes> "This transport does not update the working tree of: sftp:/etcetcetc/.  See working-trees for more docs"
<lifeless> we assume you have some reason for doing that and thus let you know that it will not be updated
<lifeless> if you don't need a working tree there, then bzr zap-tree is your friend
<jroes> ok, so I must have accidentally done something on the remote box like a bzr commit of some sort?
<jroes> I'm trying to figure out what I did to turn it into a working-tree, what kind of operation would do that?
 * jroes will grep his .shell_history
<vila> lifeless: hehe, sure, pfs_dav.c trivially implemented pfs_directory_files by..... relying on neon :-)
<lifeless> vila: oops, well.
<Peaker> how can I publish a bzr+ssh branch for all users that has a nice path and not some ://my_comp/var/hosting/bzr/... ?
<vila> lifeless: no worries. just wanted to keep you informed, that if you can still avoid it...
<jroes> Peaker: maybe you can get symlinks or hardlinks to work.  I don't think I could get symlinks to work, but I might have some permissions problems
<vila> lifeless: ... or not avoid it, but knows about the consequences for webdav
 * vila back to fixing bugs :)
<lifeless> vila: well there are some issues; I will mail the list some thoughts for packs2
<vila> ok
<jam-laptop> lifeless, vila: what about having a Transport.clean_directory()
<jam-laptop> which for most transports is implemented as lifeless  does
<jam-laptop> and for webdav could be
<jam-laptop> rmtree() + mkdir()
<lifeless> jam-laptop: feels a bit bloatwarey
<jam-laptop> I agree, but it solves the problem
<jam-laptop> It is a fairly specific request
<jam-laptop> And means we don't expose 'list_dir()' to higher levels
<jam-laptop> Certainly from a smart server perspective we would want it to be done solely on the remote side, though that would be handled by the fetch() logic I presume
<lifeless> right
<vila> jam-laptop: but doesn't address the permission bit lifeless talked about (I'm still unclear about what you worry though)
<jroes> lifeless: where is this zap-tree?  even google only found 3 results (and 2/3 were irc quotes from you)
<jroes> :)
<jam-laptop> vila: well, as you said, if they are accessing over webdav, then permissions are pretty much just apache:apache
<jam-laptop> jroes: "bzr remove-tree"
<jam-laptop> zap-tree was an old command
 * jroes nods, thanks
<jam-laptop> I think you have to be on that machine
<jroes> I'll quiet down now since you guys are in heated developer discussion :)
<vila> jroes: dont' do that :) We have time to solve our issue
<gotgenes> lifeless: any chance of a 0.92rc1 deb today? =-)
<vila> jam-laptop, lifeless : I *thought* the list_dir was... hmmm, would be deprecated one day :) But I also had the impression, at London sprint, that implementaing it for http my solve a range of issues
<jam-laptop> vila: it is considered unusable for read-only transports
<jam-laptop> but lifeless was only doing this during a write operation
<lifeless> jroes: remove-machine
<jroes> hm.  so on my remote machine I ran a "bzr remove-tree" (which I believe completed successfully, since there were no errors), and then on my local machine I ran a bzr push to the remote machine, got an error about branches diverging, so I ran a bzr merge on my local machine merging from the remote machine, and got a "working tree has uncommitted changes"   I'm not too sure why, but technically if I just want my two branches to be the same, can I just rm-rf the en
<lifeless> bleh. ignore me
<vila> the problem being that a bit of server-side configuration may be needed and that it kind of make our dumb support support have some limits
<jam-laptop> At the moment, all supported writable transports support listdir
<vila> jam-laptop: gee, cruel again ;)
<jam-laptop> jroes: Well, we are letting you know that there is divergance
<jam-laptop> you pushed something earlier that you haven't merged
<jam-laptop> and you are trying to merge into an unclean tree
<jam-laptop> The recommendation would be
<jroes> so, in that case it's telling me my -local- tree is not committed?
<jroes> or the remote tree?
<jam-laptop> "review changes; bzr commit; bzr merge; bzr commit; bzr push"
<jroes> that's what I'm confused about I think :)
<jam-laptop> jroes: The "changes in your working tree" is because you have local uncommitted changes
<jam-laptop> If you want a big hammer
<jam-laptop> you can
<jam-laptop> bzr push --overwrite
<jroes> right, so, bzr commit shows me "no changes to commit" :)
<jam-laptop> And then it will throw away whatever is extra in the server side
<jroes> I think I will use overwrite, unless I discovered a bug and you guys want me to preserve this state
<jam-laptop> vila: I think it is a little odd to have a filesystem that you can write to, but you cannot see the files
<jam-laptop> jroes: well, having merge complain about an unclean tree, but commit say nothing to commit is weird
<jam-laptop> jroes: save it for a second
<jam-laptop> bbiab
<jroes> ok
<jroes> too bad this particular local machine is windows, I don't think I have a bash_history here to see what exactly I did to repro :|
<jam-laptop> C:\Documents and Settings\<username>\.bzr.log
<jam-laptop> Or maybe it is in My Documents?
<jam-laptop> I don't quite remember where it gets put
<jroes> here's a pastebin so you guys can see what I'm talking about, I'll hunt down the log and see if I can copy the branch around and get the same results http://pastebin.com/m12f743c7
<jroes> tbh, I wasn't really having a problem until recently, and I think this has to do with something previous where my repository lock file was unable to be accessed after I failed a merge somehow
<jam-laptop> I think we try for "My Documents"
<jroes> 'tis in My Documents
<jam-laptop> jroes: can you do "bzr status" ?
<jam-laptop> Having merge disagree with commit is really weird
<jam-laptop> oh, and what "bzr --version" are you using?
<jroes> bzr status works, there are a bunch of unknowns and a removed file, and 0.91.0
<vila> jam-laptop: sure, but it goes for read-only filesystems too :) I'm a lazy guy, so as long as I could maintain the webdav plugin without list_dir and more importantly without parsing zml, I did, if that chnaged, I'll have to take a tour to the drawing board...
<jam-laptop> vila: well, we know for a fact that we have http
<jam-laptop> vila: and we aren't trying to get list_dir for readonly
<jam-laptop> vila: obviously i don't know the webdav protocol
<jam-laptop> I offered a semi-cludgy workaround by customizing it at the Transport layer
<jam-laptop> but really, we *do* want to delete those files
<jroes> I think all the problems really started when I got "ImmortalLimbo: Unable to delete transform temporary directory ..."
<jam-laptop> It might be possible to write our own index of "things we renamed into this directory"
<jam-laptop> but that can also get out of sync, etc.
<jroes> oh, maybe I should have read "Please read the limbo file" :)
<vila> jam-laptop: I understand and don't want to stop bzr going forward, webdav can well be freezed for a while, it's not as if hundreds of projects were using it daily :)
<vila> I was just hoping to push it a bit more as soon as I get auth.ring landed and true https support, now I have just another bigger problem :)
<jam-laptop> how bad is zml?
<jam-laptop> Is it drastically different from XML?
<dato> lifeless: your latest commit to bzr.dev has its NEWS entry under the old "IN DEVELOPMENT" (0.92); i don't know if the plan is to merge into 0.92, or a new "IN DEVELOPMENT" should have been created.
<lifeless> its the key to the left
<jam-laptop> Or is it like XHTML which is XML, but has specific tags you need to understand
<mwhudson> ReadonlyTransportDecorator doesn't give wonderfully informative error messages
<lifeless> dato: it's slated for 0.92
<dato> ok
<lifeless> pack disk changes::
<lifeless> packs2:
<lifeless>  - optional annotation cache
<lifeless>  - remove list-dir? discussion needed on race conditions
<lifeless>  - drop inventory parents data
<lifeless> packs3:
<lifeless>  - new inventory format
<lifeless>  - arbitrary-parent delta's.
<lifeless>  - 'pack' recompresses
<lifeless> packs4:
<lifeless>  - new delta-compression
<lifeless> ---
<lifeless> jam-laptop: ^ thats a strawman
<jam-laptop> what are you thinking as a timeframe for this?
<jam-laptop> 1 per month?
<lifeless> yah, one per release
<jam-laptop> What is the timeframe for getting retries working?
<jam-laptop> As that would be #1 for me
<lifeless> soon as you write the code ? :)
<lifeless> retries don't need a new disk format...
<lifeless> an alternative strategy for handliing old packs may remove the need to do that though
<jroes> ok, I see, I hit that ImmortalLimbo error when merging in a branch with a bunch of files, then I just tried merging with the same branch again and I got an "Unable to obtain lock file" for repository/lock.  at which point I panicked (3am), and deleted the repo lock, and subsequently branch lock when I got the same lock error on that as well
<jroes> ever since then, I've had that dissonance.  so, can I recreate my locks or is my branch entirely busted now? :)
<jam-laptop> (jroes: for future reference you can use "bzr break-lock")
<jam-laptop> And locks should automatically be replaced
<jroes> hm. hmm
<jam-laptop> jroes: had the dissonance that "bzr commit" says nothing to do, but "bzr merge" says there are changes?
<jam-laptop> (again what does "bzr status" say?)
<jroes> yeah
<jam-laptop> lifeless: the "leave them in place but mark them absent in the names index" ?
<lifeless> yah
<jroes> bzr status right now shows 1 removed file and several unknowns
<jroes> in fact, another developer's branch is in this same state now
<jam-laptop> I guess I don't understand why "bzr status" would report changes, but "bzr commit" wouldn't commit them....
<jam-laptop> You aren't doing anything like a partial commit, right?
<jam-laptop> (bzr commit just-this-path)
<jroes> I don't even know how to do a partial commit
<jroes> but awesome I really wanted to know that last night :)
<jam-laptop> lifeless: so I agree that the annotation cache should rate high in priority, especially before we have people start mass conversions from knits, and they lose all that data
<jam-laptop> I would like to see the extra knit data added
<jam-laptop> so that we can make the indicies fully redundant, and able to be regenerated
<jam-laptop> I'm not sure where that fits with "drop inventory parents data"
<jam-laptop> (but for that you are talking about the inventory ancestry graph, right?)
<jam-laptop> And I assume by "pack recompresses" is that you mostly just want the wiring in place so we can see what layouts we want to use
<jroes> hmm, so I tried to push the branch to a new location just for fun to see if you guys would run into the same problems if you did a get, and the push was successful, but when I tried to make a new branch I got a weird error about a directory not being empty  http://pastebin.com/m3783699b
<poolie_> hi all
<lifeless> jam-laptop: right, I'm talking about have compression info only for inventory storage
<poolie_> jroes, could it be you already had a partly-created branch there?
<lifeless> jam-laptop: by pack recompresses I mean doing your arbitrary-parent delta logic to get optimal storage.
<jroes> I must have really hosed this thing somehow :)   the only other problems I had were sometimes I would do a bzr diff and my machine would practically lock up because it was doing diffs on binary files for some reason
<jroes> poolie_: in the new remote location?
<jroes> both the remote dir poundbzr and the local dir poundbzr did not exist before those operations
<poolie_> hm
<jroes> poolie_: let me get you up to date, here's another pastebin from earlier - merge and commit don't agree on my branch: http://pastebin.com/m12f743c7
<jroes> theoretically you guys should be able to run "bzr branch http://jroes.net/jroes/poundbzr" in /tmp or wherever you like and get the same error I just got about directories not being empty
<jroes> I wish this repo wasn't so large
<jroes> but I guess I'm wrong because I just branched successfully :)
<jam-laptop> jroes: well the url you just gave is giving me a 404
<jam-laptop> Ah, but that is just because you have directory listings turned off
<jroes> yeah :)
<jam-laptop> http://jroes.net/jroes/poundbzr/.bzr/branch-format still shows up
<jroes> ok, so in the parent directory where I did that first bzr branch, I have a .bzr directory, so I must have committed it to something at some point
<jroes> which may be the root of all of my problems? :)
<jelmer> LarstiQ, pingz0rz
<LarstiQ> jelmer: pong
<jelmer> LarstiQ, did you see the discussion on knitpack-richroot on the list? Can you perhaps comment on the state of subtrees?
<LarstiQ> jelmer: I am not back to reading mail yet, so no. I'll have a look now.
<jelmer> LarstiQ: Subject contains "Feedback on migration to bzr"
<jam-laptop> hi LarstiQ  good to see you around
<LarstiQ> jelmer: thanks
<jam-laptop> I hope things are going well for you
<LarstiQ> jam-laptop: responding on pings and working my way (slowly) through a bzr.dev merge etc
<LarstiQ> jam-laptop: reasonably
<LarstiQ> jam-laptop: how are you?
<jam-laptop> pretty good, a little sleep deprived :)
<jam-laptop> not terribly though
<jroes> so, it's bad practice to have bzr branches within bzr branches, right?
<gotgenes> jroes: why would you have a branch within a branch?
<jroes> I have a src directory branch and then I have a branch for one of the projects
<jroes> the src branch is just kind of for keeping track of everything in my src directory for myself, and then the other branches were for the specific projects, but I don't know if this is really necessary :)
<gotgenes> jroes: Ah, I see. My understanding of the Bazaar workflow shows that maybe you should break the src up into individual branches, one per project
<LarstiQ> jroes: you can do that, but the containing branch will not track the contained ones just yet, you still have to do that manually.
<lifeless> jam-laptop: so that strawman works for you?
<schierbeck> jelmer: ping
<jelmer> schierbeck, pong
<schierbeck> have you looked at my latest logview changes?
<schierbeck> i think it's turning out pretty good
<jelmer> not yet, sorry
<schierbeck> :P
<jelmer> will have a look this evening
<schierbeck> great
<jelmer> what tz are you in?
<schierbeck> +2
<schierbeck> copenhagen
<jelmer> ah, ok - same here
<james_w> poolie_: the packaging session is at 2 in the room next to the lp room.
<fullermd> What are they packaging the attendants in, and will there be pictures?   ;)
<lifeless> hi coffeedude
<lifeless> welcome to the house of fun :)
<lifeless> abentley: ping; I want to express fetch-ghosts in bzr core; do you think an option to pull/push, or a new command is better ?
<coffeedude> hey lifeless
<lifeless> I've just droped about 90% overhead in local pack based merges :)
<fullermd> Well, only 10% to go!
<lifeless> 3 seconds to merge trivial change between two python full-history imports
<fullermd> Nifty.
<lifeless> bit slow still
<lifeless> we're still doing an inventory upcast/downcast
<lifeless> I think it should be < 2 seconds eventually
<lifeless> < 1 second once the journalled inventory/split inventory stuff is done
<fullermd> That interests me.  AIUI, that should really help us with broad trees with deep history, to say nothing of the annoying even on small trees "can't log multiple files".
<lifeless> yes
<fullermd> Eggselent.
<ubotu> New bug: #158774 in bzr "no UI for fetching/filling in ghosts" [Undecided,New] https://launchpad.net/bugs/158774
<Alien_Freak> so... .. i'm very new at this, but for now, I just want to import my code into an bzr repo that i have on a remote server, I did the init-repo and init and I have a project.stable  which I want to import all the files I currently have in a certain directory....
<Alien_Freak> what's my next step? ... check out right?
<beuno> Alien_Freak, bzr add
<fullermd> Why not just create the branch in place?
<fullermd> You can push it off into a repo somewhere else later if you want, but why not keep it simple to start?
<Alien_Freak> beuno, I have bzr/project/project.stable as an initialized project on a remote machine... and i have my trunk/ in my home dir... bzr add wont work... unless it knows what repo it needs to add the files too..... at least i think
<gotgenes> Can bzr do replacement of variables such as $Revision$ and like SVN?
<fullermd> gotgenes: Keyword substitution.  No.
<gotgenes> fullermd: :-( Is it a planned feature?
<lifeless> somewhat
<lifeless> its a bit contentious, have a look at bzr version0info though which may do what you want
<lifeless> Alien_Freak: 'bzr init; bzradd; bzr commit'
<beuno> Alien_Freak, it adds it to the directory you are currently in recursively
<lifeless> Alien_Freak: we have a getting started guide you might find useful
<beuno> as fullermd pointed out, it's probably best for you to create it locally and then push it
<Alien_Freak> yah,.. i probably should look into that...the whole branching tidbit.. is confusing me somewhat
<lifeless> Alien_Freak: http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html
<Alien_Freak> is there a book on bzr yet?  just curious..
<james_w> thanks poolie_.
<lifeless> jam-laptop: so does that strawman work for you ?
<jam-laptop> lifeless: well, you didn't respond to my comments
<jam-laptop> Like when putting the extra data into the pack would land
<jam-laptop> (extra index data)
<jam-laptop> But as an 30-mile view it seems fine.
<lifeless> oh, I missed that. I was figuring that the replacement delta work would include that
<lifeless> re: the merge/fetch performance fix. I'm confused about where I'm using a generator [in that patch, not in the index layer]
<lifeless> jam-laptop: ^
<jam-laptop> keys = ((key,) for key in need_revs)
<jam-laptop> let me check the exact line
<jam-laptop> lifeless: in your commit you changed target_keys =list ((key,) for key in next_revs)
<jam-laptop> to target_keys = ((key,) for key in next_revs)
<jam-laptop> When I recommended
<jam-laptop> target_keys = [(key,) for key in next_revs)
<jam-laptop> target_keys = [(key,) for key in next_revs]
<jam-laptop> lifeless: "the replacement delta work would include that", is that "pack4" then?
<lifeless> yes, pack4
<lifeless> jam-laptop: ah, generator there - got you, sure thing.
<jam-laptop> It seems a bit more important than waiting that long... but maybe not a big deal.
<lifeless> and I've just made revert 10 times faster :)
<jam-laptop> jelmer: I'm trying to understand some of your changes to my submission
<jelmer> gcommit you mean?
<jam-laptop> for example, you seem to have "from bzrlib.plugins.gtk.window import Window"
<jam-laptop> but I don't have a window.py file
<jam-laptop> jelmer: yes
<jelmer> jam-laptop: What upstream branch are you using?
<jam-laptop> jelmer: I'm just trying to merge your bundle into my branch
<jam-laptop> I'm not using an upstream yet
<jelmer> my bundle was against upstream
<jelmer> not against your branch
<jam-laptop> sure, but it should pull both into my branch
<jam-laptop> i'm just doing "bzr merge"
<jam-laptop> that is why things are weird
<jelmer> and that works without errors?
<jam-laptop> it should
<jam-laptop> it works with normal branches
<jam-laptop> (I had to update my repository to contain the bzr-gtk trunk revisions)
<jelmer> it shouldn't contain the upstream revisions
<jelmer> ah, ok
<jam-laptop> but conceptually it shouldn't change the merge
<jam-laptop> Which is sort of weird
<jam-laptop> because I got a lot of conflicts
<jam-laptop> And if you had merged me
<jam-laptop> I would have thought it would pick a common ancestor
<jam-laptop> that wouldn't break like this
<jam-laptop> maybe bzr-gtk has some criss-crosses that are confusing the common ancestor code?
<jelmer> have you tried merging my bundle against trunk? Does that work better?
<jam-laptop> now that is weird....
<jam-laptop> When I merged the bundle
<jam-laptop> I was getting conflicts
<jam-laptop> when I create a local branch using "bzr pull --overwrite bundle"
<jam-laptop> and then merge
<jam-laptop> it goes clean
<jam-laptop> And it is fully reproducible
<jam-laptop> really weird
<lifeless> vila: grep for is_permament in errors.py
<jelmer> hmm, wouldn't know
<lifeless> jamesh: ^
<jam-laptop> jelmer: it seems to be a problem with bzr itself, not related to you
<jam-laptop> I'm sending a bug to the ML
<vila> lifeless: yes, may not be worth an attribute, worth an additional FIXME in comment as I don't think it will be needed for handling the decorator/redirection bug
<jelmer> jam-laptop: sounds odd though
<jam-laptop> yeah
<vila> lifeless: does that answer  your ping ?
<lifeless> vila: well, I think the spelling error should be fixed
<jam-laptop> jelmer: did you do a cherrypick send?
<vila> geeee, bloody completion, had to read it 10 times :)
<vila> at least the user visible part is correct :)
<jam-laptop> hmm... probably not
<jam-laptop> but I think i figured it out
<jelmer> jam-laptop: nope, send with bzr-gtk's trunk as submit branch
<jam-laptop> jelmer: I believe the send code is creating a "base_revision_id" which is causing it to force a cherry pick
<jelmer> hmm
<jelmer> actually
<jelmer> I may have used gsend
<jam-laptop> jelmer: regular "bzr send" does it too
<jam-laptop> I think I've worked out the problems
<jam-laptop> I'll send a bug email
<jamesh> jam-laptop: by the way, I have a bunch of changes/improvements to bzr-pqm that'd be good to review/merge
<jamesh> jam-laptop: as well as cleaning things up, it adds tests
<jamesh> and makes it share more bzrlib infrastructure with the merge directive code
<jam-laptop> jamesh: good to hear, thanks for working on it
<radix> lifeless: !?!?!
<radix> bug #152008
<ubotu> Launchpad bug 152008 in bzr "Ability to unmerge or revert a merge sensibly" [Wishlist,Fix released] https://launchpad.net/bugs/152008
<radix> how's it fixed? I'd really like to use it
<lifeless> radix: bzr ervert --forget-merges
<lifeless> oh damn, misread the bug
<radix> lifeless: erm, that doesn't ...
<radix> :)
<ubotu> New bug: #158820 in bzr "[BUG] Merging an MD into a different branch causes a cherrypick" [Medium,Triaged] https://launchpad.net/bugs/158820
<lifeless> wtf is an MD  ?
<jam-laptop> Merge Directive
<lifeless> oh
<lifeless> acronyms ftl
<fullermd> IOTTMCO   :p
<jam-laptop> but of course
<jam-laptop> fullermd: well, at least with a google search :)
<Odd_Bloke> Heh, 'wtf', 'ftl' FTS.
<jam-laptop> hmm, my 'wtf' doesn't have IOTTMCO or "FTL"
<jam-laptop> maybe I need to update
<ubotu> New bug: #158824 in bzr "AssertionError after failure to find host" [Undecided,New] https://launchpad.net/bugs/158824
<fullermd> I don't remember where I picked up IOTTMCO.  I've been carting it around since I was a kid.
 * beuno googles IOTTMCO and feels stupid
<jam-laptop> jelmer: there was a test in "tests/test_viz.py" which was testing "DummyRevision" from viz/linegraph.py
<jam-laptop> wait, graph.py
<jam-laptop> anyway, there is no DummyRevision anymore
<jam-laptop> should the test just be deleted?
<jam-laptop> (As it stands, I can't run the test suite)
<jam-laptop> Which i think shows that the bzr-gtk folks aren't in the habit of running the test suite before the commit to trunk
<jam-laptop> One other thing my patch introduced was
<jam-laptop> 'bzr test-gtk'
<jam-laptop> which only runs the gtk test suite
<jam-laptop> which is a *lot* faster than loading all of the bzr test suite, just to run gtk (bzr selftest gtk)
<jelmer> jam-laptop: no, I wrote some initial tests about half a year ago, but nobody has touched it since
<jelmer> the test for DummyRevision should probably be removed, indeed
<lifeless> jelmer: please try packs with my repository branch again
<lifeless> jelmer: commit/branch/push/pull/merge/revert should now me acceptably fast for you
<jelmer> lifeless: what was the url again?
<lifeless> jelmer: people.ubuntu.com/~robertc/baz2.0/repository
<aconbere> does anyone have a link to documentation regarding group or paired use workflow? the documentation have a picture, but doesn't describe how you might want to host the share repository, or how you would resource a users branch and those kinds of actual implimentation details.
<lifeless> aconbere: not sure if we have that or not; have you looked at the users guide?
<lifeless> jelmer: where is your bzr-dbus branch, for bzr-gtk commit-notify to work
<aconbere> lifeless: yeah the user guide helps me figure out how to make branches, and merge, and all the things I already know how to do with svn, but I just don't have any clue how you set up a group work environement
<aconbere> I presume doing something like... hosting the main branch in apache, with apache mod auth to protect it?
<jelmer> lifeless: that's a good question
<lifeless> aconbere: I'm not sure whyt you'd need auth
<lifeless> aconbere: unless is private code on the internet; in which case you probably want https and auth
<aconbere> lifeless: it's private code for a small group of people
<aconbere> but we have to share it somehow over great distances
<aconbere> in my experience the way one does this is either through tcp/ip and in general these days using http :)
<aconbere> (and yes I would also pass that over https)
<aconbere> (extra either snuck in there)
 * fullermd would just do it over ssh...
<aconbere> that sounds like a terrifying hassle to add new people to the project :P
<aconbere> not only that but I would be granting full machine access to every member
<aconbere> I mean... maybe this is not a user case that Bazaar was designed for, I can keep using SVN, but I was hoping to get an idea of how to better utilize these tools, and with the way our teams are I think it would make more sense.
<lifeless> aconbere: i would just put it on a webserver
<lifeless> aconbere: then every team member can pull from it
<fullermd> Well, you can give them a restricted shell that only allows running bzr and/or sftp.  Me, I tend to solve that problem via social means (to wit; I know where they live  ;)
<lifeless> to get their code back they can send bundles easily
<lifeless> bzr+ssh/sftp is nice though because it allows read-*write* access
<lifeless> gotta go; ciao
<lifeless> jelmer: let me know about bzr-dbus and packs please.
<fullermd> The real problem is that the question "how do I set it up" is heavily dependant on the answer to "how do I want to work", which is a terribly unfair question to pose to somebody who doesn't already know bzr well enough to understand the myriad choices.
<fullermd> One way is as lifeless said; you just put the branch up on a http server somewhere where everybody [or auth'd to only the somebodies] can read it, then you (or a member of a small group with access) can merge other people's work into and update it.
<fullermd> Another way is a shared branch that a bunch of people can write, which mostly means bzr+ssh/sftp, though I think you could do very gross stuff with bzr:// or somewhat less gross stuff with bzr+http:// to open up writability.
<fullermd> The difficulty around that is that bzr doesn't have any capability of doing AAA, so the protocol around it has to handle that (which is what's nice about ssh/sftp)
<jam-laptop> well, you could set up the bzr smart server over https and have it enabled for writing
<jam-laptop> I haven't done it in a while, but it has worked
<jam-laptop> as an alternative to giving them ssh accounts
<aconbere> fullermd: what does AAA mean?
<fullermd> Authentication, Authorization, Accounting
<fullermd> At present, ssh/Apache/firewall handles Authentication, filesystem permissions provide Authorization, and Accounting is mostly done by the transport protocol too.
<fullermd> jam-laptop: I'm often glad I skipped svn, just for the fact that I don't look at "http://..." and think "Oh, yeah, that's writable"   :p
<jam-laptop> I can say back when I tried to set up svn, it wasn't all that easy to make it writable
<beuno> jam-laptop, I've tried making bzr smart server provide writing over http a few months ago, and I just kept on running into new problems (that's why I updated documentation on it). At the end, I ran into a brick wall (can't find the bug number)
<gotgenes> jelmer: Is v0.4.4 of bzr-svn really incompatible with bzr v0.91?
<jelmer> yes
<gotgenes> :-(
<jam-laptop> beuno: something about the paths not matching, iirc
<jelmer> gotgenes: there have been a couple of API changes in 0.92 that bzr-svn had to be fixed for
<jam-laptop> I remember spiv looking into it
<gotgenes> jelmer: I suppose it couldn't support both APIs.
<gotgenes> I have been hoping for the 0.92rc1 debs to hit the bazaar-vcs repos but no luck so far
<jelmer> gotgenes: 0.4.4 isn't out yet either
<gotgenes> jelmer: I've been pulling from your 0.4 branch as you told me yesterday
<jelmer> gotgenes: It could support both API's, but maintaing support for both would be a maintainance hell
<jelmer> gotgenes: You should be able to run bzr from bzr.dev as well
<beuno> jam-laptop, yup, but the end result was it impossible to push via http. I could give it another try if it needs testing. I gave up on it since no one had time to work on it at the time.
<gotgenes> jelmer: I understand about the API support. I suppose the API will keep changing frequently until bzr v1.0
<gotgenes> I really prefer debs for system cleanliness
<fullermd> gotgenes: You don't have to _install_ it; you can just run it out of the source tree until 0.92 debs show up.
<jelmer> gotgenes: 0.4.4 and 0.92 shouldn't be too far off, will both be released within about two weeks
<gotgenes> fullermd: what's the best way to use it without installing? place it in /usr/local/lib/python2.5/site-packages/ ?
<aconbere> huh
<fullermd> Nah, just stick it in your homedir.
<fullermd> I run bzr.dev out of ~/src/bzr/bzr.dev, with a shell alias intercepting 'bzr'.
<aconbere> I'm not sure I get it how people pass their data around, merge branches with eachother
<aconbere> it doesn't seem trvial to share the branches
<fullermd> People can do it by putting a branch on a web server somewhere and pointing people at it, or by sending bundles via email.
<jelmer> lifeless: find_ghosts is great
<lifeless> mm?
<jelmer> bzr up/pull for svn branches went from 10 to <1 second
<jelmer> (when it's a no-op)
<lifeless> nice
<schierbeck> jelmer: hello
<jelmer> hey schierbeck
<schierbeck> i've sent in a version without the changes page
<Peaker> hey, me and my friend both have bzr 0.90.0 and when he tries to pull a branch from me into a repo he just init-repo'd he's getting an error about repo format
<n04m> bzr: ERROR: Repository KnitRepository('file:///home/noam/enough/bzr/repo/.bzr/') is not compatible with repository KnitRepository3('http://nextflow.dyndns.org/bzr/enough/.bzr/')
<n04m> that's the error
<Peaker> bzr upgrade --dirstate-tags .   says "bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format."
<jelmer> you need "bzr upgrade --dirstate-with-subtree"
<jelmer> if the branch you're pulling was created using bzr-svn
<n04m> bzr uses a different format when pulling from svn?
<jelmer> bzr-svn requires a new bzr disk format
<n04m> jelmer: yeah, it works now
<Peaker> jelmer: I think that bzr should probably point the user to that command - I thought the --dirstate-tags was the one, but there's really no way for a user to figure it out just from bzr's output
<n04m> dirstate-with-subtree is newer than dirstate-tags?
<n04m> i agree, besides asking here there's no way we could hav efigured that out
<jelmer> Peaker: we're currently discussing that on the development list
<Peaker> jelmer: ah, ok, thanks
<n04m> jelmer: ok, thank you
<jelmer> bzr-svn's FAQ contains it (but will only be included starting 0.4.4)
<lifeless> ok, dinner time
<schierbeck> jelmer: could i get you to approve the new version? the  i'll merge it right away
<fullermd> Shows why I object to rollup format names   :p
<jelmer> schierbeck: yep, will have a look
<jelmer> lifeless: I don't tihnk there were any special requirements for bzr-dbus
<n04m> jelmer: hi, another question/comment
<jelmer> lifeless: default trunk doesn't owkr?
<n04m> i'm doing a 40MB bzr pull and the progress report is "stuck" for quite a while
<mc_> can i tell bzr somehow to remember my password?(using sftp for pulling)
<n04m> it would be nice to have some information (such as: bytes downloaded) being updated continuously so i won't worry about something going wrong
<Peaker> mc_: I asked the same and someone told me its coming real soon - you can put your public key in the remote ~/.ssh/authorized_keys2
<Peaker> mc_: for password-less login
<mc_> Peaker: well but that would only work if i would use key authentification instead of passwords i guess?
<Peaker> mc_: That's what ~/.ssh/authorized_keys2 is for -- key authentication instead of password auth
<n04m> jelmer: ack?
<jelmer> n04m, see peakers' answer
<Peaker> I didn't answer anything about  bzr progress report   I think it could be nice if bzr had one :)
<jelmer> there's been some discussion about improving progress reports as well, not sure what the status on that is
<n04m> jelmer: thanks.
<Peaker> not really bzr related, but I'd like the umask of bzr+ssh:// dirs created to have g+w, which file would that be on an Ubuntu system?
<fullermd> Your shell rc file, I presume.
<fullermd> I'd imagine there's some env variable or other you could trigger off.
<fullermd> (of course, if this is in a branch, it'll happen by itself)
<Peaker> why would push to a remote branch fail with: Generic bzr smart protocol error: Permission denied: u'...../.bzr/repository/lock/8xnfe7p211.tmp': [Errno 13] Permission denied ?
<Peaker> fullermd: ah forgot about the versioning of file modes
<fullermd> They're not versioned, they're just used as a template.
<fullermd> I'll go out on a limb and guess it's cuz permissions were denied   ;)
<abentley> Peaker: It's easy to write a shell wrapper around bzr that sets the umask, and use that for ssh.
<fullermd> Probably don't have +w on the lock dir.
<Peaker> oops I am dumb, sorry :)
<Peaker> I thought I had the entire hierarchy set to that group, but appearantly I did it too deep
<fullermd>  27151 inconsistent parents
<fullermd>  27151 file versions are not referenced by their inventory
<fullermd> wuff.
<fullermd> Pretty impressive, for a tree with under 400 revisions...
<Peaker> hmm all users' umask is now 0002, but the directories created over bzr+ssh://  still have g-w
<Peaker> unix permissions are annoying :-)
<Peaker> so its not the umask - what mode does bzr+ssh:// use for directories it makes? how do I change that?
<fullermd> Last I checked, it inherited from the dir they went in.
<fullermd> umask would only come into play when making new directories with no higher power to guide it (like init/new-push)
<Peaker> the dir its making it in has:   drwxrwsr-x  but its being made as  drwxr-sr-x  (umask is 0002)
<lifeless> jelmer: LanGateway.start does not exist in my bzr-dbus
<jelmer> lifeless: looks like I hadn't uploaded it yet, so I just did
<jelmer> it's at http://people.samba.org/bzr/jelmer/bzr-dbus/trunk
<jelmer> not registered at launchpad, because it seems to be oopsing on me again
<lifeless> :(
<lifeless> oh heh it was in the dbus trunk on the web
<lifeless> I forgot I wasn't the only one pushing there :)
<jelmer> thinking about it
<jelmer> I think you actually gave +1 for that change in Vilnius
<jelmer> my branch is also registered now, the launchpad web ui seems to like me better
#bzr 2007-10-31
<lifeless> cool
<Peaker> is it possible that the repository recorded my g-w permission bit when I first created it, and now is using g-w on all mkdirs because of that?
<fullermd> It doesn't record it, except in the perms of the dirs.
<fullermd> If you chmod -R xyz .bzr/*, it'll use xyz.
<Peaker> oh maybe its n04m's .bzr that has g-w bit...
<Peaker> he is the one making dirs with g-w :)
<fullermd> Well, obviously.  '04' doesn't include g+w   ;p
<Peaker> ya I am not sure what the deal with the l33tsp34k is there :)
<nekohayo> hi jelmer, I'm trying to fix some things up in olive, but it seems that any changes I make to /ui.py do nothing... any ideas?
<lifeless> jelmer: bugmfiling time on the cli
<jelmer> lifeless, which cli?
<jelmer> nekohayo: hi jeff
<nekohayo> I want to alleviate those jumping progressbars, but no changes are visible... even if I change the window title from "Progress" to "Monkey", it does not work
<lifeless> branch registration
<jelmer> nekohayo: maybe it's using the one installed on the system?
<nekohayo> jelmer: that's strange, locate "ui.py" |grep bzr does not return an exact match
<jelmer> nekohayo, not sure then what may be causing it
<abentley> Peaker: Did you set the *remote* umask?
<Peaker> abentley: Its fixed now, the problem was the commiter's .bzr directory, not mine
<Peaker> abentley: when he created branches under my .bzr, permissions from his remote .bzr were used
<abentley> That seems extremely unlikely.
<Peaker> abentley: he used:  bzr get URL-TO-ME  URL2-TO-ME       and URL2-TO-ME inherited the .bzr permissions of hiw CWD, not of URL-TO-ME
<abentley> When you use bzr+ssh, the permissions of the remote bzr are used, as if you were ssh-ing in, and creating the files by hand.
<Peaker> abentley: Looked a bit at the bzr+ssh code, it has an mkdir method that takes a mode and which means its likely that his local machine is telling the bzr+ssh url handler to set the modes inherited from his local .bzr, which in fact happened (as he fixed his .bzr permissions, the url2 started being created with g+w)
<abentley> Oh, you're not talking about creating files over bzr+ssh.
<nekohayo> jelmer: hmm. Now that makes me wonder, what is ui.py for inside the bzr-gtk trunk?
<nekohayo> if it doesn't use it
<jelmer> nekohayo: it *should* use it
<abentley> You're talking about retrieving data from bzr+ssh, and creating files locally.
<nekohayo> jelmer: any way to *force* it to use it?
<abentley> Owner and group can be inherited from CWD, but permissions cannot.
<jelmer> nekohayo: It should be using it in all cases
<nekohayo> then wtf o_o
<Peaker> abentley: no, I am talking about creating a remote bzr+ssh branch of another bzr+ssh branch. For some reason it used his local unrelated CWD repository perms for that
<abentley> Permissions, i.e. r/w/x, come only from the umask.
<lifeless> nekohayo: do this; python -c 'import bzrlib.plugins.gtk; print bzrlib.plugins.gtk.__file__'
<nekohayo> /home/jeff/.bazaar/plugins/gtk/__init__.pyc
<nekohayo> ah ha! wtfÂ² :) /me removes that dir
<abentley> Well, I consider it extremely unlikely that his local CWD permissions have anything to do with it.
<Peaker> abentley: Nope, the umask was and is 002.  He created branches and they had g-w until he changed his local CWD .bzr to be g+w and then the branches he created remotely in my machine started having g+W
<Peaker> abentley: that's just what happened
<abentley> Okay, if you say so.
<nekohayo> yay, it works, thanks lifeless and jelmer... I can get back to trying to sanitize that progress dialog
<nekohayo> holy cow
<nekohayo> those progressbars are weird
<nekohayo> they remove themselves dozens of times per second!
<nekohayo> don't quite know what to do with that
<fullermd> Tell 'em to quit taking so many breaks or you'll fire them?
<nekohayo> I should
<jelmer> nekohayo: I've been thinking about making it possible to set a "progress bar widget"
<jelmer> so windows can tell the progress bar to appear in a specific place before they start doing something
<nekohayo> jelmer: ?
<jelmer> (like viz analysing history)
<nekohayo> a big question I'd like to ask
<nekohayo> wouldn't it be simpler to just have *one* master progressbar?
<jelmer> nekohayo: There is a top-level progressbar
<nekohayo> that doesn't jump around and hold-up grandma
<jelmer> so you could choose to ignore all sub-progress bars
<nekohayo> ignore?
<jelmer> nekohayo, not display
<Peaker> when I "bzr pull" into a bound checkout, does it pull into my working-dir/branch, or into the remote bound branch and syncs us both?
<nekohayo> jelmer: hrmm. Do you have a branch of that or something?
<fullermd> Peaker: The latter.
<nekohayo> a bit beyond my skillset i think, but if you want a UI reviewer I'd be glad to comment, etc
<Peaker> fullermd: cool, what I'd expect :)
<nekohayo> [the coding being beyond my skillset :]
<jelmer> nekohayo: No, not yet. The progress bars need a lot of work, not just the way they look but also the way they're handled inside of bzr-gtk/olive
<jelmer> nekohayo: Comments the UI are more than welcome on the mailing list or the bug tracker
<nekohayo> jelmer: do you have a bug/discussion thread about what you're planning to make them look like yet?
<jelmer> nekohayo: Ideally, they'll be integrated in the various windows
<jelmer> nekohayo: and no longer be standalone windows
<jelmer> nekohayo: they really need a lot of refactoring first before we can look at the specific ui
<fullermd> jelmer: Hm.  Is the weird clipboard interaction of the post-tab viz intentional?
<jelmer> fullermd: clipboard interaction?
<fullermd> I'll take that as a no, then?   ;)
<nekohayo> jelmer: actually, I think the best way would be having an "info pane" like gedit's at the top below the toolbar
<nekohayo> have you ever seen it?
<jelmer> fullermd: yes :-)
<fullermd> I pull up viz, flip over to the Relations tab.  When I flip back to General, it highlights the revid and sticks it in my clipboard.
<fullermd> Odder still, when I flip back to Relations or exit viz, it restores the clipboard to what it was beforehand.
<jelmer> nekohayo: bzr-gtk is not just olive, the various dialogs can appear without olive as well
<nekohayo> jelmer: but then how would you integrate them into the various windows?
<jelmer> fullermd: Ah, I see it now too
<jelmer> nekohayo: integrate them into the various windows themselve rather than in some top-level window
<jelmer> nekohayo: or did I misunderstand you earlier?
<nekohayo> jelmer: well isn't olive just one top level window?
<jelmer> nekohayo: some of the windows that can appear with olive as top level window can also appear standalone
<nekohayo> jelmer: that's what I was thinking about, with one and only master progressbar http://blogs.gnome.org/lucasr/files/2007/02/eog-error.png
<jelmer> nekohayo: the problem is, the master progress bar isn't always linear
<lifeless> we can't do linear
<nekohayo> let's have an infamous mac OS beach ball :)
<lifeless> we can do linear so some parts of the operation
<jelmer> nekohayo: so you may want to see the subprogressbar in some cases
<jelmer> nekohayo: I think this would be an interesting thing to bring up on the list
<jelmer> but I'm getting some sleep first, g'night!
<nekohayo> jelmer: I'll copy-paste snippets of this chat onto https://bugs.launchpad.net/bzr-gtk/+bug/127734
<ubotu> Launchpad bug 127734 in bzr-gtk "Progress bars as widgets" [Medium,Triaged]
<nekohayo> (I'm really not comfortable with mailing lists)
<Peaker> is it safe to delete ~/.bazaar/svn-cache/ ?  bzr-svn is giving me weird trouble
<jelmer> nekohayo: sure, that'd be useful
<jelmer> Peaker: yes, it'll just be a bit slower trying to regenerate that data next time you use it
<jelmer> Peaker: how is it giving you trouble?
<Peaker> jelmer: depends on which svn branch scheme i use and which URL, I either get "invalid revision id", or divergence errors, or bad scheme/svn url
<Peaker> jelmer: at one point pull failed on the same URL but bind+updatee worked, but then commit failed claiming divergence
<jelmer> Peaker: which version are you using?
<Peaker> Bazaar (bzr) 0.90.0  - how do I get the bzr-svn version?
<jelmer> "bzr plugins" should print it
<Peaker> it just printed the directory. I got it from dpkg -l: ii  bzr-svn            0.4.1-1
<Peaker> btw: now it seems completely stuck at pulling from the svn...
<jelmer> Peaker: stuck how?
<Peaker> maybe its downloading, I don't know
<Peaker> I used "bzr pull https://eyal.lotem@enough.googlecode.com/svn"
<Peaker> entered the password, and its working for a looong while
<jelmer> 0.4.1 is quite old
<jelmer> and it worked fine on that url before?
<Peaker> Yeah, I think its decided to re-download the entire history, because my network is working
<Peaker> which is weird because I am pulling into a branch inside a repository that already has the entire history
<Peaker> I hope it wont do damage to my repo :P
<jelmer> whether it pulls doesn't depend on whether your network is up
<jelmer> Peaker: it says "fetching revision info" ? or "copying revision" ?
<Peaker> jelmer: my network is "working", as in something's downloading. I dont have progress report, so its my only way of knowing
<Peaker> it doesn't say anything beyond "https://enough.googlecode.com/svn is permanently redirected to http://enough.googlecode.com/svn/" after the password prompt
<Peaker> its just waiting
<jelmer> Peaker: are you sure it worked earlier? because I wouldn't know what could be asking for a password...
<Peaker> jelmer: it worked days ago, since then I pulled/pushed and did lots of things to that branch
<Peaker> nm, its not that important I gave up on pushing back to svn
<Peaker> how do I get a diff out of a "bzr missing"?
<jelmer> Peaker: I'm very curious why it broke, because it really shouldn't
<Peaker> jelmer: Well, I used trial&error and messed around with it a lot, so it will be hard to separate the variables here
<Peaker> jelmer: maybe I did something wrong..
<jelmer> Peaker: bzr diff prints diffs, missing can't
<jelmer> Peaker: if you've only used the bzr command-line, it shouldn't break
<jelmer> 0.4.1 is quite old though.. :-/
<Peaker> jelmer: I edited and then deleted ~/.bazaar/subversion.conf too
<Peaker> it had "trunk0" I tried changing to "trunk" to "none" and then to delete it
<Peaker> (in branching-scheme)
<jelmer> that shouldn't be a problem
<Peaker> well, I think debugging a non-important problem on a non-recent version of a plugin in a not-documented state of branches is probably not a priority :)
<Peaker> If I want to review the work done on a branch, relatively to its base branch, do I have to merge back, look at the diff, and then revert?
<Peaker> wow I'm getting 4KB/sec of ARP/DHCP background broadcast noise from my ISP :)
<Peaker> was wondering where that is coming from
<lifeless> Peaker: diff -r ancestor:../base
<Peaker> ancestor is a special rev token?
<fullermd>  -> help revisionspec
<Peaker> ah thanks. "bzr vis" seems like a nice way of reviewing branches too
<Peaker> I wish it showed the whole file in meld/kompare tho
<Peaker> a diff is not showing me enough context. meld doesn't seem to take input from stdin, and kompare hangs :( How do you view/review your diffs?
<Verterok> moin
<Peaker> moin?
<fullermd> Yeah, niom spelt backward.
<Peaker> is that a way to view diffs? :)
<Verterok> ups, I just was saying Hi!
<Verterok> Peaker: try with, bzr cat -r revno file_name > file_name_revno, and then use kompare/vimdiff/kdiff3
<Peaker> Verterok: I want the diff of a branch, not a specific file
<Verterok> ok
<Peaker> I guess I can just do the merge, and then use emacs's dvc
<Verterok> Peaker: I just executed, bzr diff -r branch:../trunk | kompare -
<Verterok> and (for me) worked just fine
<lifeless> Peaker: bzr difftools can run meld for you IIRC
<Peaker> Verterok: it should, it just hangs here :-(
<lifeless> night all
<Peaker> lifeless: what command would that be?
<Verterok> maybe this http://bazaar.launchpad.net/~sward-dev/bzr-difftools/trunk or http://mysite.verizon.net/sward.dev/projects/bzr_difftools.tar.gz ?
<Peaker> lifeless: thanks, night
<Peaker> difftools is giving me a diff on the .bzr dir itself :P
<Peaker> ok, kompare eats a -p1 diff just fine! whew
<Peaker> it probably doesn't like that the src/dest are identical in the default diff
<Peaker> or kompare doesn't like actually finding the involved files
<Verterok> Peaker: try passing -n switch to kompare
<Verterok> to avoid search for the files
<Peaker> nope it hangs anyway
<Peaker> If I use -p1 and replace old/ and new/ with parent-branch/ and this-branch/ it works tho
<mc__> i  killed bzr while commiting,now i cant comit cause there still is the lock.what shall i do?
<Verterok> I'm using kompare 3.5.8, maybe it's fixed in this version
<Verterok> mc__: try with 'bzr break-lock'
<mc__> Verterok: you saved my day!
<Peaker> Verterok: 3.5.8 here too
<Peaker> Verterok: you can bzr diff | kompare -o - ?
<Verterok> yes, it's work fine here, my branches are small ~50 revisions
<Verterok> and I'm making a diff of 16 revisions
<Peng> Wow. 2592.1.25.2.7.1.28.1.6.1.3.1.9.2.1.3.74.1.31.3.18.1.9.1.2.1.12.1.8.1.46.1.18.1.1.2.21.2.10.3.8.2.9.1.9.1.1 is an AWESOME revno.
<Peaker> hehehe
<mc__> Verterok: well i did  bzr break-lock,and it worked great. but now it hangs while commiting first it goes super fast but then it hangs with "[======================           ] Uploading data to master branch - Stage 4/6"
<mc__> the command i use is "bzr ci -m "now we've got working scaffolds(really)""
<Peaker> why does difftools show the .bzr in the diff?
<mc__>  
<mc__> bzr(python) uses 0% cpu
<fullermd> Sure, but what's it using on the network?
<fullermd> Uploading data doesn't take much suds.
<mc__> i dont how i can find out its bandwith usage
<Peaker> I guess I can use difftools and ignore the .bzr dir
<mc__> but it shouldnt take that long,the files are only several kb
<Peaker> trying to write a plugin to create a command that combines two commands. How do you invoke a clean-tree --missing via bzrlib? and other commands?
<fullermd> Isn't clean-tree bzrtools, not bzrlib?
<Peaker> oops it is yeah
<Peng> Yes it is.
<Peaker> ok but to run remove_tree does it make sense to instantiate its cmd_remove_tree and run that?
<mc__> hmpf,now i got "Read from remote host austriangeekforce.net: Operation timed out
<mc__> " today is not my luckiest day
<Peaker> or use bzrdir.BzrDir.open(location) that's behind the cmd_remove_tree?
<fullermd> That, I have no idea.  I suspect reimplementing the command isn't the best course, though.
<Peaker> I am not sure how to instantiate a cmd_* object
<Peaker> ok cool I have a new remove-full-tree that kills ignored files and then runs remove-tree :)
<Peng> "find . -exec 'rm -rf {}' ';'"?
<Peng> Well, excluding .bzr. :P
<fullermd> Yeah, that sure would save some space...
<fullermd> As a bonus, it not only cleans the tree, but removes unreferenced revisions from the repository   :p
<Peaker> fullermd: heh its also to avoid a mess where by my emacs is editing files from multiple branches
<Peaker> I prefer to have only the active branch's files in place
<Peaker> I think ignored files should be considered disposable, and thus remove-tree should remove them... since it doesn't I made this plugin
<mc__> now this looks like a bug,commiting small changes work,but if there are several files added bzr hangs for several minutes and then aborts
<Peaker> where can I publish a branch of the plugin I made?
<mc__> Peaker: launchpad.net ?
<Peaker> open a whole project for it? overkill, its 10 lines of python
<Peaker> is there some wiki somewhere where I can paste a branch address?
<mc__> if the project is on launchpad you can list your branch there i think
<Peaker> yeah I don't want to open a whole project for it
<mc__> contact the original author,maybe he will adopt your changes
<Peaker> editing the site wiki table is insane
<jdub> jelmer: about?
<Odd_Bloke> Peaker: You can push a branch to your own personal space without creating a project.
<Peaker> bzr currently 'crashes' when it tries to make a symlink on Windows, instead of just printing a warning and doing nothing or making a text file like in svn
<Peaker> s/currently/Bazaar (bzr) 0.90.0
<Peaker> when making a light weight checkout, does the download not include the history either?
<Peaker> cause a friend is making a light weight checkout from my machine and its taking ages, as if its downloading the entire history
<Peaker> or can that happen because I'm using a dumb server here?
<Peng> Peaker: Lightweight checkouts don't save any of the history, but if it's a dumb server, it probably needs to download quite a lot to get the latest version of all files.
<Peaker> Peng: Yeah that's what must have happened
<Peaker> Peng: I was wondering if there's a silly download-history-to-discard-it thing
<Peaker> but I guess that's only because of the dumb server
<Peaker> anyhow, thanks, gotta go
<Bloged> Good day everybody
<Bloged> I've got a, probably easy, question
<Bloged> I have a file that contains (default) configuration options. Users edit this file with for example their username.
<Bloged> I've want to keep track of the default. But want to ignore the edits made by users.
<Bloged> Is there a way to ignore edits to this file. Except when explicit commited?
<luks> I usually version myconfig.conf.default, which everybody has to copy to myconfig.conf
<Bloged> Ok... that's a solution
<Bloged> Thanks until a better solution is found this one will do
<luks> I haven't found anything better yet :/
<Bloged> Ok... to bad .bzrignore ignores only those file not yet in the repository
<Peng> Someone else asked for that feature a couple months ago. It would be pretty useful.
<Bloged> Yes it would be very useful was there a feature request or something created?
<Peng> Yeah, I think so.
<Peng> A spec.
<Bloged> Any idea where I can find that one?
<Peng> Honestly, I didn't like it much. It was kind of complex.
<Peng> Bloged: Somewhere on http://bazaar-vcs.org/ :P
<Bloged> Yep that is something I thought so... but I've searched for this feature and couldn't find anything remotely like it... Feature/Specification or already implemented :|
<Peng> Maybe it was deleted.
<Bloged> Shouldn't it be on launchpad?
<fluidics_ss2> i'm trying bzr for the first time. i want to push something using bzr+ssh but i run ssh on a different port. is it still possible?
<Bloged> I've never tried it but: <ip>:<port> isn't working?
<fluidics_ss2> doesn't seem to be
<fluidics_ss2> ahh no
<fluidics_ss2> i'm lieing it does work!
<fluidics_ss2> i was putting a slash in the wrong place
<fluidics_ss2> ok i'm getting somewhere, it's saying something about the langauge is incorrect
<fluidics_ss2> i have to set $LANG somewhere for the python interpretter
<fluidics_ss2> how do i do that?
<ubotu> New bug: #158972 in bzr "http server use both settimeout and makefile" [Undecided,New] https://launchpad.net/bugs/158972
<fluidics_ss2> bzr: warning: unsupported locale setting
<fluidics_ss2>   Could not determine what text encoding to use.
<fluidics_ss2>   This error usually means your Python interpreter
<fluidics_ss2>   doesn't support the locale set by $LANG (en_GB.UTF-8)
<fluidics_ss2>   Continuing with ascii encoding.
<fluidics_ss2> bzr: ERROR: exceptions.AssertionError: end of file reading from server.
<fluidics_ss2> ^^^ that's what i'm getting
<luks> fluidics_ss2, the remote server is probably missing the en_GB.UTF-8 locale
<fluidics_ss2> is that in python?
 * fluidics_ss2 knows very little about python
<luks> bzr+ssh just calls bzr on the server
<fluidics_ss2> oh ok
<luks> you just need to install the locale
<luks> nothing python related
<fluidics_ss2> what's a locale?
<fluidics_ss2> i mean, what sort of package name am i looking for to install it?
<Bloged> locale stands for Language Collection
<Bloged> What kind of server?
<fluidics_ss2> ubuntu
<Bloged> sudo apt-get install language-support-en
<fluidics_ss2> cool
<fluidics_ss2> thanks
<Bloged> to search for packages via command line use "apt-cache search <search_string>
<Bloged> Minus the "
<Bloged> apt-cache search <search_string>
<fluidics_ss2> yeah, i trying that
<fluidics_ss2> well that just installed a lot of stuff
<fluidics_ss2> stuff to do with fonts and open-office
<fluidics_ss2> i'm not sure that was particularly good
<Bloged> If it works now you could always autoremove this metapackage
<fluidics_ss2> well i'm still getting the same error about locale but i don't think that's the real issue
<luks> sudo locale-gen en_GB.UTF-8
<Bloged> sudo apt-get autoremove language-support-en
<Bloged> That will undo your install of the metapackage and dependencies if you want
<fluidics_ss2> do you mean autoclean?
<fluidics_ss2> yeah that didn't do anything
<fluidics_ss2> nevermind
<Bloged> No autoremove is remove and autoremove dependencies
<fluidics_ss2> ok
<fluidics_ss2> autoremove only works on edgy and newer it would seem
<fluidics_ss2> don't worry
<Bloged> Ok...
<fluidics_ss2> i think the bzr push is completing
<fluidics_ss2> i'm trying to push a branch like this bzr push bzr+ssh://ip:port/test
<fluidics_ss2> and it's creating the test dir on the remote machine
<fluidics_ss2> but it's empty
<fullermd> No it's not, it's got .bzr/ in it
<fluidics_ss2> ls -a reveals: .  ..  .bzr
<fluidics_ss2> where's my stuff then? :P
<Bloged> I'm still very new to Bazaar to... but that seems to be correct
<fullermd> In .bzr   :)
<fluidics_ss2> .bzr really is empty
<fluidics_ss2> ls -Ra /test
<fluidics_ss2> .  ..  .bzr
<fluidics_ss2> .  ..
<fullermd> Well, then push didn't complete.
<Bloged> ls
<Bloged> branch  branch-format  branch-lock  checkout  README  repository
<fluidics_ss2> yeah, i think this error "bzr: ERROR: exceptions.AssertionError: end of file reading from server." might have something to do with it
<fluidics_ss2> btw thanks for all the help so far guys
<fullermd> If you're getting that locale error, then yeah, that would probably be stopping it at that point.
<fluidics_ss2> hmm ok
<fluidics_ss2> well the apt-get install lang.... stuff didn't seem to fix that
<fluidics_ss2> i ran it on both servers
<fullermd> The problem there is likely to be not a lack of a package on the server side, but that your LANG is set wrong.
<fluidics_ss2> set | grep LANG outputs nothing
<fullermd> Try 'locale'
<fluidics_ss2> ooooo
<fluidics_ss2> well yes, now we have identified a discrepency :)
<fullermd> Maybe it's set via LC_ALL or something.  I'm not entirely clear on the intentional difference between the ways of setting it.
<fullermd> Anyway, the problem is likely to be that you've set your locale to ".UTF-8" and your system-defined locales are ".utf8" or something like that.
<fluidics_ss2> on one of the servers the locale is blank
<fluidics_ss2> which can't be right :)
<fullermd> Blank would mean C, which should be fine (may be _incorrect_, but it's not broken)
<fluidics_ss2> ok, i've run export LANG="en_GB.UTF-8"
<fluidics_ss2> and now locale output is the same on both servers, yay!
<fluidics_ss2> ok lets give this push thing another go
<fullermd> Shouldn't matter if they're different, as long as both are valid.
<fluidics_ss2> made no difference
<fluidics_ss2> i think it's python saying "i don't support en/gb utf-8"
<fullermd> Well, yeah.  That's my point   :p
<fullermd> Look at what locale tells you it's set to, and look at what locale -a says are valid choices.  You'll probably find a discrepancy.
<fluidics_ss2> ok
<fullermd> And it's probably a .UTF-8 vs .utf8 thing (at least, that's the most common one I've seen)
<fluidics_ss2> one server says:
<fluidics_ss2> C
<fluidics_ss2> en_GB.utf8
<fluidics_ss2> en_US.utf8
<fluidics_ss2> POSIX
<fluidics_ss2> and the other says:
<fluidics_ss2> locale: Cannot set LC_CTYPE to default locale: No such file or directory
<fluidics_ss2> locale: Cannot set LC_MESSAGES to default locale: No such file or directory
<fluidics_ss2> locale: Cannot set LC_COLLATE to default locale: No such file or directory
<fluidics_ss2> C
<fluidics_ss2> POSIX
<fluidics_ss2> so i guess the remote server is missing some files
<fullermd> The second, I presume is the one that was C (or blank), and you set to en_GB[...]
<fluidics_ss2> yeah
<fullermd> And the first...  well, there it is.
<fluidics_ss2> yep i pasted both in up there
<fluidics_ss2> i have no idea how to fix this
<fullermd> Eh?  Set the locale to the valid choice.
<fullermd> Find where you're getting en_GB.UTF-8 set, and change it to en_GB.utf8.  Computer don't guess words that 'look close' when you tell 'em something  :p
<fullermd> In your shell rc file, most likely.
<fluidics_ss2> ah
<fluidics_ss2> ok
<fluidics_ss2> ~/.bashrc mentions nothing about locales
<fullermd> Mmm.  I'm not sure what sequence of files bash reads.  I think there's a .profile or .bash_profile somewhere in the lineup too.
<fullermd> It may be set in the system-wide ones in /etc.
<fluidics_ss2> yeah ok i'll have a bit of a dig around
<fluidics_ss2> i can't find anything
<fluidics_ss2> i've grepped * on /etc and ~ for en, gb and utf8 and the only mentions seem to be irrelevent
<fluidics_ss2> what's the difference between declare and export?
 * fullermd mutters.
<fullermd> Yeah, so who needs power anyway?
<fluidics_ss2> this locale thing is a nightmare
<fluidics_ss2> i give up (for now)
<fullermd> How's that?
<fluidics_ss2> i think i need to do something with localedef
 * fullermd blinks.
<fullermd> Huh?
<fullermd> Does just overriding the env not do the job?
<fluidics_ss2> nope
<fluidics_ss2> i get errors in locale -a if i do that
<fluidics_ss2> locale: Cannot set LC_CTYPE to default locale: No such file or directory
<fluidics_ss2> locale: Cannot set LC_MESSAGES to default locale: No such file or directory
<fluidics_ss2> locale: Cannot set LC_COLLATE to default locale: No such file or directory
<fluidics_ss2> C
<fluidics_ss2> POSIX
<fullermd> Well, that's the server that did have it all unset, right?
<fluidics_ss2> yeah
<fullermd> It should be left unset, since it doesn't have any other locales anyway.  Your problem was on the other one.
<fluidics_ss2> but seeing as i'm in the UK shouldn't it be set as so
<fluidics_ss2> having it blank doesn't seem right to me
<fullermd> C is a perfectly valid locale.
<fluidics_ss2> what does the locale affect anyway?
<fullermd> It may not give you everything you want, but that's not relevant to your _problem_.  Your problem is on the other server, where you have it set to an invalid value.
<fullermd> A number of things, but the most important in this connection is character set.
<fluidics_ss2> basically the crux of the problem is i didn't have breakfast this morning
<fluidics_ss2> and so i'm not functioning
<fluidics_ss2> after lunch this will probably all be easy
<fullermd> Urg.  Yeah, that sounds like the root issue to me.
<fullermd> At least you had coffee, right?
<fluidics_ss2> nope, i don't think that would help really
<fluidics_ss2> coffee makes me nervous
<fullermd> ...   and you're still alive??
<fluidics_ss2> yep :)
<fluidics_ss2> i like the taste of coffee very much but i generally avoid it
<fullermd> Man.  The world _is_ full of weird people   :p
<fluidics_ss2> :)
<fluidics_ss2> yep
<fluidics_ss2> are you a bazaar developer?
<fullermd> Oh, no.  My role in life is mostly to sit around trolling unwary bzr developers.
<fluidics_ss2> trolling?
<fluidics_ss2> google says "deliberately provoking arguments on newsgroups or bulletin boards, with no other intent than to gain attention for the sake of attention"
<fluidics_ss2> well that sounds very rewarding
<fullermd> Well, everybody needs a hobby.  It keeps me off the street   :)
<fluidics_ss2> i think i'm going to have chicken and chips
<fluidics_ss2> with tomato sauce
<jelmer> jdub: hi
<fluidics_ss2> hey
<lifeless> morning sabdfl
<lifeless> debs of 0.92~rc1 up
<jelmer> yay
<lifeless> jam-laptop: check your mail :)
<Lo-lan-do> Hello
<Lo-lan-do> Is there a way to replay more than one revision at once?
<james_w> Lo-lan-do: you mean with rebase?
<Lo-lan-do> I'm thinking of the rebase plugin
<james_w> It will do as many as it can in sequence.
<Lo-lan-do> Basically, I'd like a merge where individual commits aren't collapsed.
<james_w> Ah, I haven't rebased a merge, so I'm not sure what happens.
<Lo-lan-do> But in the other direction as compared with rebase: I'd like to graft the remote revisions on top of the local ones, instead of the other way round.
<fullermd> Tricky.  You'd need a full DAG rebase.
<Lo-lan-do> I'm not trying to rebase a merge, that was just a functional description of what I'm trying to achieve :-)
<james_w> I think you would need to have a local branch of the remote one, reabse in that, and then pull across.
<Lo-lan-do> Hmm.  Makes sense.
 * Lo-lan-do gets paper+pen and starts drawing graphs
<jelmer> Lo-lan-do: "bzr replay" can accept ranges of revisions these days
<LeoNerd> Ooh.. is that like "tla replay" ..?
<Lo-lan-do> jelmer: Oh, yay :-)
<jelmer> it's not the exact reverse of rebase though, doesn't skip already completed merges by default for example
<Lo-lan-do> Any chance it could take the whole range of missing revs when no range is specified?
<Lo-lan-do> Yeah, I see.  Also, it won't change history.
<jelmer> Lo-lan-do, replay is basically an automated diff+patch+commit that keeps revision metadata
<Lo-lan-do> Hm.  Right.
<jelmer> if you want a reverse for rebase, I think that should be a different command (or perhaps an option for rebase)
<Lo-lan-do> I think what I'm looking for is something that would do one merge+commit for each remote rev I don't have locally.
<Lo-lan-do> Does that make sense?
 * fullermd blinks.
<fullermd> You mean use this instead of merge?  Why?
<jelmer> to have all remote revisions in the lhs history
<fullermd> Urgle.
<jelmer> Lo-lan-do: is this so all revisions show up in svn when you push into svn?
<Lo-lan-do> Exactly.  And so that I don't have to re-type messages.
<jelmer> so you're really trying to work around bug 158883
<ubotu> Launchpad bug 158883 in bzr-svn "ability to push non-lhs revisions" [Undecided,New] https://launchpad.net/bugs/158883
<Lo-lan-do> I guess that can be scripted rather easily, though.  If there's no interest for that kind of workflow.
<jam-laptop> lifeless: I still can't get to the other machines
<ubotu> New bug: #159021 in bzr "Unkown branch format after copy from Linux and Win32" [Undecided,New] https://launchpad.net/bugs/159021
<dato> siretart: I saw your commit in pkg-bazaar, but no upload?
<siretart> dato: yes, for two reasons: I'm on very limited bandwith right now, and I wanted to wait for the bzrtools release
<siretart> dato: if you think it is a good idea to upload right now, go ahead!
<dato> ah, I had forgotten about the latter.
<dato> siretart: nope, I wanted to wait myself, but forgot about it :)
<siretart> :)
<gotgenes> Hey, you updated the debs! Thanks, guys!
<poolie> hello
<n04m> hi, my bzr failed in the middle of a commit (on bound branch) with the following:
<n04m> TooManyConcurrentRequests: The medium '<bzrlib.smart.medium.SmartSSHClientMedium object at 0x85ebf6c>' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.
<n04m> and since that faillure,  a lock as been leaked and I cannot work anymore because it keeps waiting for the lock to be released
<lifeless> bzr break-lock
<n04m> thanks! but why did it happen in the first place?
<n04m> also: after bzr break-lock I just ran commit again and it failed again.
<n04m> with the TooManyConcurrentRequests error
<n04m> raceback (most recent call last):
<n04m>   File "/usr/bin/bzr", line 116, in <module>
<n04m>     sys.stdout.flush()
<n04m> ValueError: I/O operation on closed file
<n04m> bzr: ERROR: bzrlib.errors.TooManyConcurrentRequests: Th...........
<jam-laptop> n04m: normally you get that error when the ssh connection closes on you
<jam-laptop> bug #82634
<n04m> how can i find why does it closes?
<jam-laptop> n04m: are you sure the other machine is up and running?
<jam-laptop> (ssh host)
<n04m> yes
<n04m> i can ssh to it, and bzr update also works
<jam-laptop> Is it a large commit?
<jam-laptop> I don't know any specific reason it would close
<n04m> no
<jam-laptop> you could try switching from bzr+ssh:// to  sftp://
<n04m> i don't know if he set up sftp
<jam-laptop> but it would be the 'ssh' program that is closing its connection
<jam-laptop> most people with ssh have sftp access
<jam-laptop> you could at least try it
<n04m> ok, one sec
<n04m> seems to work except for this error:
<n04m> modified gui/CompletionWidget.py
<n04m> modified test/test_completions.py
<n04m> bzr: ERROR: Permission denied: 'f0/test_completions.py-20071031004151-wqg45t4c1dj6gdnf-5.knit': [Errno 13] Permission denied
<n04m> maybe that's what causes the ssh to close ?
<lifeless> yes, there is a bug open on this
<lifeless> its largely fixed in 0.93 - current bzr.dev - IIRC
<n04m> ok. but what's this permission error?
<lifeless> probably file system permissions on that file; does it have g+w ?
<n04m> locally yes
<lifeless> jam-laptop: whats the flag in the branch branch to set permissions manaagement on ?
<lifeless> n04m: remotely
<n04m> i was about to say: also remotely
<n04m> but i'm not sure i'm looking in the correct place
<n04m> my friend set up a bzr repository, and put it where i can access with sftp/ssh
<n04m> but he also has his own repo on that same machine - i'm not sure it matters
<n04m> (his own repo with branches bound to the same repo/branch i am working with)
<n04m> how can i know in which directory bzr was trying to access this file 'f0/test_completions.py-20071031.......'
<Peng> n04m: .bzr/repository/knits/
<n04m> weird...there are several files in that directory, some of which are owned by peaker:group (ok) and some by peaker:peaker
<n04m> i guess that's the problem
<n04m> i'm not sure why that happens - but thanks!
<lifeless> jelmer: the inspect button of bzr-gtj commit-notify seems bust
<jam-laptop> lifeless: you mean the rwx bits? (those are always on, afaik)
<jam-laptop> It is the old "sftp strips permissions" issue I'm guessing
<jam-laptop> or if he is using bzr+ssh
<jam-laptop> then he needs to be setting the umask to 0002
<jam-laptop> and then chmod g+s
<jam-laptop> (the directories
<n04m> umask is already 0002
<n04m> i don't know about g+s
<n04m> i guess we'll have to wait until he get's up.... :)
<jam-laptop> find . -type f -print0 | xargs -0 chmod 2770
<jam-laptop> n04m: ^^
<jam-laptop> you may not have the permissions
<jam-laptop> ooops
<jam-laptop> find . -type d -print0 | xargs -0 chmod 2770
<jam-laptop> find . -type f -print0 | xargs -0 chmod 660
<jam-laptop> and then
<ubotu> New bug: #159046 in bzr "bzr check uses too much memory for large trees" [Medium,New] https://launchpad.net/bugs/159046
<jam-laptop> chown -R :group .
<n04m> ok, doing
<n04m> no permissions to do that...we'll have to wait for him
<dato> jelmer: oh, you fixed #140001. I don't have to do it! thanks a lot. :)
<dato> jelmer: I poked it a bit, and I have some comments: (1) typo in FAQ, and svn timestamps should be UTC -> patch: http://dpaste.com/23821/; (2) pushing my name to svn:author raises a TypeError exception (http://dpaste.com/23823/); independently of that, in my opinion svn:author should be set to eg. the user part of the email address, to follow standard svn practice; but that's just my opinion :) and, uhm, I think not everybody who wants svn:date ...
<dato> ... set will want svn:author as well, not sure about that.
<dato> jelmer: (3) how about not making it fatal when setting svn:foo fails? so that eg. override-svn-revprops can be globally set to True? (4) not related to this particular feature, I'm encountering a "Invalid diff stream: insn 0 cannot be decoded'" error when pushing a certain repo; if you need a test-case: http://dpaste.com/23825/; (5) thanks!
<lifeless> jam-laptop: ping
<jam-laptop> lifeless: ??
<lifeless> let me run an idea past you
<lifeless> native pack reconcile.
<lifeless> I'm thinking the best thing to do is:
<lifeless>  - start a new pack
<lifeless>  - clone data to it, correcting as we go
<lifeless>  - if nothing was wrong, abort the write group
<jam-laptop> so a repack + a reconcile in one step?
<jam-laptop> pushing everything into a single pack file?
<jam-laptop> which would be deleted if we find nothing wrong
<lifeless> the alternative is to wait until we detect that something is wrong before we start cloning
<lifeless> yes
<jam-laptop> it seems okay, but it sure would be nice to know without having to write out all the data
<fullermd> The question comes to mind "should manual repacks check/reconcile too as long as they're touching all this data"
<lifeless> another alternative is to only copy the contents of packs that we think are corrupt; but index shadowing may lead to two reconciles in a row both having to move data
<lifeless> fullermd: no; because packing does not process all the same data to the same degree.
<lifeless> fullermd: but it's a good question.
<fullermd> Well, not now.  But the eventual manual repack will re-preen through all of it to re-cross-delta stuff and all, right?
<fullermd> (leaving auto-repack out of the picture, natch; 'fast' is the key there)
<lifeless> fullermd: that doesn't require e.g. parsing the revision xml's and generating testaments to check signed revisions
<fullermd> Hm.  I guess.
<fullermd> It would be nice to have the option to do 'em all in one shot, though.  "Pack down my repo to all small and optimized, check everything, and fix any inconsistencies you can.  I'm gonna go grab coffee."
<jam-laptop> well, you could have a "bzr pack --check" sort of flag
<fullermd> That may just be an extension of my desire for check --fix as well, though.
<jam-laptop> I know I'm not convinced that 1 giant pack is going to be optimal
<jam-laptop> I think having 1 pack for ancestry
<jam-laptop> and then some small packs for new data is a good thing
<lifeless> jam-laptop: we'll generate that naturally as additional commits are made
<lifeless> jam-laptop: having a single pack for lots of history works well
<ubotu> New bug: #159089 in bzr "specific error if format strings have newline corruption" [Wishlist,Confirmed] https://launchpad.net/bugs/159089
<jam-laptop> I wonder about having a big history pack, and then one pack with just the current fulltext heads
<jam-laptop> but it is just hypothesising
<jam-laptop> Anyway, I understand your point about not wanting to only write out the bad stuff
<jam-laptop> since that means the old records are still around
<jam-laptop> and you aren't sure which one a client will get
<jam-laptop> so you would have to rewrite any pack which contained a bad record
<jam-laptop> And at that point, you have to track what packs need to be processed, and it is certainly easier to just start from the beginning
<siretart> jam-laptop: against what version of bzr is bzr-builddeb.dev supposed to work with?
<siretart> james_w: : against what version of bzr is bzr-builddeb.dev supposed to work with?
<siretart> jam-laptop: sorry, never mind. dammit tab completion :)
<james_w> siretart: the one you just pulled?
<siretart> yes
<james_w> it should work with 0.92. I'm not sure when compatibility last broke though I'm afraid.
<siretart> ok. the build-dependencies in debian/control imply it should work with 0.91, but it doesn't, because bzrlib.errors.UncommittedChanges is missing
<james_w> oh, I didn't expect that.
<james_w> I'll bump the dependencies.
<siretart> james_w: http://paste.debian.net/41196
<siretart> is the build error
<ubotu> New bug: #159093 in bzr "TooManyConcurrentRequests while committing on bound branch" [Medium,New] https://launchpad.net/bugs/159093
<lifeless> hi abentley
<abentley> Hi there.
<lifeless> any chance of a bzrtools release ?
<abentley> lifeless: Sure.  I'll get that out today.
<siretart> \o/
<lifeless> thanks!
<abentley> np
<Peng> Hmmm.
<Peng> I saw a typo in the knitpack.txt doc earlier, and I just went searching for it, and I couldn't find it, but I did find 4 or 5 more.
<fullermd> Those were the decoys it meant you to find.
<ubotu> New bug: #159098 in bzr "bad "bzr info" output on dangling branch reference" [Undecided,New] https://launchpad.net/bugs/159098
<Peng> :(
<Peng> I think I'm going to submit a patch for the typos. Mind if I fix whitespace too?
<Peng> (I mean, remove whitespace from the ends of lines.)
<lifeless> fine by me
<Peng> Okies.
<Peng> Ha! Now I have a mail client running! You can't stop me from sending patches!
 * Peng wanders off.
<gotgenes> I rebound my branch to the Subversion it was checked out from (and unbound from when I was waiting for bzr v0.92), but when I did a push I get a traceback
<gotgenes> s/the Subversion/the Subversion repo/
<gotgenes> SubversionException: ('Invalid diff stream: insn 0 cannot be decoded', 185003)
<gotgenes> Nobody has access to the repo but myself so it hasn't changed since I checked it out
<gotgenes> jelmer: Any ideas? Have you seen this error before?
<gotgenes> I just did a bzr up and got the following message:
<ubotu> New bug: #159103 in bzr ""bzr push" occasionally creates a branch reference instead of a branch" [Undecided,New] https://launchpad.net/bugs/159103
<gotgenes> pending merges:
<gotgenes>   Chris Lasher 2007-10-29 Moving all to legacy.
<gotgenes> how do I enact the pending merges?
<lifeless> gotgenes: 'enact' ?
<gotgenes> lifeless: bzr enact?
<gotgenes> lifeless: ah, no, sorry. To "go ahead" with the pending changes
<gotgenes> "make it so"
<gotgenes> "give the 'go ahead'"
<dato> gotgenes: bzr commit
<gotgenes> dato: any way to use my previous commit messages?
<gotgenes> they're obviously stored somewhere because I was shown it when I did the bzr up
<gotgenes> Obviously I can copy and paste, but just wondering
<gotgenes> Well, I just did the commit and hit the same exception again
<gotgenes> SubversionException: ('Invalid diff stream: insn 0 cannot be decoded', 185003)
<lifeless> gotgenes: File a bug on bzr-svn please; jelmer should see it soon. I don't know what the bug is.
<gotgenes> lifeless: will do
<poolie> is the pack/ssh bug actually filed? can't find it...
<gotgenes> I just filed Bug #159111 for bzr-svn.
<ubotu> Launchpad bug 159111 in bzr-svn "bzr-svn can't push, commit to rebound SVN repository" [Undecided,New] https://launchpad.net/bugs/159111
<jelmer> lifeless: please file a bug (bzr-gtk commit-notify inspect button)
<jelmer> dato: please file a bug on that, with the bundle attached
<fullermd> It'd be nice to be able to set a flag to tell merge "No, really, I will never ever care about changes to this file, so don't resurrect it on merge"
<dato> jelmer: you want all issues mentioned in the same bug report?
<ubotu> New bug: #159118 in bzr "can create a pack repository over bzr+ssh, but then not open it" [Low,Confirmed] https://launchpad.net/bugs/159118
<jelmer> dato: All the ones you've fixed
<jelmer> or just send me a bundle / branch url
<mc_> hi im trying to get bzr working with CIA. im using this plugin https://launchpad.net/bzr-cia/  i already copied the directory into ~/.bazaar/plugins/cia/* and i set my cia user name. but now when i try to do bzr cia-project name i get the follwoin error "bzr: ERROR: unknown command "cia-project""
<gotgenes> mc_: shouldn't you just copy the directory under ~/.bazaar/plugins/?
<jelmer> mc_: does 'bzr plugins' list it?
<mc_> hey you're they guy who wrote it jelmer (cool) :)
<mc_> nope it doesnt
<jelmer> mc_: so you have a file __init__ in ~/.bazaar/plugins/cia ?
<mc_> jelmer: yes
<jelmer> sorry, I meant __init__.py
<mc_> of course,it's in there
<mc_> the whole error message is "Unable to load plugin 'cia' from '/Users/mc/.bazaar/plugins'
<mc_> invalid command name 'cia-project'"
<jelmer> ah, so it's actually unable toload the plugin
<mc_> ah im missing "compare_trees"
<jelmer> mc_: where did you get your copy of bzr-cia ?
<mc_> i executed __init__.py and it says that
<mc_> jelmer: https://launchpad.net/bzr-cia/ I checked out trunk
<jelmer> mc_: Strange, I can't find compare_trees in the source here anywhere :-/
<poolie> lifeless, i guess we'll need to run reconcile in the bzr.dev repo?
<poolie> and on vostok?
<He1> I've got a setup at home where I do most of my work and I can sftp into where I store my branches no problem, however when I try to do it from my comp at work using bzr in windows (where I am right now) I get a 10013 error, I've set my firewall to allow ssh to the comp where I store my branches, and can access it fine via putty, but its no dice using bzr in windows, any help would great
<mc_> jelmer: seems to be an bzrlib issue not specific to that plugin
<mc_> Traceback (most recent call last):
<mc_>   File "__init__.py", line 36, in <module>
<mc_>     from bzrlib.delta import compare_trees
<mc_> ImportError: cannot import name compare_trees
<jelmer> mc_: I think you're using an older version - what exact URL did you branch from?
<mc_> http://bazaar.launchpad.net/~jelmer/bzr-cia/main
<jelmer> mc_: what files are in your local branch? just __init__.py ?
<dato> jelmer: I'll file a separate bug for the rest, then
<mc_> jelmer: README		__init__.pyc	setup.py
<mc_> __init__.py	build		tests
<mc_> hm,hope you can decrypt that....
<dato> bug #159111
<ubotu> Launchpad bug 159111 in bzr-svn "bzr-svn can't push, commit to rebound SVN repository" [Undecided,New] https://launchpad.net/bugs/159111
<jelmer> mc_: ah, looks like launchpad is just out of date
<jelmer> one sec
<jelmer> dato: thanks
<jelmer> dato: there's no bundle attached (yet)
<mc_> jelmer: so i'll checkout the location directly then
<jelmer> mc_: i've just updated the location to http://people.samba.org/bzr/jelmer/bzr-cia/trunk
<lifeless> poolie: yes, when we switch them to the 0.92 code base running their commits
<mc_> jelmer: still the same
<mc_> Unable to load plugin 'cia_bzr' from '/Users/mc/.bazaar/plugins'
<mc_> ImportError: cannot import name compare_trees
<jelmer> mc_: what does "bzr revno ~/.bazaar/plugins/cia" say?
<mc_> jelmer: 25
<jelmer> mc_: Should be 29 if you pull from http://people.samba.org/bzr/jelmer/bzr-cia/trunk
<dato> jelmer: now, seems launchpad can't accept attachments by email (bug #159140)
<ubotu> Launchpad bug 159140 in bzr-svn "svn:date should be set to a UTC timestamp + wrong option name in	FAQ" [Undecided,New] https://launchpad.net/bugs/159140
<jelmer> dato: Yeah, hit that bug a couple of times too :-/
<jelmer> bug 30225
<ubotu> Launchpad bug 30225 in malone "Attach files via email" [High,Confirmed] https://launchpad.net/bugs/30225
<siretart> dato: if you can, feel free to upload bzr & bzrtools. I'm on very limited bandwith here, which makes updating my sid chroot painful :(
<dato> oh. I'll subscribe to that. thx.
<dato> siretart: sure, np. will do tomorrow.
<mc_> jelmer:  working :)
<mc_> jelmer: thank ya very much mate!
<jelmer> no worries :-)
<He1>  I've got a setup at home where I do most of my work and I can sftp into where I store my branches no problem, however when I try to do it from my comp at work using bzr in windows (where I am right now) I get a 10013 error, I've set my firewall to allow ssh to the comp where I store my branches, and can access it fine via putty, but its no dice using bzr in windows, any help would great, also go slow, I'm new to vcs and only know the basics of using ssh
<jelmer> He1, no idea what a 10013 error is and perhaps nobody else here does
<jelmer> please consider mailing the list, there are probably more people familiar with windows reading that
<He1> its a permission denied error, when i googled it, it seemed to be a standardized error
<He1> for multiple protocols
<lifeless> jelmer: dato: It's being worked on, some months away though (attachments via email)
<dato> ok
<lifeless> (I just asked the manager of that area :))
<ubotu> New bug: #159147 in bzr "pack progress bars incorrect" [Undecided,New] https://launchpad.net/bugs/159147
<hendrixski> ummm..... when I try to install from the bazaar repositories, I get this message:   bzrtools: Depends: bzr (< 0.92~) but 0.92~rc1-1bazaar1 is to be installed
<hendrixski> in feisty
<hendrixski> looks like somebody put in a version of bzr that breaks the dependencies elsewhere... is there a way I can specify an earlier version with apt?
<dato> hendrixski: try `apt-get install bzr=0.91-1`
<dato> or if that doesn't work, do `apt-cache policy bzr`, and substitute the version for one that exists
<hendrixski> k
 * hendrixski tries those
<dato> (or wait until bzrtoos 0.92 gets uploaded)
<hendrixski> dato, sweet the first one worked.
<hendrixski> cool, I didn't know you could do that with the equals sign :-p
<dato> hendrixski: good :)
<hendrixski> yay and now bzrtools installed too.  SUCCESS
 * hendrixski hopes this will do more stuff than version .15 did (default in the Ubuntu Feisty Repo's)
<hendrixski> dato, Happy Halloween :-)
<ubotu> New bug: #159150 in bzr "co --lightweight connects mutiple times" [Medium,In progress] https://launchpad.net/bugs/159150
<hendrixski> I'm having some trouble following this manual http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html#publishing-your-branch-with-sftp  I set up a repository on an ftp server, but now I can't seem to put my changes up there :-(
<beuno> hendrixski, what do you get when you try and push?
#bzr 2007-11-01
<hendrixski> beuno, I've been trying the send command, and I get "nothing to do"
<hendrixski> even though there are changes :-/
 * hendrixski reads man bzr and finds "push"
<beuno> hendrixski, exactly
<beuno> it's push not send
<beuno> send is for sending bundles (patches)
<hendrixski> beuno, the manual didn't do a good job of explaining that
<hendrixski> from looking at it I thought that push was just for creating... not for updating
 * beuno goes look at the manual
<beuno> hendrixski, you are right
<beuno> I'll send an email to the list and see if we can clear that up a bit, thanks
<hendrixski> :-)
<hendrixski> Thanks for looking into it and following up
<beuno> hendrixski, :D
 * hendrixski continues to explore the awesome world of bzr
 * hendrixski while throwing candy at little kids who show up at his door
<beuno> hendrixski, you can follow up on the issue in the following thread: https://lists.ubuntu.com/archives/bazaar/2007q4/033441.html
<hendrixski> cool
<beuno> (and add any input that might help)
<beuno> time to head home
<beuno> have fun learning the ropes hendrixski, and welcome!
<hendrixski> :-) It feels like a very worthwhile project... I tried it out with a friend a few days ago but I had .15 he had .91... so things didn't work... we're gonna try it again with the centralized model in a few days
<beuno> Verterok!
<Verterok> beuno: Hi
<beuno> Verterok, all good?
<Verterok> all good, you?
<beuno> pretty good too, just started working on the html-thingie a few minutes ago
<Verterok> nice! :D
<beuno> and, I have a small glitch in the XML to look into, because today, one of the repos generated invalid HTML
<beuno> er, XML
<beuno> closed </log> twice
<Verterok> ups
<beuno> but I haven't looked into it deep enough to file a bug/patch it
<beuno> oh, quick question, are you going to Lujan on saturday?
<Verterok> well this is enough to make me review the tests
<Verterok> if all go as planed, I'll
<Verterok> do you?
<beuno> Verterok, all I know up to know is that it generated from a asking for a single revision, not the whole log
<beuno> Verterok, I'm still undecided if I'm going or not, haven't got enough reasons to go yet   :p    I was thinking I migh catch you there for some brainstorming/sprint, but thinking it through, I'm not sure if those events are the best moment for such things
<Verterok> beuno: If I go, is mainly  to participate as a member of PyAr, but not sure if I'll go to the Â¿presentations? (I don't known how to translate "charlas" :P)
<beuno> Verterok, right, I don't usually go either. I'll keep thinking about it
<beuno> looking into the bug now
<Verterok> me too
<Peaker> Hey i created a repo with a default of no working trees but if I "bzr branch" in there it does create a working tree, can I avoid that?
<ignas> hi
<ree> hi all! Are there any usage examples for nested tree support (join and split) ?
<fullermd> I don't think there are...
<ree> fullermd, does it work actually on a usable level? or yet risky?
 * ree cannot figure out how to use it
<fullermd> Well, it's not really intended to be used   :)
<ree> haha
<fullermd> The backend pieces of it are pretty much in place, but most of the frontend doesn't exist.
<ree> I would like to include a separate branch as a subdir of another branch.
<ree> I cannot make any sensible use of join / split, don't understand what's going on.
<mathrick> jelmer: any luck with my bugs?
<jelmer> mathrick: not yet, sorry
<mathrick> ok
<mathrick> just checking
<lifeless> moin
<fullermd> It's downright disturbing hearing you say that when my clock says A.M.
<corporate_cookie> is there a way to edit commit messages, after committing ?
<james_w> corporate_cookie: no, you have to uncommit and then commit again.
<corporate_cookie> thanks james_w
<corporate_cookie> alas : )
<lifeless> hi
<corporate_cookie> lifeless: hello : )
<lifeless> hi corporate_cookie ; I have to go sorry
<corporate_cookie> its cool : ) i was just being friendly
<fullermd> Is it a coincidence that check shows me a number of "inconsistent parents" and "file versions not referenced by their inventory" that are exactly the same?
<ubotu> New bug: #159351 in bzr "reconcile's progress bar is broken" [Undecided,New] https://launchpad.net/bugs/159351
<ubotu> New bug: #159370 in bzr-eclipse "xml-output not detected" [Undecided,New] https://launchpad.net/bugs/159370
<Peaker> Say, is there any way to get a nice GUI for branch management (create a branch, remove a branch, etc) on some standardized branch URL scheme?
<Peaker> some folks really want a GUI to do everything
<ubotu> New bug: #159377 in bzr "commit-builder-based InterRepository implementation" [Wishlist,New] https://launchpad.net/bugs/159377
<Peaker> can I set the parent of a branch?
<jam-laptop> Peaker: "bzr pull --remember", "bzr merge --remember", etc
<Peaker> jam-laptop: that sets pull branch, not parent, doesn't it?
<jam-laptop> there is only 1 other branch
<jam-laptop> called 'parent'
<jam-laptop> well, there is a 'push' branch
<Peaker> what does the "submit:" revisionspec look for?
<Peaker> If I am going to merge into a branch, I want to review what the merge is gonna do
<Peaker> Is it best to just start the merge and review a diff, or to diff against ancestor:other_branch or submit: ?  I asked about parent because I thought it affected submit:
<jam-laptop> bzr diff -rancestor:other/branch is usually agood approximation
<jam-laptop> but it won't tell you about conflicts
<jam-laptop> many people feel like 'bzr merge' is the only truly accurate way
<Peaker> yeah I guess I'll do that
<Peaker> how do I check if a branch is pull'able, without pulling it?
<Peaker> I don't want to run merge if its pull'able
<Peaker> I do want to get uncommited changes so I can diff them
<Peaker> (for review purposes)
<Peaker> what is the "recommended" reviewing strategy?
<beuno> Peaker, bzr missing
<beuno> will tell you what the difference between branches is
<Peaker> oh, so if he's not missing anything from me there's no divergence so pull would work
<beuno> what revisions one has that the other doesn't
<beuno> Peaker, exactly
<Peaker> cool thanks
<beuno> :D
<Peaker> so if I use merge it will basically be a pull-as-uncommitted?
<Peaker> so for review I can always just use "merge" I guess..
<beuno> Peaker, pretty much, yes
<beuno> merge does introduce conflicts and such
<beuno> but I guess that concept would work
<Peaker> I think "bzr merge" should probably warn you when you could have pulled, it creates an unnecessary revision
<Peaker> I don't think conflicts can exist if its pullable
<beuno> Peaker, no, only in merges
<Peaker> yeah its probably important to know of conflicts when you review it before merger
<jelmer> Peaker, there is 'bzr merge --pull'
<jelmer> Peaker, which will pull if possible, merge otherwise
<Peaker> jelmer: yeah I know but I thought of my case as a reviewer who uses bzr merge, but I guess that's silly, I already know that from "bzr missing"
#bzr 2007-11-02
<abentley> Peaker: When you pull into a branch where you've been making changes, your changes stop being shown as the mainline.  We don't think this is a good default.
<Peaker> abentley: I am not sure what you mean, I was just wondering about the best method to review someone's changes
<Peaker> to accept/reject them
<abentley> I would generally merge them, then use diff or cdiff.
<abentley> That is, if they haven't sent you a merge directive.
<Peaker> merge directive?
<abentley> Merge directives are recipes for merging someone's changes.  They are created by the "send" command.
<abentley> They typically include a bundle of revisions in case you don't have them.
<fullermd> Unless you make them with bundle --no-bundle!    :>
<abentley> fullermd: I wish you wouldn't be so snarky.
<fullermd> Eh.  That was more whistling in the dark.  I'm too tired this week to work up good snark   :|
<abentley> Well, I put in a lot of thought and effort, and it's not fun having you be constantly critical of my work.
<fullermd> I wasn't aware that I was.  I didn't intend to be.
<fullermd> I always found it mildly amusing that you were so against that command combo; that's the sort of vague nonsense I always find fun in tools.
<abentley> You go on and on about rollup formats.  Now you mock the bundle --no-bundle thing.  And there are others I don't remember right now.
<Peaker> what is rspush good for?
<Peaker> (in bzrtools)
<abentley> Most of the time, not much.
<abentley> There are a few users, so I'm actually updating it right now.
<abentley> But you're generally better off with push.
<abentley> Unless rsync is the only supported protocol.  And even then, it doesn't work with shared repositories.
<fullermd> It does push WT's though, right?  I think that's the big thing people want from it...
<fullermd> Or was that the other rsync-push plugin?
<Peaker> why is send/bundle useful? Why not merge locally and push?
<abentley> fullermd: You're right, it does do trees by default.
<fullermd> Yeah, that's a plus.  Sadly, it seems like there are a surprising number of people who come in here asking for tree-pushing, when they only have FTP access.  It's like waking up in the middle ages.
<abentley> push requires you to publish a branch, which is a higher barrier than just sending an email.  Send works especially well with email, so it's great for mailing lists.
<Peaker> abentley: so its basically a way to allow bzr over email?
<Peaker> how does it generate the merge directive? Do you first merge, and then send instead of commit?
<abentley> You run "bzr send --mail-to email@example upstream_branch".  You don't need to merge in advance.
<Peaker> it will work under the same predicate as push would, and then it generates the diff? if not, how does it resolve the merges required?
<Peaker> also, is this how you ask pqm to merge things?
<Peaker> is "bzr patch" smarter than patch? Looks at metadata for extra information?
<abentley> Peaker: No, the upstream_branch is the branch that you want someone else to merge your changes into.
<abentley> For me, this is typically http://bazaar-vcs.org/bzr/bzr.dev
<abentley> But I use a local mirror, of course.
<abentley> bzr patch is not smarter in the way you're thinking.
<abentley> It's better because it auto-detects the branch root and applies the changes there, and because it can download a patch from a URL.
<abentley> PQM does not use merge directives yet, but we plan to update it.
<abentley> You apply a merge-directive with "bzr merge" or "bzr pull".  The machine-readable portion of the merge directive is used for merging.  The patch is mainly for human eyes.
<Verterok> Hi all
<coffeedude> lifeless: Thanks for the tarball.  Grabbing it now.
<bialix> hi! lifeless here?
<bialix> it seems like PQM is not working
<lifeless> a/away
<lifeless> bleh
<lifeless> moin
<Peaker> abentley: thanks, I was already in bed by the time you replied there :)
<ree> Hi!
<ree> Is is possible to use a bazaar branch directly from easy_setup like in svn? (http://....#egg=...) ?
<bitmonk> ree: you'd probably have to extend setuptools somehow..
<bitmonk> i was actually thinking of patching setuptools and some buildout recipes to try and use bzr to checkout svn repos with bzr-svn..
<ree> allright... there is setuptoolsbzr that allows easysetup to use bazaar branches in dependency_links
<bitmonk> really? i'll have to check that out..
<ree> but that indeed does not help with buildout
<ree> it's on launchpad
<bitmonk> well, the buildout recipes i've seen are just calling svn command
<bitmonk> so i say start there, just call bzr command, then when you have time, go back and try to use the python apis directly
<ree> with buildout I've seen it done with Makefile, that uses bzr directly. but the ideal would be if setuptools could use a bzr source directly
<bitmonk> svn isn't written in python, but it's not like there aren't python apis.  nothing wrong with os.system() in a buildout recipe..
<bitmonk> yesh that would be ideal..
<bitmonk> ah you want it for eggs, duh
<Peaker> os.system->subprocess.call :-)
 * bitmonk salutes
<ree> bitmonk, if it worked for setuptools, it would natively work with buildout without need to support it fromwithin
<ree>                     
<bitmonk> yeah
<bitmonk> i'm thinking like plone.recipe.bundlecheckout
<bitmonk> or .distros maybe
<bitmonk> which are sort of lazy, b/c they are doing Product checkouts
<bitmonk> anyway, let me know how your journey with setuptools and bzr goes, esp if i can help test..
<bitmonk> maybe once i finish this server migration i'll take a look at setuptoolsbzr at least
<keir> is anyone other than bzr using patience diff?
<Peng> I wish they would.
<fullermd> I think someone else was.
<fullermd> cdv, maybe.
<Peng> Oh, yeah, it probably does, since Bram Cohen invented them both.
<Peng> Anyone know how to get 'python -m bzrlib.patiencediff' to run on a directory instead of just a file?
<jam-laptop> Peng: adding a --recursive flag to patiencediff.py wouldn't be too hard, or you could just do it with shell tricks
<Peng> Yeah, it would probably be pretty easy with some shell trick, but I haven't wanted to bother.
<Peng> It would have to be modified to accept a file existing in one directory and not in the other, wouldn't it?
<jam-laptop> well, you would have to write some loops that recurse through the directories
<jam-laptop> and that is where you would look for one-side but not the other
<jam-laptop> oh, if you mean in shell... yeah
<jam-laptop> It would be tricky to get it right in shell, and have it detect present/missing on both sides
<Peng> I didn't mean in the shell.
<keir> we really need a page of 'compelling reasons to use bzr' instead of git/hg... patience diff should go on there!
<Peng> Well, once patiencediff.py is changed to support directories, it could be used by hg's extdiff extension. That's the reason I'm interested in it. :P
 * Peng hides.
<keir> peng, why hg instead of bzr?
<Peng> keir: I personally use it over bzr because of speed. Bzr has recently caught up, but I don't want to go through the hassle of switching back. Also, I doubt bzr's network performance is up to hg's.
<Peng> keir: Even if I didn't, there are projects I'm interested in that use hg, so it would be nice to have a non-sucky diff algorithm there.
<Peng> (It takes like 2 minutes to pull a dozen new revisions of bzr.dev. Yikes. It'd probably take 3 seconds with hg. But that's with a dumb server.)
<keir> Peng, no argument there. packs help that.
<keir> Peng, the next pack refresh should have a smarter dumb protocol index too
<keir> heh, yup, 41 seconds for 11 revs on bzr.dev
<Peng> Smarter index access sounds good. How much does it have to transfer to find the new revisions?
<dato> Peng: well, hg does not use a dumb transport.
<Peng> dato: Yeah, that's what I meant.
<Peng> dato: I didn't contruct the sentences well, but that's what I meant. hg has the benefit of a smart server.
<Peng> s/benefit/advantage/
<lifeless> ree:  setuptools can use bzr
<mneisen> Hi, i use bzr and bzrtools on Ubuntu. My problem: bzr is always released well before bzrtools, so apt wants to upgrade bzr and remove bzrtools. Is there any way to solve this?
<Peng> I haven't seen bzr get released before bzrtools.
<Peng> Except for bzr 0.92rc1 being out for a like week before bzrtools 0.92.0, but 0.92rc1 is only a release candidiate.
<Peng> Well, anyway, this isn't helpful.
<mneisen> Peng: Well, apt-get tells me the following: http://paste.ubuntu-nl.org/43030/
<Peng> I guess Ubuntu upgrades bzr more quickly than bzrtools.
<james_w> Peng: it is an exception this time hopefully.
<james_w> the aim is to upload them together, but this time bzrtools was later than the rc, and other things have now got in the way.
<james_w> (not ruling out exceptions being the norm up to this point).
<james_w> mneisen: you should just wait.
<mneisen> james_w: Will do.
<james_w> great.
<mneisen> james_w: Thanks for the info.
<mneisen> james_w: Any guess when bzrtools will be out?
<james_w> no problem. You can expect bzrtools to be updated on tuesday or wednesday hopefully.
<mneisen> james_w: Alternatively: Is there a way to "block" updates in apt-get?
<james_w> you can pin the package.
<james_w> google for "apt pinning", I can't remember how to do it now.
<mneisen> james_w: Thanks again.
<james_w> alternatively you can use aptitude and put the package on hold.
<AnMaster> Using saved location: bzr+ssh://anmaster@bazaar.launchpad.net/~anmaster/envbot/module-help/
<AnMaster> No handlers could be found for logger "bzr"
<AnMaster> bzr: ERROR: Could not acquire lock "(remote lock)"
<AnMaster> sigh, what is going on, #launchpad ppl redirect me here
<james_w> damn, I was going to point you there.
<AnMaster> I don't have any problem with other servers
<james_w> The "No handlers" thing is known and shouldn't cause this issue.
<AnMaster> james_w, well, I can push with bzr+ssh just fine to other servers
<AnMaster> and since I got redirected here....
<james_w> can you run using "bzr -Derror" please?
<AnMaster> sure
<james_w> and paste the result.
<AnMaster> just that or the push bit too?
<james_w> sorry?
<AnMaster> bzr -Derror push or just bzr -Derror ?
<james_w> 'bzr -Derror -Dhpss -Dlock push' please
<AnMaster> ah ok
<james_w> that should tell us what is happening
<AnMaster> sure will pastebin
<james_w> -Dwhatever turns on debugging output of a certain type.
<AnMaster> it takes a while before it errors out
<AnMaster> maybe 5-10 minutes
<AnMaster> between the "No handlers could be found for logger "bzr""
<AnMaster> and the next line
<james_w> that's fine. I'm going anywhere.
<AnMaster> nor am I
<AnMaster> ah
<AnMaster> http://pastebin.ca/758938
<AnMaster> james_w, ^
<AnMaster> james_w, well?
<AnMaster> guess I won't get help then
<james_w> AnMaster: no need to be like that.
<AnMaster> ok :)
<AnMaster> problem is I got to leave soon :/
<james_w> sorry for ignoring you though.
<james_w> It is raising LockContention, suggesting the lock is held.
<james_w> Is anyone else going to be pushing?
<james_w> no, it is your branch I see.#
<james_w> so you can try 'bzr break-lock URL'.
<james_w> also if you could post the end of '~/.bzr.log' that would allow me to confirm.
<AnMaster> james_w, can't be anyone else as far as I know, it is a private branch but I will try
<AnMaster> ouch that file is nearly 50 MB, that is nasty
<AnMaster> james_w, break-lock reported 2 locks that I broke
<AnMaster> but why is '~/.bzr.log' so huge
<AnMaster> for another account it is over 250 MB
<AnMaster> james_w, any way to turn off the ~/.bzr.log, I can't afford that space
<AnMaster> james_w, but here is the end of it http://pastebin.ca/758981
<james_w> I'm not sure about turning it off, it is limited in size, but I am not sure about the size.
<AnMaster> james_w, well for another account it was 250 MB
<AnMaster> doesn't seem limited to me
<fullermd> Yeah, it should auto-rotate long before it gets near that big.
 * AnMaster symlinks to /dev/null for now
<fullermd> Weird.  But yah, I've got it /dev/null linked in some places too.
<james_w> AnMaster: you should be ok now then, I'll file some bugs for you.
<jam-laptop> If he is pushing to launchpad, the "no loggers found" is actually an LP smart server bug
<jam-laptop> it means the bracnh is already locked
<ubotu> New bug: #159589 in bzr "LockContention has unhelpful text" [Undecided,New] https://launchpad.net/bugs/159589
<jam-laptop> unfortunately it isn't being sent to the user
<james_w> ah, thanks jam-laptop
<james_w> if size <= 4 << 20:
<james_w> that seems rather large
<jam-laptop> james_w: it rotates when it gets to 4MB
<jam-laptop> but it only rotates at the beginning
<jam-laptop> so if a single bzr action builds 250MB then it takes 2 rotations to go away
<jam-laptop> (It goes to .old
<jam-laptop> and then then new one overrwrites .old)
<jam-laptop> Some actions log more than others.
<jam-laptop> Off-hand i think "bzr add + bzr commit" might print out a line for each file
<jam-laptop> If you run a converter... that is one of the bigger ones
<jam-laptop> I'm not sure about bzr-svn
<jam-laptop> lifeless: any chance you could check on pqm? It seems to be stopped
<jelmer> jam-laptop: not sure about what?
<jam-laptop> jelmer: how much stuff it dumps in ~/.bzr.log
<jam-laptop> Especially on first push/pull
<jelmer> jam-laptop: less than 10 lines during connect, etc
<jam-laptop> Nothing about what files it finds, or revision, etc?
<jelmer> jam-laptop: and one line for special cases when pulling changes
<jelmer> jam-laptop: what branching scheme it's going to use mainly
<jelmer> more verbose data can be enabled using -Dtransport and -Dcommit
<jam-laptop> not a big deal. I just know that my converters would spew quite a bit into ~/.bzr.log, and it might be something to consider about bzr-svn
<jelmer> -Dcommit for push/pull
<jam-laptop> (well, *not* spitting out a lot)
<jam-laptop> jelmer: is -D printing to the screen, or only to the log
<jelmer> jam-laptop: only to the log
<jelmer> to the screen would mess with the progress bar
<lifeless> jam-laptop: sure
<lifeless> jam-laptop: looks ok
<jam-laptop> hmm.. both bialix and vila have had problems submitting
<jam-laptop> I haven't tried anything myself
<lifeless> ok, found the issue
<lifeless> it's being rectified by is now.
<lifeless> upstream ISP did naughty stuff to our network
<jam-laptop> thanks
<jam-laptop> ouch
<jam-laptop> didn't like you using 7GB/s for so long?
<jam-laptop> well, that is probably 7Gb/s
<lifeless> plugged a cable where it shouldn't be; knock on effects lead to our mail feedb being disabled.
<lifeless> jam-laptop: I'm offline again for some time LEAN traininig; please phone me or poolie on further issues.
<jam-laptop> k
<Peng> Woah, I have 65 messages from the mailing list in my inbox from after I signed up but before I set up procmail to filter it to another folder. Whee, something to read.
<gotgenes> jelmer: thanks for fixing bug #159111
<ubotu> Launchpad bug 159111 in bzr-svn "bzr-svn can't push, commit to rebound SVN repository" [High,Fix released] https://launchpad.net/bugs/159111
<jam-laptop> Peng: I think you'll find you get more than enough to read from the bazaar mailing list
<jam-laptop> I currently have 4.4k messages since 8/1
<jam-laptop> and 31,376 in my "archive" folder that goes back to 2005-05-08
<Peng> I currently have...167.
<Peng> That's close to 31,376.
<Peng> I didn't know the list was nearly this busy.
<jam-laptop> usually less than 2,000 messages per month, 1k is probably average
<fullermd> Well, this is the week to catch up, while half the list members are off being meetingly.
<jam-laptop> fullermd: next week will be even more so
<jam-laptop> As I go to the conference
<jam-laptop> This week was UDS
<jam-laptop> next week is AllHands
<jam-laptop> Peng: and that doesn't count the "bazaar-commits" list, or the bug list
<jam-laptop> I don't archive the bug list
<fullermd> Yeah, so next week there will be about 6 mails.  The whole week   :p
<jam-laptop> but sometimes it can be as active as bazaar@
<fullermd> Fortunately, I'm on enough other lists to sustain me through these hard times, when I run out of mail reading and have nothing to do but get work done.
<jam-laptop> fullermd: yeah, I used to be on a whole bunch of lists, until it just became too much
<jam-laptop> having BundleBuggy actually contributes to a bit of bloat for number of emails
<jam-laptop> as it likes to send at least 1 extra email per submission
<fullermd> Handy for traffic analysis, though.
<fullermd> I've got an xbuffy watching my bzr mailbox, and when it suddenly jumps by 2 in a sample period (30 seconds), I know somebody posted a [merge].
<jam-laptop> well http://dir.gmane.org/gmane.comp.version-control.bazaar-ng.general is a nice graph of it
<jam-laptop> peaking at close to 60 per day
<jam-laptop> I have the feeling that the last dip was when I was on paternity leave
<jam-laptop> I'm completely wrong, the dip I see was caused by our last conference
<jam-laptop> around 5/26
<dato> siretart: okay, found time right now to upload. I hope you don't mind I use my name for the changelog :)
<dato> siretart: btw, I'm retrospectively adding a tag for 0.91-2 :)
<jelmer> dato: if you're going to upload 0.92rc1, please also upload bzr-rebase 0.2 and bzr-svn 0.4.4
<jelmer> if possible
<dato> jelmer: sure
<dato> I should have some minutes left for that right now
<dato> jelmer: "Depends: bzr (>= 0.92~), bzr (<< 0.92~)" <-- s/92/93/ (the second one)?
<jelmer> euhm, yep!
<dato> all uploaded.
<jelmer> dato: thanks very much
<dato> jelmer: np
<dato> jelmer: a small remark: it's considered good practice, when closing in debian/changelog upstream bugs closed in a new relesae, to say:
<dato>   * New upstream release:
<dato>     + no longer frobnicates your files when bar is set. (Closes: #1234)
<dato> rather than only:
<dato>   * New upstream release (Closes: #1234)
 * dato leaves now.
<jelmer> dato: Ok, I'll keep that in mind fior next time
<jelmer> thanks
#bzr 2007-11-03
<schierbeck> jelmer: ping
<jaavaaguru> Hi, we're trialling using Bazaar in place of SVN in the place I work, primarily because it handles merging, and multiple personal branches much better. Some of my colleagues using Windows have had problems setting up bzr-gtk, and it looks like the problems are GTK related.
<jaavaaguru> One of the guys mailed the list today, but it doesn't seem to have arrived... although that may be something he did wrong
<jaavaaguru> I was wondering if it's worth pursuing a wxWidgets client, as we have other things using GTK, and there are various installations of GTK going around on Windows
<jaavaaguru> (they're mainly looking for GUI diff/merge support)
<Peng> I know you can set bzr to use external diff programs (difftools plugin), and there's probably something for merging too.
<Peng> I doubt anyone would be mad if you made a wxWidgets client, though.....
<jaavaaguru> Peng: really? cool. I haven't seen that yet
<jaavaaguru> I'll have a look now
<jaavaaguru> I may have a look into wxWidgets support in the long term, as I've made a wxWidgets client for one of our internal systems using Python. I'm loving Python and wx seems pretty simple to develop for
<Peng> https://bugs.launchpad.net/bzr/+bug/41435
<ubotu> Launchpad bug 41435 in bzr "Framework for external diff/merge tools" [Medium,Confirmed]
<Peng> difftools and extmerge, apparently.
<jaavaaguru> cool, that will make some of my colleagues happy. I'm pretty happy with the standard bzr diff, and have had no merge problems that I can't solve myself, so I'm happier using bzr than svn so far
<jaavaaguru> I'm in the UK, so it's getting kind of late just now. I intend having a look at Bazaar's API tomorrow. Any suggested URLs?
<Peng> Bazaar has a cool diff algorithm. :)
<Peng> patiencediff.
<Peng> jaavaaguru: I dunno. http://bazaar-vcs.org/
<jaavaaguru> One thing we miss though: being able to ignore changes between CRLF and LF line endings
<jaavaaguru> ;-)
<Peng> jaavaaguru: http://doc.bazaar-vcs.org/latest/developers/HACKING.html , perhaps.
<jaavaaguru> we do mixed Linux/Solaris/Mac/Windows stuff
<Peng> jaavaaguru: Yeah, there are proposals about that, but none of it is finished.
<jaavaaguru> Thanks Peng, sorry if I'm coming across as being lazy just now
<jaavaaguru> If I come up with anything cool, I'll add it to Launchpad along with the CCNet plugin I wrote for Bazaar, and let you guys know
<jaavaaguru> I've been watching the progress of 0.92 on the list... looks very good :-)
<Peng> Yep.
<jaavaaguru> I'm in a team of 6 people within our department and our team has been using bazaar for the last 4 weeks. We're developing a Mono/.Net app, and are using CruiseControl.NET. Seems like some of those choices may be making things difficult for ourselves, but it's all a good learning experience
<jaavaaguru> From my experience so far, I'm all for anything that helps pick up support for bazaar among the Windows guys :-)
<Peng> :)
<keir> jaavaaguru, what choices have made it hard? bzr?
<jaavaaguru> Initially, there was the "we know svn now, and we don't want to change" problem, but now I have a few colleagues using bzr, and they're amazed at how simple merging is compared to svn, and that we can have our own personal branches with no extra effort. That's a big thing for us, as we're developing a project from scratch.
<keir> jaavaaguru, glad to hear that. but you mentioned 'some of those choices may be making things difficult for ourselves'; which choices were those?
<jaavaaguru> Now that all of my team is using it (I'm not the project manager, but he's also using bzr now), the PM is looking for integration with things like KDiff3
<jaavaaguru> ah...
<jaavaaguru> I was meaning the CruiseControl.NET and ASP.NET things
<jaavaaguru> I suggested bzr about a month ago, and once I got some adoption amongst out team, we discovered that our chosen continuous integration tool (CCNet) didnt support it
<jaavaaguru> I got round that by writing a plugin
<keir> jaavaaguru, was that hard?
<keir> jaavaaguru, that quote you had was nice; would you mind if you rephrased it as a quote on bzr / why it's good / etc? to go on bazaar-vcs.org/Testimonials (currently empty)
<jaavaaguru> sure
<jaavaaguru> I'll make an iCal note to do that in the morning and jump back on here to confirm
<keir> jaavaaguru, great! i may not be here but feel free to post it yourself
<jaavaaguru> thanks :)
<jaavaaguru> As we're still in the early stages of adoption, do you think it might be better if I wait until next week where we have to finalize integrating out web app client with our business logic (BL is using bzr, and web app is using SVN at the moment)
<jaavaaguru> we plan on deciding to go with one or the other
<jaavaaguru> (not my choice, i'll be pushing for both parts staying with what they currently use)
<jaavaaguru> I imagine we'll have a decision by Wednesday
<keir> i believe in 'right tool for the job'... depends on your needs
<jaavaaguru> regardless of what happens, all my personal projects at work will be using Bazaar, and I have a reasonable say in these things :-()
<keir> neat!
<jaavaaguru> I'm trying to stay away from the ASP.NET bit... I have worked on it, but it seems like doing MVC development in ASP.NET will be a battle against the system until MS release their MVC framework later this year
<jaavaaguru> even then, it will be a beta, so I'm not holding out for it
 * jaavaaguru is getting to love TurboGears
<jaavaaguru> Anyway, I have that calendar note to review my quote/testimonial, and will do after discussing our way forward on Monday
<keir> jaavaaguru, great. i also like TG. django is nice too.
<jaavaaguru> I've recently put together a TG app that renders our internal API documentation (mixture of Docbook XML and MS's XML documentaiton format) as web pages
<jaavaaguru> as soon as I can get agreement that the company has nothing to do with the non-standard docbook-esque format we use, I'll put that on Launchpad too
<jaavaaguru> I know it's probably not that much use to Ubuntu people, but for people working in a mixture of Windows/Linux, it's handy
<jaavaaguru> thanks keir and Peng, I'm heading to bed. I'll have a good look at this stuff tomorrow
<Peng> Good night. :)
<jaavaaguru> good night
<robcruseme> http://apps.facebook.com/prezident
<jdub> jelmer: which version of bzr-svn should i be using with bzr 0.91?
<jdub> jelmer: i've just updated to the latest in the 0.4 branch, which requires 0.92
<jdub> and rebase doesn't load
<jdub> ah, it needs 0.92 too
<jelmer> jdub: Yeah, they both need 0.92. I believe the bazaar-vcs.org has 0.92rc1 debs
<lifeless> hi jelmer
<jelmer> 'morning lifeless
<lifeless> jerry seems to be having fun with packs
<jelmer> ah, that's good to hear
<jelmer> what about the workflow issues, multi-push/pull?
<lifeless> don't know yet
<lifeless> I did explain that we treated it like a cp -a/rsync of directories situation, and that you did not need a tree per branch
<fredp> hello; I have a local bzr branch of a remote svn repository; I could merge upstream change for a long time but now as I get back to work on this project I get this error message:
<fredp> $ bzr merge
<fredp> Merging from remembered location svn+ssh://fpeters@svn.gnome.org/svn/jhbuild/trunk
<fredp> bzr: ERROR: Repository KnitRepository('file:///home/fred/src/jhdebuild/.bzr/') is not compatible with repository SvnRepository('svn+ssh://fpeters@svn.gnome.org/svn/jhbuild')
<fredp> does anybody know what is happening there, and how I could fix that ?
<jam-laptop> fredp: newer versions of bzr-svn require you to use Knit3 repositories
<jam-laptop> fredp: bzr upgrade --format=dirstate-with-subtree
<jam-laptop> however, you may also need to create a new conversiosn
<lifeless> there is a bzr svn-upgrade command
<jam-laptop> since I'm guessing this is going from bzr-svn 0.3 to 0.4
<lifeless> that jelmer wrote; I believe that that is the recommended way to convert
<lifeless> jelmer: we really need to make this easier; especially if its going to happen in the future. What can I do to make it easier?
<lifeless> brb
<jelmer> lifeless: Make svn-upgrade easier or the rich-root stuff?
<lifeless> jelmer: make the user experience more pleasant when they dist-upgrade
<lifeless> jelmer: and suddenly have a new version of bzr-svn
<lifeless> and no warning
<jelmer> If we do a pull/merge and the remote host diverges, we could check if the local branch contains revision generated with an older version of bzr-svn and warn
<jelmer> another option would be to support multiple versions of the mappings in one instance of bzr-svn
<lifeless> well right now it's hurting folok  we really want to impress - users of svn in gnome
<lifeless> if I was at home I'd start hacking on making it better
<fredp> $ bzr merge
<fredp> Merging from remembered location svn+ssh://fpeters@svn.gnome.org/svn/jhbuild/trunk
<fredp> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
<fredp> but I only did bzr upgrade; I will do bzr svn-upgrade.
<jelmer> lifeless: 0.4 was released ages ago (august 4), why is it such a problem all of a sudden?
<fredp> bzr svn-upgrade
<fredp> Using saved location: svn+ssh://fpeters@svn.gnome.org/svn/jhbuild/trunk
<fredp> bzr: ERROR: Unable to import bzr-rebase (required for svn-upgrade support): No module named rebase.rebase
<jelmer> fredp: You need to have the bzr-rebase package installed
<fredp> jelmer: I came with this; because I went back on an older project; dating back before 0.4, I guess.
<jelmer> ah, ok
<jelmer> fredp: bzr-rebase is part of the distribution if you're running Debian sid, otherwise you should be able to install the plugin from http://people.samba.org/bzr/jelmer/bzr-rebase/trunk
<fredp> jelmer: fails with an exception; http://pastebin.ca/759795
<jelmer> fredp: that looks like bzr-rebase 0.1, it should be 0.2 :-/
<fredp> jelmer: yes, looks debian only has 0.1; I'll get 0.2
<jelmer> fredp: sid has 0.2
<jelmer> http://packages.debian.org/sid/bzr-rebase
<fredp> oh, mirror not uptodate, I'll use another one, damned.
<jelmer> but that also relies on bzr >= 0.92rc1
<fredp> jelmer: it ran fine without error; but now bzr diff lists all files, as removed then added
<fredp> will I lose history if I commit ?
<jelmer> oh, darn - it doesn't fix file ids in the working tree yet
<jelmer> fredp: I'd suggest creating a copy of the branch you've just upgraded
<fredp> I nevertheless commited and tried to bzr merge and got this AssertionError
<fredp> http://pastebin.ca/759808
<jelmer> or removing the working tree in the branch you've upgraded and then creating it again
<jelmer> (bzr remove-tree; bzr checkout)
<jelmer> perhaps we should mark svn-upgrade as experimental for now
<lifeless> jelmer: gutsy release
<jelmer> lifeless: ahh, ok
<jelmer> lifeless: gutsy has bzr-svn 0.4.1!?
<lifeless> yes
<fredp> jelmer: branching off then bzr merge, and it worked.
<lifeless> apt-cache madison bzr-svn
<lifeless>    bzr-svn |    0.4.1-1 | http://au.archive.ubuntu.com gutsy/universe Packages
<lifeless>    bzr-svn |    0.4.1-1 | http://au.archive.ubuntu.com gutsy/universe Sources
<lifeless> the software escaped
<fredp> thanks for your support; I can get to resolving the few conflicts.
<jelmer> fredp: no worries, sorry this process is a bit less smooth than it could be :-/
<lifeless> jelmer: more info
<lifeless> 00:06 < jdub> i pulled in bzr from hardon, but his latest rebase/svn require 0.92
<lifeless> 00:06 < jdub> so it just got beyond a joke
<jelmer> lifeless: they require 0.92 or 0.92rc1, the latter of which is packaged
<jelmer> and they're all three packaged in debian
<lifeless> yes, but gutsy is out, so we're going to have a little bit of a problem getting fixes to users
<lifeless> I'll had rebase to the bazaar-vcs.org packages asap
<jelmer> I'm surprised though that gutsy has 0.4.1 - 0.4.2 was released and packaged for debian on 9 sept, was that already before the UVF?
<lifeless> 9 sept was after UVF I think
<lifeless> ok, bztools -> bazar-vcs.org repo
<jelmer> lifeless: bzr-svn doesn't appear to be on bazaar-vcs.org either
<lifeless> its not
<lifeless> I need to get a svn build for the indings foo for dapper; hmm
<lifeless> perhaps ignore dapper for a bit
<jelmer> Having bzr-svn up would improve the user experience a lot methinks
<jelmer> 71 bugs have been fixed since 0.4.1
<lifeless> ok
<lifeless> I have to do some shopping now; will look into it later
<jelmer> k
<lifeless> jam-laptop: a review of my reconcile stuff would be nice
<lifeless> jam-laptop: if you have time :)
<lifeless> ciao for now
<siretart> dato: no, not at all. Thanks for the upload!
<simony> are there packages for dvc for ubuntu?
<dato> simony: dvc?
<simony> the emacs bzr frontend
<dato> ah. I don't know, sorry.
<simony> don't you have some bzr integration in your editor of choice? :)
<radix> http://pics.livejournal.com/deeptape/pic/000dp4t6/
<mwhudson> radix: awesome
<vila> simony: no package as dvc is currently evolving at  a fast peace, but it is hosted in a bzr branch: http://bzr.xsteve.at/dvc/
<jaavaaguru> Peng, as I was talking about last night, I started writing a wxPython Bazaar client today.
<jaavaaguru> http://sorn.net/~sandyd/blog/bzr-wx-2005.png
<jaavaaguru> It's got init and commit support. moving onto merge support now
<Peng> jaavaaguru: Cool.
<Peng> jaavaaguru: I have to admit that I probably wouldn't use it (unless it was much better at something than the command line), though.
<jaavaaguru> same here
<Peng> Okay.
<jaavaaguru> I'm creating it to make life easier for the Windows users who are used to things like Rapid SVN
<Peng> Hmm.
<jaavaaguru> I have also had some interest from OS X users
<Peng> Maybe I should check out VCS GUIs. GUIs really are better for some things than CLIs.
<jaavaaguru> I like diffing and merging in the GUI, it's usually faster
<Peng> Hm.
<Peng> Well, anyway, I'm AFK. Bye.
<jaavaaguru> bye
<jelmer> jaavaaguru: Have you tried qbzr at all?
<jaavaaguru> I did try, and didn't get far on XP at work. I don't have a PC here to try it on at the moment. I should probably get the error message and try and figure out what went wrong
<lifeless> jam-laptop: also there is a gtk gui as well FWIW
<lifeless> jelmer - you could review teh patch too :)
<jelmer> lifeless: which patch was that, the reconcile one?
<lifeless> yes
<jelmer> voila
<somerville32> Hi
<lifeless> hi
<somerville32> Would it be possible to have it setup so that I have one main branch but then several other branches which are just parts of the pie of the first one?
<somerville32> I'd like to have branches that represent modules in my project and than one big one that puts them all together.
<lifeless> somerville32: the nested tree functionality can do that; its a bit raw right now though. which reminds me... LarstiQ: ping
#bzr 2007-11-04
<somerville32> Hey. I've made Bzr quotes! :]
<lifeless> night all
<Peng> Good night.
<beuno> lifeless, you wouldn't happen to be around, would you?   I'm working with Verterok on some changes to bzrlib we would like included before 1.0, and I can't commit to the bzr's branches anymore. Is there a chance I can get activated again?
<jelmer> beuno: which bzr branch would you like to commit to ?
<jelmer> bzr.dev isn't accessible directly - please send merge requests to the list
<beuno> jelmer, no, we want to uplaod a branch to the group so both of us can commit
<beuno> and it really doesn't make sense to create a new group just for this purpose
<beuno> so we want to upload it to the bzr group, and work on it there
<jelmer> ah, ok
<beuno> (seemed to me like the logical workflow)
<Kamping_Kaiser> would i be able to install bzr on a sparc running debian Etch?
<Peng> If Python runs on it, bzr should have no problem.
<Kamping_Kaiser> thanks
<Peng> Bazaar has some C components for performance, but even if they didn't compile for some reason, it doesn't need them (it'll just be slower).
<Kamping_Kaiser> bzr intalled from backports fine. thanks.
<Peaker> If I decide to reject/destroy a branch in a shared repo, I'll get ghost revisions left, right? Is there a way to clean up such ghosts?
<LarstiQ> Peaker: ghost revisions are the opposite, they are referred to by a branch but don't actually exist in the repository.
<Peaker> LarstiQ: oh, how can that happen?
<LarstiQ> Peaker: after removing a branch you have revisions in your repo that are not referenced instead, and yes you can remove those (although 'bzr gc' still isn't written)
<gsuveg> re
<LarstiQ> Peaker: one very good source for that is branches converted from arch, where it was almost trivial to get to that state.
<gsuveg> bzr-gtk is broken?
<LarstiQ> gsuveg: nafaik
<gsuveg> gutsy and from bzr site
<Peaker> LarstiQ: How can I remove them?
<LarstiQ> Peaker: the remove-revisions plugin
<Peaker> LarstiQ: ah, thanks
<LarstiQ> Peaker: but be careful, that can also create ghosts
<Peaker> LarstiQ: if it can't see all the branches?
<Peaker> LarstiQ: or, how would it cause that?
<LarstiQ> Peaker: if you tell it to remove revisions that are still used
<Peaker> LarstiQ: Oh, I was hoping its more like "gc" :)
<LarstiQ> Peaker: the step of figuring out which ones to use is not automated afaik
<gsuveg> bzr-gtk: Depends: bzr (< 0.91~) but 0.92~rc1-1bazaar1 is to be installed
<LarstiQ> Peaker: right :)
<gsuveg> LarstiQ, sry. me sound like its a bit broken
<gsuveg> apt sources deb http://bazaar-vcs.org/releases/debs/gutsy ./
<LarstiQ> gsuveg: you're talking about specific situations wrt a distribution, your original statement was way broader
<LarstiQ> gsuveg: so that probably means newer bzr-gtk debs have to be uploaded
<LarstiQ> but bzr-gtk itself works just fine
<dato> gsuveg: we're waiting that bzr-gtk 0.92 gets releseased, otherwise it can't be packged :)
<LarstiQ> jelmer: ^^
<LarstiQ> dato: oh well, that might also block a bit ;)
<gsuveg> dato, ah.
<gsuveg> but .91 would work with .92 not?
<Peaker> why is ubuntu bleeding-edge not up-to-date with newest released bzr's?
<gsuveg> dato, and on repo bzr-gtk is only the 0.90
<gsuveg> you can edit the dependecy not ?
<dato> gsuveg: well, it's better not to
<jelmer> LarstiQ, Szilveszter does the releases these days
<gsuveg> i've back to 0.90 what in gutsy is
<LarstiQ> jelmer: k
<lifeless> moin
<ryanakca> Since codebrowse appears to be down, how could I get a file from revision 4 if that file is no longer versioned? I've tried bzr revert -r4 file ... but it complains about not being versioned...
<dato> ryanakca: try bzr cat -r 4 path/to/file >file.v4
<ryanakca> dato: thanks :)
<lifeless> ryanakca: bzr revert -r4 file should indeed have worked;
<lifeless> desperately seeking reviewers
<vila> lifeless: hi :) You have two patches pending revisions, I already expressed my concerns about transport.list_dir, I didn't dig enough reconcile nor packs so far to comment on the second (stage 1 of pack reconcile)
<vila> AIUI you plan to rework the first to avoid list_dir, if that's the case, I'd be happy to give you a +1 if that makes it happen quicker :)
<vila> ghaa, s/revisions/reviews/
<lifeless> vila: well, you know I disagree  on the list_dir usage
<lifeless> there is no technical reason I know of yet to avoid list_dir for writable transports
<vila> lifeless: ha, thanks for the precision, I was wrong then :)
<lifeless> I plan in a future packs format to see if we can remove list_dir
<lifeless> but for the current format there is no alternative
<lifeless> that isn't worse.
<vila> hmmm, so putting the webdav plugin on the back burner still depends on that then
<vila> I'll to monitor that point more closely
<lifeless> still, I'm seeking a reviewer for the stage1 reconcile packs patch
<lifeless> jelmer: ping
<jelmer> lifeless, pong
<lifeless> jelmer: I've looked at the setup.py patch; and it seems less clean to me than th autotools it's replacing
<lifeless> jelmer: I wanted to chat interactivvely about this, because I may be missing something
<jelmer> lifeless: at the moment, the python package doesn't get installed at all
<jelmer> so you're forced to run out of the source tarball
<lifeless> right, so I want to fix that
<lifeless> and I ocmcmented in the bug that I had no objection per se t o moving everything to setup.py if it was a net win; but thats clearly more than just fixing the bug
<jelmer> Also, the dependency on automake just to install a few files is a bit heavy
<jelmer> make check doesn't work currently (for me at least)
<lifeless> what goes wrong ?
<jelmer> let me check
<jelmer> lifeless: never mind, looks like config-manager got deinstalled for some reason
 * jelmer wonders if it'd be a better idea to start from scratch
<lifeless> jelmer: with pqm ?
<jelmer> not with pqm specifically, but the sort of thing I'm looking for myself
<lifeless> a little more detail might help me here :)
<jelmer> I don't need support for baz, config-manager or creating repositories and things like the current testsuite in shell, automake make it hard to add the features I am looking for (bundle support, python gpgv, loading bzr plugins, better status page)
<ubotu> New bug: #160012 in bzr "http urllib hides programming errors related exceptions" [Low,In progress] https://launchpad.net/bugs/160012
<jelmer> perhaps git support
<lifeless> jelmer: so, pqm is getting cleaned up slowly;
<lifeless> pqm does load bzr plugins - the plan is to drop all other VCS upport; support git etc via bzrlib plugins
<jelmer> pqm doesn't load bzr plugins at the right time yet, that's what my other patch fixed
<lifeless> bug #? I'll commit it now
<jelmer> I don't think there's a bug #.. was a merge request I sent to you on may 23
<jelmer> should I resend it?
<lifeless> I've found it I think. one sec, playing with it.
<jelmer> lifeless: We could still ditch autoconf and automake, use a simple Makefile for building the docbook stuff and setup.py for the python-specific things?
<lifeless> PEP8 issues but otherwise fine I think
<lifeless> (VWS after class is needed)
<lifeless> also ou create a heavweight checkout not a lightweight one
<jelmer> lifeless, what about using Makefile for docbook for bug 117197 ?
<ubotu> Launchpad bug 117197 in pqm "Doesn't install required Python package" [High,Fix committed] https://launchpad.net/bugs/117197
<jelmer> lifeless: still alive?
<mc_> how can i tell bzr which editor to use?
<dato> mc_: there are several ways, all explained in the tutorial. basically some environment variables (EDITOR, BZR_EDITOR)
<dato> mc_: and the "editor" option in ~/.bazaar/bazaar.conf
<mc_> ty
<schierbeck> jelmer: pingz0r!
<jelmer> schierbeck, pong!
<schierbeck> what do you think about using commit messages to identify revisions to the user?
<schierbeck> when they have to choose from a revision's parent
<lifeless> that might be nice
<schierbeck> i've sent a branch url to the ml
<schierbeck> have a look and tell me what you think :)
<schierbeck> currently only the toolbar buttons use it
<jelmer> lifeless: see my comments from about an hour ago
<schierbeck> ?
<schierbeck> i only just sent it in
<schierbeck> damn you're fast!
<dato> heh
<jelmer> schierbeck, that was about some pqm stuff
<schierbeck> oh
<schierbeck> :)
<lifeless> jelmer: Sorry, eating etc
<lifeless> I've merged your patch, it's off to people now
<jelmer> lifeless: any thoughts wrt using make+setup.py rather than automake?
<jelmer> lifeless, thanks for merging it
<lifeless> done, revno 172
<lifeless> network here sucks worse than well most things
<lifeless> I don't entirely get the objection to automake; automake isnot huge, it's well understood
<jelmer> It's not really aimed at installing python packages
<jelmer> you'd have to add some magic to find the right directory to install it in, the right python executable to use, etc
<jelmer> also, automake sucks in general imo
<schierbeck> jelmer: don't you think we call the navigation buttons in the viz something other than "back" and "forward"
<schierbeck> it doesn't fit with the visual representation of the history
<schierbeck> i'd rather have "up" and "down"
<jelmer> yeah, up and down sounds fine to me
<dato> but history is *time* independently of how you repreesnt it
<jelmer> I'm not so sure about using commit message to identify revisions
<dato> and time goes forwards and backwards, not up and down
<dato> IMHO :)
<jelmer> there are a lot of people that don't use clear enough commit messages
<schierbeck> jelmer: i still think it's MUCH better than, say, revision id
<schierbeck> and i think it's good enough for now
<schierbeck> until we find something better
<schierbeck> dato: but normal people don't think that way
<schierbeck> they say "i want to go down on this list"
<dato> well. you won't convince me but, alas, I'm not the bzr-gtk maintainer. :)
<schierbeck> user interfaces aren't about what's right, they're about what's right for the users
<schierbeck> :)
<jelmer> schierbeck: I'd rather not experiment like this in the branch that's used for releases
<phanatic> schierbeck: i'm about to release 0.92 and jelmer and i were talking about broken lines (ui option to disable it would be nice to have)
<jelmer> schierbeck: I think revno's would be a better temporary solution
<schierbeck> jelmer: compromise -- revno's *and* messages
<schierbeck> phanatic: i'm working on options ui right now
<schierbeck> jelmer: you have to agree, revids are completely useless for this purpose
<jelmer> yeah, revids aren't useful for this sort of stuff, indeed
<jelmer> schierbeck, I think a combination is a good compromise
<schierbeck> okay
<schierbeck> i'm currently looking at including the branch nick as well
<schierbeck> it works pretty good
<Peaker> is there a way to retroactively delete large files to save space in the repo?
<jelmer> you can remove revisions from history using the remove-revisions plugin
<jelmer> but it's very very slow (rewrites the whole repository)
<Peaker> so if I remove revisions that added large files, the continuations of those will be rebuilt without those large files?
<Peaker> or will the continuations/children just be broken?
<jelmer> In theory, yes
<jelmer> Haven't ever done that yet
<Peaker> yes broken or yes deleted? :)
<jelmer> the continuations will be ok
<Peaker> ah cool, I hope he didnt add more stuff with the big files
<schierbeck> phanatic and jelmer: how should i turn off brokenlines?
<schierbeck> if you could add a gproperty to viz.treeview.TreeView it would be pretty easy
<phanatic> schierbeck: we were pondering about a button on the toolbar which would toggle broken lines (and also remember its state)
<schierbeck> phanatic: i'd rather have it in the menu bar
<schierbeck> people probably won't toggle it every few minutes
<jelmer> schierbeck: that means the menu bar would have to be merged before 0.92
<Peaker> do you think it would be a good idea to create a plugin that removes a file retroactively by recreating the entire history in the repo excluding the addition and any changes to that file?
<phanatic> agreed. but merging the menubar branch just before release wouldn't be a good qa prectice :)
<phanatic> practice
<jelmer> schierbeck: which should really be released asap before bazaar 0.92 is released
<schierbeck> jelmer: okay, we can move it to the menubar after the release
<schierbeck> what persistence backend should we use?
<schierbeck> the conf files?
<jelmer> either the conf files or gconf, not sure what would make the most sense
<jelmer> using the conf files is consistent with bazaar, using gconf is consistent with GNOME
<phanatic> jelmer: gconf is not available on win32
<phanatic> afaik
<jelmer> ok, so we would at least have to support the conf files
<jelmer> guess we can always add gconf support later, if there's a good reason for it
<schierbeck> do we have to reload the treeview when toggling?
<schierbeck> or can it redraw dynamically
<jelmer> reloading would be acceptable for now I think
<schierbeck> okay
<schierbeck> by the way, what do you think about the menubar approach? is it something i should pursue?
<phanatic> schierbeck: from the olive point of view, a menubar on a child window looks quite interesting :)
<schierbeck> phanatic: i know, but i hate olive
<schierbeck> i never use it :)
<phanatic> many people do, love it or hate it :P
<schierbeck> i think it's important that we can set options directly from viz
<schierbeck> such as show/hide columns
<schierbeck> and a go menu really makes sense
<schierbeck> i'm only asking because i'm making some other major improvements on that branch
<jelmer> yeah, we have to keep olive in mind
<phanatic> that sounds reasonable. i don't have any other complaints about the menubar on viz
<jelmer> another option would be to add a LogWindow that is specific to olive and is somewhat simpler
<phanatic> but maybe you could allow it to be disabled
<jelmer> now that we have all the different components available as separate widgets, that should be quite easy
<schierbeck> yup, that sounds good
<schierbeck> i'll continue with my efforts then
<schierbeck> i'd like to switch to using signals and properties only
<schierbeck> the revision-/logview especially is bad
<schierbeck> with a custom callback mechanism
<schierbeck> when's the next release due?
<jelmer> all synchronised with bazaars' releases
<jelmer> s/bazaars'/bazaars main/
<Peaker> it could be nice to pop up kompare as the differ in the "bzr vis" dialog
<phanatic> we agreed to do synchronised releases till bzr 1.0
<dato> and then?
<phanatic> bzrlib should be api stable by then, so we can walk on our own path
<phanatic> jelmer, schierbeck: i'll do a release tomorrow, if you don't mind...
<schierbeck> it's fine
<jelmer> sounds good to me, provided that the broken lines feature can be turned off somehow
<schierbeck> is there a setting one can give to the cell renderer that disables the newish stuff?
<schierbeck> i'm not too comfortable with the cairo stuff
<jelmer> schierbeck: you can specify the behaviour of the broken lines code using a parameter to TreeView's constructor
<schierbeck> okay
<schierbeck> should it be None when turned off?
<jelmer> yes
<schierbeck> okay
<schierbeck> and just hardcoded to 32 otherwise?
<schierbeck> (short-term)
<jelmer> I'm not sure what the best value for it would be, it would depend on the branch I think
<jelmer> I just kept 32 as default since that's what gary used
<schierbeck> okay
<schierbeck> jelmer: what should the toggle button be labeled?
<jelmer> "Compact View" or something?
<schierbeck> okay
<schierbeck> jelmer, phanatic: pushing to lp right now
<schierbeck> i still need to implement persistence
<phanatic> schierbeck: cool
<schierbeck> phanatic: i'd like to have a meeting some time in the not-too-distant future
<schierbeck> about coding guidelines
<phanatic> :)
<schierbeck> things like the naming of callbacks
<schierbeck> there are like 3 different ways being used right now :)
<phanatic> yeah, it would be useful
<schierbeck> i'll send a message to the ml tomorrow
<phanatic> right
<schierbeck> http://bazaar.launchpad.net/~dasch/bzr-gtk/brokenlines
<schierbeck> check it out
<schierbeck> i'll go eat something :)
<schierbeck> jelmer: do you know how to implement the persistence layer?
<schierbeck> i haven't looked at the api
<jelmer> phanatic was looking at that
<schierbeck> okay
<schierbeck> i'll just take a look myself, it seems that phanatic has left
<schierbeck> well, that was pretty easy
<jelmer> you may both be working on the same thing
<schierbeck> well, i'm already done :)
<schierbeck> i've pushed it to the branch
<schierbeck> http://bazaar.launchpad.net/~dasch/bzr-gtk/brokenlines
<lifeless> ola
<Verterok> lifeless, hola
<lifeless> jamesh: hi, how did pending reviews go on further changes ?
<jamesh> not sure
<lifeless> jelmer: we need a better name for olive
<lifeless> jelmer: it's still showing as 'olive' rather than e.g. 'bzr GUI' or something
<jelmer> lifeless: please discuss that with Szilveszter, I don't use/develop Olive
<lifeless> ahha, ok
<jelmer> personally, I would rather see the integration in nautilus improved than having a standalone app
<jelmer> but I think Olive is nice to have too - it's certainly more mature than nautilus-bzr
<schierbeck> jelmer: i agree completely
<lifeless> I agree that iing the nautlius integration is important
<lifeless> s/ii/fixi/
<schierbeck> we need more work on nautilus-bzr
<schierbeck> i should eventually replace olive completely, if possible
<schierbeck> *it
<jelmer> not sure about that - olive also works on Windows and XFCE
<schierbeck> we need better integration with the Windows file browser, too
<jelmer> so there is certainly a place for it, until we get thunar and windows shell integration done
<lifeless> we have a bzr tortoise for inwdows now
<jelmer> lifeless: tortoise isn't anywhere near olive wrt functionality though
<lifeless> till; native UI++
<schierbeck> +1
 * jamesh wonders why all Windows VCS plugins are called tortoise
<jelmer> yeah, I agree
<schierbeck> btw, i got a tango guy working on some icons for us
<jelmer> jamesh: they're all slow
<lifeless> ouch
<jelmer> schierbeck: ah, nice :-)
<schierbeck> thought so :)
<fullermd> I wish one of them were easier to get going, though.  Every time I look at the installation instructions, it makes ME twitch, and I'm the *nix guy.  The idea of trying to point some of the graphicist Windows people I'd want to use it at that installation isn't confidence-inspiring.
<jelmer> we need more people developing on Windows
<fullermd> Or less people running Windows   ;)
<jamesh> by that I take it you mean other people?
<schierbeck> i'm with fullermd...
<schierbeck> hehe
<fullermd> I mean, there can't be more than a billion or so of them, right?  All it takes is a little rounding error to turn 1 into 0...
<schierbeck> how are we doing on OS X
<jelmer> jamesh: Afraid so, yep
<schierbeck> jelmer: should we review and merge the brokenlines-option branch tonight?
<jelmer> schierbeck: as long as it happens before 0.92 :-) Not sure what Szilveszters plans wrt the relaese date are
<schierbeck> i think he wants a release tomorrow
<lifeless> later all, meeting time
<schierbeck> bb
<schierbeck> well, i'm off as well
<schierbeck> see y'all!
<ubotu> New bug: #159997 in bzr "`bzr push` fails with error 530 (login incorrect)" [Undecided,New] https://launchpad.net/bugs/159997
<ubotu> New bug: #160081 in bzr "KnitCorrupt: incorrect number of lines" [Undecided,New] https://launchpad.net/bugs/160081
<siretart> jelmer: is bzr-svn supposed to support push over svn+ssh:// urls?
<jelmer> siretart: yes.
<siretart> jelmer: http://paste.debian.net/41505
<siretart> not sure what's going wrong here
<siretart> svn ls svn+ssh://svn.debian.org/svn/pkg-wpa/wpasupplicant/trunk works at least
<jelmer> siretart: please file a bug
<siretart> ok. what information do you need?
<siretart> (apart from the traceback)
<jelmer> the backtrace should be sufficient
<siretart> ok
<siretart> thanks!
<siretart> filed as bug #160085
<ubotu> Launchpad bug 160085 in bzr-svn "push over bzr+ssh:// crashes" [Undecided,New] https://launchpad.net/bugs/160085
<jelmer> thanks
#bzr 2008-10-27
<poolie> beuno, yes, that does look really nice
<evarlast> anyone run bazaar multi-user server?  you using SSH?  Is there an http option?
<lifeless> evarlast: most folk use ssh
<lifeless> you can use http/https
<evarlast> does loggerhead get me anything there?
<lifeless> loggerhead is unrelated to this
<evarlast> ok, thanks. I didn't know if loggerhead got me anything in terms of server writes.
<evarlast> I think I will go the ssh route, since it seems most popular.
<evarlast> its just we are an all windows shop, and so SSH is a little strange
<lifeless> I know the UK NHS uses bzr on windows
<lifeless> with IIS doing http server for writes
<evarlast> err.. myabe I will do smart server via http
<fynn> beuno: looks like the output of "bzr log" is Yaml.
<lifeless> awilkins that hangs here from time to time may have written up stuff about this already on the wiki
<fynn> I can just parse that.
<lifeless> I know he sent patches is to make it
<lifeless> work
<lifeless> fynn: 'bzr log' ? Its not yaml
<spiv> lifeless: oh, I didn't know about that.  That's cool.
<lifeless> spiv: which 'that' - the git book?
<lifeless> spiv: or the IIS stuf?
<spiv> lifeless: the IIS stuff.
<lifeless> yah, it is cool :)
<spiv> or maybe I did and had forgotten, some thing ;)
<Peng_> beuno: ping?
<Peng_> beuno: Never mind about the ping. I just filed bug 289708.
<ubottu> Launchpad bug 289708 in loggerhead "abstract_paths breaks InventoryUI: 'Container' object has no attribute 'absolutepath'" [Undecided,New] https://launchpad.net/bugs/289708
<Peng_> Oh, that should have a really trivial fix.
<spiv> poolie: I'll call you after lunch
<poolie> good idea :)
<spiv> :)
<spiv> poolie: is now a good time to call?  skype or pots?
<poolie> spiv, hi
<lifeless> poolie: gimme a call when you return
<poolie> lifeless, hi, i'm back, was on the phone to spiv
<poolie> is it urgent or should i finish with him?
<lifeless> not urgent
<poolie> lifeless, want to talk?
<vila> hi all
 * vila is now in winter time
<spiv> vila: hello
<spiv> vila: ah, that's why you're even later :)
<vila> spiv: hehe, this remark was in a large part for you :)
<poolie> hello vila
<beuno> Peng_, thanks
<Peng_> beuno: Great. Thanks for merging it. :)
<philn> hi
<philn> i did a tarball of a branch to move it to another computer but now on the new location i get a ....NoSuchRevision: KnitPackRepository('file:///home/phil/bzr/.bzr/repository/') has no revision phil@base-....
<philn> is there a way to fix that?
<Peng_> philn: Maybe you tarred up the branch but not the repo?
<philn> yep
<philn> is there a way to resync the repo with the branch?
<Peng_> "bzr push"? :P
<philn> haha :D
<Peng_> philn: But I'm not joking.
<Peng_> philn: You could also try again, tarring up the repo too this time.
<Peng_> philn: Use "bzr info" inside the branch to see where the repo is.
<beuno> if you want it to be standaole
<beuno> you probably want to bzr branch from it
<beuno> so you get a standalone branch
<philn> problem is that the repo is at home, i don't have access until the end of the day
<beuno> ah, then you can't really work around that
<Peng_> You should run sshd on your home machine. :D
<philn> bzr reconcile!
<mwhudson> i frigging hate util.Container, fwiw
<Peng_> Heh.
<Peng_> mwhudson: Are you gonna make it go away during the EPIC thing? ;)
 * Peng_ hides
<mwhudson> Peng_: doubt it
<philn> gosh that reconcile thing is taking ages
<luks> what are you trying to reconcile? the missing repository?
<philn> i launched it without args, so i guess... yes
<luks> well, it won't help you
<luks> if you are missing some data, you are missing the data, it can't make them up
<philn> ok, so ... would it be possible to uncommit and recommit? i have like... 3 or 4 "new" commits in that branch
<luks> ok, maybe I don't understand the situation there
<luks> can bzr log should you the revisions?
<luks> *show
<philn> no, bzr log fails
<philn> i think i'll end up doing a diff and recreate the branch from scratch
<luks> can diff show you the revisions?
<spiv> philn: commit and uncommit work on the repository -- the bit that you didn't copy into your tarball.
<spiv> philn: i.e. you didn't copy any of the history.
<philn> ok, let's use the good old diff method.
<Peng_> philn: You have *no* history. You can't do *anything*.
<Peng_> philn: The only thing you can do is create a 100% new branch, completely unrelated to your old one.
<Peng_> philn: There are no other options. You simply don't have the data.
<philn> yep i'll do that, i'll do a diff between the borken branch and the upstream one
<Peng_> Yeah, you can do that. :)
<Peng_> Wait, you have a copy of the upstream branch? What do you mean? With history?
<philn> yes i have the upstream branch, it has evolved a bit since then, but i can work with that
<Peng_> Well, it's not a major catastrophe then. You could make a new branch off of the upstream, commit your current working tree, work work work, and merge it back into your original branch when you get home.
<Peng_> It'll create some cruft in the history (especially if you created any new files), but it won't b a huge problem.
<Peng_> Your other option is to drive home and grab the rest of your data, of course. :P
<Peng_> Or you could just not commit any of your work today, finally doing it when you get home. Not great, but doable.
<Peng_> do-able?
<philn> nah can't wait, that branch is so cool
<philn> can i safely interrupt a bzr reconcile process?
<Peng_> Probably. It made a backup of the repo first, so unless you deleted it..
<philn> ok, thx
<philn> next problem: i do bzr serve on my LAN, but my buddy fails to connect... i have no running firewall
<philn> i don't even see the socket when i do netstat -n
<philn> oh should work now with --port=ip:port
<dissonans> hi
<dissonans> I'm trying to create a bazaar-managed branch of an svn-repository
<dissonans> what's the best way of accomplishing this?
<dissonans> I just tried the svn-push command (of bzr-svn), which failed with an assertion error
<beuno> lifeless, any idea on why I would get a traceback with the latest bzr-search and loggerhead?   http://paste.ubuntu.com/63208/
<beuno> any API changes I should be aware of?
<Peng_> Eh? Traceback? Where?
<[cliff]> hi all!
<[cliff]> is there a way to merge two branches from different repositories? ie. I have two projects that I'd like to merge into one without loosing history on them
<Kinnison> Yes
<Kinnison> (providing certain constraints are met)
<Kinnison> E.g.:
<Kinnison> To take project 'inner', and merge it into project 'outer' such that everything in 'inner' is inside a directory in the merged project, you could do:
<Kinnison> In the 'inner' tree: mkdir inside; bzr add inside; bzr mv everything_else inside/
<Kinnison> then commit that
<Peng_> That's hardly history-preserving..
<Kinnison> then in the 'outer' tree: bzr merge -r 0..-1 /path/to/projects/inner
<Kinnison> That merges the entire of the "inner" project into the "outer" project
<Kinnison> If you look at the branch at http://bzr.digital-scurf.org/trees/managed/aranha/devel then you'll see that branch has several bits merged in together
<[cliff]> Kinnison: looks good, i'll give that one a try, cheers mate
<Kinnison> do it in copies, in case it goes wrong :-)
<[cliff]> Kinnison: no need, it won't break anything -- famous last words lol
<Kinnison> Anyone here know if loom has been updated to work with modern bzr?
<Kinnison> I just upgraded my bzr, and lo, loom stopped working
<Kinnison> :-(
<thumper> Kinnison: ask abentley
<[cliff]> Kinnison: it actually worked flawlessly :-) thanks a lot
<abentley> Kinnison: See lp:~abentley/bzr-loom/stuff
<Kinnison> [cliff]: you're welcome
<Kinnison> abentley: I'll give that a go, one sec
<Kinnison> abentley: Yay, Loom recorded.
 * Kinnison hugs abentley 
<thumper> abentley: ping
<abentley> thumper: pong
<thumper> abentley: can I borrow you for a minutes?
<sven_> hi! when running 'bzr gci' using the latest dev branch of bzr-gtk and the latest dev branch of bzr, i can't write per-file commit comments any more. the text box for per-file commits does not show up when i click on a file in the list to the left.
<EarthLion> hey if i have made a checkout
<EarthLion> how can i remove this?
<EarthLion> can i just remove the .bzr folder?
<EarthLion> will that have any effect on the branch i made a checkout of?
<Verterok> EarthLion: Hi, remove what?
<EarthLion> stop it being a checkout/branch
<Verterok> EarthLion: bzr export /path/to/dest
<Verterok> but you can just remove the .bzr dir
<EarthLion> thanks
<LarstiQ> EarthLion: depending on what you do that may or may not be a good idea
<EarthLion> ../?
<LarstiQ> s/you/& want to/
<epsy> hi, I did not understand what bzr-notify from the bzr-gtk package was meant to do
<epsy> I tried branching off launchpad to try and got no libnotify popup, which is what i expected
<LarstiQ> epsy: there are two parts to commit notification. The listener that does the pop up (bzr-notify), and the broadcaster (lan-notify from bzr-dbus iirc)
<epsy> ah right
<dobey> hey. does bzr use the merge request stuff in launchpad?
<NfNitLoop> dobey: what do you mean by that?
<NfNitLoop> I'm pretty sure a merge request is only stored in the launchpad UI, not in bzr anywhere.
<beuno> dobey, you mean bzr the project?
<dobey> beuno: yes
<dobey> i've made a branch to use $XDG_CONFIG_DIR/bazaar as the config dir instead of ~/.bazaar, and i'd like to propose it for merging into trunk
<beuno> dobey, no, we're not
<beuno> we use bundlebuggy through the bzr mailing list
<beuno> let me find you a link on how to submit vode..
<dobey> ok
<beuno> dobey, http://bazaar-vcs.org/BzrGivingBack
<LarstiQ> dobey: that usually resolves to ~/.config/bazaar, right?
<dobey> LarstiQ: yes, that is the default
<LarstiQ> dobey: cool
<dobey> ooh. and i see there is a bug requesting it too
<dav_> hi, sorry for the easy question, but how can I update an existing branch with bazaar? I tried with "bzr update nameOfTheProject" but it doesn't work, what do I get wrong? Thanks
<Jc2k> dav_: in the branch directory, just do bzr pull...
<dav_> Jc2k, ok thanks, i'm an idiot :) cheers!
<Jc2k> dav_: good luck :)
<poolie> good morning
<poolie> jam, hi
<LarstiQ> hi poolie
<poolie> hi there
<Verterok> mornin' poolie
<poolie> hello .nl :)
<LarstiQ> poolie: are we that special? :)
<fullermd> Well, it's nice to see you there.  Germany might have tripped in the dark overnight and stumbled into you, pushing you into the ocean.
<LarstiQ> :)
<jelmer> lifeless: fwiw, bzr-search made it into experimental (and I'll request a sync for Jaunty when it's open)
<rockstar> jelmer, aren't we in freeze?
<LarstiQ> jelmer: should I try to push a bzr-gtk import fix to lp?
<jelmer> rockstar: Debian experimental isn't :-)
<rockstar> jelmer, ah yes, jaunty.  I was thinking intrepid.
<rockstar> jelmer, is there a PPA for it currently?
<jelmer> LarstiQ: what sort of fix?
<jelmer> LarstiQ: if it's just a simple import fix, just push
<LarstiQ> jelmer: 'import gobject' in bzr-notify
<LarstiQ> now I just have to find my card reader
<jelmer> LarstiQ: heh, ssh key from FSFE card?
 * LarstiQ nods
<rockstar> jelmer, is also, is there a recent PPA build for bzr-svn?
<rockstar> I can't get it installed on this machine, as its on intrepid, with bzr 1.8
<jelmer> rockstar: afaik it hasn't been uploaded to the PPA yet, there is a current package in Debian though
<rockstar> jelmer, so you're not in control of that then?
<jelmer> rockstar: no, I do the Debian packages (which eventually get imported into Ubuntu also), jam does the PPA
<lifeless> jelmer: cool
<zoke> on windows how does ssh and bzr work ?
<lifeless> zoke: I don't know the exact details; what sort of thing are you wanting to know
<zoke> How would I install ssh into my system for this to work ?
<zoke> do I need to install it from cygwin ? do I even need it at all ?
<lifeless> you can use putty
<zoke> ok, I got it, apperently with the standard windows installer bzr comes with it's own stuff for ssh connnections, so I don't need to have ssh installed
#bzr 2008-10-28
<poolie> i'm looking at marius's nick-switching patch
<grettke> Do you guys have a preferred way of migrating svn repos to bzr?
<poolie> grettke, either svn2bzr or bzr-svn (which can also round trip back to svn)
<poolie> i'm not sure, svn2bzr may be better for a one-off conversion?
<poolie> but i'd probably try bzr-svn first
<grettke> poolie: I just tried bzr-svn and it blew up.
<grettke> poolie: I am interested in a one-time conversion.
<poolie>  http://bazaar-vcs.org/svn2bzr
<grettke> poolie: I've got so much cruft in my old svn repo, I wonder if it is worth filtering...
<synic> got kind of a dumb question.  I've got a project that we've been using bzr on for some time now.  We started a new version of the project and instead of creating a branch, we created a new repo.  I'd kind of like to merge the new repo with the old one so that we have a complete version history.  Is this possible?
<Verterok> synic: take a look to: 'bzr help join'
<synic> k
<synic> Verterok: hrmm, I'm a bit confused.  It keeps saying that both trees have the same root id
<Verterok> synic: mmm, maybe using merge?
<poolie> ah, so the new branch should have come from the old one, but did not?
<poolie> try bzr-rebase
<poolie> (reading the btree prefetch)
<synic> ok
<synic> poolie: got an example of using rebase?
<synic> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
<synic> it's the same error I got when attempting to merge
<poolie> actually, is there a reason not to just merge the trees?
<synic> well, no, but I get an error when trying to do that.
<lifeless> synic: so the error about same root
<lifeless> synic: is because join is intended for rich roots
<lifeless> synic: j-a-meinel wrote a plugin
<lifeless> merge-into
<lifeless> which is a less featureful join and should work for you
<synic> it'll preserve the histories of both branches?
<lifeless> synic: yes
<vila> hi all
<poolie> hello vila!
<Rolly> just curious, has there been any progress on supporting nested trees? Last activity I can see was in the middle of 2007
<damohickey> Hello!
<damohickey> First time using IRC. Is anyone else seeing this?
<mwhudson> yes
<damohickey> Hi, Is this an appropriate place to discuss conversion of an Open Source project from SVN to Bazaar or is it about Bazaar development only?
<mwhudson> nope, conversions are definitely on topic
<damohickey> Well this is a hard question to answer but we need to prepare for this eventuality.
<damohickey> I am the leader of an Open Source eCommerce project called Freeway. We use SVN in a kind of interesting way that is not really productive for our conversion from company project to community distributed.
<damohickey> We have a public SVN but that is fed by scripts from a private internal SVN.
<damohickey> I'm just wondering what the impact would be when we move to Launchpad as it seems to logical thing to do now.
<damohickey> By impact, I mean would we have to prepare for lotts of developers wanting to contribute all of a sudden; our project is pretty interesting but not well known now.
<damohickey> We are happy enough for this to happen but want to get some idea of what happens when in the practical world when tightly controlled SVN projects open themselves to distributed version control.
<damohickey> I understand there are multiple other factors involved. Perhaps my question is are there lots of people that wait for new projects using Bazaar in Launchpad, a pent up demand of people as annoyed with SVN as us?
<damohickey> I'm sure this is a trivial concern. It's a different world thinking about distributed version control though. Very interesting, kind of like a new way of transacting with the world.
<luks> people normally don't wait for random projects to open their development model
<luks> even less so bzr users, which are a minority
<luks> if people contributed to your project before they will most likely continue even if you switch to bzr, people who are not interested will not contribute no matter what VCS will you use
<damohickey> A lot of our users (not developers) find it hard to use Torotoise SVN to get new stuff. Is there a particularly good promotional tool we can use to sell people on learning Bazaar?
<luks> honestly, if they find tortoisesvn hard to use, they will probably find bzr impossible to use
<damohickey> In some ways, this just means we have to manage our releases really carefully.
<damohickey> I'm happy enough to move still.
<damohickey> Bye for now. Thanks so much to all you people here who have contributed to the development of Bazaar. It is a really exciting process we are about to embark on. Thanks!
<mwhudson> damohickey: have fun
<dissonans> bzr-svn 0.4.13 is buggy for me on Python 2.6, Windows XP
<dissonans> should I use some other version?
<beuno> dissonans, I don't think that iether bzr or bzr-svn have been fully tested in 2.6
<mwhudson> bzr at least mostly works
<dissonans> I have to use bzr 1.7 due to bzr-svn
<dissonans> I think I only get some deprecation messages in bzr
<dissonans> it's not practical for me to use Python 2.5 on Windows since I don't have the compatible compiler (VS .NET) installed
<dissonans> I tried mingw, but that led to an obscure compilation error in bzr-svn
<evarlast> dissonans: vs.net express is free and may work to compile python 2.5
<dissonans> evarlast: sure, but I don't feel like installing it
<dissonans> I already have VS 2008
<evarlast> oh, it requires 2003 or 2005, but doesn't build with 2008?  I see. I misunderstood.
<dissonans> well, Python 2.5 is built with VS 2005
<dissonans> so I can't use VS 2008 with that version of Python
<dissonans> basically I just want to be able to use Python 2.6
<tvainika> dissonans: why don't you install python2.6 for your own work, and python 2.5 for bzr(-svn)? i think you can install both in parallel
<dissonans> tvainika: that's the problem I explained, I'm not able to compile bzr-svn for 2.5, unless I install VS 2005
<tvainika> dissonans: how about using installer package's bzr-svn?
<dissonans> it's not usable with bzr 1.7.1 at least
<dissonans> I tried
<synic> is the lp: shortcut part of a configuration file or a plugin or something?
<synic> can I add new ones?
<dobey> synic: i think it's from the launchpad plug-in
<synic> dobey: ah, thanks
<luks> synic: you might find bzr-bookmarks useful
<synic> sweet :)
<luks> synic: it will not allow you to add prefixes like foo:bar but instead bm:foo/bar
<luks> not as nice, but does the job
<synic> good enough :)
<jam> Verterok: ping
<Verterok> jam: pong
<Verterok> jam: reading the mail ATM
<jam> Verterok: I just uploaded the update-site stuff, did you get a chance to look at it?
<Verterok> jam: thanks, the version part is just to identify the archive, would be ok if I create a new archive to upload, I just remembered I need to change a xml inside the archive to link to the new url :/
<jam> Verterok: no, now that we have an update site, you are forbidden from ever updating it :)
<jam> sure, whatever you need
<jam> to get it to work
<Verterok> hehe
<Verterok> ok, I'll let you know when I finish updating the zip. Thanks!
<jam> Verterok: if possible, can you create a tarball? It turns out that machine doesn't have zip tools
<Verterok> jam: sure, np
<persia> Good day.  I have a branch of a project.  I recently did a `bzr pull`, and received the message "All changes applied successfully".  I also appear to have a file with the ".OTHER" extension that would have come from a conflict at one point.
<persia> Is there a way to determine when the conflict occured, and whether it still conflicts, or how?
<luks> run `bzr status` to see if it's still a conflict
<persia> That reports a conflict.
<persia> How about determining when?
<persia> Also, should I be able to bzr pull with a success message with a pending conflict?
<luks> I'm not sure how is behaves if there is a conflict and you pull to the branch
<dobey> persia: i would guess that "bzr pull" gives you a success message when there are no new conflicts
<persia> Mostly I'm confused about how I got into this state, and while I know I don't have any changes in the branch that are important, the apparent success message from bzr pull surprises me in the face of a conflict.
<luks> if the pull causes a conflict it would probably say so
<dobey> like, all the new merges were successful
<persia> dobey, That makes sense, although it's a little confusing if one has a branch that one uses to track development done by others which somehow gets out of sync.
<dobey> sure
<persia> For my case, it's just a matter of removing everything and getting back in sync, but I wonder if this is intentional, or if bzr ought provide some warning that things are still not in sync.
<dobey> you probably overlooked a conflict
<dobey> and then did another pull
<luks> the only way pull can conflict is if you have uncommitted changes
<persia> dobey, Right.  Based on the output of bzr status, that appears to be what happened.
<dobey> wouldn't just doing a revert on the conflict fix your problem?
<persia> dobey, perhaps.  I'm not concerned much with fixing my branch.  It becomes useless for me in two days, and is not expected to change in the meantime :)
<dobey> i mean, instead of "removing everything and getting back in sync"
<persia> And luks explained how to determine that I was indeed in a broken state, so as a user, I'm informed.
<dobey> a simple revert should put you "back in sync"
<dobey> right
<persia> So, is this a usability issue?  Should bzr say something when there is a successful pull into an unclean environment, or are users expected to know when the environment is unclean anyway?
<Peng_> Right, "revert" will get you back in sync, though it'll probably leave some garbage files around.
<dobey> well, revert + resolved then :)
<Peng_> If you revert, there's no need for resolved.
<dobey> well, resolved gets rid of the .STUFF files
<luks> except that after revert is has no conflicts to resolve
<luks> so the .STUFF files are just random unknown files
<Peng_> Oh, revert leaves behind the .STUFF files?
<persia> Well, they are listed as random unknown files in bzr status now.
<dobey> well, you can resolved, and then revert
<Peng_> Well, I guess it makes sense.
<dobey> if you just revert, you'll have to rm them by hand i guess
<dobey> would probably be good for bzr revert to do the right thing if the file is a conflict, though
<persia> So I should file a bug asking bzr to do the right thing?
<persia> And what is "the right thing"?
<persia> I'd be happy with just telling the user that the pull succeeded, but there was still a conflict, but I'm not sure if that's "right".
<dobey> well, if the file is in conflict when you do a revert, it should revert and get rid of the extra data files created by the conflict merge
<dobey> ie the .STUFF
<dobey> so there are 2 issues, bzr pull doesn't give you status of existing conflicts not created by the new merge
<dobey> and bzr revert conflictedfile, leaves the conflictedfile.STUFF files around
<luks> I think it should refuse to pull into a tree with conflicts
<dobey> that's one way to resolve the issue, sure
<dobey> it could say "N conflicts created by this merge, M already existing conflicts" also
<dobey> i think either solution is fine
<Peng_> dobey: By default, revert doesn't destroy irreplaceable data. I bet that's why it ignores the .STUFF.
<Peng_> If it just leaves them all behind, someone should make it smarter, but I bet that's the reasoning and it's just that nobody has gone to the effort.
<persia> Peng, Does bzr understand .STUFF well enough to be able to remove when one reverts to before the conflict?
<Peng_> persia: I dunno.
<persia> Because revert-to-trunk with pending conflicts may be fairly unpredictable.  Works for my use case, but I suspect my situation is rare : most people would be intentionally changing files.
<dobey> the reasoning is probably "nobody thought to make it smart for conflicts" yeah
<persia> So there are two bugs?  One about notification on pull into a conflicting tree, and the other about dealing with .STUFF on revert?
<dobey> i think so
 * Peng_ mumbles
<persia> I have the knowledge to file the first one, but I have insufficient information for the second one.  Could someone else file it?
<Peng_> I just tested it. 'bzr revert' does nuke the .STUFF.
<Peng_> It even nukes the .STUFF if they've been modified, which is probably a bad thing.
<dobey> why would anyone modify the .STUFF?
<persia> dobey, partial work to resolve the conflict, interrupted by a meeting, and forgotten overnight, for the user running bzr pull drinking their morning coffee ?
<dobey> you don't just edit the actual file?
<Peng_> What persia said.
<persia> dobey, Dunno.  Personally, I tend to resolve conflicts in a fairly complex web of temp files and patches, but that's probably not the expected behaviour.
<Peng_> Occasionally, if there are severe conflicts, I might edit one side's changes into a .STUFF file instead of dealing with the conflict markers.
<dobey> but if you forgot about the conflict, would you do "bzr revert conflictedfile"?
<dobey> or would you do the bzr pull as you said?
<persia> Conflict markers are often annoying.  Even for a trivial change of a certain class, I'll use "diff foo.BASE foo.THIS > foo; cat foo.other >> foo; vi foo".
<dobey> it seems unlikely that someone would bzr revert willy nilly in your use case. and if bzr pull failed/warned about the conflict, they would probably investigate or remember they were working on it, no?
<Peng_> dobey: Realistically, this all probably wouldn't happen to me.
<Peng_> dobey: But that doesn't mean revert's behavior shouldn't be improved, just that it's low priority.
 * Peng_ goes back to being away.
<dobey> sure
<Peng_> (lunch!)
 * dobey needs to get lunch as well
<persia> notification should resolve 80% of the potential confusion.  The rest is just enhancement
<Verterok> jam: I just mailed the tarball, thanks!
<persia> Thanks for listening.  Please change the contents of 290350 if I have inaccurately described the desired change.
<sven> hi! i'm using the current dev branch of bzr and the current dev branch of bzr-gtk. when running 'bzr gci', i can't enter per-file comments. the text box to enter them does not show up when i click on a file name
<sven> is this a known issue?
<Peng_> sven: Uh, someone (you?) mentioned this yesterday.
<Peng_> Or the day before. I dunno.
<Peng_> sven: I don't know what came of it.
<sven> Peng_, i've mentioned it, but didn't see any reply
<Peng_> Ah.
<Peng_> You might get more attention if you filed a bug. Shrug.
<sven> Peng_, ok, just thought i'd ask more informally before doing that.
<jelmer> sven, afaik you have to enable them explicitly
<Peng_> sven: You're right, but if that isn't working...
<Peng_> Oh, ok. :)
<sven> jelmer, how do it enable per-file comments explicitly?
<jelmer> sven: did you set per_file_commits to true in the config?
<sven> jelmer, hmm, no it's off. that should explain it. i have no idea why it always worked before
<sven> jelmer, it works now. thanks!
<Peng_> That was a quick fix. :)
<ronny> hi
<ronny> i think i missused bzr svn-import - used it on some svn, now i got a repo with no branches - is there a way to get a branch, or should i restart different
<Peng_> ronny: ...What do you mean "no branches"? There's nothing but a .bzr directory? If you mean that the branches don't have working trees, use "bzr co" inside a branch to create it.
<ronny> Peng_: there is no branch
<lifeless> ronny: can you run 'bzr branches'
<ronny> no
<Peng_> That's part of bzrtools.
<ronny> hmm, dammit - i just noticed im also still on bzr 1.6 from intrepid
<ronny> bzr branches has no output
<ronny> ls .bzr/ -> "branch-format  branch-lock  README  repository  svn-import-revision"
<ronny> hmm, ok, i retry with bzr clone now
<luks> I wish somebody would remove the clone and get aliases from bzr branch
<jelmer> ronny, if you want to import a single branch, use "bzr branch" rather than "bzr svn-import"
<seb_kuzminsky> hi folks, can launchpad show me a merge history like this:
<seb_kuzminsky> http://cvs.linuxcnc.org/cvs/emc2/src/emc/kinematics/tp.c?graph=1
<ronny> jelmer: ok
<seb_kuzminsky> i want to see the history of a file: on which branches were commits to this file made?
<seb_kuzminsky> is that in bzr or launchpad somewhere?
<dobey> bzr-gtk has some sort of merge graph display thing, that might do what you want
<seb_kuzminsky> "bzr graph-ancestry" is pretty close
<seb_kuzminsky> is there a view like that on lp?
<asabil> seb_kuzminsky: try "bzr vis"
<seb_kuzminsky> graph-ancestry seems to have an html output mode...
<dobey> i don't think lp has graphing stuff like that
<seb_kuzminsky> asabil ftw!
<seb_kuzminsky> thanks :-)
<seb_kuzminsky> now if only lp had something like that so I could easily show the CVS folks i'm trying to convert to bzr ;-)
<asabil> seb_kuzminsky: you can always give an url to bzr vis
<asabil> bzr vis lp:~user/project/branch
<seb_kuzminsky> right...  they dont have bzr installed, i'll take a screenshot of bzr vis on my machine and show them that
<seb_kuzminsky> they're still in this "central server does everything" mindframe...
<dobey> well, lp is just a central server
<dobey> but it's a tools thing. they are all just tools. some are better than other for somet things :)
<dobey> i still prefer svn for various things
<seb_kuzminsky> they're comparing lp to cvsweb, which provides a web interface pretty similar to "bzr vis"
<seb_kuzminsky> http://cvs.linuxcnc.org/cvs/emc2/src/emc/kinematics/tp.c?graph=1
<seb_kuzminsky> with mouse-overs and links and stuff, it's pretty good
<dobey> eh
<seb_kuzminsky> <shrug>
<lifeless> so I think someone should file a bug on loggerhead for a per-file view
<seb_kuzminsky> sure, i'll be happy to do that
<seb_kuzminsky> hm, "bzr vis" is confusing me a bit
<seb_kuzminsky> i thought the color of the dot represented the branch, but that doesnt seem to be the case
<seb_kuzminsky> lifeless: ok i filed the bug: https://bugs.launchpad.net/loggerhead/+bug/290475
<ubottu> Ubuntu bug 290475 in loggerhead "please add a per-file view of ancestry" [Undecided,New]
<seb_kuzminsky> heh
<lifeless> thanks
<lifeless> mneptok: btw
<lifeless> mneptok: I haven't heard boo about the search stuff
<poolie> hullo bzristas
<lifeless> I'll have a long black
<Rolly> Anyone know if nested branch support is still being worked on?
<HomingHamster> hello everyone
<HomingHamster> i'm running mac 10.5, i've installed bzr from the mac install package. and i've also installed the eclipse plugin by adding it a s an update site in eclipse. the only thing is, i can't fnid where bazaar has been installed. whereis bzr returns nothing.
<HomingHamster> wow, pretty quiet...
<HomingHamster> am i missing some major thing?
<mlh> BasicOSX: ^^
<mlh> I don't know whether there many OS/x users here
<BasicOSX> I run bzr from bzr
<BasicOSX> I did not install it from package I got it via bzr it's self
<BasicOSX> but it should be in /usr/local/bin/
<mneptok> lifeless: weird. the Codethink guys really wanted to see you in Boston.
<BasicOSX> Which is a symlink to /Library/Frameworks/Python.framework/Versions/
<lifeless> mneptok: huh
<lifeless> just had a power brownout :(
<lifeless> vila: hi
#bzr 2008-10-29
<spiv> poolie: if you're doing reviews, a review of http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20081027005419.GA20736%40steerpike.home.puzzling.org%3E would be good.
<poolie> spiv, ok
<poolie> am doing mail atm but will try to get to it
 * spiv fires some branches to the mailing list and goes to lunch
<pdf23ds> extmerge doesn't like me. :(
<pdf23ds> Unable to load plugin u'extmerge' from u'C:/Program Files/Bazaar/plugins'
<spiv> pdf23ds: try "bzr -Derror ...", or look in your bzr.log (see "bzr --version" for its location) to get a traceback that may explain why.
<spiv> pdf23ds: if nothing else, the traceback will be useful in a bug report against extmerge :)
<pdf23ds> OK, I think it might have something to do with abently's commit yesterday.
 * spiv really goes to lunch now
<pdf23ds> AttributeError: 'dict' object has no attribute 'register_lazy'
<pdf23ds> But thanks for the tip.
<pdf23ds> How to change the tree to an old rev?
<pdf23ds> Just my luck to have a commit yesterday break me on a project that hadn't seen any commits since March.
<pdf23ds> bzr up -r x?
<pdf23ds> bzr revert -r x
<pdf23ds> crazy australians. going to lunch at 9 PM.
<pdf23ds> Anybuddy know how to resume when you get conflicts with the replay command?
<pdf23ds> rebase-continue?
<lifeless> pdf23ds: does the help tell you?
<pdf23ds> bzr replay help is empty.
<pdf23ds> and bzr rebase help doesn't say explicitly.
<pdf23ds> I filed a documentation bug. :)
<pdf23ds> In the meantime I guess I'll try and see what happens.
<pdf23ds> It sort of acts like continue might do the right thing, tho -abort and -todo complain that you're not rebasing.
<pdf23ds> Hmm. I didn't mess as much with Mercurial, but Bazaar seems much rougher-around-the-edges than Mercurial. But I still like it more.
<pdf23ds> And OTOH, I just ran into a Subversion bug today with the latest version.
<pdf23ds> (Couldn't merge a path with spaces over https protocol, works over svn protocol. Weird.)
<lifeless> meep
<lifeless> please file a bug
<pdf23ds> About replay you mean? Where should I file that?
<pdf23ds> https://bugs.launchpad.net/bzr-rebase/ ?
<pdf23ds> (The merge thing was a SVN bug I just got hit by today.)
<lifeless> about the https file with spaces thing
<pdf23ds> yeah, that's svn.
<pdf23ds> I had the same reaction.
<lifeless> a bug on bzr-svn would be good for that; it may be something jelmer has msised
<pdf23ds> It wasn't related to bzr, I mean.
<pdf23ds> I work with SVN during the day, I'm converting my home projects to bzr.
<pdf23ds> I won't be able to get my job using bzr until TortoiseBZR is mature, and until I convince my coworkers of the joys of branching.
<jonoxer> Hi party ppl, I seem to be having some problems with interop between bzr v1.3.1 and v1.6.1 but only on some branches.
<jonoxer> Most of our dev machines (and the repo) are on Hardy, with bzr 1.3.1. But on a certain big repo when I try a checkout with v1.6.1 (on Intrepid) it first complains about the server not understanding net protocol 3, then falls back to an earlier protocol, then sits for a minute or two, then bombs with a traceback like this:
<jonoxer> File "/usr/bin/bzr", line 119, in <module>
<jonoxer> sys.stdout.flush()
<jonoxer> ValueError: I/O operation on closed file
<jonoxer> ...which looks like a permissions problem, but I don't think it is
<jonoxer> because checkouts work fine from Hardy machines
<jonoxer> Any suggestions where to look? I tried with -Dhpss and it didn't provide any more detail
<pdf23ds> Hmm. Maybe I don't need replay after all. Rebase might do the job.
<lifeless> jonoxer: I don't think its interop
<lifeless> jonoxer: 1.6 has some memory issues; try 1.8
<jonoxer> lifeless: so maybe it's a problem with this particular client
<jonoxer> lifeless: OK, I'll give it a shot
<pdf23ds> Nope, rebase requires a common ancestor too.
<pdf23ds> Revision 0 isn't considered a common ancestor, right?
<pdf23ds> bzr branch A B -r 0 is the same as bzr init B?
<lifeless> pdf23ds: nearly the same; branch will preserve the specific format whereas init will use the current default
<lifeless> this only matters if either the source branch uses a very new feature, or you're interoperating with clients much older than yours
<pdf23ds> lifeless: Well, it matters if you want to merge those branches later and find out it can't be done.
<mkanat> Wow, bzr doesn't like it when my local commits are identical to upstream commits, and I do a "bzr up".
<mkanat> Almost everything showed up as a conflict.
<lifeless> mkanat: it shouldn't conflict there; unless you added files
<jonoxer> mkanat: when you say "identical", do you mean the files actually are identical? As in the same checksums?
<mkanat> jonoxer: No, I have local uncommitted changes in addition to the local commits.
<mkanat> jonoxer: Also, the upstream files may have different permissions than my local files.
<lifeless> permissions shouldn't be an issue there; its likely the local changes
<lifeless> mkanat: but there are some things update does that make conflicts worse than they should be
<mkanat> Yeah, that's probably what I'm running into.
<mkanat> I was just surprised, didn't know if you guys knew it behaved that way.
<mkanat> It's not that bad, I have my local changes as a patch elsewhere and I can just revert and re-apply them.
<jonoxer> lifeless: I've just upgraded the problematic machine to bzr 1.8.1 (package from ppa) and it still bombs out on a checkout from the same repo
<jonoxer> The error message is identical to with 1.6.1
<jonoxer> The repo is shown as "Shared repository with trees (format: pack-0.92)" fwiw
<jonoxer> The branch I'm checking out takes about 7.8G on disk, in case that's relevant
<lifeless> jonoxer: hmm, perhaps we haven't landed the patch yet
<jonoxer> lifeless: think it's worth trying 1.3.1 on that machine? That's what we're running on every other box, and it works fine
<lifeless> jonoxer: I suspect it will work, yes
<Rolly> I'm surprised bzr-loom isn't listed in http://bazaar-vcs.org/BzrPlugins
<jonoxer> lifeless: it seems to be working (1.3.1 on Intrepid)
<lifeless> jonoxer: the memory patch may not have landed; or it may be something else
<lifeless> jonoxer: please file a bug
<jonoxer> No problem, done (Bug #290558)
<ubottu> Launchpad bug 290558 in bzr "bzr v1.6.1+ crashes when checking out large branch from v1.3.1 repo" [Undecided,New] https://launchpad.net/bugs/290558
<poolie> spiv, i agree with your comments on the hooks doc patch, so i'll apply them and merge it
<spiv> poolie: great
<poolie> i still find your nickname kind of bizarre :)
<spiv> I should trawl a dictionary for more flattering four letter words that are unlikely to already be registered on popular services...
<poolie> http://newmatilda.com/2008/01/17/attack-spivs
<poolie> excuse the distraction
<poolie> "They no longer sport pencil-line moustaches and porkpie hats, but their tell-tale signs give them away - their faux Italian pointy-toe shoes and the hairstyles sculpted into those absurd little tufts. "
<poolie> indeed :)
<spiv> Oh, I don't mind being distracted.
<spiv> That's the problem ;)
<poolie> (:
<lifeless> night all
<poolie> cheerio
<poolie> spiv, can you look at my reply there quickly?
<poolie> by quickly i mean 'it should not take long' not 'urgently'
<spiv> poolie: the reply to the hook docs patch?  Looks good to me.
<poolie> thanks
<poolie> i'll send it in
 * spiv -> yoga
<spiv> (and hacking on the train)
<poolie> i'm going to stop in a bit
<vila> hi all
<matkor> Hi ! Is there bzr-gtk release 0.96 ?  I see in maillist: Status: Fix Committed => Fix Released Â Target: None => 0.96.0 but nothing about 0.96 on http://bazaar-vcs.org/bzr-gtk ..
<vila> matkor: 0.96.0 is where the commits are made to *prepare* 0.96 :)
<vila> matkor: i.e. the trunk, a specific branch will be made once 0.96 is out I think
<matkor> vila: Ok.. so status (Fix Committed => Fix Released) change is misleading ? shoudl be left on Fix Committed ?
<vila> matkor: committed means the fix is available somewhere, released means it's merged on trunk
<matkor> ah ... thanks a lot for explanation, vila
<vila> you're welcome and not the first one needing the explanation which indicates something should be changed though...
<matkor> vila: Perhaps: Fix Commited ->  Fix merged mainline (or Accepted to next release) -> Fix Released (in official version) could  be more self-explenatory ...
<vila> The last step means that releasing a version requires an additional step whereas the actual usage doesn't... Most of the users will update only when a new release is announced and are unaware of the subtle difference. I know there is work in progress to somehow automate that step but I forgot the details
<Odd_Bloke> Presumably launchpadlib will allow it to be done (if it doesn't already).
<thumper> Odd_Bloke: what was that?
<Odd_Bloke> thumper: Marking bugs as Fix Released when an actual release happens.
<thumper> Odd_Bloke: ah
<Odd_Bloke> thumper: A better fix might be to fix the bug statuses though. ;)
<thumper> heh
<thumper> I'd say that a fix is "in progress" until it is landed on trunk
<thumper> but hey, that's just me
<thumper> I did manage to get an hg->bzr convert last night
<thumper> just with "versioned directories" and "bzr shelve"
<Odd_Bloke> Well, 'we' (i.e. bzr) do (In Progress) --submitted for review--> (Fix Committed) --merged--> (Fix Released).
 * thumper nods
<james_w> congratulations jelmer
<thumper> lifeless: ping
<jelmer> james_w, thanks, but with what ? :-)
<james_w> heh :-)
<Odd_Bloke> jelmer: I'm guessing for your AM report...
<jelmer> ah, I wasn't aware that was announced someplace
<Odd_Bloke> jelmer: debian-newmaint list.
<LarstiQ> jelmer: you know https://nm.debian.org/nmstatus.php I guess
<jelmer> Odd_Bloke, ah, thanks
<jelmer> LarstiQ, I don't expect (hope?) James to check that on a daily basis :-)
<LarstiQ> jelmer: James has resigned from DAM work afaik
<LarstiQ> oh, james_W
<LarstiQ> sorry :)
<LarstiQ> jelmer: yeah, debian-newmaint
 * LarstiQ takes this as a clear sign he should do something about breakfast
<jelmer> LarstiQ, :-)
<Odd_Bloke> jelmer: Also on a Debian related note, is there any documentation about how to use the pkg-bazaar repository?  I haven't been able to work it out, and I have an ITP for bzr-xmloutput sitting around.
<jelmer> Odd_Bloke, basically, we have one repository on bzr.debian.org per package
<jelmer> and then one branch per debian distribution (unstable, experimental)
<jelmer> the branches are bzr builddeb branches, and should ideally contain the upstream source plus debian/ directory and any necessary changes
<Odd_Bloke> jelmer: Bug 290664 is the one I promised to file a couple of days ago.
<ubottu> Launchpad bug 290664 in bzr-svn ""Can't get entries of a non-directory"" [Undecided,New] https://launchpad.net/bugs/290664
<jelmer> Odd_Bloke, thanks, I hope I can have a look at it during the weekend
<Odd_Bloke> jelmer: I have commit access, so if there's a way I can fix the repository using that I'd be happy to do so.
<jelmer> Odd_Bloke, it should be possible to add a fix for this to bzr-svn, I just need some time to analyse what's going wrong
<Odd_Bloke> jelmer: Cool, I really meant if a repository fix would be possible sooner, then I'd like to do that. :)
<jelmer> beuno, loggerhead made it into experimental btw
<beuno> jelmer, I saw!
<beuno> I've been spying
<beuno> thanks  :)
<jelmer> :-)
<jelmer> you're welcome
<jelmer> I hope we can now help get it running on bzr.debian.org
<beuno> oh, I didn't know they needed help
<beuno> let me know if I can do anything at all
<jelmer> will do
<jelmer> thanks
<davi_> what is the easiest way to search for a revision that removed a couple of lines?
<EarthLion> hey can i revert a single file to a specify version using bzr revert -r 46 foo.py ?
<pdf23ds> jelmer: abently's latest commit to extmerge breaks it on 1.8. I had to figure that out myself after branching.
<jelmer> pdf23ds, ?
<jam> vila: ping
<vila> jam: pong
<jam> hey, want to chat about the inventory stuff?
<vila> sure
<jam> I haven't heard any background to know if robert's idea is corerct
<jam> hi asmodehn
<asmodehn> hey hey jam ;-
<asmodehn> ;)
<jam> I'm a bit surprised you sent the .bzr.log to the list, but I suppose filenames aren't particularly private
<jam> it does give me a little bit of insight into your game, though :)
<asmodehn> oh did I ^^
<jam> you certainly have a very *wide* tree (lots of files)
<jam> approx 30k
<asmodehn> nah I only sent it to you I think ;-)
<asmodehn> dont scare me like that :-p hehe
<asmodehn> anyway as you can see I dont use bazaar to store the source code, but rather distributing different version of it in differnt locations
<asmodehn> which explains the size and the latency I am dealing with..
<jam> asmodehn: you're right, I wasn't looking at the folder I was in
<asmodehn> but yes lots of big files
<asmodehn> the repository with working trees is now 24GB
<asmodehn> so whenever I doa  branch it takes some time :-p
<asmodehn> especially when it s remotely
<asmodehn> I also have scripted the beginning of an automated framework on top of it, to keep different location in sync, with web interface, etc.
<asmodehn> just a beginning :-p
<asmodehn> also because of the size of it my disk is pretty full now, not sure I can do a lot of tests ... I am lacking backup space...
<jam> well, if you want to try my "convert_to_dev2" script, you can actually just use a hardlink of the old repository
<jam> and the only new data will be the indices
<jam> which is small meg
<jam> rather than 24GB
<asmodehn> mmm ok.. no need to upgrade before at all right ?
<asmodehn> ha yeah ok this is doing the upgrade... ok I ll do that then and let you know...
<jam> so I should say maybe 10MB or so, but that is pretty trivial next to the 24GB. But I would only do it on a copy
<jam> for now
<jam> then again
<jam> I could just write you the reverse script
<jam> to convert them back
<jam> not to mention my convert_to_dev2 script leaves them lying around, IIRC
<asmodehn> thats good enough then, if I can put tehm back somehow ;-)
<asmodehn> I have remote backups if needed
<jam> yeah
<jam> the script creates new indices
<jam> and just moves the old one out of the way
<jam> without deleting it
<jam> I just verified that
<asmodehn> "python convert_to_dev2.py" and thats it correct ?
 * asmodehn just a bit scared :-p hehe
<asmodehn> jam : ok running...
<jam> you have to have "bzrlib" in your python install, but it sounds like you do
<jam> I'm looking at it now
<jam> just for your comfort
<asmodehn> thanks ;-)
<asmodehn> jam : ok done ^^ pretty fast
<jam> yeah, that is all you needed to do
<jam> asmodehn: again, rewriting 20MB isn't bad versus rewriting 24GB
<asmodehn> ok but I changed only the repository I am branching towards, not the repository I am branching from..
<asmodehn> do I need to do that too ?
<asmodehn> yep :-)
<jam> the one you are branching *from* is the important one
<asmodehn> yeah I would have guessed so....
<asmodehn> mmm hang on...
<jam> I'm also not 100% sure if you need my prefetch code
<jam> Are you comfortable running bzr from source instead of from an install?
<jam> (it isn't very hard)
<asmodehn> mmm it should be ok, but I really want to avoid to mess up my repositories too much
<asmodehn> so I guess I ll try one thing at a time ;-)
<asmodehn> but yeah I could do that...
<jam> it doesn't change the disk formats at all
<jam> *just* how we access it
<jam> but start with this
<jam> see what happens
<asmodehn> k
<jam> and then we'll try that as the next step
<jam> also, can you run a quick command for me
<asmodehn> sure
<jam> find .bzr -name "*.?ix" -print0 | xargs -0 du -kshc
<jam> I think that is right
<jam> let me run it here
<jam> yeah, that works
<asmodehn> ok on which repo ?
<asmodehn> the source one right ?
<jam> the one you just upgraded
<asmodehn> ah ok
<jam> you could do the source as well
<jam> I mostly just want to see how big your indexes were
<jam> versus how big they are in btree format
<asmodehn> oh ok
<asmodehn> I l send hte result in email ot you ;-)
<asmodehn> done
<asmodehn> ah I have enough space on the disk of the source repo to back everything up :-) good news ;-)
<asmodehn> backup everything ^^ sorry me english bad :-p
<asmodehn> I m doing that now then I convert to dev2 as well so I can try the branch again...
<dstanek> how do i revert a commit? is it the same way that you do it in subversion? merge the changes between new and old back into the working copy?
<asmodehn> bzr uncommit is your friend ;-)
<asmodehn> if you really want to lose your commit
<jam> asmodehn: so from what I can see, your 31MB text index becomes 9.1MB in btree form
<jam> and your 14MB => 4Mb
<jam> MB
<jam> which is good
<asmodehn> yep wouldnt hurt ;-)
<asmodehn> if we want to add log to the data transfer, I would need to run bzr from source and modify it right ?
<dstanek> asmodehn: great thanks, i'll take a look
<asmodehn> cause at the moment the log doesnt display nothing while the process seems to be stuck...
<asmodehn> dstanek : no worries ;-)
<jam> dstanek: you could also do "bzr merge -r 10..9" if you want to revert something old
<jam> but yeah, 'bzr uncommit' is probably what you want
<jam> if it was recent
<jam> (as in the last commit)
<jam> asmodehn: so the index seems to go from almost 70MB to down to 30MB, which is about what I would expect.
<jam> Also, it does look like this repository could stand to have "bzr pack" run
<jam> Though I'll mention that running it after the conversion means we don't have a simple way of bringing the indexes back
<dstanek> it look like uncommit can also take a -r argument - will it work if you specify a revision that is not the last?
<jam> dstanek: it will uncommit everything back to that revision
<jam> not just the changes for that rev
<jam> for something old
<dstanek> ah i see
<jam> you want "bzr merge -r REV..REV-1"
<jam> sorry
<jam> you want "bzr merge . -r REV..REV-1"
<asmodehn> yeah I was thinking about that too... but I wonder if that might make one big pack, and therefore we might lose some details in debugging what is wrong in the data transfer
<jam> the '.' is important
<jam> asmodehn: it will create 1 big pack
<jam> so we can look at that more later if you prefer
<dstanek> jam: uncommit works for my immediate need
<asmodehn> jam : also having one huge pack might not be good for me if there is no way to track the progress of the download...
<asmodehn> I prefer downloading slowly but know that it s working ;-)
<asmodehn> btw, same thing, is there an incremental pull / push ?
<asmodehn> revision by revision ?
<jam> asmodehn: 'bzr push -r X", "bzr push -r X+1"
<asmodehn> yes but when I have 123 revision to push one by one because they are big and they might fail, I dont want to type that 123 times ;)
<asmodehn> was thinking of a "bzr ipush -r REV..REV " that will push revision one by one
<asmodehn> and if it breaks in the middle, the last push that worked is still there...
<asmodehn> but maybe that belongs more in a script around bzr than bzr itself
<asmodehn> jam : ... my backup copy on the source repository is still going...
<jam> asmodehn: for i in `seq REV..REV`; do bzr push -r $i; done
<jam> sorry
<jam> for in `seq REV REV`; do echo $i;  bzr push -r $i; done
<asmodehn> yeah thats what I meant ;-)
<asmodehn> but you want to check for error and stuff, so I ll gues I ll write a script for that...
<asmodehn> eventually
<asmodehn> at the moment I am pulling revision 10 by 10 to know a bit where I am at...
<jam> well, I'll mention that some of the data transferred is forgotted by the next copy
<jam> so it will be slower
<asmodehn> yep I start doing that when using 1.5, because for long transfer it used to error out
<asmodehn> where few by few it was working
<asmodehn> and since I upgraded to 1.8 it doesnt error as much which is good ;-)
<asmodehn> but it seems to get stuck longer for smoem reason :-s
<jam> 1.8 will switch to grabbing whole indexes from time to time, which might be what you are seeing
<jam> 1.5 would only grab incrementally
<jam> but could end up grabbing 2x the inventory under certain circumstances
<jam> the dev2 format solves both of those issues
<asmodehn> cool ;) good to know
<asmodehn> backup copy almost finished...
<jam> asmodehn: how's it going?
<asmodehn> jam : branching now...
<asmodehn> conversion went without problems
<jam> you're using -Dhpss for me, right?
<asmodehn> yep
<asmodehn> but looking at the log... the copy of the index is fine...
<asmodehn> looks like the copy of the pack doesnt generate a lot of transfer on teh network though.. I am a bit confused...
<jam> copying the pack should be saturating your network
<asmodehn> my pick is 1.2Kbps now ...
<jam> are you sure about that?
<asmodehn> looking at iftop onthe source network now..
<asmodehn> source server I mean
<asmodehn> it was high up during indexes
<jam> my only other guess is that you are running into swap issues on the source
<asmodehn> oh^
<asmodehn> mmm I ll check my RAM..
<jam> as we are trying to copy 20GB across
<asmodehn> nope everything looks fine
<asmodehn> source :
<asmodehn> Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
<asmodehn> Mem:   3366488k total,  3221756k used,   144732k free,     1672k buffers
<asmodehn> Swap:  2650684k total,   702536k used,  1948148k free,   558160k cached
<asmodehn> dest :
<asmodehn> Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
<asmodehn> Mem:   6110456k total,  5198228k used,   912228k free,    78484k buffers
<asmodehn> Swap:  1951888k total,       72k used,  1951816k free,  4550312k cached
<asmodehn> and I am still branching -r1 from a repo on source_dev2
<asmodehn> \ [=============================                    ] Copying content texts 3/5
<jam> 700MB in swap seems like a lot to me
<jam> but I don't know what load you run on that server
<asmodehn> well these server are running a bunch of other things ^^
<jam> so you are still seeing very little data being copied, right?
<asmodehn> but that swap used is not increasing right now anyway
<asmodehn> no transfer ont eh network
<asmodehn> well very little
<asmodehn> and with -Dhpss
<jam> you might try top of the running process as well
<jam> it is also possible that your disks are being heavily loaded ATM
<asmodehn> log stuck at 85.410     result:   ('readv',)
<asmodehn> 105.947                1099613 body bytes read
<asmodehn> 108.023  hpss call w/readv: 'readv', '/home/autobzr/deployBZR_dev2/.bzr/repository/packs/f65de233ce31cbdace7370611f49937c.pack'
<asmodehn> 108.024                11675 bytes in readv request
<jam> asmodehn: can you send  the 'ls' results for the remote repository?
<jam> I would assume that is a big file, but it isn't in the listing you sent
<jam> (since that is the local repo)
<asmodehn> this pack is 1.1GB
<asmodehn> source :
<asmodehn>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
<asmodehn> 12072 autobzr   20   0 1925m 1.9g 2404 S    0 58.4   0:03.46 bzr
<asmodehn> dest:
<asmodehn>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
<asmodehn> 25889 autobzr   21   0  228m 159m 3956 S    0  2.7   0:06.94 bzr
<jam> so it is consuming 1.9GB, which may not be terrible, but isn't a great sign
<asmodehn> yep
<jam> mostly for when you hit the 20GB files
<jam> It is possible that is taken up by other info
<jam> but I'm expecting it is the actual data that will be transmitted
<jam> asmodehn: I think it is going to have serious problems soon. I'm seeing:
<jam>         backing_bytes = ''.join(bytes for offset, bytes in
<jam>             self._backing_transport.readv(self._relpath, offsets))
<jam> which means... "read the requested bytes, and buffer it into a single string"
<jam> and return that
<asmodehn> ah...
<jam> aka, buffer 20GB in RAM before sending it over the wire
<asmodehn> that will not work :-p
<jam> so... the specific issue is that since 1.6 we are able to request the streams for multiple files simultaneously
<jam> in 1.5 we could only request one file at a time
<jam> which makes things way faster in most cases
<jam> but in your case
<jam> it means we end up requesting 90% of the pack file in one go
<jam> and you end up dying
<asmodehn> argh
<asmodehn> yep...
<jam> we could probably work around this a little bit in the client
<jam> by capping the size of a readv request
<asmodehn> but that also means there no easy perfect solution right ?
<asmodehn> ie, how much oyu are capping will depend on the RAM size, the badwith, etc.
<jam> yeah
<jam> but something like 500MB is generally a safe bet
<jam> also, could you try this over sftp
<jam> ?
<jam> I realize some bits will be slower
<asmodehn> yep
<jam> but I think it the SFTP spec requires that we transfer in 32kB chunks
<jam> so it won't actually hit this
<asmodehn> oh ^^
<jam> You don't have to
<asmodehn> worht a shot ;-)
<asmodehn> it s ok ;-)
<jam> but it would be worth having the data point
<asmodehn> yep
<asmodehn> and I am pretty desperate atm to be honest... if it doesnt work I ll go back to 1.5 and transfer revision by revision to avoid hitting errors too often...
<jam> I was in this code recently, and I'm pretty sure the client still spools up the whole request as well
<asmodehn> here we go sftp...
<jam> I may have a quick fix on the readv stuff, I'll let you know
<asmodehn> k
<asmodehn> sftp still copying inventory text...
<jam> asmodehn: I'll just mention that bzr hasn't really been designed around handling 10GB trees
<jam> We'll try to accommodate as we can
<asmodehn> yeah I would guess so ;)
<asmodehn> no worries
<jam> but it isn't a base design criteria
<asmodehn> I am just using it because it s better than copying 4GB zip files around evrytime there is just a little difference...
<jam> have you considered unison/rsync?
<asmodehn> ie easy way to get just patches transparently
<asmodehn> mmm dont know about unison...
<asmodehn> let me google that ;-)
<asmodehn> mmm looks interesting... however I need more than what it does though, such as a proper SCM who let me go back in revision history ...
<asmodehn> I feel like I need a BZR multisite :-p
<asmodehn> lol
<asmodehn> mmm sftp doesnt load the source server like bzr+ssh did...
<asmodehn> and now there is still traffic on the pipe... 200 - 300 Kbps
<jam> yeah
<jam> again, requests are made at 32kB per hunk
<jam> and the sftp code was updated to stream that back to the next layer as well
<jam> while the bzr+ssh code does a lot of "finish reading the response, then return"
<asmodehn> k
<asmodehn> so whats the plan from now .. ? I guess I ll use sftp from now on, until the bzr+ssh code is improved to handle big packs ?
<asmodehn> and I keep using my old Knits repo until the dev2 format is finalized, tested, and announced ?
<jam> well, I have a patch for it to be released in 1.9, which may happen by this Friday
<jam> so you won't exactly be waiting long
<jam> can you send me the bzr logs with the dev2 format?
<jam> I'm just curious how much of an improvement we see
<jam> (if any)
<asmodehn> sure ;-)
<asmodehn> just the destination though... the source is a bit loaded by other bzr processes running :-s
<asmodehn> ok ?
<asmodehn> would htat be enough for you ?
<asmodehn> mmm hang on maybe I can get the source one too if you need actually, the process was stuck since two days ago :-p
<jam> no, just the local one is fine
<jam> I don't think you were running -Dhpss on the server anyway
<jam> I'm not specifically interested in the remote one either
<asmodehn> yeha true, no Dhpss..
<asmodehn> but but btu ...
<asmodehn> my .bzr.log is now only 28K :-s
<jam> .bzr.log.old
<asmodehn> haaa :-)
<jam> I believe we keep 1 level of .bzr.log
<jam> just to prevent it from consuming lots of disk space
<jam> at somewhere around 4MB we copy it to .old
<jam> and start fresh
<asmodehn> k I am bziping both now... I ll send that in your email
<asmodehn> thanks a lot for the help by the way ;-)
<jam> np
<asmodehn> I ll get 1.9 on my etch next week I guess then ;-)
<asmodehn> let me know if you want me to test something ;-)
<jam> asmodehn: well, I'll likely have some readv code that I might have you play with
<jam> I'm still putting together a "summary of what is happening" to the mailing list
<asmodehn> cool ;-) thanks ;-)
<jam> asmodehn: can you grab a branch of bzr.dev to start with?
<asmodehn> yep
<asmodehn> url ?
<asmodehn> got it
<jam> 'bzr branch lp:bzr' should be fine
<asmodehn> branching from bazaar-vsc.org/bzr/bzr.dev atm...
<jam> same thing
<jam> lp:bzr is a mirror of that url
<jam> just a lot shorter to type
<jam> :)
<asmodehn> hehe cool, I ve never used lp before though :-p I more of a SVN / BSD guy :-p
<asmodehn> dev C++ too not much python
<asmodehn> but i ve heard it s quite siple, never had time to get my head around it though..
<jam> yeah, I came from C++ => python
<jam> all depends on what you are doing
<asmodehn> yep
<jam> one weird thing, the last .bzr.log seems to have a different bandwidth
<jam> like 100kB/s rather than 200kB/s
<jam> is that real?
<asmodehn> huh ?
 * asmodehn is trying to think of what happened 2 minutes ago...
<asmodehn> any clue about where in the log that changes ?
<jam> http://dpaste.com/87602/
<asmodehn> weird...
<jam> though I also see:
<jam> 43.321     result:   ('ok',)
<jam> 391.397                22190509 body bytes read
<jam> which I believe is about 60kB/s
<jam> so your bandwidth seems rather variable
<asmodehn> the locations are quite far away from each other, and a lot of other thing might happen on the network, so that wouldnt surprise me
<asmodehn> I cant recall in which order I stopped / restarte the differnet bazaar processes on hte machines in the last hour to know if it affected something or not...
<jam> I was just trying to figure if the new format was saving you anything, but it looked slower at first glance
<jam> but if your bandwith can vary 2x
<asmodehn> I see
<jam> I can say it is copying less data
<jam> do you have bzr.dev yet?
<asmodehn> Branched 3806 revision(s).
<jam> asmodehn: ok, try doing "bzr pull --ovewrite http://bzr.arbash-meinel.com/branches/bzr/1.9-dev/remote_readv_sections"
<asmodehn> ok ;-)
<jam> and then run
<jam> make
<jam> and then you should be able to run "path/to/bzr branch -r1 -Dhpss bzr+ssh://..." for me
<asmodehn> not a branch... maybe  url rpbolem ??
<jam> oh, and use "-Dindex" if you would
<asmodehn> k
<jam> ah just a sec
<jam> I just forgot to publish it :)
<asmodehn> hehe :-p
<jam> done
<jam> try again
<asmodehn> pulling...
<asmodehn>  M  NEWS
<asmodehn>  M  bzrlib/help_topics/en/hooks.txt
<asmodehn>  M  bzrlib/transport/__init__.py
<asmodehn>  M  bzrlib/transport/remote.py
<asmodehn>  M  doc/en/user-guide/hooks.txt
<asmodehn> All changes applied successfully.
<asmodehn> Now on revision 3806.
<jam> asmodehn: sounds right
<asmodehn> huh ? 3806 -> pull -> 3806 ?
<jam> different tips
<asmodehn> different one then ;-)
<asmodehn> k
<asmodehn>  Change the default readv() packing rules.
<asmodehn> ah make... what do I need to run that ?
<jam> gmake, gcc, python-pyrex probably
<asmodehn> k
<jam> I could give you the .c files if you don't want to install python-pyrex
<asmodehn> nah it s ok I can
<jam> you don't *have* to, because bzr can fall back to pure python
<jam> but certain ops are slower
<asmodehn> k
<asmodehn> I ll go package hunting ;-)
<asmodehn> brb
<jam> though not at the scale of copying 20GB across a remote network
<jam> asmodehn: so if it is difficult, you can skip it
<asmodehn> k bunch of dev packages + make + bunch of warnings, but it seems fine ...
<jam> another small advantage of the patch
<jam> if it works, you should get a little bit more progress
<jam> well, the spinner should spin more often
<asmodehn> k
<jam> I don't think it will log much more
<asmodehn> just the Dindex I guess...
<asmodehn> well hte start was pretty fast
<asmodehn> I guess dev2 indexing improvements ?
<jam> probably
<asmodehn> now it seem stuck as usual, but my network usage is around 1.2Mbps :) I feel better
<jam> :)
<jam> can you get to the remote server to check the mem usage?
<jam> It should certainly be << 1G
<asmodehn> yep
<asmodehn>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
<asmodehn>  6942 autobzr   15   0  124m 120m 2404 S    0  3.7   0:00.39 bzr
<jam> 120M sounds a lot better than 1.9G
<asmodehn> yep it does ;-)
<asmodehn> the data transfer rate oscllate between 900Kbps and 1.2Mbps ;-) nice nice...
<asmodehn> note the spinning bar doesnt seem to turn a lot in between different readv though...
<asmodehn> 91.631     result:   ('readv',)
<asmodehn> 534.986                52094902 body bytes read
<asmodehn> in between the bar didnt move
<jam> I would expect the readv to request data, then when it comes back it will spin, then it will request more, back and forth
<asmodehn> mmm
<jam> the actual transfer code still buffers stuff
<asmodehn> I dont see the bar moving while it s transferring data through network...
<jam> it is just that inbetween we are smarter about it
<asmodehn> yeah probably
<asmodehn> k
<jam> well, we make smaller requests
<asmodehn> but anyway much better now ;)
<jam> can I get the .bzr.log for it?
<asmodehn> sure ... I ll  put that in a mail ;-)
<jam> also, I'm going to have 1 more version for you to test in a sec
<asmodehn> sure
<asmodehn> I ll stop that now then
<asmodehn> and send hte mail k ?
<jam> yeah
<jam> ok, do another "pull --overwrite ..."
<jam> (you can use --remember if you don't want to keep typing the URL)
<asmodehn> it s ok I like my shell history ;-)
<asmodehn> building extension modules.
<asmodehn> python setup.py build_ext -i
<asmodehn> Cannot build extension "bzrlib._dirstate_helpers_c" using
<asmodehn> your version of pyrex "0.9.4.1". Please upgrade your pyrex
<asmodehn> install. For now, the non-compiled (python) version will
<asmodehn> be used instead.
<asmodehn> running build_ext
<asmodehn> huh ?
<asmodehn> ah but you just changed the transport in bzr lib, so that pyrex stuff shouldnt matter I guess
<jam> you shouldn't actually have anything to do there, but whatever
<jam> asmodehn: right pyrex 0.9.4.1 has a known bug
<jam> so we don't compile the extension
<jam> because when we do it segfaults
<asmodehn>  ah ok ^^ just hte version in my etch packages :-s
<asmodehn> anyway I ll branch -r -Dhpss -Dindex again...
<jam> I really like ~line 871 in bzr.log:
<jam> 25.841  expanding: 5d3c775ea20da5c234f29fb643c5d8df.tix	offsets: [13, 14, 15 ...
<jam> 25.841    not expanding large request (1424 >= 16)
<jam> with 1424 offsets in there :)
<asmodehn> heh :p
<jam> interestingly for this specific branch
<jam> the prefetch doesn't help much
<jam> we are either just reading a tiny bit
<jam> or reading a huge amount at once anyway
<asmodehn> oh added some debug message did you ;)
<jam> yeah
<jam> -Dindex is that part
<jam> but I don't think it is in 1.8
<jam> well, I *know* it isn't in 1.8
<jam> as it just landed in bzr.dev 3805
<asmodehn> mmm error
<asmodehn> bzr: ERROR: exceptions.KeyError: 1566
<asmodehn> any idea ?
<jam> quick guess is that it doesn't like the partial readv I worked on, let me look a bit
<asmodehn>   File "/home/autobzr/bzr.dev/bzrlib/btree_index.py", line 1046, in iter_entries
<asmodehn>     node = nodes[node_index]
<jam> it is possible that a page used to be cached, so we didn't request it
<jam> but when we wanted to use it
<jam> it was gone
<jam> asmodehn: can you send that log?
<jam> Looking at the code it should always have those keys
<jam> but I might have a small bug in the new code
<asmodehn> yep I ll do that
<jam> key 1566 means we are requesting really far down in the index
<jam> but that still shouldn't be failing
<jam> before the last pull, the cap was at 50MB, so it probably never hit it with your indexes
<jam> but I dropped it to 5MB
<jam> and that may have triggered something
<jam> since that index is 5.8MB in size
<asmodehn> sent ;-)
<jam> you're clogging my inbox :)
<asmodehn> hehe sorry :-p
<jam> is that one very big?
<asmodehn> no last one was 15Ko
<asmodehn> KB
<jam> weird, usually your mail gets here faster
<asmodehn> my gmail said sent 4 minutes ago
<asmodehn> mail is not that big
<asmodehn> starts with "Logs with second patch :"
<asmodehn> maybe some of your client / server thinks I am a spammer :-p
<jam> well all your others came through fine
<jam> I can check my spam folder
<jam> there it is
<jam> just took a bit
<asmodehn> ;-)
<jam> ah, I see the problem
<jam> just a sec
<jam> (it was popping a node off 2x)(
<jam> so it would skip that at a boundary point
<asmodehn> he ;) no rush ;)
<synic> is there any interest in something like gitosis for bzr?
<jam> asmodehn: ok, pull up and try the new version
<jam> synic: there is contrib/bzr_access
<synic> ok
<jam> it is probably not as complete as gitosis, but it describes how to set up multiple ssh keys to access one account, etc.
<jam> asmodehn:  3811 refactor for clarity
<jam> though 3810 is the important change
<asmodehn> mmm
<asmodehn> sorry :p
<asmodehn>   File "/home/autobzr/bzr.dev/bzrlib/transport/remote.py", line 346, in _readv
<asmodehn>     next_offset = [cur_offset_and_size.next()]
<asmodehn> NameError: global name 'cur_offset_and_size' is not defined
<jam> stupid bugs
<asmodehn> hehe ;)
<jam> asmodehn: this time I double checked and ran the test suite, 3812
<jam> I really should put the new code under test
<jam> but I wanted to make sure it was worth the effort
<asmodehn> k ;) no worries let me know when I should pull and test ;)
<jam> now
<asmodehn> roger ;-)
<asmodehn> branching...
<jam> asmodehn: so if I follow the logs correctly, the old repository was taking 900s to get to the point where it could start text.pack data. The last test showed you hit that at 90s
<jam> that seems.... way to good to be true
<asmodehn> mmm
<asmodehn> k error again...
<jam> what is the error now?
<asmodehn>   File "/home/autobzr/bzr.dev/bzrlib/btree_index.py", line 1050, in iter_entries
<asmodehn>     node = nodes[node_index]
<asmodehn> KeyError: 1566
<asmodehn> 81.151  return code 4
<jam> hm... same error
<asmodehn> yeh...
<asmodehn> and about the time to arrive to text.pack yes it s been really fast...
<jam> can you send that log again
<jam> I want to check something
<jam> asmodehn: bah, I know the problem
<jam> asmodehn: 3813 ready for you to test
<asmodehn> log sent anyway ^^
<asmodehn> I ll pull that ;)
<asmodehn> branching...
<jam> asmodehn: just as a point of comparison, could you try to branch the original repo again as well?
<asmodehn> ?
<jam> just to see if the 900s => 90s is real
<jam> use my code
<asmodehn> ah the one not dev2 correct ?
<jam> right
<jam> I would like you to do both
<jam> so I can compare
<jam> the 900s may have been a fluke
<asmodehn> mmm I still have hte remote knit and the remote dev2
<jam> or may be real
<asmodehn> but the local ( destination ) is only dev2 now
<jam> asmodehn: that is fine
<jam> I'm more concerned about remote
<asmodehn> maybe 900 is when I lost patiance and stopped it because it was sending nothing ?
<asmodehn> k then ;-)
<asmodehn> I can compare both , and hten send you the log...
<asmodehn> just branching the same stuff from both knit and dev2 repo...
<asmodehn> dev2 -> dev2 is now at 303 seconds...
<asmodehn> is that enough to compare ?
<asmodehn> should I stop that one and do the old one just after ?
<asmodehn> hte old knit repo I mean
<asmodehn> knit -> dev2
<jelmer> Odd_Bloke, ping
<asmodehn> jam : ok I saw the line you re talking about around 90s... I ll cancel my branching now from dev2 and start to branch from knit again
<asmodehn> jam: argh IncompatibleRepositories: different rich-root support
<jam> thats strange
<asmodehn> one weird thing : KnitPackRepository [...]/.bzr/repository/
<asmodehn> RemoteRepository [...]/.bzr/
<asmodehn>   File "/home/autobzr/bzr.dev/bzrlib/repository.py", line 2506, in _assert_same_model
<asmodehn>     "different rich-root support")
<jam> yeah, I understand the code path. I just don't know why it would think that.
<jam> just a sec
<asmodehn> sure :)
<jam> can you get to the remote machine?
<asmodehn> yep
<jam> what does "bzr info" say
<asmodehn> Shared repository with trees (format: rich-root-pack)
<jam> oj
<jam> ok
<asmodehn> local says : Shared repository with trees (format: development2)
<jam> so my upgrade hack turned it into something closer to "pack-0.92" without rich-root
<jam> which doesn't matter for testing, except for when you go between formats
<jam> no big deal
<jam> I'll get you something you can use
<asmodehn> mmm what abotu reverting my local repo to the old knitpack now that we have a answer for the slowliness problem ?
<asmodehn> I can wait a bit before using the new dev2 repo format...
<jam> sure
<jam> if you go to the repo
<jam> you can see files/directories that end in -gi
<jam> just move the existing file/dir to -bi
<jam> and then mv -gi => normal
<jam> asmodehn: does that make sense?
<asmodehn> yep
<asmodehn> format and indexes
<asmodehn> and packnames
<jam> right
<asmodehn> btw is there any doc around about making the repo smaller... some kind of good practice ?
<asmodehn> I am wondering if it gets rid of the packs that are not useful anymore, and that kind of stuff..
<asmodehn> ok reverting to rich-root-pack done
<asmodehn> now branching again from knitrrp to knitrrp to see how long it takes before we hit the .pack transfer...
<jam> sure
<jam> I think you'll still need to use my code
<jam> since otherwise you'll hit the wall again
<asmodehn> yep I m using your version of bzr
<asmodehn> with the debug and all the stuff ;-)
<dobey> is there any way to see the status of a submitted merge request for the bazaar project?
<jam> dobey: http://bundlebuggy.aaronbentley.com ?
<jam> possibly under Pending, or under Merged
<asmodehn> jam : first readv on pack at 296 secs...
<dobey> ah
<jam> Or if you are on the mailing list, there will be a link to the merge request
<jam> which is a stable URL
<dobey> yeah, i'm not on the list
<jam> asmodehn: so that is 296 => about 90?
<jam> log files please :)
<asmodehn> I remember I saw a 92
<asmodehn> yep they re coming ;-)
<jam> asmodehn: oh and the output of: du -ksh .bzr/repository/indices ; du -ksh .bzr/repository/indices-bi
<asmodehn> k
<jam> actually 'du -kshc' if you don't mind
<asmodehn> sure ;)
<jam> so I get the impression your "latency" bound is actually
<jam> 1) Bandwidth limited for indexes
<jam> followed by
<jam> 2) latency bound while the server queues up GB of data to return
<jam> though not really network latency
<jam> more, "takes too long and uses all of swap"
<asmodehn> yep
<asmodehn> the uses all of swap appeard only when I upgraded from 1.5
<asmodehn> before it used to transfer then error
<asmodehn> so I was transferring few revision at a time and that went fine...
<asmodehn> but recently I think the data became too huge
<jam> note that my change isn't going to make it work if you have a single file that is too big
<jam> like a single 600MB file is likely to clog things up
<asmodehn> yep and thats fine ;-)
<jam> but it looks more like you have *lots* of moderately sized files
<asmodehn> now that it doesnt error anymore on a long transfer ;-)
<asmodehn> yep
<jam> asmodehn: well, you haven't tested a transfer to completion yet, have you?
<jam> also, you say "first readv on pack" but is that after reading the text indexes?
<jam> or is that reading the inventory
<jam> there are a few different stages
<jam> judging by your times, it is after reading .tix
<jam> I just wanted to make sure
<asmodehn> hehe true havnt tested a transfer till the end yet..
<asmodehn> about the stage before pack I am not sure... you got the log in your email now ;-)
<jam> asmodehn: why that I do :)
<asmodehn> hehe :-p but I think it s after hte text index yes ;-) remembering what the progress bar was telling me
<asmodehn> jam: so I guess we re done for today are we ? I ll keep using sftp waiting for the awesome new version and new repository format ;)
<asmodehn> I am getting hungry hehe
<jam> I think we're done
<jam> enjoy your meal
<asmodehn> thanks ;-)
<asmodehn> and thanks a lot for the help ;) ill go eat and then I clean all remains of my experiments ;)
<jam> dobey: your patch is here, by the way: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1225157843.25420.7.camel%40lunatari%3E
<dobey> yeah, i found it
<dobey> thanks
<ktenney> Howdy, I'm trying to retrieve the commit message for a revision
<ktenney> it looks like lf = log.LineLogFormatter(file_handle)
<ktenney> m = lf.message(rev)
<ktenney> should work, but if so, I haven't discovered what rev should be
<ktenney> rev from revno, rev = b.last_revision_info() doesn't work
<james_w> ktenney: you need a Revision, not a revision id
<james_w> repository.get_revision(rev_id) might be it
<james_w> revno, rev_id = b.last_revision_info()
<james_w> if you don't need the revno then just just b.last_revision()
<ktenney> james_w: so I need to look at repository.Revision(self, _format, a_bzrdir, control_files, _revision_store, control_store, text_store).get_revision(rev_id) ?
<james_w> ktenney: no, I don't think so
<ktenney> james_w: revision commit messages aren't fetchable from a working tree?
<ktenney> I haven't found any shortcut
<james_w> wt.branch.repository.get_revision(rev_id)
<lifeless> ktenney:
<lifeless> t = bzrlib.workingtree.WorkingTree.open('.'); t.lock_read(); rev = t.branch.repository.get_revision(t.last_revision())
<james_w> msg = rev.message as well I think
<james_w> morning lifeless
<lifeless> ktenney: we use factory methods a lot in bzr, because the library supports working directly with multiple VCS systems
<lifeless> hi james_w
<lifeless> james_w: how goes $stuff
<james_w> lifeless: good thanks. you?
<james_w> lifeless: I met with the code team and others yesterday, and we got somewhere on how the LP stuff should look.
<ktenney> james_w: lifeless: got it, thanks
<lifeless> james_w: great
<poolie> jam, i was planning today to do more reviews
<poolie> and i have a meeting
<poolie> basically just that
<jam> do you ever not have a meeting ?
<jam> :)
<poolie> :/
<jam> Today I worked on 3 things.
<poolie> the timezones make it more disruptive
<jam> 1) Working with vila to talk about the inventory corruption he saw, and possibly what it needs to fix it
<spiv> Today I've just sent the autopack RPC patch for review (so if poolie is doing reviews... *hint*), and am in the process of landing other approved patches from this cycle.
<poolie> oh, yay
<poolie> well done
<poolie> i'll do it first
<jam> 2) I worked with someone who has a 16GB repository
<jam> and was having a hard time doing "bzr branch"
<jam> it turns out that our ability to discuss multiple file histories
<spiv> I also want to look at jam's remote readv merge/rfc (first impression is that we should approve it, and start work on a streaming readv a jam suggests)
<jam> was requesting a readv() that was about 10GB long
<jam> which would be buffered on the server
<jam> before sending
<jam> and then buffered on the client
<jam> before processing
<jam> which... doesn't work so well
<jam> and sent that to the list as spiv mentions
<jam> 3) We also played with btree indexes
<jam> which show up nicely for him
<jam> so I'm encouraged to help push a --format=1.9 in
<jam> And for future work, still trying to get the retry code working for fetch()
<jam> (end of text :)
<lifeless> I've a LeafNode I'm reasonably happy with
<poolie> ok, nice
<lifeless> working on handling too big content and spilling into a InternalNode with LeafNode children
<jam> lifeless: did you see my email about that? I think fullpath is a better route than parent_id,basename
<lifeless> considering sidetracking to fix ISO storage
<lifeless> jam: haven't seen it yet, no
<jam> lifeless: np, I sent it about 15 min ago
<jam> spiv: Is there a reason you need to special case everything, rather than just defining "autopack(self)" on Repository and using it instead of target._pack_collection.autopack()?
<jam> It at least seems simpler than special casing the InterPackToRemotePack code
<spiv> jam: which special casing are you referring to?
<jam> InterPackToRemotePack._pack
<spiv> Ah, I see.
<jam> it seems like you duplicate most of the def _pack code
<spiv> If you uncommit the last revision, you'll see why ;)
<jam> just to get the autopack() called
<spiv> It's mainly because there was a half-done check_references RPC as well that I have set aside for now.
<jam> ah, I saw that you moved that
<jam> and I wondered why
<jam> also, your "_get_target_revision_index"
<spiv> Hmm, and I guess I've pushed some of the other _pack differences into RemoteRepo.autopack
<jam> blindly uses "self.target._real_repository"
<jam> without calling _ensure_real()
<jam> are we sure that is safe?
<spiv> Yes, because is_compatible will have called _ensure_real
<jam> ah, ok
<jam> Anyway, I need to get going, but I saw those things to at least think about
<spiv> (sadly!  There's no better way to get the remote format atm, though)
<spiv> jam: thanks
<jam> anyway, there is a lot of duplication in the _pack code, that if you could just define .autopack() seems like it would go away
<jam> Why doesn't InterOtherToRemote take prescendence over InterPackRepo ?
<jam> anyway, gotta go
<jam> have a good day
<thumper> using bzrlib, how do I get the files added/removed in a commit, and the diff / diffstat?
<poolie> tree.iter_changes(other)...
<thumper> poolie: and now for a non bzr hacker?
<thumper> poolie: I have a branch that I want to compare mainline revisions of
<poolie> b = Branch.open('thing')
<poolie> b.lock_read()
<poolie> tree1 = b.repository.revision_tree(revid_1)
<poolie> tree2 = b.repository.revision_tree(revid_2)
<poolie> changes = tree2.iter_changes(tree1)
<poolie> changes=list(changes)
<poolie> for c in changes: print c
 * thumper goes to a python shell
<poolie> show_diff_trees(tree1, tree2)
<poolie> season to taste
<thumper> poolie: thanks
<lifeless> thumper: 'bzr st -r x..y' ;)
<LeoNerd> Anyone here using bzrweb, the HTTP frontend thing? I've got:  ImportError: cannot import name LocalBranch
<lifeless> LeoNerd: I tend to use loggerhead
<LeoNerd> Hrm...
<LeoNerd> I'll let you into a secret - I want to embed it in my existing website generation system
<LeoNerd> Which is perl. Having looked over the bzrweb code, it looks quite easy to drop that in by Inline::Python, and do a small bit of extra work
<poolie> LeoNerd: i think that error means it's out of date with bzr trunk
<LeoNerd> Ya.. that seems likely
<LeoNerd> Tobehonest I may just take the ideas in the code here and reimplement them myslef
<LeoNerd> Write some small bits of connector logic in Inline::Python and do the rest from perl
<poolie> is there something about bzrweb that makes it easier to do this than with loggerhead?
<LeoNerd> Not really.
<LeoNerd> It's just bzrweb was a small simple chunk of code I could easily read and work out what it does
<LeoNerd> I'm sure I could do it all myself, it'd just mean me spending a while flicking about in the bzrlib docs to find stuff
<LeoNerd> And possibly reinventing tricks this code already has
<jisakiel> greetings... I was just asking in launchpad: is there a (reasonable) way to have a server with fine-grained permissions to different projects inside a repository?
<jisakiel> they pointed me to bzr_access but I see that is incomplete, only supporting [/] repo
<jisakiel> I'm just wondering if there might be something similar to the subversion authentication available
<poolie> jisakiel: why not have different repositories for each project?
<jisakiel> hmmmm
<jisakiel> bzr_access does not seem to support that?
<jisakiel> I really like the launchpad model
<jisakiel> being a personal server I don't want to give +w to everybody who is able to push via bzr (as I track different projects there)
<jisakiel> and I'd rather not have shell accounts accesible
<poolie> jisakiel: launchpad has a repository per branch
<jisakiel> but how do they authenticate then
<jisakiel> they just told me they use a custom ssh client
<jisakiel> er... ssh server  ^^
<spiv> jisakiel: hmm, I thought it was possible to configure bzr_access differently
<jisakiel> as far as I understand
<spiv> jisakiel: ah, there's also bzr_ssh_path_limiter in the contrib/ directory
<jisakiel> in 1.8??
<spiv> Yes, and probably earlier too
<jisakiel> huh, don't see it when I do apt-get source bzr
<spiv> Oh, huh.
<spiv> It's not in 1.8
<spiv> It is in bzr.dev
<jisakiel> d'oh
<spiv> It had originally been posted on the mailing list for quite a while before that, I guess that's why I was confused.
<spiv> jisakiel: you can always have different SSH keys for different repositories.
<jisakiel> point is
<jisakiel> users would be using their own ssh key
<jisakiel> just like in launchpad
<jisakiel> and I, somehow, would be able to give them + or - W
<jisakiel> just like editing svnauth
<Peng_> Argh, Loggerhead is unhappy.
<jisakiel> I guess the only "reasonable" way is to explode the number of groups in the server
<jisakiel> one per project
<jisakiel> and use filesystem permissions
<jisakiel> but *urgh*
<spiv> jisakiel: there's another possibility -- if you're just interested in restricting writes (not reads), then you could use PQM to manage the branches you want to restrict write access to.
<spiv> jisakiel: it's a different workflow, so it might not be suitable for you.
<spiv> jisakiel: it's how the bzr trunk is managed, for example; bzr developers keep their own branches of bzr wherever they like, but to commit to the trunk you need to send a request to the PQM bot.
<jisakiel> heh, I guess it might be easier to extend the bzr_access script than to deploy that
<jisakiel> ;)
<spiv> jisakiel: PQM checks that the request is authorised (via PGP), does the requested merge, runs the test suite, and then only if the tests pass does it commit and publish the merge.
<spiv> It solves a slightly different problem, but maybe it's useful to you.
<jisakiel> seems too complicated but txs anyway
<spiv> Fair enough.
<jisakiel> ( and test suites are still utopia in the CS courses ;) )
<spiv> The problem with extending bzr_access is that the bzr client always asks for --directory=/ when it connects over bzr+ssh.
<spiv> (Ah! ;) )
<spiv> (and because the bzr client can't know which directories it will need in advance, it can't really do anything else)
<jisakiel> I see
<jisakiel> yikes
<jisakiel> :D
<spiv> You could make it spawn something other than plain bzr serve, i.e. write a bzr plugin to provide a virtual filesystem with the restrictions you need.
<jisakiel> --directory=(?P<dir>\S+)\s+
<spiv> There are already the building blocks for that in bzrlib (there's psuedo-chrooting logic and also force-readonly logic already there in bzrlib.transport.decorators)
<spiv> It wouldn't be trivial to write, though.  Certainly not as easy as editing a config file!
<jisakiel> still seems like a not-trivial ammount of work
<jisakiel> that's it
<spiv> jisakiel: right, that regex is always going to just see /.
 * spiv nods
<jisakiel> then get_directory?
<spiv> If you can bear it, using filesystem groups sounds the most practical for you.
<spiv> get_directory will always get / :(
<jisakiel> and bzr+ssh sends / because...?
<spiv> The author of bzr_access was a bit optimistic about what the bzr client would do.
<jisakiel> lol :D
<jisakiel> just like me
<spiv> Because the client can't know what directories it will need to look at before connecting.
<spiv> Opening a branch may require opening a shared repository in an arbitrary parent directory, or resolving a branch reference at an arbitrary location, etc.
<jisakiel> aaahm
<jisakiel> I was just scratching my head, as bzr+ssh://host/whatever/path seems complete
<spiv> e.g, "bzr log bzr+ssh://host/whatever/path" can't spawn a remote bzr serve with --directory=/whatever/path, because the actual revision data might be at /whatever.
<spiv> Or even /!
<jisakiel> but nevertheless
<jisakiel> ah
<jisakiel> bzr serve is, of course, restricted in doing ".."
<jisakiel> because what would be the point in having --directory
<jisakiel> otherwise while browsing the log one could just go "up" like I guess bzr log /whatever/path does
<spiv> --directory is there so that "bzr serve" over TCP can serve just part of your filesystem, and also so that bzr_ssh_path_limiter can be written.
<spiv> Right.
<jisakiel> (which btw I can't find in bzr-dev, at least not in http://bazaar-vcs.org/bzr/bzr.dev/contrib/ )
<spiv> Hmm, someone really ought to write that hypothetical plugin I was referring to and add it to contrib/
<jisakiel> lol
<jisakiel> seems overwhelming to me right now, sorry :D
<spiv> (that someone is probably me)
<jisakiel> I guess this excludes some "business" uses of bzr more-or-less-centralized workflows
<spiv> Huh, it's not in bzr.dev.  Oh man, I'm an idiot.
<spiv> It's in my local checkout, not committed!
<jisakiel> heh, bzr add perhaps? :P
<jisakiel> it happens xd
<spiv> jisakiel: http://rafb.net/p/P1TEcP10.html
#bzr 2008-10-30
<spiv> jisakiel: it's basically a very very simple alternative to bzr_access :)
<jisakiel> hmm, I see
<jisakiel> like *very very very* simple
<jisakiel> I kinda like more the original, as it allows for several repos
<jisakiel> http://www.selenic.com/repo/index.cgi/hg-stable/file/tip/contrib/hg-ssh
<jisakiel> but seems easy enough to extend
<jisakiel> won't make any troubles because of the "bzr log" problem?
<jisakiel> I mean: right now, I'd just have "bzr init ~bzr/repo" and then push over the different projects there, but...
<spiv> So long as you don't restrict the client from seeing directories they need.
<jisakiel> and you wouldn't have anything needed "up" unless...?
<spiv> e.g. if you do bzr init-repo /bzr/proj && bzr init /bzr/proj/branch, then it's ok to limit the client to /bzr rather than /
<spiv> Or even /bzr/proj
<spiv> But if you limit to /bzr/proj/branch, then the client won't be able to access the shared repository at /bzr/proj, and it will need to access it.
<jisakiel> ncht
<jisakiel> and btw
<jisakiel> is there a way of checking out (like in svn again, it's just that I used to use it a bit before) the whole repo? IIRC checking out /bzr/proj would not work
<jisakiel> could be wrong though
<spiv> Not really, no.
<spiv> You could just "cp -a" it ;)
<jisakiel> consider that as a suggestion as well ;)
<jisakiel> that way you would be able to checkout not just "trunk", but all development branches as well
<spiv> Yeah, we would like to have better ways to manipulate groups of branches.
<jisakiel> *if* you use a shared repo to hold them (which seems logical)
<spiv> At the moment shared repos are just a storage optimisation, rather than implying any semantic like "these branches are part of a group of related branches"
<jisakiel> aham
<jisakiel> well, semantic seems implied from the storage optimization (if there are shared files between the branches as to make it worth it... they are definitely related)
<spiv> But in practice, they usually are related.  So it is tempting to use shared repositories like that... but it's not part of our design yet, and we're wary of making design mistakes that will be hard to undo.
<jisakiel> last year I didn't know of shared repos and end up with hundreds of megs of slightly different big branches
 * spiv nods
<jisakiel> yeah, I guess it could be considered independent enough
<jisakiel> as in "you could want to have a group of related branches without having them under the same folder"
<spiv> The other thing in favour of using shared repos for a "group of related branches" concept rather than creating a new concept is it would be less concepts for users to learn about.
<jisakiel> it's kind of easy, yep
<jisakiel> I guess it brings new problems... I lost track a bit of launchpad enhancements, but I don't know if shared repos are compatible with development branches
<jisakiel> I seem to recall something from the rss related
<spiv> You can use shared repos with any format except the really ancient ones.
<jisakiel> as to avoid having huge branches to checkout from the servers
<jisakiel> ah, so I can just bzr init-repo shared, then checkout inside from lp?
<jisakiel> and if there is storage to be won it will?
<jisakiel> (cooool)
<spiv> Ah, you can, but that won't help you avoid downloading all of history ;)
<jisakiel> I guess I should have just branched from my existing branches, then pulling from the repo, but that was a merge-fest waiting to happen
<spiv> You can do "bzr checkout --lightweight" and since 1.6.1 "bzr branch --stacked", though.
<jisakiel> we used branches and not checkouts nevertheless
<spiv> Basically, if you already have the history locally, then a shared repo can help you.
<jisakiel> heh, --stacked functionality seems to overlap a bit with shared repos, doesn't it
<spiv> An new (and thus empty) shared repo doesn't perform any differently to a standalone branch+repo.
<spiv> Hmm, not really :)
<spiv> But maybe I'm too close the implementation to see what you mean ;)
<jisakiel> sure you are! :D
<fullermd> --stacked can give a result that superficially looks like the a result of shared repos in the short term.  How's what?   :p
<jisakiel> as in "--stacked saves storage? by reusing the common history? from the pointed branch" vs "shared-repo reuses whatever"
<fullermd> Really, in much the same way and for the same reasons as hardlinking the repo.
<jisakiel> so, summing up (gotta go!), a plugin -and, possibly, modificating bzr+ssh behaviour?- would be needed to replicate svnserve functionality...
<jisakiel> oh, btw can't I use bzr over https (even if unefficient?) that's another way of authenticating (weaker, though) and having fine-grained permissions...
<spiv> That is an option, and it should work.
<jisakiel> I might try that then as a first approach
<jisakiel> and afterwards try to bang the limit_path script until I get it to work as I'd like :)
<spiv> Although, hmm.
<spiv> It might be a bit fiddly to set up.
<spiv> Let us know how you go :)
<jisakiel> webdav shared folder, and .htaccess I guess
<spiv> Oh, webdav.
<spiv> That's probably not so bad, although I'm not familiar with the state of the webdav code.
<jisakiel> heh, that's easier
<spiv> (Is that still provided by a plugin?)
<jisakiel> yep
 * spiv nods
<jisakiel> mod_dav irc
<jisakiel> iirc
<spiv> Oh, I meant, on the bzr side :)
<jisakiel> lol
<fullermd> Well, no matter how you slice it, you can't set authority boundaries other than at repository boundaries.
<spiv> If you have trouble with webdav, vila is a good person to chat to for help -- depending on timezones :)
<jisakiel> just saw something related to https in the configuration section of the docs, so I guess it should more-or-less work
<jisakiel> heh, ok, txs for the info
<fullermd> I'm not sure the webdav stuff still works.  It was broken at one time, and I didn't think vila had touched it in a good long while.
<jisakiel> ough
<jisakiel> I'll try just for the record then
 * fullermd nod.
<fullermd> 's the only way to be sure.
<jisakiel> as I think I had the webdav shared folders still working
<jisakiel> in fact
<spiv> jisakiel: or if the users are using linux, you could get them to use http://dav.sourceforge.net/ to make webdav look like an ordinary filesystem ;)
<jisakiel> what I can't is trick bzr to push over webdav into plain http, can I
<jisakiel> as I was trying the webdav thing but I have it over http (yeah, I know, insecure etc ;))
<spiv> I don't know enough about the webdav plugin, sorry.
<jisakiel> ncht
<spiv> (I would have thought it would work, but I really have no idea :)
<jisakiel> bzr: ERROR: Invalid http response for http://jisakiel.dyndns.org/privado/.bzr/branch-format: Unable to handle http code 401: expected 200 or 404 for full response.
<jisakiel> (whatever)
<spiv> I think you need to use http+webdav:// to use the plugin?
<jisakiel> that's what I meant
<jisakiel> I'll try in other time, as I gotta go now
<jisakiel> quick last one: any *simple* (as in "grep") way of knowing which folders would a branch need to be accessible for it to work
<jisakiel> (as the limit_path would perhaps be able to share from the upmost needed folder that way)
<jisakiel> well, I'll have a look myself. Thanks so very much for the insights!
<jisakiel> goodbye all... ^^
<poolie_> spiv: i presume you did test the autopack rpc? how did it go?
<spiv> poolie_: it seems to work, although it's a bit of a hassle to test by hand.  I guess I could script "for i in seq 10 ; do bzr ci --unchanged -m 'foo'; bzr push bzr://... ; done"
<poolie_> i think it would be wise to at least try that against both servers that do and don't supporti t
 * spiv nods
<spiv> I'll give it a work out, see what breaks.
<spiv> And look at that, it broke!
<spiv> D'oh.
<poolie_> :/
 * spiv fixes
<spiv> Ah, but the full test suite does notice, I mustn't have run that as recently as I thought I had.  Hmm.
<spiv> Looks shallow, anyway.
<spiv> Yeah, just a last-minute snafu in the final quick-cleanup-before-hitting-submit revision.  I'm checking for other gotchas.
<poolie_> spiv, i'm sending a partial review
<poolie_> will be back on it in a bit
<spiv> poolie_: thanks
<lifeless> poolie_: I'm going to catch a train before 5, to skip transit crowds going to a friends birthday
<lifeless> poolie_: I'll hack on the train
<poolie_> sure, have a good trip
<spiv> poolie_: FWIW, working autopack rpc cuts the number of RPCs for the 10th push of 1 revision from 179 to 44.
<poolie_> nice
<poolie_> still a bit high but nice
<spiv> Yeah.
<spiv> The change to -Dhpss to make it dump call counts to stderr makes this sort of measurement much more convenient.
<vila> hi all
<vila> fullermd: I've got news for you :) webdav wasn't updated for a while but was finally updated and is now passing the test suite for some months (both against our internal test server and against a real apache2 server)
<vila> fullermd: And since the bzr transport API is one of the most stable we have, the plugin doesn't need updates and I changed the requirement to be a simple bzr >= 1.6
<vila> Too bad jsakiel seems already gone, but if he got a 401, he has to provide a user for authentication
<poolie_> spiv, did you send the update to that patch?
<poolie> hi vila
<Odd_Bloke> jelmer: Belated pong.
<thumper> poolie: ping
 * thumper hopes poolie is still around and lookng at his computer
<poolie> hi
<poolie> on phone still
<thumper> poolie: ok
<poolie> hi, i'm free
<thumper> poolie: I was going to ask about the auto pack bug with stacked branches
<thumper> I hadn't realised exactly what the problem was
<thumper> but if it fails on all autopacks, that is very bad for LP
<poolie> thumper: that would be bad
<poolie> is there a bug # for this?
 * thumper pokes jml
<jml> this is the check reference one, iirc
 * jml looks
<jml> this one is related but not it, I think, https://bugs.edge.launchpad.net/bzr/+bug/280608
<ubottu> Launchpad bug 280608 in bzr "Stacked-on branch not unlocked when commit_write_group fails on stacked branch" [Undecided,New]
<jml> poolie, thumper: https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/280595
<ubottu> Launchpad bug 280595 in launchpad-bazaar "RevisionNotPresent error when mirroring stacked branches" [High,New]
<poolie> are you saying this is a knock-on effect from autopack not dtrt?
<thumper> I think so
<thumper> but I don't have enough info just yet
<thumper> I was only just told that it was related to autopack
<poolie> launchpad whitespace breakage ftw :/
<beuno> poolie, in comments?
<poolie> yeah
<jml> as you can tell from the comments, there are a lot of related, confusing bugs with serious sounding error messages
<jml> and these are happening regularly among the Launchpad team, making the system seem flaky
<beuno> poolie, I have a branch that may fix that, just need to do some further testing on it to make sure it doesn't break in other browsers
<poolie> yay
<beuno> mwhudson, I'm working on getting "head:" to be used by default in the URL if you're looking at the tip in LH
<beuno> so people don't have top URL hack anymore
<poolie> presumably bug 280608 is just cosmetic, as losing the lock at that point should have no visible effect
<ubottu> Launchpad bug 280608 in bzr "Stacked-on branch not unlocked when commit_write_group fails on stacked branch" [Medium,Confirmed] https://launchpad.net/bugs/280608
<poolie> it's not physically held afaics
<beuno> mwhudson, not sure if this is fiddling too far down: http://paste.ubuntu.com/64537/
<poolie> i'll merge that patch anyhow
<mwhudson> beuno: is that in fix_revid?
<beuno> mwhudson, no, get_revno
<beuno> we don't run revnos past fix_revid in many places
<mwhudson> oh right
<mwhudson> beuno: basically, i don't know what a good ui is here
<beuno> so, this would, in a way, make it impossible to get the actual revno, so it kinda sucks
<beuno> hm
<beuno> I could start slapping fix_revid or something on URLs
 * beuno revertrs
<mwhudson> when someone clicks on the first revision on the changes pages, are they clicking on it because they're interested in the head revision, or because they're interested in that particular revision
<mwhudson> beuno: certainly, i think when people click the 'files' tab, 'head:' is appropriate in urls
<mwhudson> but this probably means we need to carry a bit more state around
<LarstiQ> jelmer: a branch got renamed in svn, and now bzr-svn thinks it's an entirely new branch. Can I just tell it 'no, it is actually _this_ branch'?
<jelmer> LarstiQ, does it still use the same branching scheme?
<LarstiQ> the new dir is a sibling of the old one, but let me check
<LarstiQ> jelmer: Guessed branching scheme: TrunkBranchingScheme(0), guess scheme to use: SingleBranchingScheme(foo)
<LarstiQ> jelmer: where foo is the path in the svn repository under trunk/, so that differs between pre and post move
<jelmer> LarstiQ: if the branching scheme is different, there's no way to let it recognize the old history
<LarstiQ> and the SingleBranchingScheme is always tied to the exact location in svn repository, so moves will always impose a cut between bzr branches?
<jelmer> LarstiQ, yes
 * LarstiQ grumbles
<jelmer> LarstiQ, branching schemes suck, deal with it :-)
 * mwhudson waves https://bugs.launchpad.net/bugs/291046 around
<ubottu> Launchpad bug 291046 in bzr "pushing branch6/packs5 to location with default stacking policy creates broken branch" [Undecided,New]
<LarstiQ> jelmer: I don't know how I'm going to deal with it yet, it seems to me there is enough information available to not break so horribly.
<jelmer> LarstiQ, 0.5 no longer has branching schemes and deals with this properly
 * LarstiQ glomps jelmer 
<LarstiQ> jelmer: is there an ETA?
 * LarstiQ lunches
 * Jc2k must know how this magic works... =)
<gour> is '--1.6.1-rich-root' safe format to use?
 * gour also wonders  when we'll see some reduction in format number
<lifeless> gour: if you're using rich roots at all, 1.6.1-rich-root is fine to use
<lifeless> gour: its listed as supported after all
<abentley> jelmer: :pull is actually :parent, so "I'll consider changing the default ... to :pull, :parent" is a bit wrong.
<jelmer> abentley, ah, ok
<jelmer> LarstiQ, "when I have time"
<LarstiQ> jelmer: right :)
<LarstiQ> gour: but be warned that non-rich-root doesn't mix well with rich-root
 * jelmer wonders if rich root is ever to become the default..
<LarstiQ> jam: did you need any more information on bug 50568 ?
<ubottu> Launchpad bug 50568 in bzr "'bzr push' does not preserve sgid bit on newly created directories" [Medium,Confirmed] https://launchpad.net/bugs/50568
<gour> jelmer: why not?
<gour> some format(s) perform better?
<unenough>  i want to backup my repo. what's the easiest way to store the smallest archive with the whole repo in it?
<jam> LarstiQ: good morning. I haven't followed up on it, but I'll look at your script
<LarstiQ> jam: thanks
<LarstiQ> jam: for my immediate situation I've just setfacled
<LarstiQ> which works fine
<jam> LarstiQ: well, for that particular one, I think you are creating a new branch, which is a bit different than pushing existing code into the repo
<jam> but I'll admit that is probably broken
<jelmer> gour: it's not been happening for quite a while
<jam> so I'm thinking we should open a new bug for what you are encountering
<jam> because it is probably a different fix than bug #50568
<ubottu> Launchpad bug 50568 in bzr "'bzr push' does not preserve sgid bit on newly created directories" [Medium,Confirmed] https://launchpad.net/bugs/50568
<unenough> is there a way to create an archive of my repo?
<unenough> easy way
<jam> unenough: rsync my-repo copy-of-my-repo ?
<unenough> doesn't that include a lot of redundant data?
<jam> unenough: redundant in what sense?
<unenough> copies of complete files  (the current working copy)
<unenough> that happen to exist under the repo dir
<unenough> branches
<unenough> i don't know what to call them
<unenough> besides, sometimes it's much more convenient to just have a .gz file of the repo
<jam> unenough: well you can do "tar cvzf repo.tar.gz .bzr/repository" however that won't keep the branch pointers
<jam> as they are kept in their individual directories
<unenough> that's why i want a single command to do it
<unenough> like, "bzr archive" :)
<jam> I could help you write a plugin for it, but no there isn't something trivial that already exists
<Odd_Bloke> Something with 'find' would probably work.
<Odd_Bloke> jam: I think this was discussed in London, but I don't remember what the conclusion was.
<Odd_Bloke> Or if, indeed, there was one.
<jam> I think I need to alias ":e" to vi in my shell :)
<unenough> jam, Odd_Bloke there is this https://launchpad.net/bzr-gzipped-bundle
<unenough> but it seems dead
<jam> unenough: that is a really old plugin that has been replaced by builtin-code
<jam> and it wouldn't do multiple branches
<jam> (The current "bundle" format is bzipped anyway)
<jelmer> Odd_Bloke, nevermind
<jelmer> Odd_Bloke, I was going to mention there was another ITP open about bzr-xmloutput
<jelmer> Odd_Bloke, but that seems to be assigned to you now
<jam> markh: ping
<spiv> jam: I just sent an update to the autopack patch
<spiv> jam: now I'm off to try sleep despite the hot weather
<jam> spiv: I thought it was cold there
<jam> did it suddenly switch?
<jam> (again)
<spiv> jam: It's been very variable the last two weeks.
<jam> spiv: I also sent an update to your Graph change
<jam> though you are probably too tired to look over it now
<spiv> Tomorrow is forcast to be 36 celsius.
<spiv> jam: I've taken a quick sleepy glance, and I like the look of it.
<spiv> jam: thanks very much for making a complete patch, rather than just comments.  That's very helpful at this point in the release cycle :)
<jam> yeah, I thought it would be
<jam> you're certainly welcome
 * spiv -> zzzz
<jszakmeister> jelmer: you there?
<jelmer> jszakmeister, yep
<jszakmeister> Ran into a bzr-svn bug (I think)
<jszakmeister> Ever see the error:
<jszakmeister> ReadOnlyError: A write attempt was made in a read only transaction on KnitPackRepository
<jelmer> jszakmeister, what version of bzr-svn?
<jszakmeister> I branched from an svn repo, made some changes, pushed into a shared repo, and then treied to push from the shared repo into a new branch of subversion
<jszakmeister> The latest (0.4.13, I believe)
<jszakmeister> Wait... I'm not so sure about that... hold on.
<jszakmeister> Crap.  0.4.11
<jszakmeister> Let me update and try again
<jszakmeister> I though I had installed the latest on this machine... but it was probably my desktop at home.
<jelmer> please try to reproduce with 0.4.13 first
<jszakmeister> Yeah, I'm trying that now...
<jszakmeister> Sorry, I thought I was at 0.4.13 already. :-(
<jszakmeister> jelmer: The error went away.
<jszakmeister> Sorry for the noise.
<jelmer> another bug well fixed :-)
<jam> jelmer: ping
<jelmer> jam, pong
<jam> I'm trying to build bzr-svn 0.4.13 so that we can have the windows installer
<jam> and I'm running into problems at compile time
<jam> specifically:
<jam> subvertpy\subvertpy\editor.c:140: error: initializer element is not constant
<jam> subvertpy\subvertpy\editor.c:140: error: (near initialization for `TxDeltaWindowHandler_Type.tp_deal
<jam> loc')
<jam> I believe this happens when you set a static structure
<jam> to point to a function
<jam> which only exists in a dll
<jam> which isn't legal on Win32
<jam> because the address isn't known until load time
<jam> (This happens for trunk/0.4.10,11,12,13)
<jam> Do you know if markh did some customization of bzr-svn that didn't make it back into trunk for it to build on win32?
<jam> I also get a bunch of errors about: util.h:28: warning: ignoring #pragma GCC visibility
<jam> jelmer: ?
<jelmer> jam, sorry
<jam> np, we all get busy, I just didn't know if you read any of what I said or not
<jelmer> blegh
<jelmer> yeah, I suspect Mark has a patch for that
<jelmer> it should probably be upstream
<jelmer> the fix would probably be to add a (yuck) wrapper function
<jam> jelmer: the standard python way is to leave the entry as a NULL pointer and then during the __init__ function
<jam> you populate it
<jam> well INIT_MODULE or whatever the specific function is
<jam> I've done the hack for other stuff
<jam> I just didn't know how he managed to compile it
<jam> and thought maybe he mentioned it to you
<jam> well, I guess I was hoping he sent you a patch that you just forgot about until now
<jam> :)
<jelmer> jam, not that I remember :-)
<jam> jelmer: so if I was to try to make a fix to get a stable released bzr-svn packaged into a win32 installer, what branch should I use?
<jam> just do it off of the tag:bzr-svn-0.4.13 ?
<jelmer> jam, yep
<jam> ok, it wasn't ever clear to me what the 0.4 branch was versus trunk versus 0.5, etc
<jelmer> jam, 0.5 (aka trunk) is not ready for use yet
<jelmer> jam, the 0.4 branch is the stable branch from which all the 0.4.x releases are made
<jam> jelmer: I think I have a patch
<jam> it was actually a lot simpler than I was worried it would be
<jam> just 3 'dealloc' functions that need to be set at runtime instead of startup
<jam> however, I don't actually have it running yet, because of dll load failures
<jam> but I think that is just PATH issues
<jam> the build succeeded
<jelmer> any chance you can send me the patch?
<jam> well, I'm trying to see if I can actually get it to work
<jam> but yeah, I'll send it to you
<jam> I'm pushing it to lp right now
<jam> lp:~jameinel/bzr-svn/0.4.13-win32
<jam> jelmer: pushed, would you rather I sent you a patch?
<jelmer> jam, no, thanks, I think know how to use bzr merge :-)
<jam> jelmer: so... I am able to build it, but now I get a lot of:
<jam> DLL load failed: The specified module could not be found.
<jam> whenever I try to use it
<jam> (during import client)
<jam> so no joy yet
<jam> jelmer: If I run from 'cmd.exe' instead of running under cygwin, I at least get the popup describing the dll that couldn't be loaded. Which seems to be "libapr.dll".
<jam> And I can say that 'libapr-1.dll' is in the Subversion directory, but "libapr.dll" is not. Why would that be?
<jelmer> jam, Not sure what's the problem there..
<jam> maybe markh is a better person to ask
<jelmer> jam, the windows specific bits in setup.py are beyond me..
<jam> though I haven't seen him around :)
<jam> jelmer: what is weird is that the subversion-dev .zip file does indeed have a 'libapr.lib'
<jam> so you have to supply "-llibapr" as you would expect
<jam> however, it seems to correspond with a 'libapr-1.dll' but someone didn't tell it that
<jelmer> jam, are you using setup.py ?
<jam> jelmer: yeah, I'm using setup.py to build it
<jam> on my home machine if I don't manually set the path, it dies because of a missing libsvn_client-1.dl
<jam> if I put the Subversion dir first, it dies because of a missing libapr.dll
<jam> it seems when someone was building subversion they got confused as to what dlls they were supposed to use
<awilkins> It is rather tricksy, I'll have to say
<jelmer> jam: lp:~jameinel/bzr-svn/0.4.13-win32, right?
<lifeless> hi
<jelmer> 'morning Robert
<jelmer> jam: my bzr and launchapd don't seem to recognize it
<jam> jelmer: yeah, I'm using stacking and it didn't seem to propagate to the http:// side, though it worked for we to branch via bzr+ssh
<jam> morning lifeless
<jam> lp:~jameinel/bzr-svn/0.4.13-win32 should be correct
<jelmer> jam, even fetching over ssh doesn't seem to work
<jam> jelmer: weird
<jam> I'm sure it worked here, because I had to install it on the shared windows host
<jam> I'll just send you a bundle for now
<jelmer> jam, thanks
<jam> sent
<jam> jelmer: so when I look at the dev files that that Subversion supplies, the libapr.lib seems to be claiming it will be building a libapr.dll even though there is only libapr-1.dll
<jam> so probably someone built it incorrectly
<lifeless> vila: awake?
<vila> no :)
<lifeless> vila: oh good
<lifeless> vila: so the answer to why the chk of a file is not the sha of its contents is not related to the tests ;)
<lifeless> vila: it is - the CHK for an object is the hash of bytes resulting from encoding it - there is a type header prefixed - not the hash of the thing itself
<vila> oh, so that the chk map can be used for anything
<lifeless> s/chk map/chk store/
<lifeless> but yes
<lifeless> we should be able to scan it and determine the object type to call back to to parse and process data
<lifeless> so for a files content the type is probably something like 'bytes:\n'
<lifeless> but it means what is hashed is still != the files content itself
<lifeless> (not that we use CHK stores for file content today, or in my branch's planned scope at all)
<vila> right, the focus is on inventories right ?
<lifeless> yes
<jam> jelmer: I think I've sorted it out.... but it makes me sad
<jam> It seems that whoever is building the .zip files is doing it differently than the person building the Setup-Subversion.exe installer
<jam> all of the _dev.zip files point to "foo.dll"
<jam> while the installer points to "foo-1.dll"
<jelmer> jam, Thanks, patch merged
<jelmer> jam, Ahhhh
<jelmer> jam, Yeah, there's different people providing patches
<jam> ebswift versus djh
<jam> jelmer: any idea who I should poke with a stick?
<jelmer> jam, saywha?
<jam> jelmer: http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91
<jam> ebswift is the one making the .msi installers
<jelmer> ahh
<jam> djh is the one making the .zip flies
<jam> and they don't talk to eachother I guess
<lifeless> jam: in case you didn't knw, cygwin's mingw is subtly different to mingw's mingw
<lifeless> the -1 different looks like libtool to me
<jam> lifeless: well it works fine here, which is enough for me
<jam> I'll see if that is the problem, though
<lifeless> cygwin's mignw is a gcc cross compiler
<lifeless> mingw's is a native compiler. IIRC
<jam> lifeless: well, compiling against the 1.5.4_dev.zip and making sure the 1.5.4.zip dlls are first in my path means that everything succeeds
<jam> so it is a _dev.zip + .zip having different pointers than the Setup program ...
<lifeless> jam: sure
<lifeless> jam: so I'm thinking they are using a different libtool
<jam> could be
<jam> jelmer: do you have a bzr-svn that doesn't cause every branch probe to completely abort when running bzr.dev?
<jam> 0.4.13 claims it is completely incompatible with bzr.dev and aborts the process
<poolie> hello jam
<jam> hi poolie
<poolie> jam, spiv, lifeless, call in 1m if you like
<jelmer> jam: the 0.4 branch works with bzr.dev
<jam> jelmer: so just update?
<jelmer> jam, yep
<jam> I should say it only occasionally aborts, like when I'm checking out a new branch
<jelmer> jam, only when bzr-svn comes into play
<jam> well, only when it *thinks* it needs to come into play :)
<jelmer> only when *bzr* asks it to probe a location for a bzr-svn branch (-:
<jam> what happened to only issuing a warning?
<jelmer> it only issues a warning when it's one version out of sync
<jelmer> but 0.4.13 is two versions out of sync
<spiv> poolie: hi, I slept in.
<poolie> hi, np
<poolie> want to join us now?
<lifeless> poolie: did you try me?
<poolie> tried it, didn't like it :-P
<lifeless> .oO
<lifeless> now why don't I remember tat
<fullermd> Hey, who used all my ether?
<lifeless> dunno, you should check on ethertube.com
<lifeless> poolie: so, call then?
<lifeless> spiv: you failed
<spiv> poolie: starting skype now
<disturbedsaint> hi
<disturbedsaint> Is there somebody with tortoisebzr experience around?
<poolie> mhammond may be around in a bit
<poolie> or you can just ask
 * markh is here!
<poolie> oh hi
<poolie> :)
<markh> hi :)
<markh> disturbedsaint: what's up?
<disturbedsaint> just triend tbzr but it doesnt seem to display anything
<disturbedsaint> since the included .txt's and wiki don't provide too much info I guess im kinda stuck
<disturbedsaint> Not getting the nice context menu's a shown in the screenshots
<markh> hrmph
<markh> you aren't using a 64bit windows?
<disturbedsaint> nope
<disturbedsaint> 32bit xp
<markh> there is optionally a diagnostic tool installed - 'tbzrtrace.exe' I think.  It's not installed by default though - you need to click the "diagnostic tools" option at install time.  Can you recall if you selected that?
<markh> if not, would it be possible to re-execute the installer and select that?
<markh> (oh - you aren't using bzr 1.8-lite are you?)
<disturbedsaint> I branched
<disturbedsaint> which might be the reason
<markh> branched?
<markh> running from sources?
<disturbedsaint> kinda doing 10things at the same time, sorry for unclear reaply
<disturbedsaint> running from sources indeed
<markh> ah
<markh> so you have pywin32-212 and have registered the shell execution by executing "mtbzr/scripts/tbzr.py"?
<disturbedsaint> pywin32-212.win32-py2.5.exe
<disturbedsaint> and I ran the script
<disturbedsaint> with debug
<disturbedsaint> but the output in PythonWin/Trace Collector isn't all that helpfull
<markh> so no tracebacks or anything?
<markh> you probably need to restart explorer too.
<markh> (inno sends a shell notification that we don't when run manually - we should!)
<markh> if you tell explorer to use a new process for each window, you can often avoid restarting - I tend to restart from the same command-prompt I registered with, which makes sure the env is setup correctly
<disturbedsaint> ah, got a traceback
<disturbedsaint> <type 'exceptions.ImportError'>: No module named win32pipe
<markh> strange
<markh> ah - python from sources too?
<disturbedsaint> afaik not
<disturbedsaint> but is a long time ago I installed it
<disturbedsaint> C:\Python25\Lib\site-packages\win32\win32pipe.pyd exists, dont know if its the right one
<markh> "python -c import win32pipe" works?
<markh> yeah, it will be
<markh> so pythonpath is messed up in com which implies the registry.  Do you have the key HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.5\PythonPath?
<disturbedsaint> importing win32pipe in python shell works
<disturbedsaint> yes,HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.5\PythonPath is there
<markh> it should have the default value of the default pythonpath - c:\python25\lib should be right
<markh> it might have a couple with ';' seps
<disturbedsaint> C:\Python25\Lib;C:\Python25\DLLs;C:\Python25\Lib\lib-tk
<disturbedsaint> should be fine
<markh> yeah
<markh> so - maybe check that is the *first* traceback you see.  Otherwise I'd be inclined to add a 'print' somewhere to see what PYTHONPATH is
<markh> also, seeing if the scripts in shellext\tests work would be interesting.  I suspect they will
<disturbedsaint> ill rerun python tbzr.py --debug and see if I get a traceback
<markh> I expect that to work.  I'm guessing somehow the PYTHONPATH isn't correct when python is loaded a a COM object - it seems to work when Python is loaded normally
<markh> those tests also use COM objects - but I expect them to work as it is Python loading the Python COM objects, so the pythonpath is likely to be correct still.
<disturbedsaint> k
<disturbedsaint> kind of complicated :P
<markh> yeah
<disturbedsaint> yeah first traceback is missing win32pipe
<markh> and that is only when trying to use the shell ext, or at registration time?
<markh> bizare though - win32pipe isn't the first win32 module loaded.
<disturbedsaint> after registration when I browse a folder
<disturbedsaint> by using notepad, open
<markh> what are the last few lines in the traceback?
<markh> hrnmph - that is insane.  The traceback must point at client.py
<disturbedsaint> http://nopaste.info/702238f887.html
<markh> ahh - hg :)
<markh> so that is very strange.  win32pipe is imported in those modules *after* pywintypes, win32api and win32event
<markh> so its not a simple path issue
<disturbedsaint> there is no win32pipe.py
<markh> but it looks like a simple "python can't find module" error, rather than "found the module but failed to load it"
<markh> win32pipe.pyd is the correct file
<igc> morning all
<disturbedsaint> but there is a win32api.py and win32event.py file
<markh> it is right next to win32event.pyd, which is imported directly before win32pipe!
<markh> igc: good morning!
<disturbedsaint> its middle of the night here :P
<igc> hi markh!
<markh> disturbedsaint: oh - you have something strange going on then :)(
<disturbedsaint> ill redownload pywin32
<markh> I think py2exe might create stub .py files for .pyd files.  I can't imagine how they got there for you though.
<markh> disturbedsaint: you might need to uninstall and nuke the dirs too
<markh> what dir is win32api.py in?
<markh> igc: how are things?
<disturbedsaint> in some shady temp-dir
<markh> heh - nuke that :)
<disturbedsaint> C:\Python25\Lib\site-packages\isapi\test\build\bdist.win32\winexe\temp
<markh> hrmph
<markh> oh
<markh> you tried to py2exe an isapi extension?
<igc> markh: surgery was successful ... recovering slowly
<disturbedsaint> not that I know
<markh> igc: awesome!! :)
<disturbedsaint> could have been part of something else though
<igc> markh: more in 3 weeks time though
<markh> igc: what is recovery prognosis?
<markh> ouch
<markh> so one more in 3 weeks, then hopefully just recovery?
<igc> markh: kind of - another 4 hr operation in 3 weeks, then recover from that, then a few months of chemo to wrap up
<markh> bugger
<igc> markh: so a long journey
<igc> markh: nice to be back online though!
<markh> yeah :(  and yeah :)
<markh> i expect its nice to know the first hit was a success
<markh> must be a weight from your mind
<igc> yup
<igc> markh: and how are you?
<markh> I'm very well!
<igc> excellent!
<markh> had about 10 days in china for my brother's wedding - was quite amazing!
<igc> wow
<markh> absolutely fascinating place
<markh> disturbedsaint: this is one of the reasons that redoing the COM part in C++ is on the list of things to do...
<disturbedsaint> markh: is it that much harder in python?
<disturbedsaint> btw test_iconoverlay.py is OK, test_contextmenu.py fails
<markh> its probably just stale.
<markh> disturbedsaint: its much easier in python - python's more of a pain from a deployment and 'embedding in other random processes' POVs.
<disturbedsaint> I see
<disturbedsaint> well I'm off to bed
<disturbedsaint> if there's anything I can test or try I'll be here on the irc this weekend
<markh> disturbedsaint: sorry I couldn't get you going, but something very strange is going on with those imports - and we haven't yet got to anything tbzr related!
<markh> I'll be on and off here too - just ping me
<disturbedsaint> Well Ill do a clean python install to start with
<disturbedsaint> prolly till tomorrow
<markh> check there are no other dupes of 'wn32api' in your tree or on your PYTHONPATH
<disturbedsaint> Will do!
<disturbedsaint> have a nice day! (or night?)
<markh> I'd try adjusting client.py and printing win32event.__file__ just before the win32pipe import
<markh> it should print the file right next to win32pipe.pyd!
<markh> 10:15 am for me - about to make coffee no 2 :)
<markh> good night!
<disturbedsaint> will try that
<disturbedsaint> thx!
<disturbedsaint> gb
<chx> after bzr init I get Standalone tree (format: pack-0.92) I have bzr 1.8 installed is there something I need to do? bzr init --1.6 maybe? 0.92 seems very old.
<lifeless> chx: thats fine
<lifeless> chx: that just says that the default format was created in bzr 0.92
<lifeless> chx: so you can use the repository / branch with bzr clients back to 0.92
<chx> oh ok.
<ccxCZ> how do I convert relative path to file id?
<lifeless> poolie: do we do announcements on lp about bzr releases
<ronny> yo
<lifeless> ccxCZ: in python?
<ronny> is there any documentation about the metadata i can put into a bzr repo and how it worksÃ
<ccxCZ> lifeless: yup
<lifeless> ccxCZ: tree.path2id(relpath)
<poolie> lifeless: yes, we do
<lifeless> hno has observed that there isn't a 1.8 announcement
<lifeless> I haven't verified this
<ccxCZ> lifeless: I haven't noticed that, thanks
<poolie> that may be true
<ronny> lifeless: what kinds of additional metadata about history is possible in bzr?
<lifeless> ronny: I'm not sure what you mean
<ronny> lifeless: i mean extra information i can assign to revisions
<lifeless> ronny: at commit time bzr can record arbitrary key:value properties
<ronny> (afair rich root + bzr svn do use stuff like that to keep clones able to communicate with the svn upstreams)
<ronny> lifeless: and after commit?
<lifeless> ronny: there is no facility for editing a revision after its committed
<ronny> lifeless: i dont want to edit, i just want to add stuff
<lifeless> ronny: that would count as editing :)
<ronny> sad
<lifeless> ronny: you could build a lookaside system on top of bzr's core I guess; what you're asking it pretty vague to me, I don't really understand your use case
<lifeless> ronny: the very very very deep level of bzr is a write-once key:value database
<lifeless> ronny: everything is built on the write-once aspect, because that makes distribution and transfer of data and integrity _much_ simpler than if we didn't have that
<ronny> lifeless: i just want append-only metadata thats added after the actual commit
<Odd_Bloke> ronny: A text file?
<lifeless> ronny: so, we don't have a pre-canned mechanism for that today; you could write one using bzr's primitives, or even as odd_bloke says just use a text file
<ronny> no NOT files
<Odd_Bloke> ronny: Why not?
<ronny> its metadata about the history, not part of the actual history of the data im managing in the scm
<lifeless> ronny: I understand that
<ronny> think of it as rich tags
#bzr 2008-10-31
<ronny> i want it to be distributed with the commit its refering to
<Spaz> strange question...
<Spaz> what is ubottu written in?
<Spaz> and is it open source?
<Spaz> oh it's a supybot :(
 * Spaz cries a bit, and forks back into the background
<ronny> monotone can do that just fine
<lifeless> ronny: AIUI monotone it will do that because it syncs the entire database bidirectionally unconditionally
<ronny> lifeless: its append-only - and metadata are certified key-value pairs on the revision
<lifeless> ronny: I'm sorry, but we don't have an existing facility. What is the monotone facility called so I can look it up
<ronny> (and it can have more than one key-value pair with the same key)
<Odd_Bloke> ronny: What would happen when the same revision was richly-tagged in two different branches at the same time?
<ronny> lifeless: certificates
<lifeless> Odd_Bloke: monotone's storage system is quite sophisticated, you get two tags with different certs
<lifeless> ronny: thanks
<ronny> Odd_Bloke: thats the way fast-forward merges with branches work in monotone
<ronny> i rev, n branches
<lifeless> ronny: http://www.monotone.ca/docs/Certificates.html <- the right place?
<ronny> just n certificates with the key branch, and the branch names as value
<ronny> lifeless: yeah
<lifeless> ronny: right, I've been through some related stuff before
<ronny> lifeless: it allos to do quite cool things
<lifeless> ronny: I'll read this on the train after work; I wish I could offer you a precanned answer, but we don't have one
<ronny> like accept only revs that have passes a set of tests on all buildbots
<lifeless> AFAIK neither hg nor git have precanned answers for adding-metadata like this either
<ronny> lifeless: basically all mainstream dvc's have toy-level metadata
<lifeless> I think its a perspective thing
<lifeless> monotone has a very different worldview
<lifeless> like darcs has a different worldview
<lifeless> and its good to learn and consider ideas; however the challenge for bzr/git/hg in this space is that much of monotone is built up from the certificates primitive, and well, we're not.
<ronny> lifeless: well, the core of it is the graph of files/revisions (i dont correctly understand it, but bzr's graph should be pretty close)
<ronny> however everything thats not part of the real history of files is not in that graph, but a certificate that add information (commit messages, authors, dates, ...)
<fullermd> Which is to say, a rather different worldview   8-}
<ronny> but much more sane and practical
<fullermd> A matter of perspective.  Some people consider CVS more sane and practical too.
<ronny> one can just limit updates by the certificates added to an revision
<ronny> (ie test passes, developer approval, anything else)
<fullermd> Yes, but by its very nature that means that the metadata is completely divorced from the data.  Two people could have the same revision, but have completely different ideas about how committed it, when it was committed, and what the log message was.
<fullermd> So you end up having to have conflict resolution procedures for that, and accepting the local-view issues.
<ronny> you just dont have to care about that
<fullermd> Neither is necessarily Right, but there are different tradeoffs either way.
<fullermd> I'll care about whatever I wanna care about, thankyouverymuch   ;)
<ronny> well, its all there, and if you pull it, you keep it
<spiv> The weather is getting warm enough that I'm starting to really notice it when I run the test suite on my laptop...
<poolie> spiv, it's supposed to get up to 36C today
<poolie> also
<spiv> Yeah, I saw :/
<jelmer> lucky bastards
<poolie> apparently batteries getting hot in a laptop while at full charge is a leading cause of early exhaustion
<poolie> in the sense of their capacity decreasing
<spiv> My battery is already down to ~40% capacity, but it is about 2 years old.
<poolie> so if you want to be really frugal it's better to pull them out while on ac
<spiv> Hmm, maybe not quite that bad, but pretty low.
<poolie> this is pretty annoying if you bump the cord though :)
<spiv> Right, which I do do :)
<poolie> apparently it is best to store them at about 50% charge
<poolie> which is a bit hard to arrang
<lifeless> yah
<lifeless> there is a site
<lifeless> that has differnet battery types and storage levels
<AfC> It's probably best, though, to arrange for you laptop not to oops at 100% CPU when you think it's suspended before putting it in a bag and closing the zipper. There's just nothing like the smell of singed components that comes from baking your machine in constrained CPU exhaust.
<fullermd> Oh, sure there is.  Like the one time I put 120 volts across a 2N2222...
<lifeless> thats a DC diode isn't it ?
<lifeless> a little one
<fullermd> NPN bipolar transistor.
<lifeless> duh, yes
<lifeless> I need to do more electronics I think
<fullermd> It lasted a good quarter of a second, I figure...
<AfC> What's a few extra volts between friends?
<lifeless> AfC: electric
<fullermd> Well, a few extra volts presumably means a lot of extra amps   :p
<fullermd> After all, a transistor is just a fuse with gain...
<poolie> spiv, i thought i remembered multiple occurrences of _ on the lhs of an assignment giving an error in python
<poolie> but it does seem to work, at least in 2.5
<lifeless> poolie: don't see why it would error, it just has to bind multiple times :)
<lifeless> poolie: I think for _, _ in thing:
<lifeless> poolie: that might error
<poolie> it's not a big deal
<spiv> poolie: I dimly recall there being some case where than happens, but I can't seem to find it now.
<spiv> So I guess it's sufficiently obscure not to matter :)
<spiv> poolie: ok, I think I have only one more thing to do on the autopack branch
<spiv> poolie: which is deciding what the "NotPackRepository" error on the wire ought to look like
<lifeless> spiv: why error?
<lifeless> spiv: if there is no return value, and its not a pack repo, just swallow
<spiv> lifeless: well, that's a possibility.
<spiv> It is an indication that at best something weird is happening.
<spiv> Because it shouldn't ever be trying that verb on a non-pack repo.
<spiv> Not returning an error has the advantage of being a little bit simpler.
<spiv> Ok, I think I'll just not return an error, I'm happy with that.
<spiv> lifeless: thanks
<poolie> that's ok with me too
<spiv> Ok, I've just sent the current patch to the list.
<spiv> I think this version is ready for merging as-is, so please take a look and give it a BB: blessing :)
<poolie> i will
<poolie> spiv, you have a handful of other patches approved for 1.9
<poolie> if you're sure of them now would be a good time, while i read this
<poolie> lifeless: so would there be any drawbacks to making 1.9 (the btree format) be rich-root only?
<poolie> i guess conversions into it would be substantially slower as we'd have to rewrite all inventories
<lifeless> poolie: do the sha1's get rewritten correctly?
<lifeless> I still don't have a clear answer to this
<poolie> when the inventories are changed when fetching into a rich root repo?
<lifeless> and yes, while the default isn't rich root, I think there are clear drawbacks to adding a new format that is a trapdoor for users on the default
<lifeless> yes
<lifeless> and during reconcile
<lifeless> I don't know the status of this; I thought it was the one remaining issue; I may be wrong and its done.
<poolie> what would reconcile be doing here?
<poolie> s/here/relevant to this
<lifeless> there are existing repositories with damaged goods
<lifeless> where the revision sha1 is the sha1 of a non-rich-root inventory, but the inventory is a rich root one
<lifeless> I have a patch I cannot land for 'check' to check the sha1's are valid
<lifeless> reconcile can in theory detect this specific issue by converting the repository to a non-rich-root one, serialising, and if the sha then matches, rewrite the revision object to have the current inventories sha
<poolie> cannot land the patch why? because there's no reconcile code to fix up what it finds?
<lifeless> yeah
<lifeless> in fact, IMO accessing inventories should check the sha1 against the revision as a matter of course
<lifeless> but thats different (though still dependent)
<Peng_> beuno: ping?
<poolie> spiv, review sent
<spiv> poolie: thanks
<spiv> poolie: I don't see the review anywhere?
<poolie> :/
<poolie> try now?
<spiv> poolie: I see it now
<spiv> I just tested 'bzr pack' manually, and it's working ok over HPSS.
<spiv> And that explicit raise is correct (although it maybe it'd be worth making a self._ensure_ok(response) helper like RemoteTransport uses?).
<poolie> ok
<poolie> please send it to pqm then
<poolie> it does seem kind of buggy to me that so many of the client stubs check the response explicitly
<poolie> (i may be out of date here, i know you landed something for this)
<spiv> _translate_error handles responses that are flagged as errors, this is checking that a successful response doesn't have garbage (which is perhaps less useful now that error responses are clearly flagged on the wire).
<poolie> ah i see
<spiv> It's more interesting when the response may be one of a fixed set of values.
<spiv> I think maybe that the client should be more liberal and not worry about the content of responses that it doesn't use in any way.
<spiv> But atm we're pretty consistent about doing it this way.
<spiv> Ok, it's with PQM.
<spiv> I'm going to grab a late lunch.
<michalski-bj> when trying to push my branch(that I own)(bzr push lp:~<username>/+junk/<project>)
<michalski-bj> it says: bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Emichalski/%2Bjunk/vector-core/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<michalski-bj> ...
<Peng_> michalski-bj: Run 'bzr lp-login your-username'
<michalski-bj> ok thanks, I think I remember doing this on my old pc, you should add these instructions to the error message
<lifeless> poolie: back
<michalski-bj> thanks again, gotta go, bye
<Peng_> Has that error message improved in a recent version?
<warren> [warren@newcaprica ldm-trunk]$ bzr diff
<warren> bzr: ERROR: [Errno 12] Cannot allocate memory
<warren> [warren@newcaprica ldm-trunk]$ bzr diff
<warren> === modified file 'src/ldm.c'
<warren> Really odd...
<warren> bzr-1.7-1.fc9.x86_64
<Peng_> "Errno 12", huh? I wonder why that happens instead of a MemoryError?
<lifeless> Peng_: probably a C extension
<lifeless> Peng_: raising OSError(errno, strerror(errno))
<Peng_> Oh, ok
<lifeless> warren: ^
<warren> meaning?
<lifeless> warren: not sure about root cause; does this happen repeatedly for you?
<warren> lifeless: yes
<warren> lifeless: although not all the time
<lifeless> warren: there should be a backtrace in ~/.bzr.log
<warren> lifeless: http://fpaste.org/paste/8358
<lifeless> hmm, I don't have a browser handy
<lifeless> warren: could you file a bug please?
<warren> umm, where, how?
<lifeless> https://bugs.launchpad.net/bzr/
<fullermd> _readdir_pyx
<spiv> Yay, autopack-rpc landed.
<lifeless> fullermd: interesting; readdir is ENOMEMing? - or -
<lifeless> warren: actually
<lifeless> warren: I bet that this is a fixed bug in 1.8
<lifeless> warren: readdir has some special needs for errno handling
<warren> ok
<lifeless> we didn't have that correct in the first release of the readdir bindings
<fullermd> Seems like it.  That's what errno 12 is on my system (though I'm pretty sure those vary a fair bit from system to system)
<lifeless> they're pretty stable for the common ones
<poolie_> lifeless: i'd like you to make a 1.9 branch when my current pqm job completes
<poolie_> approximately then anyhow
<poolie_> if it would be much easier you can do it now
<lifeless> poolie_: tell me when its ready, I've made the branch, just need pull over the top
<poolie_> kk
<lifeless> poolie_: I'm leaving for the train in < 10 minutes though
<lifeless> ok -> train (the 4:03 gets to town hall with at 15 to, allowing a timely walk with no crowds)
<spiv> I'm looking at a similar trip, different train line :)
<vila> hi all !
 * gour sent reply to 'bzr vs. git' thread
<luks> hopefull it will not turn into a
<luks> ... into a 'bzr vs git' thread
<luks> man, I can't type
<poolie_> i hope so too
<poolie_> i'll kill the thread if it does
<poolie_> life's too short
<newfeats> hi.  i'm trying to set the BZR_SSH variable.  how would i go about that?
<poolie_> on windows or unix?
<newfeats> win.
<newfeats> i created my SSH keys already and IDed myself.  it suddenly then asks for BZR_SSH variable.
<newfeats> i'm using putty from openssh.org's site links.
<newfeats> getting tired of conservatives.
<beuno>  
<poolie_> newfeats: (back) what message are you getting exactly?
<poolie_> could you open something at http://answers.launchpad.net/bzr
* poolie_ changed the topic of #bzr to:  Bazaar version control system | http://bazaar-vcs.org | please test 1.9rc1 and format 1.9 | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<newfeats> poolie_: https://answers.launchpad.net/bzr/+question/49587
<luks> newfeats: it's missing the main information, the actual error message
<poolie_> ok, i took a stab at it
<poolie_> good night though
<Spaz> hello :0
<Spaz> :)
<Spaz> happy halloween
<uws> Urgh
<uws> Bzr is eating all my RAM
<uws>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
<uws> 14032 wbolster  20   0 2492m 1.4g 1536 D   13 73.5   5:54.59 bzr
<uws> 2GB RAM in total
<Peng_> That's awesome. What the heck are you doing with it?
<Peng_> (Sorry, not helpful.)
<uws> just branching a repo
<uws> try for yourself:  bzr branch lp:~uws/webkit-open-source/webkit.trunk WebKit
<uws> bzr 1.8 btw
<uws>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
<Peng_> No thanks. I've already got Firefox using all my RAM.
<uws> 14032 wbolster  20   0 2502m 1.6g 1520 R  100 79.8   6:22.60 bzr
<uws> Also eating all 100% of my CPU
<uws> well, one of my cores
<Peng_> Oh, that's your branch?
<Peng_> Jeepers, how large is it to cause that?
<uws> Peng_: it's huge
<uws> it's (not even up to date) mirror of the webkit svn repository
<uws> Finishing pack 5/5
<uws> Yay. RAM usage dropped
<Peng_> What does "bzr info -v" do? Download the entire indexes?
<uws> Peng_: on my branch?
<uws> bzr is now eating 100% CPU in "Build phase 0/2"
<uws> whatever that may be
<uws> ai, RAM usage growing again :(
 * uws waits for the OOM to kick in ;)
<Peng_> uws: No, in general. I ran "bzr info -v" on your branch, and it was using a lot of bandwidth and the RAM kept growing (only to like 90 MB, but..).
<uws> What does "build phase" mean?
<Peng_> Oh..I guess I can check the code. :P
<vila> uws: building the working tree
<uws> takes 100% cpu for minutes already
<uws> and this is a relatively fast machine
<Peng_> Hmm...hasn't that been improved recently?
<uws> 1.8 is quite recent
<uws> the progress bar is halfway done and just advanced to "build phase 1/2"
<Peng_>     * ``bzr co`` uses less memory. It used to unpack the entire WT into
<Peng_>       memory before writing it to disk. This was a little bit faster, but
<Peng_>       consumed lots of memory. (John Arbash Meinel, #269456)
<Peng_> That's more recent than 1.8.
<uws> Hm, good
<uws> Branched 29843 revision(s).
<uws> YAY!
<Peng_> Yay
<jrydberg_> hi.
<visik7> it's been a while since I used bzr upload I don't remember how to put it through ssh I got bzr: ERROR: Unsupported protocol for url "sftp://...
<visik7> or ssh://
<uws> vila: Install python-paramiko
<uws> vila: then sftp:// ("dumb") and bzr+ssh:// ("smart") should work
<visik7> oh
<visik7> and for permission there is no way to have a post command that fixes them?
<Pieter> is ian here?
<james_w> Pieter: Ian Clatworthy?
<Pieter> yes
<james_w> it's the middle of the night for him
<Pieter> ah :)
<spiv> aadassdfsd
<Odd_Bloke> spiv: aadassdfsd to you too.
<spiv> Odd_Bloke: I would also have accepted "gesundheit"
<james_w> if I have a 16000 path tree, is it going to be more efficient for bzr workingtree operations to have it split in to directories?
<james_w> it's just a flat layout currently
<awilkins> james_w: I can't see why it would be any different, personally
<james_w> it seemed to be taking an age to read the dirstate
<james_w> it's not so bad now though, once it's reasonably up-to-date
<awilkins> This on Windows?
<james_w> nah
<awilkins> I get the same ; once it's "warm" my tree of 4000 odd paths will `bzr st` in less than a second
<awilkins> On *nix it's rather faster though :-)
<james_w> this is a rather odd tree
<awilkins> 16,000 files in one folder, yes, that's a little off
<awilkins> *odd
<james_w> it's not source code or anything
<james_w> just a bunch of log files
<awilkins> Heh, I can imagine
<awilkins> Why, pray tell, do you version logfiles?
<awilkins> Would it not be just as good to incrementally back them up?
<james_w> it was Rob's suggestion, though I think I'm implementing it wrong
<awilkins> Since a logfile, in my experience, is not mutable once it's finished?
<james_w> I think it's supposed to clear the tree after committing
<awilkins> Meh?
<james_w> so it's instead of logrotate
<james_w> I'm using it as a kind of logwatch
<awilkins> What, sort of "bzr commit -m "Lots of logs" ; rm *  ?
<james_w> hmm, can't find where Rob uses it to compare
<james_w> it's on bzr-playground.gnome.org somewhere, but I think it's hidden
<awilkins> james_w: Oh, is it supposed to be renaming each rotated log to the same filename?
<james_w> yeah, I think that's what Rob does
<awilkins> james_w: that way you can compare the logs to each other based on their diff (and presumably spot anomalies easier)(
<awilkins> Works ok as long as your diff viewer supports rules to ignore timestamps I suppose.(or if you set your log formats to omit them)
<james_w> though his is in in-process, so it just writes the log, commits, and then removes it. I can't really do that, as I have four processes
<awilkins> james_w: How about - write log until finished, rename log to a file that ISNT in your ignore pattern
<awilkins> Have job that watches for new non-ignored files
<james_w> yeah, that could work
<awilkins> I've been using it to diff my output from a program so I know if I break it (in the absence of proper unit tests /me slaps own wrist)
<james_w> :-)
<awilkins> It spits about 9000 files so it's v. useful on that score
<Odd_Bloke> What are split-inventories?
<rocky> don't suppose anyone's updating http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html for the 1.9rc1 release?
<Tak> is there a known winstaller for a bzr-svn that works with a newer bzr than 1.5?
<jelmer> Tak: Hi
<jelmer> Tak: I think John was looking at creating one for 1.8 last night
<jelmer> not sure what the status of that is
<jelmer> jam: ping
<Tak> jelmer: hello, cool
<jelmer> Tak, btw, did you see my changes to monodevelop-bzr?
<Tak> yeah, I'm just merging them into my branch now
<Tak> I was just going to ask how things were going wrt md-bzr
<jelmer> I'm still waiting for a new version of monodevelop to hit debian sid :-/
<Tak> heh
<Tak> that won't happen until after mono 2.0 hits
<Tak> "bzr: ERROR: Repository KnitPackRepository is not compatible with repository KnitPackRepository"
<Peng_> Tak: One repo is --pack-0.92, one is --rich-root-pack.
<Odd_Bloke> Tak: And the error message has been improved, I believe. :)
 * Tak waiting for new bzr to hit debian sid :-P
<Peng_> Oh, really? That's good.
<jelmer> tak: there's new versions in experimental
<Tak> hm @ experimental
<Tak> argh, now my wc is rich-root-pack and my lp branch is an old format - how do I resolve this?
<Peng_> Tak: Well, you could upgrade the lp branch, or you could push your current branch to a non-rich-root repo to downgrade it (probably).
<Peng_> Err, wait.
<Peng_> Or pull it into a non-rich-root repo.
<Tak> I tried to upgrade the lp branch
<Peng_> I dunno. *Something* like that should work, if someone didn't go and break it.
<Tak> some of the other branches are rrp, so it's going to be a pita if I can't convert mine somehow
<Peng_> Tak: What happened?
<Peng_> Tak: You might have to use the full bazaar.launchpad.net URL, and you might have to use sftp
<Peng_> (Yes, this is a pain.)
<Tak> hmm, I tried the bzr+ssh url
<Tak> I'll try others
<Tak> ok, it looks like it's going with sftp
<Tak> success!
<Peng_> Great. :)
<awilkins> Yes, the SFTP works, I don't think the smart server does upgrades
<Peng_> I thought that had been added recently (1.6?), just thunking over to the VFS. But that might've been something else.
<awilkins> Hmm, which version is Launchpad running though
<tvainika> jelmer: do you have plans to upload bzr 1.9rc1 to debian experimental?
<jelmer> tvainika, Yeah - I just wasn't aware it was out already :-)
<Peng_> awilkins: 1.7.1rc1
<Peng_> upgrade over bzr+ssh was added in 1.6rc2.
<Peng_> But I think there are issues with LP.
<james_w> what's the "--strict" argument to testament for?
<awilkins> james_w: It seems to produce a different hash
<awilkins> james_w: Why this is, I'm not sure
<james_w> yeah, that's what concerns me
<awilkins> Theory - the strict has includes the log comment
<awilkins> git hashes include their log comments, perhaps bzr does not by deafult
<james_w> it adds in ie.revision and ie.executable to what is hashed for each ie
<chrisob> When I get a 'bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)' What should I check? I know there is connectivity and the user has permission (tested from another PC)
<awilkins> chrisob: What's the server?
<chrisob> an internal linux server, I dont know if thats what you mean though. I have only just started supporting users on it...
<awilkins> Hmm, which protocol are you using
<chrisob> SSH
<awilkins> Ok, can this machine just open a plain old shell using SSH for that user?
<chrisob> bzr info bzr+ssh://<username>@<server>
<awilkins> Ah, how about - is this machine running ssh-agent with the appropriate key loaded
<chrisob> well it has no problem with another shell connection using ssh
<chrisob> i though it could be a key problem
<chrisob> though i dont know where it references the key
<awilkins> ls
<awilkins> oops
<awilkins> chrisob: It should just choose try all the keys in the local ssh-agent against the server and see if they work for the user you are specifying
<chrisob> okay thought so....thanks for the help
<mwhudson> jelmer: bzr.dev get svn://svn.twistedmatrix.com/svn/Twisted/trunk twisted-bzr-svn
<mwhudson> bzr: ERROR: The branch svn://svn.twistedmatrix.com/svn/Twisted/trunk has no revision None.
<mwhudson> jelmer: ^ seen that one before?
<jelmer> mwhudson, yeah
<jelmer> mwhudson, what version of bzr-svn?
<mwhudson> jelmer: lp:~jelmer/bzr-svn/0.4/ as of a day or two ago
<jelmer> hmm
<mwhudson> jelmer: i'm updating now, will try again
<jelmer> mwhudson, please file a bug
<jelmer> mwhudson, I did fix some things related to this, but more than a month ago
<jelmer> it's actually another exception masked by an exception handler in bzrlib/builtsin.py
<mwhudson> jelmer: still happens with trunk everything
 * mwhudson embuginates
<mwhudson> jelmer: https://bugs.edge.launchpad.net/bzr-svn/+bug/291686
<ubottu> Launchpad bug 291686 in bzr-svn "branching twisted svn fails with "bzr: ERROR: The branch svn://svn.twistedmatrix.com/svn/Twisted/trunk has no revision None."" [Undecided,New]
<jelmer> mwhudson, thanks
<jelmer> mwhudson, isn't it like 4 in the morning in NZ btw?
<mwhudson> jelmer: i'm in london :)
<jelmer> ahh :-)
<jam> asmodehn: hey, I just saw your email. The change I made isn't in 1.9 AFAIK
<asmodehn_> jam : yeah that what I realized... I am using your dev versions now to replicate what I have to ;)
<asmodehn_> hopefully it ll go to the end this time ;)
<jam> well, worst case I suppose you could use rsync
<asmodehn_> I tried that but I am not sure yet how to properly use it
<asmodehn_> but yes for now I ll keep using your dev version ;)
<asmodehn_> at least for the big transfers
<asmodehn_> 1.9rc1 for the rest I think
<asmodehn_> jam : mmm doesnt finish... hit the other bug I posted to the mailnig list :-s
<jam> asmodehn_: the ldap one?
<asmodehn_> yep
<asmodehn_> just sent another email with the end of the log
<asmodehn_> but yeah maybe I should play with rspush instead :s
<jam> so... the locking thing seems like a more significant issue that you need to resolve.
<jam> one quick fix is to just do
<jam> bzr whoami "My User <my@username>"
<jam> or whatever makes sense for you
<jam> it sounds like that would fix it
<asmodehn_> the whoami already shows the right user...
<jam> but is it getting that "by accident" from the system, or because it is set somewhere?
<asmodehn_> you mean I need to force it to write it somewhere in bzr ?
<asmodehn_> bzr whoami return the current user running the command right ?
<asmodehn_> anyway I did that and I ll run the bbranch again...
<jam> asmodehn_: aren't you also doing something weird with "sudo/su" ?
<jam> could it be that the other user is not configured correctly?
<asmodehn_> bzr whoami is fine everywhere...
<asmodehn_> I mean return the good user
<asmodehn_> maybe I need to "force it" so it gets stored somewhere in .bzr ?
<asmodehn_> everywhere I mean ?
<ktenney> Howdy, what is the recommended bzrlib version of $>bzr revert -r10
<ktenney> I would suspect bzrlib.workingtree.Workingtree.revert, but don't see how to specify a revision to revert to
<ktenney> there is bzrlib.transform.revert(working_tree, target_tree, filenames, ... but I don't know where to plug in version numbers
<james_w> ktenney: for the transform thing I suspect you pass a target_tree which is
<james_w> target_tree = wt.branch.repository.revision_tree(rev_id)
<james_w> I suggest you look at cmd_revert in bzrlib/builtins.py
<ktenney> james_w: ok, previously I was discouraged from the builtins.cmd_xxx when scripting, however in this case, preferred to the transform thing?
<james_w> ktenney: no, I'm just suggesting looking at how bzrlib implements revert might give you some clues about implementing revert
<ktenney> james_w: ah, ok, thanks.
<asmodehn_> jam: mm it looks like explicitely setting teh bzr whoami the problem has been fixed... I ll test once more though...
<asmodehn_> jam: mm ok seems it did... bit confusing... in that case, shouldnt whoami return something more when it s not been setup in bazaar, or when the bazaar and the system result dont match ?
<disturbedsaint> hi all
<Peng_> Shouldn't "bzr help formats" list the knit formats as deprecated?
<Peng_> So...should using btrees on bzr.dev's repo make much of a difference performance-wise?
<Peng_> What about something larger?
<Peng_> Are the indices created by "bzr upgrade" fully packed and whatnot?
<Peng_> (fully optimized, I mean)
<fullermd> I would assume they otter be, since it's touching everything anyway.  Not that that necessarily bears on whether it does, but...
<Peng_> Right.
<Peng_> I tried running "bzr pack", but it took 3 seconds and did nothing.
<Peng_> I almost want to try to pack it again, but my disk cache has been thrashed enough today.
<lifeless> beuno: search in loggerhead trunk is broken ?
<Peng_> lifeless: Does "bzr upgrade"ing to btrees create them all fully optimized and eveyrthing, or should you run "bzr pack" afterwards?
<lifeless> Peng_: they should benefit much less from 'bzr pack'
<Peng_> Should they benefit at all?
<lifeless> yes, there is always the latency impact of multiple pack files
<lifeless> so packed is always optimal vs unpacked
<lifeless> just the index layer doesn't suck now
<Peng_> Well yeah, but... Ignoring multiple pack files, after running "bzr upgrade --1.9", is there any reason to "bzr pack"? Will it save 5 KB of disk space or anything?
<lifeless> no
<Peng_> OK :)
<Peng_> Thanks.
<Peng_> Nice, upgrading one large repo to btrees made the indices go from 60 to 18 MB. :)
<disturbedsaint> markh: are you there?
<markh> disturbedsaint: i am - hi!
<disturbedsaint> hi
<disturbedsaint> been trying a little more, clean install and all, but not that much progress unfortunately :/
<markh> did you try printing win32event.__file__ just before the failing import of win32pipe?
<disturbedsaint> didnt get that far :/
<disturbedsaint> "FAILED to import tbzrlib - please adjust your PYTHONPATH"
<disturbedsaint> since I am running from sources and dont want to install it to site-packages (for now, to keep the new install clean ;) but the tbzr dir is in sys.path
<markh> right - the way I do things is to not try and get 'tbzrlib' in site-packages at all - just set PYTHONPATH to point at the parent of the tbzrlib directory.  I do the same with bzrlib itself - PYTHONPATH points at both bzrlib and tbzrlib
<markh> the *parent* of tbzrlib must be
<markh> ie, a python shell should be able to do a simple import of tbzrlib
<disturbedsaint> tried to do it in a clean way with .pth files, but that doesn't really seem to work
<markh> set set PYTHONPATH=c:\parent_of_tbzrlib
<markh> s/set set/just set/
<lifeless> Peng_: :)
<markh> (due to some magic, its not necessary for this to be set globally - just when registering the extensions - the path where tbzrlib is written to the com object's registry and used at runtime)
<pekuja> is it possible to undo a merge if there's a conflict?
<Peng_> pekuja: If it's uncommitted, "bzr revert"?
<pekuja> ah, of course
<disturbedsaint> markh: the part about it not beeing needed globally is to hard for me to grasp Im afraid :x
<markh> um - its not necessary to try and set PYTHONPATH to point at tbzr lib in a "global" way.  Just at the cmdprompt you are using is fine
<pekuja> how about a pull? that'd just be a matter of going back to a previous revision, right?
<Peng_> pekuja: Well, what do you want to undo? If you want to get rid of the new revisions, "uncommit", though that doesn't touch the working tree.
<Peng_> pekuja: You shouldn't pull with uncommitted changes.
<pekuja> oh, right, you have to commit a pull too?
<pekuja> sorry, I'm new
<disturbedsaint> markh: have to reboot, just installed tsvn, brb
<pekuja> and I meant if I pull something, but maybe that has changes I didn't want to have... well I guess it's kinda not a real issue
<pekuja> well, maybe if the newly pulled code breaks something without creating a conflict
<pekuja> how would I "undo" the pull?
<pekuja> revert?
<Peng_> pekuja: Undo how? You could "bzr revert -r 123" to revert the working tree to a previous revision.
<pekuja> yeah, well I meant going back to how my branch was before I pulled somebody else's changes
<Peng_> pekuja: What do you mean by that? If you want to remove the new revisions from history, use uncommit.
<pekuja> not like undoing the actual changes, just not including them at that point in my particular branch
<Peng_> Er.
<Peng_> I don't know what that means.
<pekuja> ok
<pekuja> I'm having trouble explaining it here...
<pekuja> but yeah I think uncommit might be what I mean
<pekuja> I just meant I'm not looking into removing the changes such that if the other user were to pull from my branch later, they'd have the changes removed
<pekuja> so basically, a pull fetches me changes from another user's branch and commits them in my branch, while a merge will get me the changes but commit nothing? (so that I can resolve any conflicts and then commit when the code is ok)
<Peng_> A pull makes your branch a mirror of another branch. A merge lets you, well, merge changes into your branch, without having to throw out your unique history.
<disturbedsaint> markh
<disturbedsaint> still get the same error
<disturbedsaint> added the print win32event.__file__ but where would it print to? since the error happens when opening the file-open dialog box
<markh> is should print to win32traceutil, just above the ImportError traceback
<markh> it should print the path to a .pyd file, and it should be the win32event.pyd next to win32pipe.pyd
<disturbedsaint> ah, got it!
<disturbedsaint> C:\Program Files\TortoiseHg\win32event.pyd
#bzr 2008-11-01
<markh> there's your problem :)
<disturbedsaint> its hg :/
<disturbedsaint> ill uninstall
<markh> well
<markh> just work out how it got on your sys.path
<disturbedsaint> was comparing hg with bzr :P
<markh> but yeah, this channel will be unlikely to adise you to *not* uninstall hg ;) :)
<disturbedsaint> :P
<markh> it looks like tortoise's installer or something is broken - tbzr should not interfere with a stand-alone python install :(
<markh> s/tortoise/hg/
<markh> ack :) s/tbzr/hg/ too -  I think I'll give up :)
<disturbedsaint> I guess thg's install is broken then, since it does somehow add itself to sys.path
<disturbedsaint> when I just run a python shell though it's not there
<markh> strange
<markh> maybe the python.dll from that dir is found before any others?
<markh> if that dir is before system32 on PATH I could see that happening...
<disturbedsaint> will have a look,
<disturbedsaint> in the trace it says bin path =  C:\Program Files\TortoiseHg
<disturbedsaint> you're right I guess "C:\Program Files\TortoiseHg;C:\Program Files\TortoiseSVN\bin;C:\Python25"
<markh> hrm - bin path should include \windows\system32 - all should work if you move that before hg
<markh> or uninstall hg :)
<disturbedsaint> yeah :P
<disturbedsaint> will do!
<disturbedsaint> bad behaviour! :P
<markh> for my interest, why are you playing with sources instead of just the binaries?  you hoping to hack a little?
<Peng_> Maybe you should take this up with the hg guys too to get that side of it solved.
<disturbedsaint> yeah I'd like to get the latest version
<disturbedsaint> +I don't mind to do a little trial&error/editing here and there to make it work
<disturbedsaint> Can't fix a lot (yet, still want to learn more bout python) but can at least file bugs and test
<markh> yeah - its possibly just their installer.  I'm not sure I'll get to finding and subscribing to their mailing lists etc
<markh> ultimately we will be replacing that code with c++ anyway, so it should be less of a problem.
<markh> and hopefully 'ultimately' means 'in the next couple of months'
<disturbedsaint> you also know c++ or is someone else going to do the codeing?
<markh> i know it too
<disturbedsaint> I can file a bug for hg btw
<markh> are you sure you didn't manually add that dir to your PATH?
<disturbedsaint> the hg dir?
<markh> if not, I guess the bug should say "please ensure you add yourself to the end of PATH, not the start"
<disturbedsaint> 100% sure I didnt do that myself
<markh> yeah
<markh> cool
<markh> and say "the problem is that python COM objects rely on pythonxx.dll being found on PATH, and if the hg one is found before the one in system32, COM objects will use the incomplete hg python modules and likely fail"
<disturbedsaint> k
<disturbedsaint> will do, thx!
<disturbedsaint> yeay! I've go overlayed icons now!
 * disturbedsaint = happy :)
<Peng_> Ehh..
<markh> woohoo :)
<disturbedsaint> markh I've submitted a "bug" btw with the icon for the systray
<markh> yeah, I saw that, thanks.
<disturbedsaint> it's not included and seems to be hardcoded to "C:\Python25\Lib\site-packages\bzr.ico"
<markh> its "hard-coded" to the parent of bzrlib
<disturbedsaint> couldn't find where it was set in the sources
<markh> if bzrlib is run from a source build it works
<disturbedsaint> ah ok, thats why I couldn't find it
<markh> somewhere like fixup_icon in tbzrlib\*.py
<markh> its possible to use bzr from a source tree - just set PYTHONPATH to point at that too.  Then the icon will work.
<markh> Note that all "help" links will also fail in source builds as we can't locate the built bzr docs.
<disturbedsaint> I see, will do that
<disturbedsaint> k
<markh> (but at least it says "sorry - can't locate the docs in a source build" :)
<disturbedsaint> also noticed the 3 links from the traymenu don't do anything
<disturbedsaint> help/settings/about
<markh> they should.  check .bzr.log
<markh> you have the qbzr plugin installed?
<markh> note that for debugging, it might be useful to exit the taskbar process, then manually execute 'python tbzrcache.py -v' - that will re-run the taskbar program, but show output on the console as well as logging it.
<disturbedsaint> thats easier indeed
<disturbedsaint> and I dont have qbzr atm because of the clean install :/
<beuno> lifeless, it is
<beuno> I sent you the traceback a few days ago
<markh> you won't get too far without it.
<beuno> probably wan't a good idea not to report it
<beuno> Peng_, pong!
<disturbedsaint> ok :) will fix that tomorrow, time to go to bed, quiet late already
<disturbedsaint> Thanks a lot for your help!
<markh> cheers!  good night!
<disturbedsaint> thx
<disturbedsaint> have a nice day!
<disturbedsaint> bye!
<markh> you too
<Peng_> beuno: Hahaha, hi.
<Peng_> beuno: Um..a few days after the abstract_paths stuff, Googlebot started causing lots of errors like 'NoSuchId: The file id "<whatever>" is not present in the tree None.'I guess it was finding links to files in revisions where they didn't exist? Do you think that could have happened?
<beuno> Peng_, well, my guess would be that it was still lookinf for file IDs
<beuno> although, those URLs should probably be valid...
<Peng_> Hmm
<Peng_> You're right. At least one example was with a file ID.
<beuno> Peng_, I will do some tests and see if I broke fileids
<beuno> I shouldn't of
<Peng_> Euhh.
<Peng_> One of the requests that bombed was for /annotate/811/some/path?file_id=totally_different_file_id
<fullermd> It's reaching into the future and handling the result from 'bzr cp'.
<Peng_> fullermd: It's not handling it very well. :P
<Peng_> How do you check the file ID of a path?
<fullermd> No, _it's_ handling it fine.  It's not Google's fault your version of bzr is too old   :p
<lifeless> beuno: I filed a bug with the fix
<lifeless> beuno: you broke it :)
<Peng_> lifeless: Who broke what?
<Peng_> Are we talking about me?
<Peng_> (I mean, my issue)
<fullermd> Colonel Mustard, in the library, with the wrench.
<lifeless> beuno: loggerhead's search facility
<Peng_> Oh.
<beuno> lifeless, I did?  aw...
<beuno> I'll merge it in tomorrow
<beuno> thanks
<lifeless> beuno: [(foo)] != [(foo,)]
<beuno> now, I need some sleep to manage the halloween alcohol  :)
 * beuno waves
<lifeless> be
<lifeless> bye
<Peng_> G'night.
<gour> what 1.9 format brings?
<gour> will 1.9 remove some of the old formats?
<luks> bzr doesn't remove all formats
<luks> old
<AfC> Well, as long as we can get rid of the gawdawful mess that is present in the help of `init` and `init-repo`, what is silently supported doesn't matter. But right now that is the very first impression one has of bzr, and it howls.
<Odd_Bloke> I think the first impression one has of bzr is whatever the tutorial you're following tells you.
<gour> still, looking at plethora of formats is not encouraging...
<Odd_Bloke> No, that's true.
<gour> some months ago, shortly after moving to bzr, i asked the same question and all what changed is some new formats :-)
<jelmer> gour, I really think we should move to using a rich root format as default..
<jelmer> gour, that eliminates half of the formats for the future
<gour> jelmer: i agree. the present situation is messy...too many formats
<gour> the 'old' formats should become 'hidden'
 * gour is doing sys-upgrade which brings python-2.6
<AnMaster> hm?
<AnMaster> pack-0.92?
<AnMaster> yeah why haven't the default format changed from that yet (in 1.8 which is what I have)
<gour> and we got new '1.6' formats
<rocky> how is python2.6 support with bzr 1.9 ?
<LarstiQ> rocky: afaik all known 2.6 issues were released in 1.8
<rocky> oh cool
<LarstiQ> ehm, fixes for those issues
<LarstiQ> rocky: so I expect 1.9 to be all dandy
<rocky> jelmer: which version of bzr-svn for bzr 1.9 ? :)
<ronny> hmm, how much better is bzr v1.9?
<fullermd> .1 obviously.
<lifeless> Peng_: how are you liking btrees?
<LarstiQ> ronny: any area in specific?
<LarstiQ> ronny: it has things I care about, but you might not.
<ronny> LarstiQ: speed, repo size?
<ronny> hmm
<ronny> sometimes i wish bzr had a monotone-style branching ui with updates to specific revisions
<LarstiQ> ronny: btree indices in format 1.9, pack optimizing for size more (possibly 25%), less memory usage for checkout, annotate fast path
<LarstiQ> ronny: I'm unfamiliar with monotone I'm afraid, other than using it as part of the OpenMoko build
<ronny> LarstiQ: branches can have multiple heads, and one can easyly move the dirstate to previous revisions within that branch
<LarstiQ> ronny: just the dirstate, or does that also work well for daggy fixes?
<ronny> of course well for dagy fixes
<LarstiQ> ok, so what's the ui like?
<ronny> mtn up -r the_rev_i_want; edit; commit;merge
<ronny> btw, it works the same in hg
<LarstiQ> how far would you be along to that if you had up -r?
<fullermd> mtn's allowing multiple heads on a branch is what makes daggy fixing work so well there.
<fullermd> Without that, it's a whole lot more work.
<LarstiQ> (ie, hg, in the case of two heads, automatically merges them with an unqualified merge iirc)
<fullermd> (now, you don't _actually_ need to support multi-headed branches to do it per se, but you have to hack up something near indistinguishable)
<ronny> LarstiQ: hu? hg doesnt auto-merge multiple heads
<LarstiQ> ronny: I mean, you don't have to specify what you want to merge, if you say you want to merge, and have two heads
<LarstiQ> ronny: is that wrong?
<ronny> LarstiQ: ah, ok thats right
<LarstiQ> that latter part might be a bit troublesome
<LarstiQ> oh, but no
<LarstiQ> it could work nicely if you had a :other-head style thing
<fullermd> Well, it works in mtn since that's all that 'merge' does.
<LarstiQ> fullermd: right, bzr already has a meaning for just 'bzr merge'
<luks> hm, committing to an "outdated" tree and updating only the tree parent id (not the branch) seems like an interesting idea
<fullermd> Well, I haven't put much thought into the best way to represent it in bzr.  I mean, we can't even update -r yet...
<luks> it would be basically like a local commit in a bound branch
<LarstiQ> jam: hmm, your file_log plugin breaks selftest in an interesting way
<LarstiQ> jam: not that that is relevant anymore, but it tries to load 'bzrlib.plugins.file_log.', which then gets to 'module = getattr(module, '')', and suprisingly module doesn't have a '' attribute.
<rod__> hi, i'm trying to do 'bzr ls --kind=directory --non-recursive mybranch/some/folder' to list the contents of a directory in a branch, but it doesn't return any results.  i know this seems like a very basic question, but i can't find much help by searching for it.  thanks
#bzr 2008-11-02
<Peng_> lifeless: I'm not sure. I only converted two repos to btrees, and I didn't keep non-btree versions around, so I can't compare. I think diffing in the larger one is much faster though.
<Peng_> (Well, I did keep non-btree versions around, but in a backup way, not a usable way.)
<ub3rst4r> hi, yesterday i doing a commit to my launchpad account. i accidentally used the del to remove some files that i didnt want to commit. I restored them, but they are the wrong files and i cant find the another file that I had.
<ub3rst4r> anyone?
<grettke> Hi folks.
<ub3rst4r> wtf is everyone
<grettke> I created a new repo using the 'svn-import' command. I want to push each of my "trunk projects" from that repo I just created into my normal repo. But it is complaining that the repository format is not correct (different rich-root-pack). That is true, my main repo is not rich-root-pack, I don't need it to be. Is there a workaround here?
<jelmer> grettke, yes, you can upgrade your normal repository to rich root pack
<jelmer> grettke, bzr upgrade --rich-root-pack
<ub3rst4r> hi, yesterday i doing a commit to my launchpad account. i accidentally used the del to remove some files that i didnt want to commit. I restored them, but they are the wrong files and i cant find the another file that I had.
<grettke> jelmer: I see, so I should have created it initially, at least. Understood. Thanks jelmer.
<grettke> jelmer: Wonderful that an upgrade path exists!
<jelmer> ub3rst4r, you mean "bzr rm" ?
<ub3rst4r> yes
<jelmer> ub3rst4r, did you commit the removal?
<ub3rst4r> jelmer no, i should of! now i cant find the files anywhere
<jelmer> ub3rst4r, but the files were versioned before?
<jelmer> ub3rst4r, you can get an older version of a file by running "bzr cat -r<old-rev> <filename>"
<ub3rst4r> ill try that
<ub3rst4r> bzr: ERROR: u'HiveManager.cs' is not present in revision
<jelmer> ub3rst4r, the file was not versioned at that revision?
<grettke> jelmer: Potentially dumb question. I created my mainline repo using 'init-repo', and then each project with just 'init'. Do I upgrade the whole repo, or the individual branches. The thing is that I know you can create the whole repo with rich-root-pack...
<ub3rst4r> well i added it, but then i removed it
<jelmer> grettke, you have to upgrade the repository
<ub3rst4r> and then they were moved to the recycle bin and i restored all but 1 file which i cant find
<grettke> jelmer: I see. Thanks.
<ub3rst4r> and the files that i did restore are older
<jelmer> ub3rst4r, and you specified an old-rev in which the file did exist?
<ub3rst4r> yea
<ub3rst4r> i dunno what to do
<grettke> jelmer: Are you guys getting many SVN->BZR switchers?
<jelmer> grettke, yeah, quite a few
<jelmer> ub3rst4r, sorry, it's probably better to email the list
<grettke> jelmer: What had you used before BZR? What were you favorites?
<jelmer> grettke, I've used cvs, svn and darcs before bzr
<ub3rst4r> jelmer what do u mean, email the list?
<jelmer> ub3rst4r, please email the bazaar mailing list, as there don't appear to be a ot of people around at the moment
<grettke> jelmer: What did you like *most* about SVN?
<jelmer> grettke, ease of use I guess
<grettke> jelmer: What is the standard procedure for "moving" a project. I want to move it from /repo/proj to /proj, move is not the right command. Should I create the new proj, just branch and push to the new project, then delete the old one?
<jelmer> grettke, not sure I understand - moving a branch in bzr should be as simple as doing a filesystem move
<grettke> grettke: I see. I am stuck in svn land.
<AfC> jelmer: (well, no, not exactly; if there's a shared repo at .. or somewhere, then just moving the "branch" directory is insufficient. Using `bzr branch` will always work)
<grettke> jelmer: Sames goes for renaming it?
<AfC> grettke: yes, renaming is transparent.
<grettke> AfC: It is a shared repository
<AfC> grettke: then if you are moving the branch _outside_ of that shared repository, then you'll need to use branch.
<AfC> grettke: if you're just moving it around within (below) that shared repository, then it'll have no impact.
<AfC> grettke: there are three things in Bazaar that you need to be aware of (if doing such shenanigans).
<AfC> 1) "Working Tree" (ie, a checkout of the sources)
<AfC> 2) a "Branch" (usually co-located with the Working Tree; it lives in .bzr/branch/)
<AfC> and
<AfC> 3) a "Repository" (which can be anywhere from . on up; it lives in .bzr/repository/)
<AfC> If the Repository is co-located with the Branch (is co-located with the Working Tree) then you have the situation that is commonly created when you just do a standalone `bzr init .` or `bzr branch`
<grettke> AfC: Thanks. That notion is slowing sinking in.
<AfC> in THAT common scenario, then yes, you can happily move the branch (carrying the  working tree and repository with it) to your hearts content.
<AfC> but if you've used the equally common shared repository idea,
<AfC> [which is a good idea]
<grettke> AfC: My mainline repo is --no-trees. All of my working trees are elsewhere.
<AfC> then you have the catch that the directory containing the Working Tree and Branch does not contain the Repository (which stores the revision data) and so if you go and move that directory somewhere else
<AfC> it'll be at a loss to find its revisions.
<AfC> Hence, for that case, use `bzr branch`.
<grettke> AfC: I see. The repository is different than the .bzr directory. If I had not used the --not-trees, then every branch would have its on repository?
<grettke> AfC, jelmer: So why choose a common shared repository over a repo in every branch?
<AfC> No. If you had not used no-trees then every Branch in the Repository would have a full Working Tree present as well.
<AfC> Branches outside from under that shared Repository will [have to] have their own repositories (copies of all the  revisions making up that branch) along for the ride.
<grettke> AfC: More is sinking in...
<grettke> AfC: So for my mainline repo, if I init it with --no-trees, that just means when I create branches that working copies won't also get created, and that there is a single repository shared by all branches, and when I back up that repo, I can just file-copy that directory and I will be finished. What is the benefit of a shared repo, space saving?
<AfC|out> There's no "mainline repo". There is a "mainline branch".
<AfC|out> That lives somewhere.
<grettke> AfC: Right... thanks.
<AfC|out> It's either got all it's own revisions, or they're at ../ or ../../ or ... somewhere
<grettke> I will have mainline branches that have a shared repo, that is it.
<AfC|out> No. There is a single mainline branch. Singular. Other branches (forks of it, hopefully someday to be merged back into it) living along side it can avoid duplicating all the revision data if you share it at ..
<grettke> AfC: I read the user guide, but clearly I'm not getting. What else should I read?
<AfC|out> {shrug} In one project I'm involved in we have a brief getting started note, http://java-gnome.sourceforge.net/4.0/HACKING.html but I think what you need to do is stop worrying so much about setup and just get on with using it. The other stuff will become clear in due course.
<grettke> AfC: That is what I've been doing. I've got my svn stuff I want to move over, too.
 * AfC|out goes out
<lampliter> how do you tell if the main image (what I have on launch pad) is different from the branch I have locally?
<Rolly> lampliter: bzr missing?
<Peng_> jelmer: ping?
<jelmer> Peng_, hi
<Peng_> jelmer: Hello.
<Peng_> Err
<Peng_> jelmer: I have an odd bzr-svn issue
<Peng_> (I was able to work around it, but anyway..)
<Peng_> I haev a shared repo where I have copies of Python's various branches, both imported myself using bzr-svn, and using the imports on http://code.python.org/
<Peng_> Today, I was trying to branch http://code.python.org/python/2.6/ , but it failed with a RevisionNotPresent.
<Peng_> I already had a copy of http://svn.python.org/projects/python/branches/release26-maint (the svn version of that branch) in the same repo. After pulling the latest changes, I was able to branch the code.python.org branch successfully.
<Peng_> RevisionNotPresent: Revision {svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Fbranches%2Frelease26-maint:66865} not present in "2166@6015fed2-1504-0410-9fe1-9d1591cc4771:p
<Peng_> ython%2Ftrunk:Lib".
<Peng_> Erk
<Peng_> So yeah. :D
<LarstiQ> luks: I've got a very very ugly hack to do search for qannotate on file texts. It currently just pops up a QLineEdit without a parent to prompt for the search text ;)
<jelmer> Peng_, One of the two was probably made with a buggy (older) version of bzr-svn
<Peng_> jelmer: How did doing the other pull fix it?
<eudoxos1> Hi there, I've been googling around for shallow branches and I am wondering what is the progress on that front (blueprints, wiki, blogs, all silent on that). Stacked branches are related to that, right? Is that on schedule for whatever comes after 1.9?
<faheem_> Hi. Is bzr-gtk the recommended tool for viewing a repos dag? I've had some difficulties with it, debian lenny.
<faheem_> !bzr-gtk
<ubottu> Sorry, I don't know anything about bzr-gtk
<faheem_> Using olive-gtk, that is.
<faheem_> Should I be using the versions in experimental?
<faheem_> To be more specific, if I do olive-gtk, and click on log, I get "Please wait, loading ancestry graph.." which then hangs.
<faheem_> This is with the Debian apt repos.
<faheem_> I also get a traceback.
<jelmer> faheem_, please file a bug
 * awilkins prefers qbzr for viewing a repos dag
<awilkins> But I still prefer gconflicts because qbzr doesn't have one ;-)
<jelmer> awilkins, qbzr as in qlog ?
<awilkins> jelmer: Yes
<faheem_> jelmer: File a bug where, with Debian or upstream?
<jelmer> faheem_, debian
<faheem_> awilkins: Is qbzr in Debian?
<faheem_> jelmer: Ok, will do.
<jelmer> faheem_, no, qbzr isn't packaged for debian
<faheem_> What is the bzr equivalent of hg paths?
<faheem_> jelmer: Severity normal Ok?
<Neil> I have baz Bazaar version 1.4.2 and Bazaar (bzr) 1.8.  How do I import my change history from one to the other?  The BAzaar webpage points to bzrtools, but bzrtools 1.8 seems to have no such command.
<jelmer> Neil, it's split out into a separate plugins these days
<jelmer> faheem_: Yeah, sounds fine
<jelmer> faheem_, what does "hg paths" do?
<Neil> jelmer: Do you know where I can get that then? Thank you
<faheem_> jelmer: the repositories which hg knows about - specifically, the repos it was cloned from.
<faheem_> bzr info looks like it gives me what I want.
<jelmer> faheem_, I think "bzr info" comes closest
<jelmer> Neil, http://code.aaronbentley.com/bzr/bzrrepo/bazimport/ seems like it contains a version of that plugin
<Neil> thank you
<jelmer> but I'm not sure whether or not that is the latest
<Neil> well I'll try it, heh
<faheem_> jelmer: Done. Are you a developer?
<jelmer> faheem_, yep
<faheem_> Shall I post the bug number here when I get it?
<jelmer> faheem_: no - thanks, but I should already be automatically notified by email
<faheem_> jelmer: Ok. Take care. Thanks.
<Neil> dang.  Unable to load plugin 'bazimport' from '/usr/local/bzr-1.8/lib/python2.5/site-packages/bzrlib/plugins'
<LarstiQ> it used to be in bzrtools
<Neil> I wish it still was in there since bzrtools is working :-)
<LarstiQ> Neil: could you pastebin the traceback (from ~/.bzr.log)
<Neil> how do I get a traceback for it?
<LarstiQ> Neil: it should be in ~/.bzr.log
<Neil> ah thank you, looking
<Neil> http://www.hakubi.us/temp/bzr-log
<LarstiQ> Neil: or, what also would have worked, is -Derror
<LarstiQ> Neil: ah, it expects a recent bzr
<LarstiQ> Neil: introduced in revision 658 in bazimport
<Neil> hmm
<LarstiQ> Neil: so, you could use a slightly older version of bazimport, or a newer version of bzr.
<Neil> thank you very much
<LarstiQ> Neil: try bzr revert -r 657 for the former
<Neil> guess I get to start learning bzr manipulations right away :-)
<LarstiQ> (in bazimport)
<Neil> hooray, it shows up without error in bzr help commands
<Neil> now the real test though :-)
<LarstiQ> right, that bzr can import the plugin doesn't guarantee the plugin can do the conversion between two version control systems :)
<LarstiQ> but if it can't, that is certainly a bug, and not api drift
<Neil> I've been using arch actually for 6 years, but I'm co founding a new company and need to share the tree with someone on Windows.  So I have to pull out some of my work, and Bazaar looked like the best best.
<Neil> I'll probably end up moving over my personal stuff as well
<LarstiQ> Neil: cool
 * LarstiQ calls it a night
 * Odd_Bloke calls it a fish.
#bzr 2009-10-26
<dash> jelmer: http://yellow5.com/pokey/archive/pokey80_3.gif
<lifeless> james_w`: around?
<TDJACR> Bazaar just took up 765 MB of ram
<spiv> TDJACR: you're adding some large files to bzr?
<james_w> lifeless: briefly
<lifeless> nvm, filed a bug
<TDJACR> spiv: No, I branched launchpad
<spiv> TDJACR: oh, right.  That's a very large branch, we've been working on improving the memory use in bzr's trunk
<spiv> TDJACR: bzr's trunk plus a couple of patches that will land shortly uses roughly 2/3rds of the memory of 2.0.1 I believe, and that should keep improving as we work towards 2.1
<spiv> TDJACR: (there's ~65000 revisions in Launchpad's history last time I checked, and about 7000 files!)
<spiv> TDJACR: so, basically, known problem, but we're working on it
<lifeless> vila: buildbot trunk has my subunit patch
<igc> back
<spiv> lifeless: so, how far away is a proper fix for the --subunit issue that's preventing PQM from rejecting test failures?
<spiv> lifeless: I'm wondering if we should temporarily remove the --subunit option until we figure out a better fix.
<lifeless> spiv: I'm hoping to start on the cleanup this avo
<lifeless> just want to get one of the dx ppa builds up first
<lifeless> still solving teething problems
<spiv> lifeless: cool, "this arvo" is a good enough answer for me.
<spiv> lifeless: mind if I assign the bzr bug to you?
 * spiv updates the bug description
<lifeless> spiv: uhm
<lifeless> spiv: I don't particularly care, but its a different bug I think
<lifeless> spiv: and its not my top priority, I'm just trying to squeeze it it
<lifeless> *in*
<spiv> Hmm.
<lifeless> right now I don't recall how messy the badly mapped things are
<lifeless> basically need to un-messy them and get detection out of the TestResult and back to the TestCase
<lifeless> it might be an hour, it might be a day
<spiv> and then we'll need the subunit in the pqm updated?
<lifeless> possibly. I won't try to depend on the latest, but I may have to.
<lifeless> have a look at the code ;)
<spiv> Ok.  I think I will temporarily disable the --subunit option then.  The niftiness isn't quite worth the discomfort, and it'll be easy to turn back on when it's sorted.
<spiv> Thanks.
 * spiv has a late lunch
<lifeless> spiv: subunit doesn't need improving
<lifeless> spiv: I've tried to correct this meme in the bug, but its not seeming to stick, so I'm coming direct :)
<spiv> lifeless: please feel free to edit the description and summary directly :P
<spiv> lifeless: I wrote the most recent comment before seeing yours about it not being subunit that needs improving, though.
<lifeless> spiv: kk
<lifeless> spiv: I'm not stressed, I just want to fix the meme :)
<_Andrew> hi
<_Andrew> I'm getting the error "These branches have diverged. Use the missing command to see how."
<_Andrew> What's the "missing" command and if it's missing how do I use it?
<spiv> "bzr missing"
<_Andrew> ah, I was doing it wrong.. --missing
<spiv> And you'll probably want to use "bzr merge" rather than "bzr pull" to combine the different changes made on the two branches.
<_Andrew> ah ok
<_Andrew> Yes that's working
<_Andrew> Since I'm already here could you tell me what "M*" means? It's that a conflicted merge?
<spiv> See "bzr help status-flags"
<spiv> M means the contents of the file have changed (been modified), * means the execute bit changed.
<_Andrew> ok thanks for the help! :)
<_Andrew> Actually I have another question, sorry. Say I have branch A with a file and I want to merge changes from branch B, but I don't want branch A to merge changes from a specific file, how do I do that?
<spiv> _Andrew: You can do "bzr merge path/to/branch-A/some/file"
<spiv> (IIRC)
<spiv> _Andrew: note that cherrypicking a change like that won't be tracked by bzr though, i.e. bzr won't remember that you've done that merge (unlike most merges), so it might cause conflicts next time you merge from that branch.
<_Andrew> Can't you just lock the file or something?
<_Andrew> It's an image and I don't want the images to change
<spiv> _Andrew: oh, you want to ignore changes to a specific file
<spiv> _Andrew: you can do "bzr revert that_file" after the merge
<spiv> (sorry, I misread your question)
<spiv> _Andrew: in general there's no way to say "only these parts of this branch should change".  You can split a project into multiple branches, though, which may help.
<KhaZ_> Question: for shared repositories to work, do you need to have them be subdirectories in the shared parents root?  Or could I have them (on Windows for instance) as far apart as on different drives?
<spiv> KhaZ_: you need the branches to be inside the shared repository directory, but you can have the working tree(s) for those branches anywhere.
<KhaZ_> Fascinating.  I never thought about separating the branch from the working dir, but I suppose that's always been the case; I just assumed they were one in the same.
<spiv> [Branches inside a shared repository are tiny; the things that take up space are the history (which is inside the shared repo) and the working copy that you can edit (which does not have to be co-located with the branch)]
<spiv> If you do "bzr init-repo --no-trees" (or later "bzr reconfigure --with-no-trees"), then branches in that repo by default will have no working tree.  You can then do "bzr checkout /path/to/repo/branch" from any directory you like.
<spiv> Er,
<spiv> "bzr checkout --lightweight ..."
<spiv> The --lightweight is important, otherwise it will make a full copy of the history rather than use the branch's repo :)
<KhaZ_> Interesting.  So say I currently have two repos that (I believe) are 'standalone', but they really are just clones of each other that I do work in.  I can use reconfigure to change it to a shared repository scheme?
<spiv> Yes, I believe you can do "bzr reconfigure --use-shared", although I don't know the precise details.
<KhaZ_> Hrmm, I'll have to read into that.  Do shared repo's have any other benefit besides space saving?
<spiv> Just space-saving, really.
<spiv> (Although that can in turn lead to speed improvements)
<dash> well branching is quicker inside it because you don't have to copy as much
<dash> right yes
<spiv> e.g. the time to do "bzr branch" will be much much faster, as dash says :)
<KhaZ_> Right.  Hrmm, maybe I'll put it on the backburner then... Don't do much branching luckily. :)  Still, good to know.
<spiv> KhaZ_: If you have two branches inside a parent, and you cd to that parent and do "bzr init-repo ." then you should be able to cd to each branch and do "bzr reconfigure --use-shared".
<spiv> s/inside a parent/inside a parent directory/
<KhaZ_> But literally the parent - not just any common ancestor, yeah?
<KhaZ_> I currently have two paths that could be shared, but they're basically about four levels apart from each other (I'm versioning the contents of my work (Perforce) repo, but source code only, is why I ask).
<KhaZ_> (On a side note, shazbot is sourceforge's git cloning slow!)
<spiv> I'm not sure how fussy bzr reconfigure is.
<KhaZ_> Interesting.  I might try that then.
<spiv> I suppose you could always make the repo in the immediate parent and then after the reconfigures move the .bzr of the repo up a few levels.
<vila> hi all
<spiv> Hey vila
<spiv> vila: I've disabled --subunit in make check for now until lifeless figures out what needs to be done to make it do what we need
<spiv> vila: so hopefully babune will stay nice and green from now on
<vila> spiv: I've read that and lifeless replies and announce that it will work on it on the bzr side, thanks
<vila> spiv: well, babune has a bad flu since a couple of weeks with the leaking tests and then the terminal width saga took me a while to figure, so it's good to know *that* failure source is closed :-)
<lifeless> hi vila
<jelmer> what's this babune thing people are talking about?
<igc> jelmer: buildbot test server that vila runs
<jelmer> ah, thanks
<igc> hi vila
<vila> hi Ian !
<vila> jelmer: BAzaar BUild botNEt
<jelmer> :-)
<vila> jelmer: https://launchpad.net/bzr-buildbot-net and http://babune.ladeuil.net:26862/ for the full monty
 * igc dinner - night all
<jelmer> g'night Ian
<cpf_> Just a quick question, how do I install the bzr explorer (and run it?)
<cpf_> I executed the setup.py install, tried "bzr explorer", but the explorer plugin cannot be loaded...
<cpf_> Ok, reinstalling qbzr fixed the issue ^^
<vila> cpf_: what OS/versions are you using ?
<cpf_> vila: debian, python 2.5.4, bzr 2.0.1
<vila> cpf_: ok, so you're installing the plugins system-wide and not in your ~/.bazaar directory ?
<vila> cpf_: and when you said "but the explorer plugin cannot be loaded" did you get a proper message telling you about an unmet dependency on qbzr or just a "can't load plugin" kind of message ?
<cpf_> vila: Uh, 10:32 < cpf_> Ok, reinstalling qbzr fixed the issue ^^
<cpf_> I ended up installing in ~/.bazaar/plugins, but it's all the same now, it works like a charm XD
<cpf_> vila: Oh, and no message about an unmet dependency. Just: "Unable to load plugin 'explorer' from '/usr/lib/python2.5/site-packages/bzrlib/plugins'" (When it was installed globally)
<vila> cpf_: ha, that was my fear, hence my question
<vila> cpf_: can you file a bug against bzr-explorer on lp mentioning your versions so that a better error message can be issued
<vila> and by the way, what made you suspect qbzr ?
<cpf_> http://doc.bazaar-vcs.org/explorer/en/install-source.html << End of page
<cpf_> I had all the rest...
<cpf_> Thought I had qbzr already (used to have it at least)
<cpf_> Must've lost it somewhere xD
<vila> either bzr-explorer setup.py or __init__.py should report it more nicely IMHO :-/
<cpf_> I agree, but __init__.py looks scary :(
<gioele> Can  BZR_PLUGIN_PATH point directly to a directory that contains a single plugin or should it point to a directory that contains other directories with plugins (like ~/.bazaar/plugins)?
<hmeland> The latter.
<gioele> :(
<hmeland> Maybe you can trick it with some symlinks?
<lifeless> vila: what do you think of allowing a path to name a plugin
<gioele> I think I'll have to. I am developing a plugin. Right now the development is in a subdir of ~/.bazaar/plugins/. But I'd like to move it to another local repo (point 1) and use the pipelines plugin that creates a serires of directories/branch (point 2).
<lifeless> e.g/ foo:pluginname@directory
<vila> lifeless: I think it's an inferior solution if you want to test a specific version of a plugin *because* that plugin may depend on other plugins
<lifeless> vila: well yes, but its a recurring request
<vila> so I think it's better to create a dedicated directory for the tests where you put symlinks to whatever plugins you want
<vila> lifeless: true
<vila> may be we should add two command lines options: --plugins and --single-plugin ?
<vila> adding the command-line option is more or less missing right now (I use BZR_PLUGIN_PATH=-site all the time and far more typing than --plugins=-site
<lifeless> vila: I'd rather come up with a good syntax to specify in the path
<vila> lifeless: like a leading-but-otherwise-forbidden char ?
<gioele> Maybe the semantics of BZR_PLUGIN_PATH could be changed to mean: if the directory itself does not contain a module at the top level, then it act like it does not. Otherwise, if the BZR_PLUGIN_PATH contains a plugin in the top level, then load that without recursion
<lifeless> gioele: can't do that
<vila> gioele: 8-(
<lifeless> need a plugin name
<gioele> lifeless: why?
<gioele> (btw I cannot find a complete example on the use of BZR_PLUGIN_PATH in the documentation, just quick references)
<lifeless> gioele: because plugins get loaded into bzrlib.plugins.NAME
<vila> gioele: there is, wait
<lifeless> gioele: which makes them regular python packages/modules rather than 'different' things
<gioele> lifeless: can't you say "load the python module that lies in exactly that directory"?
<lifeless> gioele: load it as what
<lifeless> what would its name be?
<vila> gioele: http://doc.bazaar-vcs.org/bzr.2.1.0b1/en/user-reference/index.html?highlight=bzr_plugin_path#bzr-plugin-path
<gioele> lifeless: basename `dirname $path`
<bialix> hi all
<vila> lifeless: +plugin:<path> ?
<lifeless> gioele: that would be wrong far too often
<lifeless> vila: something; too tired to thing through consequences; my sketch was the one with @ before
<vila> hmm, using ':' is bad here :-/
<gioele> vila: oh, I was looking into the dev documentation. Thanks for the link
<vila> oh, that was a skecth, sorry, didn't realize
<vila> hmm, so you could override the dir name, right, that should be optional though, but I see the point
<vila> lifeless: @ is a good idea and since '+' is already mandatory, I think +[name]@directory will do fine, but the main problem I can see is that it's not a real PATH spec and will need special handling
<lifeless> vila: whats the + for?
<vila> +/- is used to add or remove from BPP (BZR_PLUGIN_PATH), see url abov
<lifeless> vila: + isn't needed then
<lifeless> vila: unless soeone wants to edit the path
<vila> by default you start with +user:+core:+site so if you say BPP=-site you ends up with +core
<vila> because +user is the default value for BPP
<vila> it's needed to identify magic values
<lifeless> I dispute that
<lifeless> its just code
<vila> oh, you mean when using @
<vila> lifeless: look at the tests:
<vila> ['myplugin'], ['myplugin', '-user', '-core', '-site']
<vila> ['myplugin', '+core', '+site', '+user']
<vila> the former is myplugin only, the later is myplugin first
<lifeless> vila: I don't understand your point
<vila> lifeless: what are you disputing (I may misunderstand that :-) ?
<lifeless> that + is needed to use @ as I propose it be used
<vila> yes, my latest remark, + is not needed for @
<lifeless> well, your latest remark was telling me tolook at the tests
<vila> because - makes no sense
<lifeless> so, you can understand my confusion
<vila> lifeless: sorry, I meant my remark after you said  'I dispute that'
<lifeless> so, I don't understand your point *after* that remark
<lifeless> why are you telling me to look at the tests
<lifeless> what do I have wrong
<vila> lifeless: forget it then, I thought you disagreed with 'you mean when using @'
<lifeless> vila: I didn't ssay *anything* after that, except to express confusion
<vila> lifeless: ok, let's reset at: '@ does not need +' ok ?
 * spiv expresses confusion with a confusing expression ;)
<lifeless> ok
<phcoder> hello, all. I develop in a project which uses svn as main repo. I previously worked with it through git-svn and now due to general dev move to bzr I move to it too. I imported my git stuff with bzr-git but now I find myself unable to merge anything coming from bzr-svn with anything coming from bzr-git. Any help?
<Bear10_> I'm having a bit of trouble figuring out how bazaar works, can someone help me out? I've created my repository, and comitted the initial files, now I don't know how working on a remote repository works. Sure I can connect fine, but in the xplorer when I connect it says its on revision one and that there are no working branches.
<jam> morning all
<bialix> hello jam
<bialix> Bear10_: read tutorial from this section and down http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html#publishing-your-branch-with-sftp
<Bear10_> thanks
<Bear10_> bialix, okay I understand this concept, but are all branches you create first local? then you upload the whole branch, and it then creates that branch on the server for others to work on it?
<jam> Peng_: the chk_map patch is on its way to pqm
<jam> vila: let me know if there is babune fallout
<bialix> Bear10_: you can create branch on server first
<phcoder> bialix: would you by chance know how to import git-svn to bzr and have same ids on files as bzr-svn'ed branches?
<bialix> it does not realy matter
 * jam needs to go wrestle bzr-rewrite into submission so I can officially announce 2.1.0b1 
<vila> morning jam !
<Bear10_> sorry im new to this heh read everything i could now its a matter of putting it into practice
<vila> jam: if you ping me as soon as it lands, I'll make a run just for you
<jam> Bear10_: you can do it either way
<vila> jam: or if I happen to see it lands before you ping me, I'll telll you
<bialix> phcoder: I can't say for sure. Try asking jelmer, jam, vila and lifeless
<jam> *I* tend to create branches locally, and then push them when I'm ready for it
<bialix> hi guys
<vila> hey abilx
<jam> phcoder: svn => git => bzr is going to be very difficult to get identical to svn => bzr
<Bear10_> jam, that seems most logical (to me)
<bialix> lol
<jam> I would recommend using "git dpush" back into svn, and then pulling from there
<bialix> vila: :-#
<jam> Bear10_: of course, I create *lots* of branches, and push fairly regularly
<vila> wow, how did I typoed that....
<phcoder> jam: you mean dcommit? It could work. I need to setup local svn for this
<Bear10_> jam, where is the "main" build / revision of the app stored? in a branch? the root?
<jam> phcoder: right
<jam> dcommit
<jam> Bear10_: I don't quite understand the question
<jam> what "app" ?
<Bear10_> jam, the project
<vila> sorry Alexander, I meant to type bialix, may be I should use the completion more :)
<bialix> vila: I was under impression it was intended
<bialix> vila: anyway you made me good lol
<vila> not at all, no idea how it occurred :-/
<Peng_> jam: Great. :)
<vila> ha good :)
<bialix> vila: everything is fine
<bialix> :-D
<jam> phcoder: note, though, that I think you need the *same* svn UUID, and some other such bits
<phcoder> Actually git preserves svn ids. Can I perhaps somehow hack bzr-git to use them to create IDs?
<Bear10_> okay i think i understand this now
<Peng_> I think a recent revision of bzr-git has some git-svn stuff.
<phcoder> the last line in log entries looks like "  git-svn-id: svn+ssh://svn.savannah.gnu.org/grub/trunk/grub2@2618 d0de0278-0dc1-4c01-8a07-af38b3205e46"
<phcoder> Peng_: oh. Looks like my sid is outdated. Going to find bzr dev repo
<bialix> jam: official announce will be good. it becomes bad habit to wrap tarball, build installers and then announce after a month
<bialix> jam: no pun intended
<jam> bialix: well, since the 2.1.0b1 installer still doesn't work
<jam> I haven't announced
<jam> I was hoping jelmer would release an updated bzr-rewrite
<jam> but he didn't seem to notice my queries
<Peng_> phcoder: Note that I didn't claim it will work or anything! :P
<jam> so I'm going to have to do it myself
<bialix> jam: I know. But they to gold almost 2 weeks ago
<bialix> *going to gold
<phcoder> Peng_: I guess I'll have to find out and hack if needed. Can someone provide me an insight on how file UUIDs are generated?
<phcoder> or a link to dev doc should be ok
<jam> phcoder: it depends on the source and converter
<jam> I believe bzr-svn's codebase is where you want to look
<jam> IIRC it was something like branch@revno+path
<Peng_> I think the syntax might be a little different, but that's basically it. It includes the repo UUID.
<Peng_> (I think?)
<phcoder> How can I look at File IDs in my repo?
<Peng_> phcoder: Various commands accept a "--show-ids" argument. "inventory" might.
<jam> vila: what is the status of: https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/13832
<jam> Did you decide to abandon it?
<vila> huh ? Certainly not, but you said you wanted it to be discussed, so I'm waiting :-)
<vila> Well, may be I should have summarize some more ideas I had since, but I thought there was already some meat (and code !) to start the discussion
<vila> like, we may want to move some parts of that into bzrlib.ui....
<vila> ...fater our discussion friday, I wasn't sure about the outcomes, having thought a bit more about COLUMNS, it seems that if we see it in os.environ, it means the user set it, so I stand by my design to obey it if present (unless proved wrong, but all my tests on various OSes so far...)
<vila> s/fater/after/ damn fingers
 * vila removes his boxing gloves
<phcoder> bzr is downloading at 2 KB/s on otherwise decent connection. What may be the cause?
<vila> jam: what were you referring to in 'Peng_: the chk_map patch is on its way to pqm' ?
<jam> vila: https://code.edge.launchpad.net/~jameinel/bzr/2.1-static-tuple-chk-map/+merge/13740
<jam> using StaticTuple in the CHKMap code.
<vila> pqm queue is empty...
<bialix> phcoder: bzr ls --show-ids
<phcoder> bialix: already found it, thanks. When I'll download bzr at this 2KB/s I'll get hacking on it.
<phcoder> I'll probably go with lightweight checkout
<bialix> you can get tarball then
<vila> jam: so you didn't submit it to pqm yet ?
<jam> vila: it is submitted, and going through testing now
<jam> unless it got rejected...
<jam> hmm.... I sent it, I'll try again, I guess
<vila> may be some delay between you and pqm...
<jam> No, I'm just full of it
<jam> I realized I wanted to update NEWS before submitting
<jam> and then forgot to push and then submit
<vila> happens :-/
<phcoder> Tarball downloading is at 400KB/s. Checkout is at 2KB/s. Why is this? Unfortunately I have the same problem on grub2 bzr too
<jam> phcoder: what version of bzr?
<jam> vila, Peng: now it is *really* there
<phcoder> phcoder@debian:~/repos$ bzr version
<phcoder> Bazaar (bzr) 2.0.1
<vila> jam: ok
<vila> jam: I haven't read the patch in detail, so just a quick check: it doesn't makes the C extension mandatory right ? (Welll babune *will* tell, but you're faster :-)
<jam> vila: it isn't supposed to. It *is* supposed to make using one of the StaticTuple implementations mandatory
<vila> errrr, I thought spiv said he desactivated --subunit on qpm but I'm still seeing the progress report...
<vila> ohhh, I missed more than I thought then, you made python and C impls. for StaticTuple ?
<vila> I thought you keep using tuple for python...
<phcoder> link here http://bazaar-vcs.org/BzrPlugins to bzr-svn is broken can somone provide me the good one?
<jam> vila: he did, and it is a different progress indicator
<jam> hence why it says "0%"
<jam> vila: _static_tuple_py.py inherits from 'tuple'
<jam> rather than wrapping it
<jam> so that you don't get 2x memory *bloat* when not running the extensions
<vila> ok
<jam> phcoder: 'bzr branch lp:bzr-svn' ?
<Peng_> jam: BTW, when using _static_tuple_py, does intern() intern forever?
<vila> jam: by the way, one of the expected outcome from reducing memory consumption was also to reduce time spent handling it, did you see some significant performance improvement  there ?
<jam> Peng_: yes, I can't mutate the refcount of native python objects
<phcoder> jam: worked. Thanks
<jam> vila: 'time bzr branch launchpad' went from 10-11m => 8.5m
<vila> jam: nice !
<jam> vila: I think it is mostly from removing GC objects
<jam> which I *think* has a quadratic effect
<jam> everytime you allocate N gc objects, it does a gc sweep
<jam> and then you have +N objects
<Peng_> jam: ...That's kind of bad.
<vila> often more than linear yes
<jam> so after doing 100k objects, you have triggered 100k / 700 sweeps, and each one at 700 objs, 1400objs, ... etc
<jam> anyway, I expect small to no improvement for "bzr branch bzr" but a modest improvement for 'bzr branch lp'
<jam> and probably an even bigger on for "bzr branch mysql"... probably quite significant for "bzr branch OOo"
<visik7> is there a way to tell the webdav plugin to remember user and pass ?
<vila> visik7: yes, use authentication.conf
<visik7> vila but I need to specify the user/pass in that file ?
<visik7> what's the difference of specifying if in branch.conf as http+webdav://username:password@domain/path ?
<vila> visik7: well, either that or you type them
<visik7> I would a way to autosave from the command line when I first branch/checkout
<vila> autosave is a can of worms nobody want to open now
<vila> visik7: but patches welcome !
<vila> specifying them in branch.conf is more risky and branch specific whereas authentication.conf will allow you to specify them *once* for each host
<vila> or even a whole domain depending on your usage, see the doc
<visik7> ok
<vila> visik7: http://doc.bazaar-vcs.org/development/en/user-reference/index.html#authentication-definitions
<nyu> $ bzr upgrade --format=rich-root-pack
<nyu> bzr: ERROR: Cannot convert from format Branch format 7 to format <class 'bzrlib.branch.BzrBranchFormat6'>.    No converter
<nyu> am I out of luck?
<nyu> with bzr 2.0.1
<jam> nyu: that is a downgrade, is there a reason you want to do so?
<nyu> jam: I want to remain compatible with bzr 1.5
<jam> nyu: I guess that isn't something we specifically worked on. let me check the code a bit
<jam> yeah, i think Branch7 was introduced in bzr 1.6...
 * nyu screams vendor lock-in ;-)
<jam> is there a reason 1.5?
<nyu> well
<nyu> I use 1.5 myself, as it comes in debian lenny
<nyu> and I wouldn't want to make it harder for all lenny users to access the repo
<d1b> nyu: just make it available via svn / git  as well..?
<nyu> actually it comes from svn, but we only have trunk there
<nyu> uhm.  I guess most users can live with just trunk
<d1b> nyu: do users use svn / bzr?
<nyu> well, I was thinking more s/users/casual contributors/
<nyu> the kind of people who send a patch once and are never seen again
<jam> nyu: well, it is trivial to do the downgrade
<jam> we just didn't implement it
<jam> I think it will be about a 10-line plugin
<jam> give me a sec
<nyu> oh
<nyu> phcoder: sounds like an easier approach
<phcoder> nyu: what an effect when a GNU maintainer asks ;)
<nyu> hey, I wasn't asking
<nyu> just suggesting :-)
<nyu> want me to give up with 1.5 completely?
<d1b> nyu: what project is this btw ?
<nyu> d1b: GRUB
<d1b> oh.
<d1b> grub uses bzr?
<nyu> to some extent yes :-)
<d1b> i only see svn on the site tho.
<nyu> maybe we end up switching completely
<nyu> oh, haven't had time to update it
<nyu> besides, the website is still in *CVS*
<d1b> nyu: plz do provide another version control system to download stuff via tho :) -> im also on lenny and don't want to update foo just to get the dev current stuff
<d1b> etc.
<jam> nyu: well, I looked at implementing a converter, but it looks like the upgrade code doesn't want to do it cleanly. So I'll give you the real secret way
<jam> echo "Bazaar Branch Format 6 (bzr 0.15)" > .bzr/branch/format
<jam> nyu: as long as you aren't using stacking, format 6 is identical to format 7
<nyu> jam: lol
<nyu> ok :-)
<jam> the format bump was mostly a 'compatibility' flag.
<jam> We didn't want older bzr's to think they could write to a stacked branch
<jam> and then bork the content
<nyu> if I don't know what stacking is, does that mean I'm not using it?
<jam> 'bzr branch --stacked'
<jam> I doubt you are using it
<jam> possibly on Launchpad, but that doesn't sound like where you are doing this stuff
<nyu> $ bzr branch sid/mips
<nyu> bzr: ERROR: Unknown working tree format: 'Bazaar Working Tree Format 6 (bzr 1.14)\n'
<nyu> uhm
<jam> nyu: 'bzr2.0 remove-tree' 'bzr1.5 co .'
<jam> actually, I think "bzr remove-tree; bzr co" would do just fine with 2.0
<nyu> still same error
<nyu> note this branch is an import from git
<jam> nyu: well, if you just do "bzr remove-tree" then it shouldn't be possible. Though I'm wondering if there is another WT somewhere that is confusing it.
<nyu> WT?
<nyu> well, this branch is inside a rich-pack
<nyu> and I'm branching to outside of it
<nyu> same problem when branching to inside the rich-pack
<bialix> WT == working tree
<vila> jam: babune run started
<jam> vila: thx
<phcoder> which API function is used to add a file to a repo?
<Tak> I'm using WorkingTree.smart_add
<Milo-> hello, is there a documentation somewhere how to handle binary conflicts?
<Milo-> mv file.ext.OTHER file.ext causes 'unknown file.ext' message to status, so that sounds like a bad idea.
<GaryvdM> Milo-: That's odd - Are you sure you did not have a typo.
<Milo-> it gives two messages to status
<Milo-> "removed file.ext" and "unknown file.ext"
<Milo-> and when you finally hit bzr resolve, it says all is fine, but when you commit is says "missing file.ext.OTHER"
<GaryvdM> Milo-: If not confidential, please pastebin the actual output
<Milo-> I'm thinking I should move file over another like that.
<Milo-> I shouldn't*
<Milo-> can't, team mate handled that conflict
<Milo-> with my instructions.
<Milo-> and he used windows's bazaar integration..
<GaryvdM> Milo-: "missing file.ext.OTHER" - that sounds like "file.ext.OTHER" was committed.
<Milo-> GaryvdM indeed :/
<mzz> that sounds like something/someone did a "bzr add file.ext.OTHER", and then "bzr resolve" removed that .OTHER file
<mzz> hmm, I can't reproduce anything but a cosmetic problem if I do that though.
<mzz> specifically I get a "missing a.OTHER" when I commit, but the commit succeeds and a.OTHER doesn't seem to get committed anywhere.
<mzz> that doesn't seem to be a merge/resolve-specific thing, actually.
<mzz> if I touch, bzr add, and rm a new file I get that same "missing b" on commit (and it's not mentioned at all in status)
<jfroy|work> Does bazaar support relative dates for logging?
<jfroy|work> For example, "
<jfroy|work> *For example, "give me the logs for the past week"
<Milo-> I did the binary conflict now with openoffice
<jfroy|work> (for some definition of week)
<Milo-> made file.odt, changed it in two locations
<Milo-> commited the other one
<Milo-> updated on the other checkout and got conflict, now I only have "file.odt.OTHER, file.odt.THIS, file.odt.BASE"
<mzz> jfroy|work: skimming "bzr help revisionspec" says it can do yesterday, today, and tomorrow, but I see no other relative things there
<Milo-> file.odt has been renamed to file.odt.OTHER
<Milo-> thought THIS had my changes and OTHER the other person's changes.
<mzz> Milo-: checkouts are special like that, iirc
<jfroy|work> I guess you could use -r date:{last's week date}..
<Milo-> so how do you resolve the conflict?
<Milo-> should I manually merge the stuff to the .OTHER and then just hit resolve?
<Milo-> or what?
<mzz> Milo-: I'm pretty sure you should just put the right content in file.odt and then "bzr resolve"
<IslandUsurper> Milo-, if file.ext is the way you want it, you can probably bzr rm file.ext.OTHER
<mzz> Milo-: normally bzr gives you a bunch of files to make that easier: your version, the other version, the closest ancestor version, and a merge
<Milo-> hehee
<mzz> Milo-: it can't give you a merge for a binary format, which is probably why file.odt is now missing
<Milo-> did `bzr resolve file.odt`
<Milo-> that removed the .OTHER .THIS and .BASE
<Milo-> and now I don't even have the file.odt :D
<mzz> yes
<mzz> ah
<mzz> that's odd
<Milo-> renamed: file.odt => file.odt.OTHER
<mzz> normally you just do "bzr resolve" and it detects which conflicts you actually resolved
<Milo-> that was one of the lines that I got when I did bzr update
<mzz> bah, the term I did this in has no scrollback
<Milo-> what if I just want to ignore the changes my team mate did?
<mzz> you'd cp or mv the right file to file.odt and bzr resolve
<Milo-> that's what I told my team mate to do
<Milo-> and we had the missing 'error'
<Milo-> since it committed all nicely it doesn't 'really' matter
<mzz> I tend to avoid checkouts in cases where you actually end up merging, because they're a little confusing.
<mzz> I don't understand why you'd get that error unless something went and bzr added that file
<mzz> (it's entirely possible some integration thing did that, I don't use those)
<Milo-> I use branches with my laptop and checkout with my desktop
<Milo-> since laptop is mostly offline (or can't reach port 4155), and desktop isn't
<Milo-> well, I used bash, and that renamed the .odt file completely
<mzz> I think the message you're getting is just cosmetic (it noticing the file vanished from the working tree since the last time it looked)
<jam> Milo-: "bzr resolve file.odt" forcibly resolves the conflict. (giving an explicit name tells us that you want this file to be unmarked.)
<mzz> yes
<Milo-> jam yes
<jam> as for "mv file.odt => file.odt.OTHER"
<jam> that would hint that you had deleted the file locally
<jam> and someone else made changes that you merged
<Milo-> yes I know
<Milo-> thought it would bring the local copy back
<jam> if you still want the file gone "bzr revert file.odt" should do the right thin
<Milo-> by re-renaming the OTHER
<jam> Milo-: it *did*, but as "file.odt.OTHER" to indicate it was deleted locally
<mzz> it's trying to prevent you from accidentally resurrecting the file, afaict.
<Milo-> but now if I move some other file as 'file.odt', the change history points to some other file, that gets destroyed along with file.odt.OTHER ?
<mzz> I'm not sure if this is exactly *always* the case, but if you do get a conflict it's pretty unusual to be able to commit the conflicting file as-is.
<mzz> I don't follow.
<mzz> if you put some completely unrelated file in as file.odt and say "bzr resolve" or "bzr resolve file.odt" I'd expect it to remove file.odt.{THIS,BASE,OTHER}
<mzz> I don't understand what "the change history points to some other file" means
<Milo-> it removes them, but the repo still has history of that file.odt that had the conflict in the first place..
<mzz> yes
<mzz> (how could it not have that history?)
<Milo-> and now that the file.odt is no longer that file, the history isn't exactly 'his' now is it?
<mzz> what?
<Milo-> file.odt is replaced with some other file
<mzz> well, he did "bzr merge somebranch", and committed.
<mzz> so the history from branch "somebranch" is now part of the history of that branch too
<Milo-> the history points to the old file.odt, right?
<mzz> that's what a merge *does*, very roughly.
<Milo-> but this wasn't from merge..
<mzz> if you run "bzr log file.odt" you'd see those old revs, yes.
<Milo-> ok
<mzz> if this is a checkout that got out of date and got updated that *is* a merge
<mzz> I am confused about what you're confused about!
<Milo-> heh
<nyu> how do I extract a diff of the whole branch? (other than searching the branch point + bzr diff -r<branchpoint>..<head>)
<dash> nyu: bzr diff -rancestor:../parentbranch
<dash> where "../parentbranch" is the path to the branch you want to diff against
<nyu> thanks
<beuno> Peng_, hi
<beuno> would you like to take a peak at my YUI3 mp?
<Peng_> beuno: Sure, but I can't really review it.
<Peng_> I'd be happy to poke at it a bit, though.
<beuno> Peng_, poking at it and seeing if there's anything broken is good progress  :)
<Peng_> beuno: What do you mean by the search results being "off"?
<beuno> Peng_, if you search, the autocomplete doesn't appear beneath the search box, it ends up middle aligned or something like that
<Peng_> Oh, fun.
<beuno> yeah, I will fix that
<Peng_> Well, I just put it up on http://bzr.mattnordhoff.com/loggerhead/.
<beuno> it seems to work for me
<Peng_> beuno: The YUI module pluginhost is getting loaded too
<Peng_> I mean, and it isn't declared in the page, so it always gets loaded from Yahoo! instead of using the local copy.
<beuno> Peng_, that's interesting
<Peng_> beuno: Mind if I assign bug #439155 to you?
<ubottu> Launchpad bug 439155 in loggerhead "Upgrade to YUI 3.0.0" [Low,Triaged] https://launchpad.net/bugs/439155
<beuno> Peng_, not at all, I could use the karma!
<Peng_> :D
<Peng_> beuno: Ah, sorry, pluginhost doesn't get loaded after I refresh everything.
<beuno> Peng_, good. Those things are a PITA to debug
<Peng_> beuno: Poking around a bit, everything does seem to work. :)
<beuno> Peng_, super. Could you comment on the MP so we encourage mwhudson to approve?  :)
 * beuno waves at mwhudson 
<mwhudson> beuno: hello!
<beuno> mwhudson, how are you?
<mwhudson> beuno: i am ok
<mwhudson> slightly disheartened by how much email even a single day off has resulted in
<mwhudson> beuno: how are you?
<beuno> mwhudson, pretty good, doing the release week dance, but good
<mwhudson> ah yes
<beuno> mwhudson, did you have time to look at me yui3 branch?
<mwhudson> beuno: no
<mwhudson> beuno: did you do the merge proposal thing?
<beuno> mwhudson, https://code.edge.launchpad.net/~beuno/loggerhead/yui3-0-0/+merge/13744
<mwhudson> strange, i don't have that mail
<beuno> mwhudson, it ooped  :)
<mwhudson> oh yeah :)
<mwhudson> hm, it doesn'
<mwhudson> t have a diff either
<vila> jam: breathe again !
<vila> jam: babune just finished (and except for random leaking tests related faliures on OSX all is well)
<vila> jam: well, and one random on gentoo, but that doesn't count either :-/
<fullermd> Oh, does that means it's safe to go back in the bzr.dev?
<vila> fullermd: hehe, it has always been safe :-)
<fullermd> Famous last words...
<mwhudson> beuno: replacing region.left with search_box.get('offsetWidth') doesn't seem like it's going to work
<beuno> mwhudson, it doesn't  :)
<mwhudson> i see
<beuno> I need to fix that before landing
<mwhudson> beuno: why does region no longer work?
<beuno> mwhudson, it's a great question. I haven't been able to find out. I went around in circles for a good hour, and gave up  (that includes asking in #yui3)
<mwhudson> i love the way noone actually knows what they're doing in js :(
<beuno> :)
<mwhudson> i mean, i know _i_ don't
<mwhudson> beuno: basically i agree with Peng
<mwhudson> beuno: it looks fine, but fix the bug before landing, eh?
<beuno> mwhudson, sure, I will and land, thanks
<mwhudson> beuno: i might try to poke at fixing the bug today if i get a moment
<beuno> that would be nice
<huf> hi, we used to have a working bzr smart server (with bzr+http, fcgi, apache)
<huf> the bzr on that system was upgraded to 1.16.1, and now a bzr push (from a client with bzr 2.0.1) returns this:
<huf> bzr: ERROR: Server sent an unexpected error: ('error', "An attempt to access a url outside the server jail was made: 'chroot-139343724:///'.")
<huf> what could this be, where should i look for answers?
<mwhudson> it's a bzr bug i think
<GaryvdM> huf: What was the bzr version of the client?
<Peng_> huf: Bug #348308.
<ubottu> Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Fix released] https://launchpad.net/bugs/348308
<Peng_> The one bug number in the world I have memorized.
<Peng_> huf: The fix is in bzr.dev; upgrade your server to it. Or, you can use the monkeypatch listed in that bug.
<huf> thanks, that patch seems to have fixed it
<huf> how long should a branch of a ~200M repo take?
<huf> roughly
<huf> okay ;) i managed to segfault apache's mod_fcgid process handler with a bzr branch command
<Peng_> That's awesome.
<huf> oookay, now i get a timeout in the fastcgi process handler
<huf> FastCGI: comm with (dynamic) server "/var/www/bzr.nws.hu/bzr-smart.py" aborted: (first read) idle timeout (30 sec)
<jam> mwhudson: hmm.. I've been getting a lot of "Internal Server Errors" in loggerhead today. Does that get recorded as an OOPs ?
<mwhudson> jam: no :(
<jam> mwhudson: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/bzrlib/_simple_set.pyx
<jam> now, that turns out to be a bad URL
<jam> since it is "_simple_set_pyx.pyx"
<mwhudson> jam: hooray loggerhead error reporting
<jam> but I wouldn't have thought a bad path would cause an ISE
<mwhudson> it shouldn't, indeed
<Peng_> There's an open bug on better handling of bad input.
<huf> what's the "best practice" method of making password-protected r/w repos and serving them on the net?
<jam> huf: anonymous readonly ? or no access?
<jam> http? or ssh?
<jam> The most common is to just provide bzr+ssh:// and require full ssh authentication
<AfC> My lord. 120 MB of download to propagate a few patches to Eclipse. Someday, oh someday we'll have a binary delta distribution system that is as efficient as the source delta distribution system aka bzr.
<awilkins> Can you just push branches into Ubuntu One?
<gioele> abentley: hi
<abentley> gioele: hi.
<gioele> abentley: is bzr-pipeline supposed to work only with bzr 2.1 and not with 2.0?
<abentley> gioele: The 2.0.0 branch is supposed to work with 2.0, and the trunk branch is supposed to work only with 2.1
<gioele> abentley: I didn't see a 2.0 branch. Is it on launchpad?
<abentley> gioele: Yes: https://code.edge.launchpad.net/~abentley/bzr-pipeline/2.0.0/
<gioele> abentley: ah, OK. The Launchpad page for bzr-pipeline didn't show a 2.0 branch. Could you add that to the list of branches?
<abentley> gioele: There isn't a 2.0 branch, it's called 2.0.0.
<gioele> abentley: well, the problem is that launchpad says that it is merged, so it is no longer active, no it will not be shown by default in the list of bzr-pipeline's branches
<abentley> gioele: Right.  I have just fixed that.
<gioele> abentley: thank you
<larsemil> what do i do when a branch has diverged=
<dash> well, it means there are changes in your version and the other version
<dash> you can merge them if you like
<AfC> Hm. I wonder what would happen if used bzr to transfer songs to my MP3 player, rather than using rsync/unison. Be interesting to see what would happen with such a large amount of opaque data [interesting and no doubt ugly].
<dash> AfC: do you often use diff on yor mp3s? :)
<lifeless> AfC: it would work
<AfC> dash: :)
<larsemil> i did. and then i get a main.cpp a main.cpp.THIS and .BASE
<lifeless> just use a little more memory
<AfC> lifeless: the width (ie GBs) wouldn't be a problem?
<lifeless> AfC: the size of an individual song matters
<lifeless> in aggregate, it matters for the packing - db file balancing
<lifeless> personally, I wouldn't use bzr to put files on an mp3 player, because I have many more songs than disc space on such devices
<AfC> So, the situation is that I'm using Rockbox now on my iPod. It's pretty good! Some rough edges, but quite innovative in other areas. Rather than using (say) gtkpod to get files there, one just copies files to its [vfat :(] filesystem.
<AfC> Over time, I delete songs I've decided I don't like. This happens on both sides. So I've started using Unison (rather than rsync --delete).
<AfC> and that's fine, except that it takes Unison almost an hour (!) to find out what the change map is.
<AfC> [one strangeness is that the mtimes of the files on the device seem to be perennially off by one hour]
<AfC> so that's why I'm speculating that bzr might do a better job.
<AfC> on the other hand, there is the question of where to keep the Repository, the fact that the repo would be huge like the Working Tree that I play from normally is, etc
<AfC> and, of course, I realize full well that this is not what bzr was meant for.
<larsemil> i dont get it - if a branch has diverged do i have to put up the two documents and manually change and edit to the version i would want?
<dash> larsemil: do 'bzr merge <otherbranch>'
<abentley> AfC: I suggest putting the repo on your computer, and keeping a lightweight checkout on the rockbox.
<AfC> larsemil: are you talking about source code [or a text based document] or a binary [ie, compressed zip, proprietary binary data, etc, word processor] document?
<abentley> You'll only commit when you want to sync.
<AfC> abentley: yeah
<abentley> You could have a standalone tree on the computer, and a lightweight checkout of that on the rockbox.
<AfC> abentley: [I'm mentioning this largely to elicit either a "it'll be interesting to see how you go" or a "you're on drugs, Cowie."]
<AfC> abentley: that would make sense
<spiv> AfC: I don't think those two options are mutually exclusive ;)
<AfC> hic
<lifeless> AfC: the time offset thing is probably vfat mount options
<AfC> lifeless: that was my guess
<lifeless> AfC: vfat time storage is local, and you've had daylight savings transition recently
<lifeless> ext stores timestamps in utc, so doesn't do that
<lifeless> AfC: I know one guy managing a 100+GB photo collection with bzr
<AfC> lifeless: I must admit that much as the automounter magic is convenient, I haven't the faintest idea how to go about configuring options for specific devices
<lifeless> it does it tolerably
<AfC> huh
<AfC> [yeah, the DST thing was my guess, though it wasn't a once-off across the transition date, it seems to keep coming up]
<spiv> mwhudson: I'm working on that path escaping patch now
<mwhudson> spiv: awesome
<spiv> mwhudson: I can tell that the existing test wasn't written by me because I always use \N{INTERROBANG} when I need a unicode character ;)
<mwhudson> :)
<Peng_> spiv: No snowman?
<spiv> Peng_: you mean, no snowmanâ½
<Peng_> Heh.
<dash> zing
<spiv> Someone should make a deck of playing cards with some wacky unicode glyphs rather than the traditional suits.  "My 9 of Interrobangs trumps your 8 of Snowman!"
<Peng_> That's a really good idea.
<Peng_> I'm still mostly not a fan of novelty playing cards, though.
<dash> spiv: also use cuneiform numbers
<lifeless> Peng_: if your branches are not on launchpad, consider using lp apis to tell lp that you have updated your branch
<lifeless> in a post push hook
<Peng_> lifeless: Ehh, that's a little complicated. But yeah, I know I need to set something up.
<lifeless> Peng_: should be pretty easy
#bzr 2009-10-27
<Peng_> lifeless: The LP URL isn't stored anywhere. The code can usually guess it, but not always.
<Peng_> lifeless: Plus, not every branch is mirrored on LP.
<Peng_> lifeless: It's probably still do-able, but it requires a little thinking, which I haven't wanted to do. :P
<SamB_XP> Peng: americans these days!
<wgrant> Why are the branches not hosted on LP?
<Peng_> wgrant: Why don't I host my branches on LP?
<wgrant> Peng_: Right.
<Peng_> wgrant: Eh. If I did host them on LP, I'd only be using my VPS for ntp and irssi. How'd that be fun?
<SamB_XP> Peng: it sounds better if you claim to be "testing" it ;-P
<igc> morning (ish)
<poolie> hello
<poolie> how're the old positrons? :)
<offby1> they keep annihilating the electrons.
<igc> hi poolie!
<poolie> hi igc
<igc> poolie: how's the email mountain? :-)
<poolie> substantial :)
<lifeless> .-=^=-.
<jam> mwhudson: question about python for you
<jam> It seems that subclassing from tuple gives me an object that is 8-bytes bigger
<jam> until I add an attribute, then it seems to grow a __dict__ and blossom another 140 bytes
<lifeless> heh
<jam> Even adding __slots__ = ()
<jam> it still seems to have the extra 8 bytes
<jam> do you know why?
<lifeless> python type vs native type?
<jam> lifeless: yeah, I was worried that the pure-python StaticTuple would have a __dict__ all the time, so I added __slots__ = (), only to find 0 change on normal instances.
<jam> anyway, I haven't found the code that handles subclassing builtins, other than "tuple_subtype_new"
<jam> but that doesn't seem to indicate what 'tp_alloc' is set to for the new class instance
<spiv> jam: hmm, that does seem to be the key question
<jam> spiv: anyway, I can live with 8 bytes overhead for StaticTuple instances when they don't compile extensions
<jam> versus 28 for the ST instance if we wrapped a tuple instead of subclassing it
<mwhudson> jam: not off the top of my head
<spiv> jam: gdb says PyType_GenericAlloc
<jam> mwhudson: I thought you might have some inkling, as I thought you mentioned when 'tp_dict' is negative
<mwhudson> jam: i probably knew once :)
<jam> spiv: right and that is just based on "tp_itemsize" and "tp_basicsize"
<jam> so we need to figure out what is setting "tp_basicsize"
 * igc lunch
<spiv> jam: for me, the tp_itemsize and tp_basicsize are the same for a trival "class T(tuple): __slots__ = ()" and tuple.
<jam> spiv: so I posted some testing here:
<jam> https://code.launchpad.net/~jameinel/bzr/2.1-pure-static-tuple/+merge/14006
<jam> can you reproduce?
<jam> (creating 1M instances of a child of tuple is 8 bytes more memory than 1M instances of tuple)
<jam> which is 16 bytes more memory than 1M instances of _static_tuple_c.StaticTuple
<jam> regardless of __slots__
<jam> spiv: I *do* see that if you have "add_dict" set, then it adds a pointer to the end of the instance. And I think I see that add_dict should be set to 0 if __slots__ is set.
<jam> but that doesn't seem to be what I'm seeing in practice...
<lifeless> sure its not a type pointer?
 * lifeless is speculating
<jam> lifeless: all objects in python have a type pointer, even 'tuple'
<jam> so it should be able to just re-use that location
<jam> since it is fixed for inspection
<jam> it could be a mro or something like that
<jam> however, looking at "typeobject.c"
<jam> essentially "type->tp_basicsize = base->tp_basicsize + (add_dict ? 1 : 0) + (add_weakref ? 1 : 0) + (num_slots)
<jam> spiv: in my testing, I even see it if I comment out all of StaticTuple's implementation except for the __slots__ statement.
<spiv> jam: I see no memory difference under 2.6 between [tuple([n]) for n in range(1000000)] and s/tuple/T/, where T is that trivial subclass with empty __slots__.
<jam> spiv: oddly enough, I *do*
<spiv> jam: I *do* see different results with zero-length tuples
<spiv> i.e. pass [] instead of [n]
<jam> spiv: well there it is because 'tuple()' is a singleton
<spiv> Right.
<spiv> jam: my testing method is pretty simple, I'm running this:
<spiv> python -c "T = type('T', (tuple,), {'__slots__': ()}); x = [T([n]) for n in range(1000000)]; print 'ready'; raw_input()"
<spiv> jam: and then looking at /proc/<pid>/status
<lifeless> jam: what python version do you have?
<jam> lifeless: 2.6.2
<lifeless> spiv: and you ?
<jam> spiv: "trace.debug_memory()" on windows
<jam> which looks at /proc/pid/status on linux
<spiv> 2.6.4rc2
<lifeless> right
<lifeless> I suspect its the __slots__ change which broken boost-python in 2.6.3
 * lifeless handwaves furiously
<jam> lifeless: that could be...
<jam> spiv: on Python 2.4.3 under linux I see no difference with __slots__ and 8 bytes without __slots__
<spiv> jam: *nod*
<jam> spiv: I just upgraded to python 2.6.4, and I still see the same thing...
<jam> very very strange
<jam> w/ or w/o __slots__ it adds 8 bytes
<jam> maybe an alignment thing?
<jam> subclasses not being as tightly aligned...
<jam> anyway, the merge proposal is still good to have, as it helps somewhere (on spiv's machine. :)
 * jam wanders off to bed
<spiv> jam: I just hit approve, btw
<spiv> jam: in case you want to do a PQM submission from bed ;)
<igc> lifeless: do your changes in dirstate2 reduce it's size? IIRC, you were looking to take one of the 'columns' out weren't you?
<lifeless> igc: I haven't done that
<wgrant> Will anything blow up if I symlink a shared repo's .bzr into a subdirectory, in order to segregate my branches?
<poolie> wgrant: the .bzr/repository directory?
<poolie> mm
<poolie> it's not really supported
<wgrant> poolie: I was thinking the entire .bzr.
<poolie> what exactly do you mean?
<wgrant> poolie: I have ~/launchpad/lp-branches with lots of branches in it.
<wgrant> I have a particular line of work which will need about a dozen branches.
<wgrant> I want this to live in a subdirectory.
<wgrant> So the related branches are obvious and separated from the rest.
<poolie> ok
<lifeless> igc: I'd be delighted to brain dump/find my old notes on removing columns
<lifeless> wgrant: it will work fine
<poolie> so i don't think you need to do anything with symlinks
<lifeless> wgrant: but its not need, just use a subdir
<wgrant> lifeless: That's what I thought, but best to be safe. Thanks.
<poolie> just make a subdir
<lifeless> wgrant: 'mkdir project'; bzr branch trunk project/1
<lifeless> etc
<spiv> wgrant: you can have an arbitrary number of subdirectories between a repo and a branch, though..
<wgrant> spiv: Oh, it will look all the way up?
<lifeless> wgrant: yes
<wgrant> That's convenient.
<wgrant> didn't know that...
<lifeless> wgrant: we aim to please
<igc> lifeless: I think there was a bug report for removing a column. Maybe add them there?
<wgrant> lifeless: You succeed.
<spiv> :)
<lifeless> igc: are you considering picking up dirstate2 and running with it?
<lifeless> I won't be following up for a while..
<igc> wgrant: if there's somewhere in the doc I should change to make that more obvious, please let me know
<igc> lifeless: no
<igc> lifeless: I was just trying to understand some benchmark results
<wgrant> igc: I haven't read the bzr docs in at least three years. I have no idea what they're like now.
<igc> lifeless: see #461651
<igc> wgrant: I guess that answers that question :-)
<lifeless> bug 461651
<ubottu> Launchpad bug 461651 in bzr "Implicit packing during branch is often suboptimal" [Medium,Invalid] https://launchpad.net/bugs/461651
<lifeless> igc: yes, I saw that
<igc> 11M for a FireFox dirstate seemed large
<lifeless> igc: getting rid of the the extra tree columns wouldn't shrink that any
<lifeless> as its not a merged dirstate
<igc> lifeless: ah - ok. Thanks
<vila> hi all
<poolie> hello vila!
<vila> welcome back poolie :)
<poolie> thanks, it's good to be back
<igc> hi vila!
<wgrant> igc: So, I decided I should read through some of the docs. They really are excellent these days.
<wgrant> (where do I file typos in them?)
<igc> wgrant: the docs are genuinely a community effort but, hey, I'll take the credit :-) :-)
<igc> wgrant: unfortunately, it depends
<igc> wgrant: most of the docs are in the core but some, like the migration docs, are separate projects
<igc> wgrant: if you file doc bugs against the core, we can shuffle the assigned project if appropriate
<wgrant> igc: 'Why Switch to Bazaar?' is the one I just found a typo in.
<igc> wgrant: it's in lp:bzr-migration-docs
<wgrant> igc: Thanks.
<wgrant> igc: One other thing I noticed (horrible horrible nitpicking, I know) is that the migration docs don't seem sure on whether to use sentence or title case for various levels of headings. It just makes it look that bit unpolished.
<igc> wgrant: the unwritten rule is Title case for document headings, sentence case otherwise
<lifeless> igc: I'd be a lot happier if all the docs were in the core
<lifeless> so the debian package would include them
<igc> lifeless: all the docs can't be in the core - many of them are built from plugins
<lifeless> igc: I thought that was just the plugin guide one?
<igc> lifeless: other like the website and doc-website bridge multiple releases
<lifeless> igc: well, the website is differnet
<lifeless> its /docs/ I care about
 * wgrant will submit a couple of migration docs MPs later tonight.
<lifeless> if the ReST were generated and committed to trunk, then it could be included in the deb package
<GaryvdM> Hi lifeless
<GaryvdM> lifeless: I'm looking at bug 320236.
<ubottu> Launchpad bug 320236 in bzr-search "Index authors" [Wishlist,Triaged] https://launchpad.net/bugs/320236
<GaryvdM> lifeless: Would it be allright if specified the field that a term applies to in the document_key
<GaryvdM> lifeless: e.g. for authors/commiter : ('r','a',rev_id)
<lifeless> I'd hesitate to do that
<lifeless> its not a good use of the index space
<lifeless> either index with a more appropriate term
<lifeless> ('author', 'fred')
<lifeless> or query the matching revisions to filter more
<GaryvdM> lifeless: Ok - I think I'll index with a more appropriate term
<lifeless> GaryvdM: my advice though
<lifeless> GaryvdM: post process
<lifeless> accessing revisions is fast
<lifeless> and you'll already have a short list
<GaryvdM> lifeless: Ok
<lifeless> adding more data to the search index is likely to just slow things down
<lifeless> *if* data shows that it would make a huge difference, then I'll happily drill into this in more detail with you
<lifeless> consider though - how many revisions would have a hit for 'Robert' and not have that be author/committer
<lifeless> [remember that you won't be comparing against file texts here]
<GaryvdM> lifeless: Yes - that makes sense.
<vila> lifeless: you know there are still  3 test failures for loom ? (Related to switch)
<lifeless> vila: no, I didn't
<lifeless> unless, perhaps, I put up a branch for review
<vila> lifeless: ./bzr selftest -s bb.test_switch trigger them all
 * igc dinner
<lifeless> vila: have you filed a bug on loom? if not, please do so
<vila> lifeless: ok
<vila> bug #461743
<ubottu> Launchpad bug 461743 in bzr-loom "test failures related to switch" [Undecided,New] https://launchpad.net/bugs/461743
<hsn> anybody have experience with bzr support in maven? it seems that bzr protocol is unsupported and sf.net servers does not provide http access to bzr repo
<GaryvdM> Hi igc
<igc> hi garyvdm
<GaryvdM> igc: I've been thinking about rename/move for qbzr.
<GaryvdM> I want to hear your ideas on ui.
<GaryvdM> And bounce some of my own.
<igc> bug 298242
<ubottu> Launchpad bug 298242 in qbzr "New dialog for auto rename" [Low,Confirmed] https://launchpad.net/bugs/298242
<igc> garyvdm:^
<GaryvdM> So the idea I have is that from the treewidget (i.e. qcommit, and qbrowse) you can right click, rename, or you can drag and drop move
<igc> garyvdm: sounds great
<GaryvdM> igc: Sorry - I forgot that you had the right up in the bug.
<igc> garyvdm:I like you ideas
<GaryvdM> And the other idea that I have is that you can highlight a missing file, and a unversioned file, and right click, "Mark as Move"
<GaryvdM> igc: Cool
<igc> we could combine them by just showing the dialog I outlined, with ...
<igc> the relevant radio button pre-selected
<GaryvdM> igc: I see
<igc> drag n drop would be really nice for move
<igc> garyvdm:^
<igc> garyvdm: it's my bed time - any other questions?
<GaryvdM> igc: Nope. Thanks for your time.
<GaryvdM> igc: Sleep well.
<igc> garyvdm: thanks!
<igc> night all
<jam> morning all
<vila> morning jam !!!
<vila> did you intended to vote but forgot on the dwim revspec ?
<vila> jam: the tone of your comment sounds like a vibrant approve but... :)
<jam> vila: I intended to enter the discussion.
<jam> though I do approve the change
<jam> vila: there, feel better :)
<vila> lol, thanks for fullermd :)
<jam> Peng: https://code.edge.launchpad.net/~jameinel/bzr/2.1-st-from-iterable/+merge/14027
<jam> vila: I'll go ahead and submit his patch then.
<vila> jam: I'm doing right now if you haven't started...
<jam> vila: ah, please do
<jam> I just didn't see it in PQM yet
<vila> pqm'ed
<vila> I had some... weirdness-I-dont-even-want-to-start-looking-at
<jam> rockstar: are you around for a bit of a chat?
<Peng_> The question is, how do I mark my merge proposal as superseded?
<gioele> mwhudson: hi, have you got a tarball of the generated bzrlib API?
<jam> Peng_: you can mark it as "work in progress" and it will be hidden from the review queue
<jam> or "Merged" if you want to treat it as merged into mine...
<jam> I don't have a better way
<jam> Peng_: Or just wait until the patch lands and see if lp marks it merged for you
<rockstar> jam, hi
<jam> good morning rockstar
<jam> I hope you've had your coffee this morning :)
<Peng_> jam: I'm confident that LP will mark it merged.
<jam> I'd like to pick your brain a bit about things that the bzr team can do to help you guys
<Peng_> Huh, set(['foo bar']) is a lot faster than set(StaticTuple('foo bar'))
<jam> most notably, things that *I* should focus on :)
<rockstar> jam, great.  I don't drink coffee shop, but I'm about to head out to one.
<rockstar> jam, can it wait about an hour?  I have some branches to land.
<jam> rockstar: absolutely
<rockstar> jam, great.
<Bear10_> when I do a bzr add dir it says it ignored 2 files but doesn't say which
<Bear10_> any ideas how to find out which?
<jam> Bear10_: bzr ignored
<Bear10_> thanks
<Bear10_> see :)
<Bear10_> woops wrong window
<Peng_> jam: Thanks for all of your help recently. :)
<jam> Peng_: thanks for your interest
<Bear10_> has anyone experienced problems where the icons just never update, and you have to manually update to see if your still on the same version as the binded branch?
<Arc> does bazaar support commit hooks such as buildbots, special handling of certain file types (ie, unzipping an ODF so it's contents are stored in VCS and diffed vs the zip as a binary blob, metadata checked and passed, etc)
<Peng_> Bazaar does have good hook support, so they can probably be used for all of that.
<Arc> do the hook distribute to users?
<Arc> or do they need to be manually installed by each committer
<Arc> looking at bazaar from the mercurial model
<Arc> especially for hosting media
<Peng_> Arc: Manually installed.
<Arc> so we're not really better off with bzr over hg
<Arc> except for perhaps the licensing issue, which hg is very sub-optimal for
<Peng_> It is?
<jfroy|work> mornin'
<Arc> GPLv2 only vs GPLv2+
<Arc> GPLv2-only is not AGPLv3 compatible
<Peng_> Arc: I think they're working on GPLv2+.
<Peng_> Or already did it.
<Arc> really?  I thought their maintainer was dead set against it
<Peng_> Arc: I think he suddenly and quietly changed his mind. I'm not sure, though.
<Arc> ok
<james_w> Is GPLv2+ AGPLv3 compatible?
<james_w> I wouldn't have thought that it would be
<Arc> yes, because the GPLv3 is AGPLv3 compatible
<Arc> GPLv2->GPLv3->AGPLv3
<Arc> GPLv3 section 13 makes it so
<james_w> ah, thanks
<Arc> we're building a web framework for our project that is licensed under the AGPLv3, and would really like to get mercurial integration
<Peng_> Arc: See the thread in mercurial-devel "Re-licensing email", starting 2009-10-14.
<Arc> Peng_: i just read, thanks :-)
<Tak> is there anything special I need to do to `import bzrlib` on windows, having installed with the default installer?
<Tak> aha, got it!
<Tak> didn't think to look in the zipfile
<cjwatson> jelmer: can I interest you in what appears to be a bzr-svn data corruption bug? it's happening to the grub project, who are just looking at adopting bzr; unfortunately at the moment they're using the bzr/bzr-svn from Debian lenny (but could be persuaded to upgrade if I can demonstrate that some of their problems would go away with newer code)
<cjwatson> jelmer: jml took a look at it here and said "uh, this probably needs John or Jelmer" :-)
<Tak> anyone with python on win64 want to do a `python -c "import sys; print sys.platform"` for me?
<jml> cjwatson, I was _so_ much more eloquent than that.
<jml> cjwatson, I was using internal rhyme and everything.
<cjwatson> jml: :-)
<Peng_> mwhudson: ping, if you don't mind doing some hand-holding.
<Peng_> Tak: Maybe try #python.
<Peng_> What OSes are used at Canonical? Just Ubuntu? :D
<Tak> or maybe not!!!
<Peng_> Tak: Why not?
<GaryvdM> Peng_: bzr is cross platform!
<cjwatson> jelmer: bug 462109, if you're interested
<ubottu> Launchpad bug 462109 in bzr-svn "corrupted branch with bzr 1.5, bzr-svn 0.4.10, and roundtripping" [Undecided,New] https://launchpad.net/bugs/462109
<Peng_> mwhudson: Semi-unping. (Sorry, I know that's not very helpful.)
<Tak> in case anybody cares, the result is "win32"
<GaryvdM> Hi
<GaryvdM> Is there a way to get a tree for NULL_REVISION without a reference to a repository?
<GaryvdM> Ah - nvm - I grep and I grep, but I could not find. I asked here, then switch back to my IDE, and it was right in my face :-P
<GaryvdM> RevisionTree(self, Inventory(root_id=None), NULL_REVISION)
<BrianBatchelder> I'm trying to figure out how to prevent the merging of a particular file whenever I merge between two branches.  We have a hierarchical branch setup, with branch "A" as our release branch, and "A.1", "A.2", etc. as development branches.  When a dev branch is ready to release, it merges to branch "A", and then that code is merged down to the rest of the development branches.  But I have one branch-specific file that can't be merged during this process. 
<BrianBatchelder> must be version controlled, because it is needed in checkouts of the development branches.  Any ideas of how to do this?  Thanks.
<maxb> bzr revert it in between merge and commit, always?
<dash> BrianBatchelder: revert it before you commit the merge?
<BrianBatchelder> I'm not the only one who does the merges, so I'd like it to be automatic.
<dash> shell script time :)
<BrianBatchelder> Is there a simple way to hook the merge operation and automatically revert it?
<BrianBatchelder> Or perhaps limit the users who can modify that file?
<mwhudson> Peng_: good <time of day>
<Tak> jelmer: http://img148.imageshack.us/img148/1204/mdbzrwin32.png
<Peng_> mwhudson: Hi. :)
<Peng_> mwhudson: So anyway, never mind about the ping. I was trying to figure out loggerhead.wholehistory, and managed it well enough.
<mwhudson> Peng_: cool
<Peng_> Not that I understand it, but I was able to accomplish what I was working on. :P
<Peng_> The revision graph cache is one scary data structure. :P
<mwhudson> yes, and it should be fixed by deletion really
<mwhudson> otoh, we can't escape the need for revision numbering for now
<jfroy|work> jelmer: is the svn revno corresponding to a particular bzr revision available to hooks?
<jfroy|work> I'd like to write some sort of post-revision-push hook (if that's possible) that would need to know the corresponding svn revno (and possibly the push URL) of each pushed revision.
<samokk> hey. wondering about something simple : I see that bzr 2 has a new repository format 'nearly as efficient as git', and also supports the import of git branches. if the 2a format is only nearly as efficient, then why not use git repo format by default ?
<dash> git doesn't support all of bzr's features
<samokk> oh ok
<faheem> can anyone point me to large public bzr repos for testing? i'm using 2.0.1
<hsn> faheem: mysql
<maxb> faheem: Launchpad's own source is pretty large
<lifeless> faheem: what sort of testing
<lifeless> hsn: mysql haven't upgraded their branches, so aren't a very good test case for testing - still performs slowly
<bob2> drizzle otoh is about to upgrade
<igc> morning
<lifeless> bob2: cool; I only lurk in IRC, you're in the list?
<bob2> yeah
<apm121> mysql migrate from ? svn or cvs ?
<bob2> they came from bk
<wgrant> bzr-git doesn't seem to be able to branch over HTTP yet. Is that the case?
<mwhudson> wgrant: it is
<wgrant> mwhudson: I guess I'll do a local clone and branch from that. Thanks.
<poolie> hello
<lifeless> hi
<mwhudson> i have this vague notion that bzr plugins can't be in eggs
<mwhudson> is there something fundamental about this, or could it be fixed?
<lifeless> mwhudson: it could be fixed I guess
<lifeless> mwhudson: plugins are just packages that we do 'import bzrlib.plugins.package'
<mwhudson> hm
<lifeless> mwhudson: plugin loading is thus in two phases: setup an appropriate python path on bzrlib.plugins.__path__
<lifeless> scan manually for all packages in that path
<lifeless> call 'import bzrlib.plugins.package' for the resulting names
<mwhudson> i guess it's the "scan manually" part that goes awry with eggs?
<lifeless> yes
<lifeless> now, things keep getting tweaked there
<lifeless> I mean to go into the code, delete all the cruft and make it simple again
<lifeless> (for instance, I believe bzr in a .zip is handled differently, for no good reason)
<mwhudson> so if i were to focus very narrowly on what i'm thinking about right now, which is launchpad, i could probably put (say) bzr-svn in an egg and import it by hand
<lifeless> oh yes
<lifeless> I'd expect that work fine
<lifeless> see also IRC log for me chatting with vila about allowing specifications of individual plugins on BZR_PLUGIN_PATH
<mwhudson> hmm
<mwhudson> BzrError: Attempt to escape test isolation: 'file:///var/tmp/codeimport/data/worker-for-branch-1/bzr_working_tree/' [u'/tmp/testbzr-MThLsv.tmp/', 'file:///tmp/testbzr-MThLsv.tmp/', u'/tmp/testbzr-MThLsv.tmp/lp.codehosting.codeimport.tests.test_worker.TestSubversionImport.test_import/', 'file:///tmp/testbzr-MThLsv.tmp/lp.codehosting.codeimport.tests.test_worker.TestSubversionImport.test_import/', 'file:///tmp/testbzr-MThLsv.tmp/']
<mwhudson> what is this trying to tell me?
<mwhudson> oh, i see
<mwhudson> not the most helpful error message
<spiv> No, I guess not.
<johnf> jelmer: you about?
<spiv> Some text like "is not inside one of" between the url and the list of acceptable locations would probably help.
<spiv> And maybe "Attempt to open BzrDir outside test isolation" would be better too.
<johnf> anyone know if there is a solution to this problem when running bzr check "reason: Parent not in inventory." It is from a branch that was originally branched from SVN
<mwhudson> spiv: yeah
<spiv> Huh, PQM is only just now playing my merge requests from yesterday.  I wonder where they got stuck.
<poolie> hello spiv, igc, mwh
<igc> hi poolie
<poolie> hi there igc
<igc> poolie: can you review https://code.edge.launchpad.net/~ian-clatworthy/bzr/filtering-revert-bug/+merge/14022 today? Given you're not working on the content filtering bug, I'm going to take it back on board. This is step 1.
<poolie> ok, i'll try
#bzr 2009-10-28
<poolie> done!
<poolie> low latency fwt
<poolie> ftw*
<poolie> igc: i commented - what do you think?
<igc> poolie: can you explain more?
<poolie> it seems unfortunate to me that the tests would need to mutate and then restore a library-wide variable
<poolie> as opposed to just changing their instance of the tree
<poolie> maybe i'm massively confused?
<poolie> or apparently you're relying on python looking up the name both instance-wide and class-wide?
<poolie> that works, but we really discourage it
<poolie> it can be confusing or fragile
<igc> poolie: none of that is new. content-filters are registered library-wide and that was the easiest way to test them
<poolie> i don't see anything else accessing WorkingTree._content_filter_stack
<poolie> only on particular instances
<igc> poolie: in testing, I need fine control over when filtering is on vs off
<igc> poolie: from memory I need to patch in at the class level ...
<igc> because the tree is implicitly created by branching
<lifeless> igc: filters are registered, but what about being enabled?
<lifeless> igc: I mean, say I have two WorkingTree instances
<lifeless> surely they don't have the same filter stack
<lifeless> if one tree has eol conversion enabled and the other doesn't
<igc> lifeless: we don't have per tree filtering
<lifeless> I thought that that was all we had
<poolie> igc, so it's a bit weird and likely to break eventually
<poolie> i think at least you should add a comment there
<igc> lifeless: we only have global rules (much to my frustration)
<poolie> but it's not new code, so you don't need to clean it up to land this
<poolie> therefore +1
<poolie> hth
<igc> poolie: it does. I'll submit the next patch after this one lands
<igc> poolie: can you update the review? I'll add the comment to the tests as requested
<poolie> k
<lifeless> james_w: around?
<lifeless> igc: I must say I'm confused as to why we have global filters only; I was sure we had agreed on an initial locations.conf/bazaar.conf based setup - which doesn't imply global library state at all
<igc> lifeless: it never got off the ground. I tried a patch along those lines and the design didn't hold up. I can't remember all the details now
<lifeless> ok
<jelmer> johnf: hi
<johnf> jelmer: howdy. Did you see my bzr check question?
<jelmer> johnf: no
<johnf> one sec
<johnf> johnf: anyone know if there is a solution to this problem when running bzr check "reason: Parent not in inventory." It is from a branch that was originally branched from SVN
<johnf> jelmer: ^
<jelmer> johnf: sorry, haven't seen that before
<jelmer> johnf: can you reproduce this somhow with a fresh import?
<johnf> jelmer: problem is we moved on from using SVN as a backend. I suppose I could import and then apply all patches since
<jelmer> johnf: Does reconcile fix it perhaps?
<johnf> let me try that
<tedg> igc: So I can't get the svn-import to work.  How did you run the svn-import?  (what parameters)
<tedg> igc: I've been figuring it was me, but I'm getting ready to blame bzr-svn :)
<johnf> jelmer: nope http://pastie.org/672762
<johnf> tedg: Initially I didn't do an import since we where backing onto svn. I branched it
<igc> tedg: I can't remember. Let me try again and see if that jolts my memory ...
<tedg> johnf: ?  I'm not sure what you're saying.  I'm trying to do an import.
<arjenAU> ahoy oh gurus of bzr land, I come to you in a quest for enlightenment
<johnf> tedg: sorry thought you where referring to my problem. Just ignoe me
<arjenAU> oh hi igc
<tedg> johnf: Ah, okay.  No problem :)
<igc> hi arjenAU
<arjenAU> so, I have a branch with 2 extra local revisions (committed) and 1 remote revision committed. so pull says branches have diverged. fine. so I merge from the remote branch and it says nothing to do. guh?
<igc> tedg: I think I used bzr svn-import --all source dest
<jelmer> johnf: You might want to do a clean import using a new version pof bzr-svn and then branch your new work into that
<johnf> jelmer: sounds like a good idea
<tedg> igc: Okay, let me try that.  I wasn't using --all, I thought you were grabbing one branch.
<igc> tedg: which version of bzr abd bzr-svn do you have?
<igc> and
<igc> bzr plugins will tell you
<igc> the bzr-svn version
<johnf> arjenAU: what does bzr missing --theirs-only say?
<tedg> igc: 1.0.0dev
<jelmer> johnf: you'll want to use a new shared repository
<arjenAU> johnf: that i'm missnig one rev.
<johnf> arjenAU: does bzr status say you have merges pending?
<arjenAU> nops
<tedg> igc: That gets me to an exception: AssertionError: Unable to find direct lhs parent for <CachingRevisionMetadata for revision 7680, path tags/start/experimental ...
<arjenAU> johnf: nop it seems cleanly committed on both ends, just diverged. so a merge should work I'd say.
<johnf> arjenAU: ok if "bzr check" says everything is OK then I'm out of ideas and will hand over to a higher power :)
<arjenAU> johnf: yep ok
<igc> arjenAU: sounds weird ...
<arjenAU> igc: hehe yea. running 2.0 on jaunty from ppa.
<igc> arjenAU: here's what I'd do ...
<arjenAU> igc: i possibly forgot something, just can't think of what. it look sfine just doesn't fly
<arjenAU> ok listening
<igc> grab a copy of the remote branch locally
<igc> try merging from that copy into your branch
<arjenAU> ahye and pull merge. ok
<igc> arjenAU: I recall some weirdness ages ago where the branch had a change but the working tree wasn't refreshed
<igc> so merge got confused and said nothing to do
<arjenAU> nothing to do still...
<arjenAU> should I try merging the other way?
<igc> arjenAU: one way to ensure the tree is in sync with the branch is to 'bzr revert', assuming you have no local changes
<arjenAU> well I do have local changes is the ponit
<arjenAU> but not uncommitted
<igc> revert is safe if your local changes are committed
<lifeless> arjenAU: run 'bzr revision-info' in your local branch
<lifeless> and with the url of youre remote branch
<lifeless> also pastebin 'bzr info' for both branches
<arjenAU> url of remote branch where?
<arjenAU> revision-info doesn't accept the bzr+ssh syntax
<tedg> igc: Okay, it seems that appending part of the svn path helps.  Then it's not looking for the odd repository layout from the CVS import.  It's coping revisions now.  Which means my lap is getting hot from the laptop :)
<igc> tedg: :-)
<tedg> Oh my, bzr is using 1.5GB of RAM...
<igc> tedg: trunk has lots of memory improvements thanks to jam
<igc> tedg: if required, you can convert using that (safely)
<tedg> I might have to... we'll see.  I only have 2GB physical.  If it hits swap, it'll never finish :)
<tedg> Nope.  Error'd out :(
<tedg> Hmm, why don't errors generate crash files?
<igc> tedg: if you throw the error in a bzr-svn bug report, jelmer is pretty good at solving them
<tedg> I can't imagine this error is very useful: ERROR: Must end write group before releasing write lock on CHKInventoryRepository
<tedg> Without even a backtrace.
<tedg> That's all I got.
<igc> tedg: if you run with -Derror, you should see a backtrace
<igc> tedg: though it's surprising you didn't get one anyway
<arjenAU> lifeless: revision-info doesn't accept the bzr+ssh syntax
<fullermd> arjenAU: You'd have to use the '-d' arg.
<arjenAU> lifeless: http://pastebin.org/48867
<fullermd> arjenAU: What branch are you merging?
<arjenAU> fullermd: remote into local
<fullermd> Yeah, but what's 'remote'?
<arjenAU> the one with the url
<fullermd> There are two URLs, and they're different.
<arjenAU> oh both
<arjenAU> bother sorry
<arjenAU> hang on
<fullermd> Are you sure you're missing'ing the same branch you're merge'ing?
<arjenAU> indeed apparently not.
<tedg> igc: Not enough memory to get the backtrace.  Tried to upgrade to nightly, but now bzr-svn won't work because of API version issues.  :(
<tedg> Why can't this information be encoded in to the packaging so that it's known at install?
<tedg> It's really annoying that bazaar breaks even when apt is happy.
<arjenAU> fullermd: the plot thicken
<arjenAU> +s
<SamB_XP_> tedg: I'm going to blame jelmer ;-P
<lifeless> tedg: what ppa are you using?
<SamB_XP_> if only for not setting the PPA managers straight
<igc> tedg: ok, I have plenty of memory here. I'll try doing some of the conversion now
<tedg> lifeless:  http://ppa.launchpad.net/bzr-nightly-ppa/ubuntu
<lifeless> so, nightly friction
<tedg> igc: This is what works for me: $ bzr svn-import --all -Derror inkscape.svn/inkscape inkscape.bzr
<tedg> igc: Well, where "works" is generates an out of memory error :)
<arjenAU> ok fullermd lifeless igc the prob came from the fact that we have push, parent and submit branch urls... so it gets confusing.
<tedg> lifeless: Sure, but apt should stop bzr from installing then.  Or atleast warn me that the others need to be removed.
<lifeless> tedg: nightlies dont have the right metadata
<lifeless> tedg: they are pulling trunk, and there isn't a connection between trunk commits changing deps and the apt packaging
<lifeless> tedg: same issue that bobthebuilder recipes need updating for
<tedg> lifeless: yes, but it seems that the API version is related to the bzr version.  So it would seem that the bzr-svn package in Karmic should have a depends on bzr (= 2.0.0) if it's going to only request and deal with a specific version.
<lifeless> tedg: no, the API version is like a soname, it changes when we break things, not when a release is done per se
<lifeless> tedg: what does dpkg -l bzr
<lifeless> show?
<tedg> bzr            2.0.0+4766+129
<lifeless> so
<lifeless> dpkg thinks that you still have bzr 2.0.0 on your system
<lifeless> as I said, metadata mismatch
<SamB_XP_> lifeless: perhaps this metadata should be derived from something within the bzr tree somehow ?
<lifeless> SamB_XP_: perhaps
<SamB_XP_> like, maybe the API version ;-P
<lifeless> tedg: you shouldn't use nightlies unless you're willing to deal with such mismatches, which will occur
<tedg> lifeless: Believe me, I don't want to use nightlies :)
<lifeless> so why are you?
<tedg> lifeless: Because apparently they have memory fixes in them, that might bring down the memory of my import.
<tedg> As apparently I don't have enough physical memory.
<SamB_XP_> tedg: why are you using physical memory anyway ?
<lifeless> there are significant memory improvements in trunk, thats true
<lifeless> however igc is doing it now, right?:)
<tedg> lifeless: And I'm uninstalling the nightly as we speak :)
<igc> lifeless, tedg: rsynch'ing the inkscape svn repo as we speak
<tedg> igc: If you could casually watch the memory usage as you're running, that'd be helpful.  If I'm close, I'd like to get this working as we're going to have to update with the final release hopefully in a couple days as well as pulling other sub-repos out of the SVN tree.
<tedg> (website, docs, etc.)
<igc> tedg: sure
<igc> bbiab
 * igc lunch
<MTecknology> So.. loggerhead
<MTecknology> better installed from bzr instead of apt?
<spiv> MTecknology: hmm, I've never tried installing it :)
<MTecknology> spiv: I'm trying to remember this and from what I recall from a year ago you run it and you don't really have control over what it listens to; I want it to run throguh apache..
<spiv> I'm pretty sure you can control that.
<MTecknology> ok, cool
<spiv> See the loggerhead.conf.example
<spiv> (http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/annotate/head%3A/loggerhead.conf.example)
<MTecknology> thanks :)
<spiv> The README has a section on serving it from behind apache, too.
<MTecknology> OH!
<MTecknology> I remember this now... apache proxy
<MTecknology> spiv: what's with the .1 files in there?
<MTecknology> like serve-branches.1
<spiv> No idea.
<mwhudson_> man pages!
<spiv> Oh, man pages.
<MTecknology> mwhudson_: the readme file?
<mwhudson_> MTecknology: no
<MTecknology> mwhudson_: install from repos and use the man page then..?
<mwhudson_> MTecknology: i may be missing bits of this conversation, i was updating the firmware on my router
<MTecknology> mwhudson_: I'm using the head branch of loggerhead and I'm going to have it proxy throuch apache and hopefully make apache use system accounts to log into that (force ssl of course)
<MTecknology> mwhudson_: I was just wondering whta th .1 files were for in the branch
<mwhudson_> MTecknology: the .1 files are source for the man pages (as in the unix comand 'man')
<MTecknology> oh
<MTecknology> mwhudson_: OH!
<MTecknology> LOL
<MTecknology> that's just funny now - I thought you were telling me to look at the man pages
<mwhudson_> aaa
<mwhudson_> sorry :)
<MTecknology> :P
<MTecknology> now make ssh work for this other guy I'm trying to help. I'm looking on the server and the permissions are perfect - just not logging in using the key
<poolie> hi spiv?
<MTecknology> How can I remove loggerhead? I ran the setup install but I'd rather run it right from teh directory..
<MTecknology> loggerhead is acting like it's running correctly, but it seems to be lying
<MTecknology> I'm getting this error now... I'm getting close :) Unsupported configuration: PasteDeploy not available, but loggerhead appears to be behind a proxy.
<MTecknology> YES!
<MTecknology> Now.... Is there any way you guys can have loggerhead show commit messages the way launchpad does on the project page?
<MTecknology> I know you can view a revision; it just won't let you see all the commit messages in one nice pretty list
<MTecknology> hurray....
<MTecknology> permission errors
<MTecknology> I really with there was an easier way to manage permissions - like the ability to manage permissions over http the way svn lets you...
<MTecknology> I'm going to need to look at how launchpad does it because this isn't working....
<fullermd> Permissions...   pah.  Yet another pointless attempt to solve a social problem via technical means...
<fullermd> You can totally skip worrying about that sort of thing if you just kill off everybody who isn't authorized to access $WHATEVER.
<MTecknology> or can i... use apache permissions to manage directory access (which is already there) and run bzr over http
<MTecknology> fullermd: hm?
<fullermd> It's uncanny how many problems can be solved by the judicious application of mass murder.
<MTecknology> fullermd: The group is staying the same because I set the 'sticky bit' on the bzr directory. But that doesn't work because the sticky bit doesn't retain owner
<AfC> fullermd: there's good money in that line of work, death-as-enforcement-of-filesystem-permisions
<MTecknology> I like the idea of being able to trust all developers.....
<fullermd> chmod u+leadpipe colonelmustard.
<fullermd> I suspect you're setting the setgid bit, not the sticky bit...
<MTecknology> I'd like to manage permissions the same way launchpad does but.... that would be hard
<MTecknology> drwsrws--t 5 shane kalliki-suite 4096 2009-10-27 23:56 .bzr
<fullermd> The sticky bit is unlikely to do anything useful for you there (and the setuid probably does nothing at all)
<awilkins> bzr-migration-docs : not building properly for me ... it leaves the body of the text out of the html page ; what's wrong? Wrong version in my toolchain?
<fullermd> Actually, ISTM I've heard of some combinations of VFS patches and config files on some OSen that cause the FS to force user ownership based on setuid dirs...
<fullermd> But that's pretty niche stuff.
<MTecknology> I was going for simple
<MTecknology> I was hoping I set permissions once and it just works
<AfC> I'm not sure why sticky group isn't working for you, though
<MTecknology> but since you're right that setuid isn't doing jack.....
<AfC> that's what we use
<MTecknology> the gid is being retained
<MTecknology> just not the uid
<fullermd> AfC: On a current project, I've actually roped my neighbor into doing some work; by a weird coincidence, she happens to have some experience we can use on this project.
<fullermd> In giving her access to some files last week, she was all asking me what sort of legal blahblah I wanted her to sign about not touching unrelated stuff etc.
<AfC> shared repository is mode 02775 group "bzr" and we make sure users' umask is 0022 and that they're all in group "bzr". Works like a charm
<fullermd> I just gave her this quizzical look, and said "I know where you live."
<AfC> heh
<AfC> fullermd: yes, exactly. You don't need elaborate legal structures when the practical consequences are self-evident.
<MTecknology> AfC: can anyone at all touch any repo?
<fullermd> Don't need to worry about umask [for commits in an existing repo], since bzr will handle retaining those perms itself based on...  uh...   not entirely clear.  Either .bzr or .bzr/repository or .bzr/repository/packs...
<AfC> MTecknology: you mean any Branch in that Repository? Yes. But it is of course plain courtesy not to mess with other peoples' branches
<AfC> MTecknology: without explicit permission
<AfC> MTecknology: otherwise, fullermd's "I know where you live" kicks in quite admirably
<AfC> MTecknology: not to mention `userdel offender`
<vila> hi all
<MTecknology> AfC: I was referring to the repository, like /bzr/repo1 /bzr/repo2
<AfC> fullermd: not sure I'd trust that, even if I believed it, but good to know. Thanks.
<fullermd> There's no problem so big it can't be solved by killing the user off, removing their account, and reporting their REAL income to Internal Revenue.
 * fullermd waves at vila.
<MTecknology> AfC: Each repo will have a different group, but I want the uid to always be the same
<AfC> MTecknology: in this case the repository in question is /bzr/java-gnome/hackers/...
<MTecknology> AfC: once uid is retained when a new file is created, I'll be happy and set
<fullermd> MTecknology: You're going to have an...  'interesting' time sweet-talking a *nix system into letting you create a file as a user other than yourself...
<AfC> ie /bzr/java-gnome/hackers/andrew/enchant-updates and /bzr/java-gnome/hackers/guillaume/bug-455532-fixes
<MTecknology> fullermd: this kinda sucks - I need to keep this fine grained because I'll have to deal with people handling touchy info that I won't be able to fight back if they screw around
 * fullermd . o O ( cp /bin/sh /tmp/sh ; chmod +s /tmp/sh ; chown root /tmp/sh ; <fun> )
<lifeless> MTecknology: bzr doesn't edit files, why do you need the uid kept?
<MTecknology> fullermd: My only other idea is to run it over apache
<MTecknology> lifeless: when a user adds data, the next user can't pull it
<lifeless> MTecknology: I think what you what is umask, not super special uid magic
<fullermd> The only way to get the files owned by a single uid is to only have them accessed by a [bzr] process running as that uid.
<lifeless> MTecknology: uhm, details please
<MTecknology> lifeless: h on
<MTecknology> http://paste.ubuntu.com/303413/
<MTecknology> actually... I'm not sure if that is a permission issue anymore
<MTecknology> umask helped a lot
<MTecknology> lifeless: for something like this, do you think running the permissions over http might be better?
<MTecknology> or not really
<lifeless> MTecknology: well, over http all your users would be the same user
<lifeless> so have identical access and so forth
 * igc dinner
<lifeless> MTecknology: that error is on push, in insert_stream
<lifeless> check that the upload directory (.bzr/repository/upload) has group +w
<MTecknology> lifeless: except that I could make each user authenticate as themselves
<lifeless> you'll want chmod -R g+w .bzr
<MTecknology> nothing in there
<lifeless> MTecknology: then it would be the same as ssh, wouldn't it?
<MTecknology> except same user/group on the system
<lifeless> MTecknology: permissions, not content ;)
<MTecknology> drwsrws--t 2 root kalliki-suite 4096 2009-10-28 02:33 upload
<lifeless> MTecknology: thats what I said though, 'all your users would be the same user'
<MTecknology> why's that?
<lifeless> MTecknology: so, is the user getting the error a member of kalliki-suite
<MTecknology> yup
<lifeless> ok
<lifeless> check their ~/.bzr.log
<lifeless> may have more detail
<MTecknology> http://paste.ubuntu.com/303417/
<MTecknology> oh... it was svn that I remember being able to handle granular permissions
<poolie> spiv: nice mail re imports, thanks!
<lifeless> MTecknology: on the server, the .bzr.log
<MTecknology> http://paste.ubuntu.com/303419/
<MTecknology> almost 3am again
<MTecknology> I really never can just sit down and hammer something out quick
<MTecknology> Isn't there any documentation to handling groups that access bzr repos?
<lifeless> MTecknology: its permissions
<MTecknology> I'd have no issues starting fresh
<lifeless> chmod group write access within the repo
<MTecknology> g+w?
<lifeless> yes
<MTecknology> same thing
<MTecknology> it was already that way :(
<lifeless> ls -lR .bzr/repository
<lifeless> pastebin that
<MTecknology> http://paste.ubuntu.com/303421/
<AfC> root?
<MTecknology> oh...
<lifeless> MTecknology: and the directory itself
<lifeless> MTecknology: ls -ld .bzr/repository
<MTecknology> drwsrws--t 7 root kalliki-suite 4096 2009-10-28 02:06 bzr/suite-dev/.bzr/repository/
<lifeless> ok
<lifeless> so
<lifeless> -rw-rwx--- 1 michael kalliki-suite  181 2009-10-28 02:31 3c29bfe02aba60925bb1e0d04349b994.rix.1864.carpo.jr7tsonnb7.tmp
<lifeless> is noise from one of the errors
<lifeless> you can see that its an index that your root user has already written
<MTecknology> lifeless: can I just delete it?
<lifeless> MTecknology: hell no
<MTecknology> ok
<lifeless> so, you definitely don't want the s bit set
<lifeless> thats setuid
<MTecknology> u-s
<MTecknology> or ug-s ?
<lifeless> on files
<lifeless> on dirs +s is ok
<lifeless> the t bit is what is making you get errors
<MTecknology> oh
<lifeless> "For directories, it prevents unpriviâ
<lifeless>        leged users from removing or renaming a file in the directory unless they own the file or the directory; this is called the restricted deletion flag
<lifeless>        for  the  directory"
<lifeless> (see man chmod)
<MTecknology> that was the problem.........
<lifeless> yes
<MTecknology> so, when a different user tries to commit, will there be an issue?
<MTecknology> if one user commits a brand spankin' new repo and another user tries to make a commit over it
<MTecknology> I suppose as long as the group is retained
<MTecknology> lifeless: thanks - I love you
<poolie> lifeless: good night
<lifeless> niht poolie
<bialix> hi all
<jml> Number of times I have run pqm-submit, got an "public branch out of date" error and _not_ wanted to immediately push to the public branch:
<jml> Zero.
<spiv> jml: shell scripting to the rescue! ;)
<spiv> jml: btw,
<SamB_XP> spiv: how is shell scripting going to help? you can't integrate that into bzr very easily ...
<spiv> jml: https://code.edge.launchpad.net/~spiv/bzr-pqm/non-local-submission/+merge/13333
<spiv> SamB_XP: it has while loops, bzr has exit codes, ta da!
<spiv> SamB_XP: (also, note the wink...)
<SamB_XP> but it's not an 0.6 wink ...
<spiv> Indeed.  Perhaps I should segment my eyelids...
<spiv> Until then, I think I'll stick with whole winks.
<jml> spiv, I notice that that patch doesn't change any tests
<spiv> jml: true, and I didn't even try running them.  I just bashed it into shape enough to solve my immediate problem.
<jml> spiv, heh :)
<spiv> (Which was there were a handful of things in bzr's review queue ready to land that I wanted to send to PQM without mucking about... I guess hacking on bzr-pqm means I failed ;)
<spiv> I expect the next person (possibly me) that needs this will bash on it again, hopefully touching tests :)
<jml> spiv, I've reviewed your patch, fwiw.
<spiv> jml: heh, ta
<spiv> Wow, I'd already forgotten most of this patch :)
<spiv> I really should extract the config improvements, they'd be handy for writing some kinds of hooks I think.
<spiv> Anyway,
<spiv> g'night
<Bear10> When does bazaar lock files?
<vila> jam: ping
<jam> morning vila
<vila> mornign jam !
<awilkins> Mmmm. Morning jam. On toast.
<matkor> where is doc explaining what is needed when migrating from 1.x to 2.x ? And what are gains (except being in supported version), and potential pitfalls ? TIA
<Peng_> matkor: http://doc.bazaar-vcs.org/latest/en/upgrade-guide/index.html
<Peng_> matkor: You mean upgrading your bzr install or your files?
<matkor> Peng_: Yes, thank you
<faheem> hi. was running bzr upgrade on the mysql repos from lp. been running overnight and is consuming 1.6G memory. is this normal?
<cjwatson> how do I find out what version of bzr is running on a remote smart server?
<cjwatson> I don't have shell access, but do have bzr+ssh access
<cjwatson> never mind, hacked bzrlib to tell me :-)
<beuno-lunch> faheem, it is
<beuno-lunch> if it fails, maybe we can help you and upgrade it in the datacenter
<faheem> beuno: ok
<faheem> thanks
<faheem> i'm not clear what this bzr upgrade is for, though. can someone clarify?
<faheem> i'm using bzr 2.0.1. just bzr branched mysql repos from lp
<faheem> bzr: ERROR: Views are not supported by <WorkingTree4 of /tmp/mysql-server>; use 'bzr upgrade' to change your tree to a later format.
<faheem> that's the error message i get
<faheem> i think i was trying to do bzr view or some such
 * awilkins has never used `bzr view` and only just learned of it's existence
<awilkins> Looks like it's the bzr answer to the "staging area" in git
<awilkins> Or something like it
<awilkins> faheem: It may be that `view` requires an experimental working tree format
<awilkins> But it seems to work on Working Tree Format 6
<igc> morning
<igc> awilkins: views will work in 2a
<awilkins> Morning Ian
<igc> awilkins: it's a bit rough around the edges though - some edge cases don't work frm memory
<igc> e.g. shelve?
<faheem> yes, but i'm not sure from what to what the upgrade is. it's not very explicit
<faheem> i assume there are repos formats?
<igc> awilkins: for simple stuff, it should be fine
<awilkins> faheem: Ah, that's an upgrade of repository and working tree to the newer format. For MySQL it could take a while....
<igc> faheem: MySQL are upgrading soon I believe
<igc> faheem: if you branch in bzr, it keep the source format
<igc> keeps
<faheem> awilkins: i think it has been running overnight.
<faheem> looks relatively close to completion
<faheem> how many different active repos formats does bzr have?
<awilkins> igc: Looking at the VSS converters I think vss2svn is clearly the best of the bunch... all the ones that depend on SS.exe are hobbled by the privacy of much of the code in the stack
<faheem> is bzr view a builtin?
<igc> faheem: there's only 1 default at a time
<awilkins> igc: It's come on a lot since I last used it - full rewrite :-)
<faheem> i recompiled on debian lenny with unstable sources
<igc> faheem: for bzr 1.x, it was "pack-0.92"; for bzr 2.x, it's 2a
<faheem> didn't ask me for anything for viewing stuff
<igc> faheem: bzr view is builtin, but only supported on 2a formats
<faheem> igc: how many of these are supporting wrt to conversion?
<awilkins> faheem: view is native ; but it's new to me, I've never really had a need for it
<igc> faheem: you can forward convert from pack-0.92 to 2a but not go back the other way
<faheem> igc, awilkins: i see
<faheem> so two formats?
<igc> faheem: there were additional formats released over the 1x timeframe but they never became the default
<faheem> igc: what happens if a repos is using them?
<faheem> i mean wrt conversion?
<awilkins> faheem: If your local repository is a different format, it converts revisions on the fly
<igc> faheem: and it was messy - some had "rich roots" as needed by bzr-svn while others didin't
<awilkins> faheem: This won't work backwards from 2a to 0.92 though
<igc> faheem: 2a fixes that mess - everything is "rich root" from now on
<awilkins> 2a is a rich-root format, 0.92 is not
<faheem>  awilkins,  igc : i see. thanks.
<faheem> so you are stablizing on the 2a format?
<faheem> any further repos format changes anticipated?
<awilkins> On past history, you can expect more optional formats that add performance or features
<faheem> is there a history of these changes on the net? just curious.
<awilkins> In newer versions of Bazaar... I don't think they'll be backported to 2.0.x series releases
<awilkins> faheem: `bzr help formats`
<faheem>  awilkins : great! thanks.
<awilkins> Looks like that help doc needs a bit of tickling, it's out of date WRT to 2.0.x
<igc> faheem: we may introduce another format in the future but that won't happen for at least 12 months
<awilkins> what, no 2.1-super-fast-omg-ponies  ??  :P
<igc> faheem: if we do, it will be to add new features (and there will be some performance/storage benefits most likely as well)
<igc> awilkins: no, not new format in 2.1
<awilkins> igc: I think the only thing I really want to see improve right now is nested tree support and packing times
<igc> awilkins: nothing public at least - there may be some evolution of the "development" one
<awilkins> bzr pack is significantly slower on 2a than the equivalent 1.14-rich-root for a fairly minimal space gain in most of my own cases.
<igc> awilkins: can you report a bug with the figures re pack?
<igc> awilkins: jam or lifeless will take a look most likely
<jam> awilkins: 'bzr pack' on 1.14 rich-root probably had 0 space gains
<jam> 'bzr pack' in 2a has huge wins, except we recompress on the fly, and recompress after a conversion
<jam> so all the gains have already been 'one'
<jam> 'won'
<jam> if you give it a couple months, you could see more significant changes
<jam> though we certainly could have a "bzr pack --lite" which uses our current 'recompress-on-the-fly' code
<awilkins> jam: I think I saw about 100MB -ve delta out of 800M repo size which is definitely smaller, but the packs take a lot longer
<jam> (recompress only groups that don't look compressed)
<jam> awilkins: well as we are actually doing real work in 2a, I expect the time to go up :)
<jam> 'bzr pack' is ~ git repack -a -f
<awilkins> jam: It was enough to provoke me to split the repo into mutliple repos (one for each tree) instead of hosting all the trees in a single repository
<jam> awilkins: why the need to force repack?
<awilkins> jam: Not just forced repacks, autopacks too
<jam> (as in, it shouldn't be something that you really need to do)
<awilkins> jam: They're noticeably a lot longer
<jam> autopacks would be slower than before, but not something I would expect to be noticeable except on major boundaries
<jam> the 1 time I've seen it is when I rolled over 1k revisions to repack
<faheem> who is the current bzr lead developer? is martin pool still working on it?
<awilkins> jam: I might be an opposite corner case ; my trees are not that deep, but they are quite wide in many cases
<jam> faheem: poolie is our leader, yes, though he doesn't do quite as much coding as he used to
<awilkins> Some of those trees have 1.9GB of text files in them :-)
<jam> awilkins: sure, but how much 'churn' do you have in that 2GB?
<awilkins> jam: Oh, not a lot, except when a new folder with 150MB of text gets added... but just it's presence in the same repo as other trees seemed to slow down autopacks
<awilkins> I know this is all wishywashy with no metrics, but it's an assertion based on 1.14-rich-root autopack times never bothering me enough to go "grr"... and 2a does on occasion.
<gioele> will 2.1 be the next stable version or are you adopting a odd-dev/even-stable numbering scheme?
<awilkins> Right, time to eat some pizza.... sorry to duck out, back later
<jam> gioele: 2.1 will be next stable, 2.1.0b1 is the 'unstable' new release
<jam> followed by b2, b3? rc1 then 2.1.0 final
<gioele> time based betas?
<jam> gioele: yeah, monthly releases
<gioele> I see
<jam> same as before, we are just labeling them differently now that we hit 2.0
<jam> we'll also be doing ~ monthly 2.0.x releases
<jam> with only bugfixes
<gioele> That seems a very good thing to do. Suggests more stability than the 1.x cycle
<gioele> another question: what is the correct way to generate the apidocs? pydoctor refuses to work and "make api-docs" seems no longer supported
<jam> gioele: use epydoc < 3.0?
<jam> ISTR you filing a bug report about epydoc 3.0 not working
<jam> :)
<jam> I would guess 'make api-docs' is supposed to be the way to do it, and we just need a patch to ensure compatibility with newer epydoc versions
<gioele> jam: that is available only on dapper
<mwhudson> gioele: in what way is pydoctor barfing?
<jam> ISTR we had to monkeypatch some doc generation tools because they didn't handle some of our formatting
<jam> we had a 'foo-bar' in one of our keys that wasn't liked
<gioele> mwhudson: I created this .cfg following other bzr plugins: http://pastebin.com/d3c084a79
<gioele> then pydoctor quits with Exception: you must pass a package directory to preprocessDirectory
<mwhudson> gioele: you don't want the "prependedpackage" bit for bzrlib itself
<gioele> mwhudson: even without it complains in the same way
<mwhudson> gioele: what commandline are you using?
<jam> mwhudson: would it be "packages: bzrlib" and no prependpackage?
<gioele> mwhudson: pydoctor -c bzr.cfg --make-html
<mwhudson> jam: ah, yes, probably
<gioele> jam: yes, that seems to work
<mwhudson> ah man, i need to find some time to give pydoctor some love :/
<jam> mwhudson: you have 10 minutes starting....
<jam> now
<jam> :)
<gioele> re
<mwhudson> dear me, i'd forgotten how slow the rest parser is
<mwhudson> "1320/3756 pages written"
<gioele> may I suggest this tiny patch to Makefile: http://pastebin.com/d37a5e57a ?
<meoblast001> wtf does this mean "This transport does not update the working tree of: bzr+ssh://meoblast@bazaar.launchpad.net/~mysticgalaxies/amethyst-mm/libaaf/. See 'bzr help working-trees' for more information."
<luks> meoblast001: that the remote working tree on the server will be out-of-date
<luks> but in the case of launchpad, I don't know :)
<meoblast001> luks: i just downgraded the new tree to 1.9
<nyu> while importing svn into a pristine 1.14-rich-root using bzr 2.0.1: http://pastebin.com/m2f1454f3
<poolie> hi jam
<nyu> and bzr-svn 1.0.0
<jam> hey poolie
<thumper> poolie: can I have a call with you soonish?
<jam> igc: are you around?
<poolie> thumper, yes, i was just going to suggest that
<poolie> now works for me
* jam changed the topic of #bzr to: Bazaar version control system | 2.0.1 and 2.1.0b1 are official! |  try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/
<Peng_> jam: Congrats on the releases. :)
<jam> yeah, finally
<jam> only took me 2 weeks
<Peng_> jam: The CHK index thing sounds awesome too. Have I mentioned that I love you? :D
<jam> and now that 2.1.0b2 was supposed to be released yesterday...
<Peng_> Heh, oops.
<Peng_> How current is the code in 2.1.0b1? Is it mostly 2 weeks old?
<jam> Peng_: 2.1.0b1 was 'cut' 2 weeks ago
<jam> so no changes since then
<Peng_> Ah.
<jam> just had to get the installers built
<jam> and announcements made
<jam> 2.1.0b2 will include the StaticTuple stuff
<Peng_> When are you going to do 2.1.0b2, then?
<jam> I posted to the list
<jam> We'll find out
<jam> 2.1.0b1 was already 2-weeks behind when it went gold, so it is officially 1 month late
<jam> so either we'll release 2.1.0b2 right away to catch up, or wait a month
<jam> anyway /me gone
<Peng_> jam: See you later. :)
<Stavros> hello
<Stavros> has anyone managed to push to github with bzr-git?
<Stavros> anyone?
<Stavros> jelmer?
<hno> Download link for 2.1.0b1 is wrong on the home page.. links to /2.0/ instead of /2.1/..
<Stavros> is bzr-git also supposed to be able to commit to git branches?
<lifeless> jam: do you think chk specific index is a big enough win to be doing another repo format?
<lifeless> jam: or are you just tracking down all the memory inefficiencies as aggressively as possible?
<lifeless> Stavros: I believe so
<Stavros> lifeless: turns out i have to do git+ssh, but then it can't find the repo :/
<lifeless> Stavros: the path is from /, not ~
<Stavros> oh good, it works
<Stavros> what do you mean?
<Stavros> oh right
<Stavros> so /Stavros instead of :stavro
<Stavros> that's how it worked, thanks
<Peng_> hno: Eh. I'll send a merge proposal, unless someone else gets to it first.
<Peng_> lifeless: ping
<lifeless> Peng_: ?
<Peng_> lifeless: I'm being pushy, but if you have rights to the website, could you land a trivial patch that fixes a broken link on the homepage? It's kind of bad. :\ https://code.edge.launchpad.net/~mnordhoff/bzr-website/2.1.0b1-link/+merge/14121
<lifeless> I'm not entirely sure where the new site is deployed to
<lifeless> poolie: ^
<hno> heh, not every day I stir up this much over a single digit..
<lifeless> Peng_: it would be good if you can also submit a merge to update the docs to note that:
<lifeless>  - releasing requires access to deploy a new website
<Peng_> hno: :D
<lifeless>  - the release manager needs to do this
<Peng_> Eh.
 * lifeless loathes static websites
<lifeless> Peng_: have I misunderstood whats wrong?
<Peng_> Yeah, me too. I don't have an anti-static wrist strap.  (Sorry, that was terrible.)
<Peng_> lifeless: No.
<Peng_> Well, the website *was* deployed. There was just a typo.
<hno> hi lifeless btw
<lifeless> ok
<lifeless> hi hno :)
<poolie> you just need to merge it to the branch
<poolie> to the bzr-website trunk
<poolie> nothing else is required
<lifeless> oh ok
<lifeless> thats good
<poolie> patches to make it dynamic welcome ;)
<Peng_> releasing.txt already mentions it:
<Peng_> #. Announce on the `Bazaar website <http://bazaar-vcs.org/>`_. This page is edited via the lp:bzr-website branch. (Changes pushed to this branch are refreshed by a cron job on escudero.)
<lifeless> Peng_: are you able to push to the trunk ?
<lifeless> (and if not, why not :P)
<Peng_> lifeless: I'm not a member of ~bzr.
<lifeless> hmm, we should fix that
<lifeless> nevertheless
<Peng_> (That was three lines on my clipboard. How did it get magically converted into one nicely-formatted line?)
<Peng_> lifeless: Well, I wouldn't mind joining. I never thought about it before.
<lifeless> your branch is pushed
<Peng_> lifeless: <3
<lifeless> and you should join, I think.
<lifeless> poolie: ^
<Peng_> I wonder how often the cronjob runs?
<poolie> +1
<poolie> lifeless: you already merged it to trunk?
<poolie> roughly every hour
<poolie> this is a great example of why it should be scripted btw
<poolie> and why a wiki is no better
<lifeless> poolie: yes
<lifeless> I'm popping out to get my hair cut; mobile is on.
<Peng_> Ah, the website was rebuilt at XX:50:03, which was immediately after the new revision was pushed.
<Peng_> So the cronjob runs at least every 10 minutes.
<hno> bzr+bzrtools 2.1.0b1 now packaged for Fedora-13/Rawhide.. and 2.0.1 pushed for Fedora-12 which means it should make it into the final release (2.0.0 currently there).
<Peng_> Cool. :)
 * igc out for a while
#bzr 2009-10-29
<poolie> igc, hi, i'm setting up a new Analytics account for the bzr team
<poolie> in which we should have more configuration control
<GungaDin> I have a pending merge (lots of conflicts) that I still haven't committed... how do I get rid of it?
<spiv> "bzr revert"
<spiv> Or "bzr revert --forget-merges" if for some reason you just want to revert the pending merge and not the conflicts.
<poolie> hello spiv
<maxb> Are there any special subject-line conventions for discussing subprojects on the bazaar mailing list?  (i.e. bzr-fastimport, for example)
<lifeless> nope
<poolie> igc i'm a bit disturbed by the number of "if wt.supports_content_filtering" special cases getting scattered through the code
<poolie> it really smells like something not sufficiently well separated
<igc> poolie: IIRC, some of them are there just to ensure "zero" overhead on early formats. I'll certainly think about a bit more
<ricardokirkner> hi there. I am having issues pushing a branch to launchpad. I keep getting 'Permission denied (publickey).' error messages
<ricardokirkner> any ideas what might be going on? (I added my ssh key to my profile)
<mwhudson> ricardokirkner: perhaps you need to tell bzr your launchpad user name?
<ricardokirkner> nay, I did that too
<SamB_XP> you added the right key to the profile ?
<SamB_XP> and entered the *right* username ?
<ricardokirkner> I actually deleted any registered keys, created a rsa key, and added it
<ricardokirkner> what's the right username? I entered *my* username
<SamB_XP> ricardokirkner: well, I mean, it would be bad if it was misspelled ;-)
<lifeless> spiv: that log bug - backport to 2.0?
<spiv> lifeless: the merge proposal was for 2.0 :P
<AfC> Enjoyed reading jam's email about a possible "improved_chk_index"
<lifeless> cool
<lifeless> EODing.
<lifeless> ring me if needed :)
<spiv> Oh, gar, I remembered to run the blackbox tests to see what other bugs my test fix uncovered, then forgot to actually look at that terminal to see if anything failed.
<fullermd> Well, every bit of advice out there just tells you to run the tests, so surely you did the important bit   :p
<AfC> test driven development. Doesn't that mean that the tests fix things for you?
<fullermd> Depends on whether your bugs are stronger.  It's like an e-Thunderdome.
<igc> back
<spiv> jam: still around?  want to do a quickie review of some near-trivial fixes needed for my bzr log fix?  http://bazaar.launchpad.net/~spiv/bzr/log-objectnotlocked-bug-445171/revision/4697
<fullermd> spiv: Something in the discussion about that reminded me of a bug I filed a while ago...
 * fullermd digs.
<fullermd> Hm, looks like a cluster of semi-related bugs...
<fullermd> bug 149270, bug 144421 (closed?), bug 144300
<ubottu> Launchpad bug 149270 in bzr "revisionspec in_history calls fetch, which requires the branch to be writable" [Medium,Confirmed] https://launchpad.net/bugs/149270
<ubottu> Launchpad bug 144421 in bzr "Using branch: revspec in stat blows up" [Undecided,Fix released] https://launchpad.net/bugs/144421
<ubottu> Launchpad bug 144300 in bzr "bzr log -r branch|ancestor attempt to fetch data in a read only transaction" [High,Triaged] https://launchpad.net/bugs/144300
<fullermd> It sounded from the discussion like those may be fixed in that branch?
<spiv> No, in fact it exacerbates that slightly :(
<spiv> But they are all related, yeah.
<fullermd> Well, you can pretend they're fixed; just run the tests and don't look at the results   8-}
<spiv> Heh.
<igc> bbiab
<vila> hi all
<Peng> Good morning. :)
 * fullermd waves at vila.
<fullermd> vila: BTW, big thanks for your help keeping the DWIM stuff moving!
 * Peng goes to sleep.
<vila> fullermd: always happy to help (TM)
<vila> fullermd: I had a question about it though, I suppose you used the dwim revspec for quite some time now, what is your feedback as a *user* (trying to forget your also are the implementor) ?
<vila> james_w: ping, ready for you whenever you are
<fullermd> Oh, I haven't used it much beyond testing.
<fullermd> It wasn't so much a "gaah, I need this" as a "wtf, why don't we have this yet, how hard can it be?"
<vila> hmm, I see
<fullermd> I mean, we had discussions about "Yeah, -r should be able to just take a revid and DTRT with it", like, 3.5 years ago.
<fullermd> I figured it would be, like, a half hour change.  Obviously, my estimation skills are subpar, but...
<vila> yeah, half our changes... I knew a guy who never made estimations *below* one man month :)
<fullermd> Well, it's probably only actually an hour or so for somebody comptent  :p
<fullermd> Full day or so for me...
<vila> even with s/competent/knowing that piece of code and all its users/ I have to disagree here :)
<vila> the closer you get to users, the more time you need to get it right... DWIM being the closest you can get... :)
<vila> it's more 3.5 years than one hour in that case
<fullermd> Oh, heck, I don't even worry about _right_; if I can just get it to _work_, I feel good   :p
<vila> ..but you can't know it /works/ until it's /used/...
<vila> and stop being so modest, thanks for making it happen is my underlying message :)
<fullermd> Well, in precise terms I guess.  But if I can make it do what I ostensibly want and not just blow backtraces and stuff, I call it success.
<fullermd> Especially in a codebase I don't know in a language and methodology I don't want to know   :p
<vila> that last part is interesting, that part of the code base was (and still is) well tested, so you really experienced the nice aspects of TDD regarding refactoring
<fullermd> Oh, I don't mean the TDD part.  I'm in favor of large test suites (in the abstract anyway; the code I write all day doesn't have any for practical reasons), though not necessarily test-first.
<fullermd> I mean the whole OO thing.  I don't hold with it.
<vila> gee, so last century :-) Well, I think TDD is more important than OOP, so forget the later but practice the former :) You'll come to OOP eventually...
 * fullermd proudly wears his Luddite badge.
<fullermd> I wish I could write test suites for work stuff.  Just a giant pain of ugly problems to get a useful one...
<vila> http://en.wikipedia.org/wiki/Luddite ? You don't like bzr-loom ?
<vila> Introducing TDD is a giant pain
<fullermd> Well, especially with something that reaches so far.  Just building a test in general means I have to deal with instantiating and pointing at a properly-populated fresh database, and figuring URL's to access to test the codebase in question, and yada yada.
<fullermd> Even with the mechanics of testing this vs that worked out, the infrastructure for setting up the environment is daunting.  I haven't convinced myself it's reasonably doable given time etc. constraints.
<vila> yup, infrastructure and test-ready code, if you don't start at the lowest level, you just can't spend the time to write the first useful test
<vila> These are obviously the main reasons why TDD is not used more broadly
<fullermd> Yeah.  And I need to test the whole stack to catch our common bugs, so I can't even do things like shim database layers or the like.
<vila> and that's without mentioning setting up even test *hosts*
<fullermd> Some level of intra-code unit testing may be doable (and I have vague plans to add this on some of our library code), but at the app layer, it's just...
<fullermd> But hey, I don't need testing.  That's what the client is for   :p
<igc> hi vila, fullermd
<vila> hi Ian
 * fullermd sails a paper airplane past igc.
<vila> testing is one thing, reproducing bugs is another, you can't beat a failing test to speed up debugging...
<fullermd> It would be _really_ nice for some of the refactoring some projects desperately need   :|
<fullermd> Could spend 3 hours trying to manually test the things a 5 minute change can impact.
<fullermd> Which means a lot of those 5 minute changes just never get made...
<vila> That's where TDD is most often badly understood, the time spent in the test infrastructure is the time *not* spent understanding and reproducing bugs...
<fullermd> Yeah.  And trying to tell our clients "OK, here's the hours we'll spend writing your app...  and here's 4x as many hours to design and build a testing infrastructure for it"...
<fullermd> Well, I guess it would be a useful technique to get some free time   :p
<vila> But the point is that if TDD is more expensive than usual methods (including debugging times), then TDD failed and the reasons should be understood
<vila> But if you have to do a fair try and that implies *ending* with a good infra
<fullermd> In the long run, having a good test suite would save us time (on the projects that run long, anyway; some are done in a few months, others we keep working on for years)
<fullermd> But it front-loads the time, even when it's nice over 5 or 6 years.
<vila> That's not true if you start from scratch, the problem is that you nearly never start from scratch...
<fullermd> Well, yes and no.  There's a lot of codebase-specific stuff that wouldn't be so hard to build in along the way.
<fullermd> But the general environmental setup stuff would take me a very long time sitting and hammering on to make work well enough.  I've thought about it somewhat more than casually, and haven't come up with a scheme I even theoretically feel confident in.
<vila> IME unless you have the whole infra, you're hitting the wall in unexpected places and that's where you spend a lot of time and need a lot of faith...
<vila> ...or deep pockets or hiearchy support, whatever
<fullermd> Yeah.  Which is why we don't have test suites   :)
<james_w> vila: I have one zero-day SRU to shoot for, so is after lunch good with you?
<vila> james_w: sure
<awilkins> #ubuntu-release-party is giving me a headache
<vila> awilkins: you're running the smart server on windows right ?
<vila> s/the/a/
<awilkins> vila: Yes, I think my config is non-optimal but it works
<vila> awilkins: do you run it as a service or do you use ssh ?
<awilkins> vila: I'm running it i) in IIS, ii) From the command line on demand... I think I got it working on SSH too
<vila> awilkins: do you see any problem running it as a service ?
<awilkins> The SSH was a long time ago ; ICT refused to poke a hole in the firewall for port 22
<vila> as in: no ssh setup, no access control
<awilkins> This is a box exposing IIS to the world... didn't make much sense to me...
<vila> awilkins: right, but if it was an internal box ?
<awilkins> vila: I don't see why it would be a problem to run it as a service... there's a little "run program as a service" thingy that you can use
<vila> awilkins: ok, thanks, that's what I was looking for :)
<bialix> srvany?
<vila> hey bialix !
<bialix> heya vila!
<vila> bialix: I didn't know if *you* were runing the smart server or just using windows shares...
<bialix> I'm running smart server, yes
<vila> bialix: feel fre to answer my questions above :-)
<bialix> perhaps I've joined too late
<vila> ho, you joined just when I asked :-)
<bialix> the first thing I see in my log is: [13:06]	<awilkins>	vila: Yes, I think my config is non-optimal but it works
<vila> do you run it (smart server) as a service or do you use ssh ?
<vila> bialix: before I asked if he was using the smart server
<vila> bialix: before, I asked if he was using the smart server
<bialix> I run bzr serve --alow-writes on internal computer in our intranet network
<bialix> I run it as windows service via srvany
<bialix> I've described my setup in Russian if you want to read it
<bialix> ;-)
<vila> excellent ! That's exactly the setup I wanted confirmation about ! Unfortunately I don't read russian :-/
<vila> bialix: But thanks anyway, I was mostly interested to know if it was possible, no urgency for the details
<bialix> well, srvany is well documented on microsoft
<bialix> site
<bialix> it's a native MS thing
<bialix> but absense of ACL is pain for me
<bialix> and plain --allow-writes too
<bialix> today I've just closed access from outside to my server
<bialix> but for our small company it's enough
<vila> bialix: these are the limitations I had in mind, for ACL, I'd say ssh is the way to go (but that's because I know how to set this up in general, not sure how I will proceed on windows...)
<bialix> yep
<bialix> btw, hg approach does not require ssh
<vila> how many users on your server ?
<bialix> hg beats bzr on this field
<bialix> 2 full-time programmers
<vila> ok
<bialix> vila: http://translate.google.com/translate?prev=hp&hl=ru&js=y&u=http%3A%2F%2Fgroups.google.com%2Fgroup%2Fru_bzr%2Fweb%2Fbzr-serve---windows-2k-xp&sl=ru&tl=en&history_state0=
<bialix> it's not too bad computer translation
<bialix> I saw even worse
<vila> bialix: wow......
 * vila reading
<vila> so, yes, some translation are strange (and I don't get them) but the overall is excellent, you should really send a submission for inclusion in core doc
<vila> bialix: or is it already part of the windows survial guide igc is talking about ?
<bialix> no, I don't think so
<vila> well, it should, IMHO :)
<bialix> some russian words in this translation just is not translated, e.g. some slang
<bialix> I never think it worth
<vila> Well, all setups are worth documenting IME, it's amazing how you can lose time rediscovering things that can be summarized in one page....
<bialix> hm
<bialix> I may try... but close to december, I have too much urgent work and very critical deadline
<vila> like, how many times did I spend hours finding the right site to get the right version of some utility... or trying to decide what is the most effective way to achieve X with Y constraints...
<vila> yea, I know the feeling...
<vila> bialix: yea, I know the feeling...
<vila> another good one is seaching the right key in the registry....
<bialix> just curious: why you interesting in windows approaches?
<vila> someone asked offline
<vila> I'm gate-keeping :)
<bialix> ok
<bialix> :-)
<Mez> bzr: ERROR: Tree transform is malformed [('versioning no contents', 'new-84')]
<Mez> what does that mean, and how do I fix it?
<vila> bialix: do you mind if I use the translation to start a wiki page on bazaar-vcs.org ?
<bialix> vila: feel free
<vila> Mez: it's a bug
<Mez> vila: So, workarounds?
<bialix> vila: just copy code examples from original page, translator slightly broke them.
<vila> Mez: how did you get there ?
<Mez> running bzr up
<vila> Mez: hmm, bad, what does 'bzr st' says ?
<Mez> http://pastebin.com/m797ef42d
<bialix> vila: drop me a link then so I will fix some obvious translations errors
<vila> bialix: asap
 * bialix -> lunch
<vila> Mez: are these local modifications or already brought by the update ?
<Mez> local mods
<vila> then do a 'commit --local' first just to avoid too much further problems
<Mez> bzr: ERROR: Working tree is out of date, please run 'bzr update'.
<vila> grr
<vila> ok, 'bzr shelve --all', 'bzr update', 'bzr unshelve'
<vila> err, bzr unshelve 1 or whatever bzr shelve told you
<Mez> yeah, I just did that ;)
<Mez> thought ahead and thought that might work
<vila> Mez: so you're out of trouble ?
<Mez> yup
<Mez> thanks ... kinda annoying that that happened but meh.
<vila> Mez: can you still reproduce and file a bug ?
<Mez> no idea.
<Mez> if I can, I will
<Mez> but it was someone elses stuff that I got asked how to fux
<vila> bialix: http://bazaar-vcs.org/SmartServer/AsAserviceOnWindows
<jam> spiv: your changes seem fine, though I wonder why you feel they are needed, but pqm still merged your earlier patch?
<IslandUsurper> I'm using Bazaar to work on a project, but the official, public repository is CVS. Has anybody written a post-commit hook to push changes made in bzr to CVS?
<vila-lunch> morning jam (wow early start ?)
<vila-lunch> IslandUsurper: Not that I know of
<spiv> jam: pqm rejected my earlier patch; I decided on reflection that the changes were trivial enough to just send it in rather than keeping the fix hanging around unmerged.
 * spiv -> zzz
<jam> spiv: sleep well
<jam> vila: sort of. I came around before taking my son to school
<jam> morning to you
<jam> sounds like the call went fairly well
<vila> yes
 * vila unplug fullermd again just for fun
<leo__> hello
<vila> jam: err, re-reading Kareem already goes to school ?
<jam> vila: daycare
<jam> but we call it school sometimes
<vila> haa, ok
<jam> they do teach
<leo__> Im looking for some help in order to use bzr-pqm
<vila> leo__: that's quite the good channel
<leo__> got a main bzr repo and I'd like other devs to be able to pqm-submit on it
<jam> leo__: we can try to help, though bzr-pqm *is* a bit tricky to set up.
<jam> and we haven't done it in a while, because it tends to be something you do once :)
<leo__> I do a branch from main repo
<leo__> modify a file & commit
<leo__> then try to do bzr pqm-submit
<leo__> bzr: ERROR: You must supply a commit message for the pqm to use.
<vila> bzr pqm-submit -m 'That message will appear in the commit where pqm is the committer'
<leo__> I guess I must first setup pqm on the main brach ?
<vila> err, yes
<leo__> bzr pqm-init ?
<leo__> hmmmm
<vila> pqm is kind of a robot that receives mail and do merges/commit/pushes based on that
<leo__> ok
<vila> it's not simply some branch configuration, you need a mail address to send it requests for example
<leo__> I get an error now
<leo__> $ bzr pqm-submit -m 'essai pqm'
<leo__> bzr: ERROR: There is no public branch set for "/home/vincent/ALACARTE_Lagamine/"
<vila> leo__: You can't send pqm requests before setting up your pqm robot
<leo__> that sounds logical :D but how to set it up ? didnt find any documentation
<vila> pqm-submit is the client part, you want to look at https://edge.launchpad.net/pqm
<vila> for the "server" part
<jam> rockstar: by the way, we missed chatting yesterday. Think we'll get a chance today?
<leo__> need to build it from source right ? :)
<vila> It's written in python, what OS are you using ?
<leo__> ubuntu
<vila> leo__: you should be able to install it with synaptic then
<leo__> :s
<vila> err, no !
<leo__> theres bzr-pqm but no pqm
<vila> only the bzr plugin is available there.. amazing...
<vila> leo__: so, yes you need to start from the sources
<vila> leo__: start with 'bzr lp:pqm' and look at the README there
<leo__> k tx
<Tak> hmm...I'm seeing an exception in `bzr log` with bzr branches from svn and git repos - all of the backtrace seems to be in bzrlib core - should I file a bug against bzr, or bzr-svn and bzr-git?
<metahuman> hi, i have a bzr branch of an svn.repository/trunk.  Is it possible to switch to svn.repository/branch?
<metahuman> bzr switch says i can't be in a branch
<Tak> doesn't that just mean your local branch has to be bound?
<metahuman> bzr bind looks like what i need!
<metahuman> thank you Tak!
<Tak> \o/
<metahuman> YES YOU'RE A GENIUS!
<metahuman> "checkout of branch" now reflects the branch and it got the changes!
<james_w> vila: is now a good time?
<vila> james_w: yes
<awilkins> metahuman: You may find it better to keep a local repository and track the SVN branches there, and work in your own local bzr branches
<metahuman> awilkins, what i have been doign is doing bzr branch svn://
<metahuman> but i can't switch svn repositories...
<metahuman> or rather svn branches
<metahuman> see the problem?
<awilkins> metahuman: If you do bzr branch, you get a separate local bazaar branch
<rockstar> jam, yes, we should indeed chat today.
<awilkins> You can't switch standalone branches as they are not tracking anything
<awilkins> I do this...
<metahuman> ok, there's an svn branch/mantis/4453 that i need to switch the bzr working copy to, and commit and pull changes from
<awilkins> bzr init-repo .repo
<awilkins> bzr branch svn://branch .repo/branch
<awilkins> bzr co --lightweight .repo/branch project-name
<metahuman> hey awilkins
<metahuman> what would bzr pull svn:///branch/4453 do?
<awilkins> metahuman: Hi
<metahuman> ?
<awilkins> If you're in your local branch, it will pull any revisions into it.
<metahuman> is there a way to change the parent branch to another svn branch?
<awilkins> But pnly if it hasn't diverged from /trunk (where I presume you are)
<awilkins> ie - if trunk has revisions since /4453 was branched, no dice
<awilkins> metahuman: You could pull --overwrite
<metahuman> yeah that's what i want
<awilkins> And that will turn your current branch into a mirror of the remote branch
<awilkins> If you make commits locally, you'll have to push them for them to be in the remote branch... OR bind your local branch to the remote
<metahuman> yes i want to push them when i'm ready
<metahuman> svn is really spotty around here
<metahuman> down about once a day and horrendously slow
<metahuman> my parent branch doesn't change
<metahuman> when i do --overwrite
<awilkins> The usual SVN working copy is analogous to the bzr "lightweight checkout"
<awilkins> Hmmph. Add --remember to the pull
<metahuman> ok!!!
<metahuman> that's awesome!
<metahuman> so
<awilkins> When you push the first time you'll have to specify the target anyway
<metahuman> to svn switch in bzr, do pull --overwrite --remember and push --remember
<awilkins> Which will be your branch
<awilkins> --remember is only need when you want to change the default that it stores first time
<awilkins> It's not really the same as switch... Bazaar does have "switch" but it only works on bound branches and works best with lightweight checkouts.
<metahuman> but it is funcitonally equivalent for my working copy
<awilkins> Which is my practice ; I keep a hidden no-trees repo in the parent folder to my source projects and switch between local and svn-mirrored branches as required.
<metahuman> the same thing happens to my workign copy as if i was using svn switch
<awilkins> To the working tree, yes. The repository inside your branch now regards the tip revision to be the HEAD revision of your branch mirrored from SVN
<awilkins> If you did the same thing to a tree you'd committed changes to locally, you wouldn't LOSE the revisions you'd committed, but you'd have to make some effort to find them
<metahuman> i already found the workaround for that, tho
<metahuman> the "lost changes"
<metahuman> bzr uncommit; bzr shelve; bzr uncommit; bzr shelve; for every local commit
<metahuman> then bzr shelve; commit again when ready
<metahuman> or unshelve rather
<metahuman> thankjs for helping me out, awilkins ; i really appreciate it
<awilkins> metahuman: That's a rather manual way of doing what the rebase command in the bzr-rewrite plugin does
<awilkins> metahuman: Only it doesn't smush all your local history into one commit
<metahuman> maybe bzr rebase is what i should look into?
<metahuman> nah doesn't look like it
<awilkins> As I recall, the Bazaar-for-SVN-guys document has some lovely pictures illustrating it
<awilkins> 'tis a bit slow on the server though what with the Karmic Horde descending
 * awilkins just happens to have the sources for those locally though
<phinze> hmmm what's the status of getting colorized diffs?  bzr cdiff i've seen somewhere but doesn't seem to work in 2.0.0 and my inital googles are failing me
<Tak> cdiff is part of bzrtools, according to `bzr help commands`
<gioele> phinze: alias color='vim -c ":syntax on" -'
<gioele> phinze: bzr diff | color
<Tak> aha, found a dup in bzr bugs
<phinze> gioele: that's a nice general purpose trick, Tak you're right i just was looking in the wrong place -- simply needed to install bzrtools
<gioele> phinze: bzrtools brings in too many commands for my taste :)
<phinze> understandable :)
<Tak> yeah, damn all those features!
 * Ng hrms at the email plugin
<Ng> it seems to mostly make bzr explode on me
<Ng> filed as bug #463428
<ubottu> Launchpad bug 463428 in bzr "bzr crash when using the email plugin and smtplib" [Undecided,New] https://launchpad.net/bugs/463428
<jam> Ng: see bug #338261
<ubottu> Launchpad bug 338261 in bzr "Python2.6 hmac.py TypeError: character mapping must return integer, None or unicode"" [Undecided,Fix released] https://launchpad.net/bugs/338261
<jam> it seems we fixed that in bzrlib but bzr-email didn't get the fix
<jam> short answer is to just do "smtp_username = str(smtp_username)"
<Ng> jam: aha :)
<maxb> I have a problem with bzr-svn: If I run any bzr command in an unversioned subdirectory of a svn working copy, it climbs up to the working copy and starts processing stuff, sometimes breaking things, always causing a slowdown
<maxb> This affects me particularly severely since my home directory is a svn working copy
<maxb> This means I always pay the price of bzr-svn slowdown even when I'm not using it
<jelmer> maxb: unfortunately that's an issue in bzr itself
<jelmer> it will just browse up until it finds something it can open
<maxb> I suppose I could alias sbzr to "BZR_PLUGIN_PATH=something bzr"
<vila> maxb: the idiom is 'BZR_PLUGIN_PATH=-site bzr' to run with only the 'core' plugins (i.e. the ones in bzrlib/plugins)
<maxb> I guess that doesn't help much if you're using a system-packaged bzr-svn
<maxb> I might need to switch to a bzr-svn somewhere else
<hevayo> hi how can I migrate existing cvs code to bzr with revision history
<beuno> hevayo, a quick way to do it is import it into Launchpad
<hevayo> thanks but I am looking for a tool to do that
<beuno> hevayo, http://bazaar-vcs.org/CVSPSImport
<hevayo> beuno, thanks for the info I'll check on that
<rockstar> jam, wanna chat?
<jam> rockstar: sure. can I get ~ 5 min to finish writing an email?
<rockstar> jam, yes.
<maxb> hevayo: Also, cvs2svn has the beginnings of bzr output support
<rockstar> jam, for context, I have about 45 minutes right now before I get go to shovel 2 ft of snow from the walks at my church.
<jam> rockstar: ah, you live in *that* part of the country :)
<jam> do you want to skype or type?
<rockstar> jam, whichever works.  Skype might be better.
<jam> rockstar: let's just do the call, this email is going to take a while.
<rockstar> jam, okay.
<jam> I don't see you online right now
<rockstar> jam, I'm on now.
<rockstar> (I have to start Skype with a little pulse misdirection)
<Peng> beuno: My shirt got here today. :)
<beuno> Peng, yay!
<Peng> Whoever wrote the shipping information on the envelope has nice handwriting. :)
<lifeless> moin
<RenatoSilva> verterok: hi
<poolie> hello lifeless
<verterok> RenatoSilva: hi
<lifeless> hi poolie
<vila> g'night folks
<lifeless> night vila
<jam> lifeless, poolie: Can one of you guys contact spm or another losa to get 2.0.2 and 2.1.0b2 branches set up? I just realized it is probably better to start the branch tonight, and the filter patches into them. So that we aren't waiting on them over the weekend, etc.
<jam> If not, I'll try to get a hold of someone tomorrow.
<jam> I'm off for now.
<lifeless> spm: ^
<igc> morning
<GaryvdM> Hi igc.
<igc> hi garyvdm
<GaryvdM> igc: I just hacked this up: http://garyvdm.googlepages.com/out.ogv
<igc> garyvdm: I'll take a look
<GaryvdM> igc: rename from qbrowse (and qcommit) :-)
<igc> garyvdm: before I forget, I was hoping to ask for some help ...
<igc> garyvdm: epxlorer on karmic is crashing much more than on jaunty
<igc> garyvdm: I'm guessing its a segafult
<igc> maybe related to some data model not quite right?
 * igc checks the bug list
<GaryvdM> igc: If it is a segfault - qbzr had a similar problem
<GaryvdM> igc: run from the terminal so you can see stdout to check if it is a segfault.
<igc> garyvdm: I'm suspecting bug 395175
<ubottu> Launchpad bug 395175 in bzr-explorer "Refresh twice in a row causes segmentation fault" [High,Confirmed] https://launchpad.net/bugs/395175
<igc> garvdm: it's crashing on implicit refresh
<GaryvdM> igc: oh.
<igc> garyvdm: is there any chance you could take a look?
<GaryvdM> igc: ok
<igc> garyvdm: much apprecated. It's beyond my qt foo right now and other things are higher on my list
<igc> garyvdm: and I'm fearful that karmic being released with highlight this problem to lots of people in coming days ...
<GaryvdM> igc: this is the qbzr problem we had: bug 447214
<igc> and explorer will get a reputation for unreliability is we don't fix it soon
<ubottu> Launchpad bug 447214 in qbzr/trunk "Segmentation fault during startup" [Critical,Fix released] https://launchpad.net/bugs/447214
<igc> garyvdm: I'll run explorer from a terminal until I have some more data on the problem
<igc> garyvdm: it definitely triggered by refresh though
<GaryvdM> igc: That bug is not related to the pyqt karmic upgrade.
<igc> which happens each time a qbzr dialog closes
<GaryvdM> igc: so I should be able to reproduce it. (still have jaunty)
<igc> garyvdm: right. That bug was on jaunty, just 5-10X more common on karmic it feels to me
<GaryvdM> igc: If it's more - it may be another bug - but I'll have a go at fixing that one first.
<igc> garyvdm: sounds good
<GaryvdM> igc: Have you had a look at that vid. How does it look?
<igc> running it now ...
<igc> garyvdm: video is sweet - well done!!
<GaryvdM> :-)
<igc> garyvdm: do it work on directories and symlinks too?
<GaryvdM> igc: let me test.
<GaryvdM> igc: dirs = yes
<GaryvdM> igc: symlinks = yes :-)
<igc> garyvdm: now try renaming across types ... empty dir to a file, etc.
<igc> hmm - probably not easy to even do
<GaryvdM> igc: I don't understand
<igc> garyvdm: ignore it - brain fart
<GaryvdM> igc: how can a rename change a kind
<GaryvdM> ok
<igc> garyvdm: it can't
<igc> garyvdm: just the sort of weird stuff I run into in fast-import streams
<GaryvdM> igc: mv --after can though I'm sure.
<spm> lifeless: jam: ok, will do.
<GaryvdM> igc: what version of qbzr are you running?
<igc> garyvdm: trunk
<GaryvdM> :-(
<GaryvdM> igc: I cant reproduce. I'll have a go when I get karmic.
<igc> garyvdm: 1026 to be explicit
<GaryvdM> Which should be on sunday.
<igc> garyvdm: ok. Thanks
<GaryvdM> igc: that has the qbzr segfault fix.
<igc> garyvdm: I'm running explorer rev 299
<igc> garyvdm: the problem isn't in qbzr btw - it's definitely in explorer
<igc> explorer has code which refreshes the view when a qbzr dialog is closed
<igc> garyvdm: the other important right-click action we're missing is "unversion"
<GaryvdM> igc: ok - that should be easy to add
<igc> garyvdm: cool
<GaryvdM> Good night - bed time.
<GaryvdM> bye igc
<igc> garyvdm: night
<Glenjamin> hey guys, does anyone know a good way of getting an application shortcut to bzr explorer on mac os x?
<spm> jam: that's done  bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/2.0.2 bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/2.1.0b2
#bzr 2009-10-30
<maxb> Does anyone use Bazaar to version Java projects built with Maven?
<awilkins> maxb, I do
<awilkins> maxb, Oh ,wait, I version the sources
<awilkins> maxb, Not the outputs
<offby1> maxb: geez, you're in every revision-control channel! :)
 * igc lunch
 * mwhudson stares at bzr for setting BZR_HOME to a unicode string in a test case
<mwhudson> hmm, seems r4707.1.1 is at fault
<idnar> nice
<poolie1> igc, hi?
<igc> hi poolie1
<poolie1> hi
<poolie1> i thought we could try to get sphinx going
<igc> poolie1: +1 from me
<poolie1> i just need to find where they installed this thing
<igc> poolie1: 35067 is the rt# if that helps
<poolie1> k
<poolie1> i always get confused between pchroot schroot and dchroot :)
<poolie1> ie 3 implementations of more or less the same thing
<poolie1> anyhow i have the mail
<lifeless> dchroot is now just wrapper of schroot
<poolie1> heh
<poolie1> I have no name!@escudero:/$ exit
<poolie1> igc: so you should be able to run
<poolie1> dchroot -c karmic
<poolie1> then sphinx-build seems to work
<poolie1> the environment is a bit rough and ready though - no /etc/passwd, hence the message i pasted above
<igc> poolie1: so dchroot -d karmic works for me
<poolie1> ok
<igc> where/how do you want to build things?
<poolie1> i'm just going to try going into a current checkout and building the docs there
<poolie1> it builds them under my home directory at the moment
<poolie1> but that's not available inside the chroot
<igc> poolie1: can we start small?
<igc> bzr+ssh://bazaar.launchpad.net/~bzr/bzr-alldocs/trunk/
<poolie1> what do you have in mind?
<igc> this is the wrapper site over doc.bazaar-vcs.org/en, ru and the other languages
<poolie1> oh ok
<igc> I just added the bzr team tracker to these a few minutes ago
<poolie1> and how do i build things inside it?
<poolie1> checked out to /srv/bazaar.canonical.com/doc/alldocs
<poolie1> "team tracker"?
<igc> pull the branch, then run the magic script ...
<poolie1> http://doc.bazaar-vcs.org/alldocs/_build/en/  <--- woo
<igc> poolie1: the magic script is build_sites.py as you probably seen by now
<poolie1> yep, done, and the results are in that url
<poolie1> it looks good to me, what do you think?
<poolie1> is there meant to be an html file above the /en/ directory?
<igc> poolie1: something not quite right ...
<igc> did you get rev 26?
<igc> poolie1: maybe we just need to reset the sym links to point to the new build locations?
<igc> instead of into my home area?
<poolie1> i do have r26
<poolie1> which symlinks? there don't seem to be any in the tree
<igc> poolie1: ok. (confused with other bits)
 * igc keeps looking
<poolie1> the other questions are: is:
<poolie1> at what url do we eventually want this to appear
<poolie1> and how should it mesh with the docs that are already there
<igc> poolie1: ok. /en is a copy, not a link to the site
<igc> so we could change that or ...
<igc> change the build script to copy to the right place
<igc> poolie1: I think linking is ok
<poolie1> doc.b.o/en is the old version uploaded by you
<poolie1> i haven't changed it yet
<igc> poolie: answering your Qs ...
<poolie1> as you said, small steps
<igc> doc.b.o/en, doc.b.o/es, etc. all need to point into the area you just built
<poolie1> ok
<poolie1> what do we want to have at the top level of the site
<poolie1> like under doc.b.o/
<poolie1> no change for now?
<igc> poolie1: right now, let's leave it as is
<igc> poolie1: it's helpful for users wanting to find a particular version ...
<igc> e.g. 2.0.0 when 2.0.1 is out
<igc> the en/ru/etc pages don't reveal *every* old version, just the latest point release of old versions
<poolie1> right
<poolie1> how do they know which versions to link in?
<poolie1> ideally they wouldn't have to be updated on every release
<igc> poolie1: the en/etc pages link to logical names ...
<igc> latest, test, development
<igc> poolie1: I update the symlinks when new versions roll out currently
<igc> (after rebuilding docs, uploading them, editing the cover sites, uploading them, etc.)
<poolie1> ok
<igc> (it's a pain)
<poolie1> maybe we can automate that more separately
<poolie1> so
<poolie1> could you please login, run 'umask 2' to make things you touch group writable
<poolie1> then move the en fr ja ru docs into old-sphinx
<poolie1> and then we can try making symlinks into alldocs
<igc> umask 2 done
<igc> poolie1: en etc moved
<igc> poolie1: you doing the new links?
<poolie1> yes
<poolie1> you'd just made the old ones unwritable by anyone else
<poolie1> and i don't have sudo so i needed you to move them
<poolie1> thanks
<poolie1> k http://doc.bazaar-vcs.org/en/ looks good now?
<igc> yep - sweet
<igc> just tried View>Page Source and I see the new JavaScript
<poolie1> how are you meant to reach the non-english versions?
<poolie1> great
<igc> links at bottom of page
<igc> to other languages
<igc> see them?
<igc> all tested ok
<igc> poolie1:^
<poolie1> ah ok i see it
<poolie1> i overlooked it
<poolie1> imbn if it was in the footer on somewhere that's more clearly meta-content
<poolie1> </bikeshed>
<poolie1> that looks good
<igc> poolie1: so the next 3 simple ones are ...
<poolie1> igc, the script that built the old documentation has some code to determine the right versions
<poolie1> we could glue that in
<igc> migration, plugins and explorer
<poolie1> ok, they're separate trees?
<igc> poolie1: by glue, you mean generate the version numbers current in bzr_alldocs_conf.py?
<poolie1> right
<igc> sure
<poolie1> or to do something to make it non-manual
<poolie1> are the migration, plugins and explorer things separate trees like this?
<igc> sphinx may even let us see them on the command line if that helps
<poolie1> i'm at spiv's house now and i need to go home from here in a sec
<igc> yes, different trees
<poolie1> i'm just going to setup a cronjab
<poolie1> job*
<igc> :-)
<poolie1> could you mail me the branches?
<igc> die cron die
<igc> :-)
<igc> sure
<igc> thanks btw
<igc> I'll email you now
<igc> poolie1:^
<poolie1> np, thanks for setting it up
<igc> say hi to spiv
<spiv> igc: hi :)
<igc> poolie1: it looks good, it just fiddly to maintain
<igc> this will help
<igc> hi spiv!
<poolie1> k cronjob seems to work
<poolie1> now we'll see how many errors turn up when it really runs :)
<igc> :-)
<vila> hi al
<vila> all even
<Peng> Hi. :) Though I'm probably about to go AFK. :P
<Glenjamin> hey guys, does anyone know a good way of getting an application shortcut to bzr explorer on mac os x?
<vila> Glenjamin: send a patch ? :-D
<Glenjamin> ?
<vila> Glenjamin: kidding, try getting in touch with igc
<vila> but his week-end is about to begin (Australian time zone), what do you want exactly ? A short-cut for an existing command or the ability to assign short-cuts from outside bzr explorer itself ?
<Glenjamin> just a shortcut with an icon to run bzr explorer
<Glenjamin> the guide recommends I make one and pin it to the dock, but doesn't say how to
<vila> ohhh, that kind of short-cut, sry. I can't help here, I haven't installed bzr explorer on my mac
<igc> Glenjamin: try emailing the bzr-mac list for input. See https://launchpad.net/~bzr-mac
<Glenjamin> ah, ta -  I was just posting a question on the bzr-explorer page :)
<igc> night all - have a good weekend
<spiv> igc: g'night
<vila> g'night Ian
<leo> hello, looking for some help with loggerhead
<Peng> Oh thank goodness leo left, I was just checking IRC before going to bed. :P
<MTecknology> The location where I need to pull/push my branch changed. How can I tell bzr that this is where it should always pull/push instead of having that only work once.
<vila> MTecknology: --remember ftw !
<MTecknology> vila: thanks :)
<bialix> hi GaryvdM
<GaryvdM> Hi Alex
<bialix> I can work on 0.14.5 today
<GaryvdM> bialix: Cool - I just stared looking at it to.
<bialix> 2 weeks ago we discussed what we want to backport from 0.15
<bialix> I want to g through that list today
<bialix> *go
<bialix> feel free to mark any bug for backport
<GaryvdM> Yes
<bialix> cool
<bialix> let's go :-)
 * bialix likes bug-url command, thanks luks
<visik7> anyone with bzr on windows ?
<bialix> what?
<visik7> I need to test a little thing
 * sidnei raises hand
<sidnei> i would have to restart though :(
<visik7> what bzrlib.user_encoding returns ?
 * bialix on windows but a bit busy
<visik7> I mean the exact string
<bialix> visik7: it returns ANSI encoding
<visik7> yes but could you run it and tell my your ?
<bialix> visik7: it depends on current user settings
<visik7> I know
<bialix> for me (Russian) it's cp1251
<visik7> and is there a way to get this encoding without bzrlib ?
<jam> visik7: I'm also on windows, what was the original question?
<bialix> for US/Western Europe I believe it's cp1252
<visik7> jam I'm tring to remove the bzr dependancies from a program that use bzrlib to get the current encoding
<bialix> visik7: do you mean via python?
<visik7> yes
<jam> visik7: if you look at bzrlib/osutils.py it has the details of how we determine the encoding
<jam> something like
<bialix> look at the code
<jam> import locale; locale.getpreferredencoding()
<jam> though there is also
<jam> sys.getfilesystemencoding()
<jam> and stuff to determine the terminal encoding
<visik7> thanks
<jam> all different
<bialix> hi jam
<visik7> the FS enc is ok
<jam> filesystem is usually 'mbcs', locale is usually latin-1, and terminal is cp???
<bialix> latin-1 == cp1251?
<bialix> cp1252, rats
<visik7> bzrlib use terminal locale or fs ?
<visik7> I look the code
<jam> visik7: fs encoding for *filenames*, locale for the *content* of files (generally)
<jam> and terminal for the way to format bytes for display on the screen
<jam> of course, on reasonable systems *all* of those are "utf-8" :)
<bialix> windows supports unicode for filenames, no need to use fs encoding, it's always mbcs anyway
<bialix> GaryvdM: I think I've marked all bugs I know: https://launchpad.net/qbzr/+milestone/0.14.5
<GaryvdM> bialix: cool - I'm going to to the tag one now
<bialix> GaryvdM: I'm porting qsubprocess --bencode
<GaryvdM> bialix: I did push uncommit commit push on lp:qbzr/0.14, so you may need to do pull --overwrite
<GaryvdM> bialix: err - no - you beat me to the second push never mind
<bialix> ok
<jam> can a losa check out lp:~bzr-pqm/bzr/2.1.0b2 it was meant to be created from "lp:bzr" but it seems to be at revno 4668, when lp:bzr is at 4778 (about 110 revisions newer)
<mthaddon> jam: sure
<jam> spm created it for me last night, and I didn't notice until today
<jam> mthaddon: if you want to just "bzr push" to force it to update, that would be fine with me
<mthaddon> jam: from current lp:bzr ?
<jam> mthaddon: yeah
<mthaddon> jam: revno 4778
<jam> thx
<mthaddon> done
<corp186> I accidentally pushed the wrong branch to a new lp branch
<corp186> how do I revert the lp branch back to the initial state?
<bialix> GaryvdM: I see there is all green now
<bialix> rats
<bialix> corp186: re-push with --overwrite flag
<corp186> bialix: I get "No new revisions to push."
<bialix> you wrote: corp186>	I accidentally pushed the wrong branch to a new lp branch
<bialix> do you have copy of original "right" branch
<bialix> ?
<corp186> ahh, I see what you're saying
<corp186> yeah
<bialix> cd to "right" branch and push --overwrite
<corp186> bialix: thanks, that worked
<bialix> always happy to help (c) jam
<bialix> :-)
<GaryvdM> My irc is very lossy - I can only see in chatzilla, half of what I can see here: http://irclogs.ubuntu.com/2009/10/30/%23bzr.html
<GaryvdM> And - messages that I have sent don't appear there. No wonder no one answers my questions some times.
<bialix> Garyvdm: I've backport all revno I remember
<bialix> I see you finished too
<GaryvdM> Yes
<GaryvdM> bialix: When you are idle, check this out: http://garyvdm.googlepages.com/out.ogv
<GaryvdM> Bialix: rename in qbrowse/qcommit
 * bialix opens link
<GaryvdM> 1.1mb
<bialix> Garyvdm: I'll wait till tomorrow morning to cut tarball, ok?
<bialix> GaryvdM: what is ogv?
<GaryvdM> Ok - I'm going to do some hacking  - on drag and drop move
<GaryvdM> ogg video
<GaryvdM> Best player on windows for that would be vlc
<bialix> hmm, I hope K-lite codec pack knows how to play it
<GaryvdM> Hi luks
<bialix> GaryvdM: COOOOOOOOOOOOOOOOOOOOOL
<GaryvdM> :-)
<bialix> and how to move file? drag-n-drop?
<GaryvdM> Yes - that's what I'm working on now.
<luks> hey
<bialix> oh, cool cool cool
<bialix> heya luks
<jelmer> hi *
<jelmer> /topic Welcome in #qbzr ;-)
<GaryvdM> And for --after - you will be able to select a missing, and a unversioned and chose mark as resolved
<GaryvdM> Hi jelmer
<bialix> heya jelmer
<bialix> what's .topic?
<bialix> what's /topic?
<GaryvdM> Topic for #bzr is âBazaar version control system | 2.0.1 and 2.1.0b1 are official! | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/â
<GaryvdM>  /topic allows you to change that
<bialix> ah, ok
<bialix> jelmer: cool article about bzr-svn/git/hg
<bialix> jelmer: we all hope on bzr-hg
<bialix> GaryvdM: how you made that video?
<GaryvdM> bialix: with gtk-recordMyDesktop
 * bialix nods
<GaryvdM> bialix: it very easy, but I think it is linux only.
 * bialix nods
<bialix> GaryvdM: everything ready to release, will do it tomorrow
<GaryvdM> bialix: cool
<bialix> I leave 0.16? for you
<GaryvdM> bialix: I'm going to see where I can get to with move and rename, and release 0.16 on Sunday
<GaryvdM> yes
<jelmer> bialix: thanks
<bialix> FTW!
<bialix> if only there will be something like github or bitbucket but for bzr with reasonable small fee for private repos -- I'll be mostly happy
<bialix> GaryvdM: do you have any codename for 0.16 in mind?
<GaryvdM> bialix: Sorry - no
<GaryvdM> Lots of work in the Tree view
<GaryvdM> *TreeWidget
<jelmer> bialix: whatever happened to the work that rocky burton was doing?
<bialix> what's nice tree in your region?
<bialix> jelmer: rocky burton? sorry, I don't follow
<bialix> GaryvdM: what's nice tree in your region? tree you like?
<GaryvdM> bialix: http://en.wikipedia.org/wiki/Acacia
<GaryvdM> http://savannaenvironment.files.wordpress.com/2008/04/acacia.jpg
<bialix> GaryvdM: Acacia grew and here too
<bialix> so let's use its name?
<GaryvdM> I see - was just reading the Wikipedia article.
<bialix> but in my region it has white flowers
<bialix> I'll add Acacia as codename to 0.16, ok?
<bialix> GaryvdM ^
<GaryvdM> Cool
<bialix> :-)
<GaryvdM> bialix: are you using trunk?
<bialix> right now I'm testing 0.14.5
<bialix> I'm switching between both from time to time
 * bialix is very busy with my main work
<GaryvdM> bialix: Sure, I understand
<GaryvdM> bialix: I'm looking for feedback on the new directory grouping in qcommit.
<bialix> ok, I'll switch and will test it these days
<bialix> Garyvdm: ping
<GaryvdM> pong
<bialix> Garyvdm: recently I've discovered that qlog FILE don't show revisions where file was removed
<bialix> e.g. if you re-add file later
<bialix> the same with plain log though
<GaryvdM> bialix: yes - know bug, same in log
<vila> bialix: hmm, lovely codename :-) I love Acacias, they can smell so good at times...
<bialix> heya vila
<bialix> GaryvdM: there is already bug?
<GaryvdM> bialix: I think so - trying to find it.
<bialix> vila: I have a misteriuos plan according to which we will name all qbzr releases after trees
<GaryvdM> bialix: bug 181520
<vila> lol
<bialix> vila: but sometimes it make sense to use something funny
<ubottu> Launchpad bug 181520 in bzr "bzr log FILE don't show revisions where file was removed" [High,Confirmed] https://launchpad.net/bugs/181520
<vila> bialix: That's quite  appropriate, there so many branches there :)
<bialix> GaryvdM: lol, it's my bug
<GaryvdM> bialix: I'm sure I also log a dup...
<bialix> GaryvdM: I mean: can we fix it for qlog or it depends heavily on bzrlib behavior?
<bialix> vila: :-D
<fullermd> Isn't acacia technically a bush, not a tree?
<bialix> GaryvdM: I have feeling that we have fixed it in the past
<GaryvdM> bialix: The method is similar for qlog and log, so if we fix it for one , then fixing it for the other is easy.
<GaryvdM> bialix: It would be easy to fix, but it would be slower.
<bialix> :-/
<bialix> fullermd: wikipedia said it's a group of shrubs and trees
<vila> fullermd: hmm, well, there was one in my parent's home garden, it was a tree, definitely :)
<bialix> fullermd: I saw only trees in my city
<bialix> there is a lot of acacias
<bialix> slower is bad word
<GaryvdM> bialix: Here is the bug I logged: bug 368976 That says it only happens log uses deltas, which happens if you do log dir, or log file -v
<ubottu> Launchpad bug 368976 in bzr "File graph doesn't join re-added files to the main graph" [Wishlist,Triaged] https://launchpad.net/bugs/368976
<GaryvdM> Oh - sorry - thats a different bug.
<bialix> GaryvdM: ok, so it's related to the fact file-graph missing deletion
<bialix> GaryvdM: that bug looks ok
<GaryvdM> bialix: no - Your bug is that it does not show the revision that removes the file. My bug is that if you remove, and re add a *dir*, it only shows the second bit of history, not the first
<GaryvdM> bialix: My bug is the one that would be easy to fix, but it would be slower.
<bialix> ah, sorry, I misread
<bialix> anybody knows about undelete plugin?
<GaryvdM> bialix: Your bug - I don't know how we could fix. (Except for looking at the inventory for every revision, which would be much much slower.)
<bialix> GaryvdM: so, am I correct that this sort of info just missing in per-file-graph?
<GaryvdM> bialix: yes
<bialix> bad
 * GaryvdM ventures out to seek food.
<lau> hi, i am noobing here but any time i perform a modification on a file (local branch)
<lau> i first have to bzr add before bzr commit ?
<dereine> i need to replace lp: with the right url?
<dereine> does someone know where lp points to?
<Pilky> dereine: lp:project equates to bzr+ssh://bazaar.launchpad.net/~ownerOfMainBranch/project/mainbranchname
<Pilky> dereine: eg lp:bazaarx equates to bzr+ssh://bazaar.launchpad.net/~bazaarx-dev/bazaarx/dev/
<dereine> Pilky: thx
<dereine> so for https://code.launchpad.net/~d7cx/d7cx-views/DRUPAL-7--3 it would be bzr+ssh://bazaar.launchpad.net/~d7cx/d7cx-views/DRUPAL-7--3 ?
<Pilky> dereine: in theory, yes
<dereine> Pilky: is there a  public commando from the bzr commando?
<Pilky> hmm? not sure what you mean
<GaryvdM> lau: Only the first time the file is committed.
<corp186> How can I delete a tag in a remote repository?
<corp186> I know no one else has cloned the branch yet
<GaryvdM> corp186: bzr tag --delete
<GaryvdM> corp186: Then bzr push
<lau> thx GaryvdM, i have a scenario i do not clearly understand
<lau> 1- i bzr update from a lp bzr repo
<corp186> GaryvdM: I even used bzr push --overwrite, but it still didn't delete the tag
<lau> 2- i modify 2 files from my working dir
<lau> 3- i bzr commit to lp bzr repo
<lau> 4- it commits my 2 modified files _+ 2 others files w/ MERGE-SOURCE in them
<lau> what could be the root cause of the MERGE-SOURCE text in these 2 files ? w/o any
<lau> error during the bzr update ?
<GaryvdM> corp186: maybe try bzr tag --delete -d url/to/remote
<dereine> Pilky: perhaps "bzr get_path lp:foo"  would return the bzr+ssh.... url from the project to check out
<GaryvdM> lau: What is the url of the branch on lp?
<Pilky> dereine: I don't there is an option, because if you're using bzr you should be able to just use the lp:foo path anywhere you need to
<Pilky> dereine: what exactly are you needing the URL for?
<corp186> GaryvdM: -d did the trick, thanks :)
<lau> GaryvdM: it is a personal project i prefer not to tell ? i really think it is my fault because
<lau> i am noobing here ...
<dereine> Pilky: awesome, i just don't need to transfer the url, just give bzr branch the url, thx for the eye-opener
<Pilky> dereine: yeah, anywhere there is a path you can pass in an lp:foo eg to branch bzr itself you'd type
<Pilky> bzr branch lp:bzr mylocalbranch
<dereine> Pilky: would it be able to define own shortcuts?
<Pilky> dereine: I believe so, but I'm not sure how. I think it may require a plugin to be written
<GaryvdM> dereine, Pilky: bzr-bookmarks
<GaryvdM> https://launchpad.net/bzr-bookmarks
<dereine> thx
<lau> GaryvdM: i think know that it was old trash from my working tree
<lau> these 2 files with some MERGE-SOURCE and TREE in them
<lau> without any .BASE, .THIS or .OTHER
<lau> was a old remanation from my working tree, does it make sense ?
<GaryvdM> Yes
<GaryvdM> lau: You can uncommit, remove the cruft, and then commit again
<GaryvdM> lau: If you use qcommit, it will remember the commit message for you.
<lau> yes i did that thx
<lau> what are the tools i can use in order to prevent this happen again ?
<lau> i mean old dirty stuff in my working tree that i commit inadvertently ?
<GaryvdM> lau: read the diff before you commit?
<lau> :) right ok
<GaryvdM> lau: bzr will allways tell you if there was a conflict, and it has put in thoes merge things.
<GaryvdM> lau: Many bzr commands to merges to the working tree: pull, update, merge, switch
<GaryvdM> jam: ping
<GaryvdM> If I have a list of paths, is there a easy way to get the path of the lca using a python, or bzrlib api?
<jam> hey GaryvdM
<GaryvdM> Hi jam
<GaryvdM> jam: I wanted to ask you the question above.
<GaryvdM> if I have ["a/b/c", "a/b/d", "a/c"] I want to get "a"
<jam> GaryvdM: lca? Do you mean the minimal paths to include everything you specified?
<jam> osutils.get_minimum_path_selection() IIRC
<GaryvdM> yes
<GaryvdM> Ah -cool
<jam> it is used along with 'is_inside_any'
<jam> this is to avoid passing the entire tree in for 'first commit' ?
<GaryvdM> Thanks alot.
<GaryvdM> jam: No - it for qbrowse, drag and drop move
<GaryvdM> I need to work out of a selection of paths is ok for a move
<GaryvdM> jam: this is ok: http://imagebin.ca/img/UH2_flra.png
<GaryvdM> This is not ok: http://imagebin.ca/img/Zynept0Z.png
<jam> GaryvdM: perhaps, but I could see the latter being ok, just taking more work to figure out what exactly goes where...
<GaryvdM> Jam: do you create a new "ui" dir, or dump it in the root of where it was moved to?
<jam> GaryvdM: good question :)
<jam> hence the "what goes where"
<jam> *I* would say that if you select files, then they get dumped into the target dir
<jam> w/o creating a new 'ui' dir
<GaryvdM> jam:  I guess that would make sense for a selection like this: http://imagebin.ca/img/UZLOAps9.png
<jam> GaryvdM: right
<jam> though you could always "punt" and say that all files must be in the same dir, etc.
<GaryvdM> jam: for now, I would prefer to just disable it. It needs to do what the user expects, and there will always be uncertainty here.
<GaryvdM> So I want to check that if a path is  selected from a sub dir, then both the dir, and all of it children must be selected.
<smartgpx_> nck smartgpx
<smartgpx_> nick smartgpx
<lifeless>  you want a / at the start of that
<smartgpx> lifeless: thanks Robert
<GaryvdM> jam: get_minimum_path_selection was not what I was looking for, but was what I needed :-)
<jam> GaryvdM: I'm glad you got what you wanted
<lifeless> jam: its saturday for me, but if you want to talk about the push regression I'm up for that
<jam> lifeless: debugging further it seems to only occur if you have a remote bzrdir w/o a remote branch
<jam> so it isn't quite as critical as I thought
<jam> It then pushes the whole repo
<jam> rather than just the ancestry
<lifeless> so
<lifeless> /.bzr/repository
<lifeless> /foo/.bzr
<lifeless> bzr push ../foo
<lifeless> ?
<jam> foo/.bzr/branch-format but no foo/.bzr/branch/
<jam> lifeless: right, something like that
<lifeless> so I've seen some odd stuff in that space recently too
<jam> lifeless: the checkout stuff ?
<lifeless> I filed a bug about branch references getting pushed
<jam> yeah
<jam> I've been trying to walk through the steps
<jam> and we have some *horribly* indirections
<jam> 'Branch.push()' calls into InterBranch.push which calls _basic_push which calls Branch.update_revisions which calls InterBranch.update_revisions which...
<jam> lifeless: and I believe that is when you *do* have a target branch
<jam> which I was trying to compare w/ when you *don't*
<lifeless> yeah
<jam> I need to just single-step through it and figure out what is going on
<lifeless> I expressed concerns about IB but jelmer felt it was really needed
<lifeless> It was already arcane deeper in anyhow
<lifeless> but IB won't be related to the new branch case, I'm fairly sure
<lifeless> thats all in .clone()
<jamey_uk> I'm trying to pull a branch in and get this error: "bzr: ERROR: Invalid url supplied to transport: "invalid port number  in url: bzr+ssh://[my-url]"
<jamey_uk> in my ~/.ssh/config file I have 'Host [ip-address] \n User [username] \n Port 1989 \n Hostname [my-domain.com]'
<lifeless> bzr won't care about that
<jamey_uk> Does anyone know why I get the error if I've set my custom port in ~/.ssh/config?
<lifeless> what is the actual url you are using
<lifeless> you can replace the host and path with arbitrary thgins
<lifeless> but we need to see something that is equivalent to tell whats going on
<jamey_uk> kind of following, one sec
<jamey_uk> bzr pull bzr+ssh://dropoutuk@dropoutuk.com:/home/dropoutuk/www/
<lifeless> get rid of the :
<jamey_uk> at the beginning?
<lifeless> no
<lifeless> before /home
<jamey_uk> oh
<jamey_uk> great, what's an easy way to find out the bzr version installed? the server i'm pulling from is ubuntu 9.04 and this machine is ubuntu 9.10 - i'm getting "Bazaar repository format 2a (needs bzr 1.16 or later)"
<jamey_uk> and just out of interest, I've used that syntax before for ssh:// paths, why the missing colon before the path? (or am I mistaken generally)
<sven_oostenbrink> fullermd: bzr is FAST... in comparison with SVN / SVK anyway... I have a source code tree of 40.000+ files and its bzr add, boom, done... bzr commit... okay, takes a bit more, but still.. FAST! :)
<jamey_uk> Can anyone help me with my bzr 1.16 or greater problem?
<lfaraone> Have any speed benchmarks been done with the new branch format and git? http://bazaar-vcs.org/Benchmarks only seems to cover size.
<jamey_uk> I've got a repo on my remote server and trying to pull locally into a freshly init'd repo but keep getting error "azaar repository format 2a (needs bzr 1.16 or later)". Any ideas?
<vila> jamey_uk: 'bzr version' will tell you which version you're using
<sven_oostenbrink> fullermd: I have a development group of 3 persons (myself included).. I want every developer to work on his own branch so that everybody is working seperately on their own laptops (so there will be 3 branches).. then I want the trunk to be on a central server.. we will all merge our changes to that place..
<vila> jamey_uk: to upgrade to the latest stable version, see https://edge.launchpad.net/~bzr/+archive/ppa for instructions
<jamey_uk> vila, thanks seems like Ubuntu 9.04 has 1.13.1 whilst 9.10 has 2.0.0. What's the safest way to upgrade to 2.x on the former?
<sven_oostenbrink> fullermd: That sounds like a good idea? to do it like that? Then, I have the current tree over here on my laptop..  I bzr init, bzr add and bzr commit that tree.. How do I get it to be on that server? bzr push ssh+bzr://me@server ?
<jamey_uk> vila, thanks you beat me to it :)
<vila> jamey_uk: always happy to help (mt) :-D
<vila> s/mt/tm/
<jamey_uk> vila, how do I add the key for that source to my apt?
<vila> jamey_uk: read that page, open the Technical details, click 'Read about installing'
<vila> You'll get all the gory details with ready-to-copy commands
<jamey_uk> that's exactly what I did but I has only bash at my disposal :)
<jamey_uk> no X here my friend
<vila> jamey_uk: ? 'ssh -Y' to the rescue ?
<lifeless> jamey_uk: the : at the end leads into a port, bzr uses urls, not rsh paths
<jamey_uk> haha no, no, I don't need no X11 thank you :)
<jamey_uk> lifeless, ah yes of course thanks for explaining
<jamey_uk> vila, being a total n00b sorry, I thought it was a two stage process - first to fetch a GPG key or something, then to use apt-key. all is swell
<vila> jamey_uk: great, because I just realized I'm wat past bed time :-)
<vila> g'night all !
<jamey_uk> g'night, thanks for your help!
#bzr 2009-10-31
<fullermd> sven_oostenbrink: Sounds reasonable enough.
<sven_oostenbrink> fullermd: I do have one doubt though..
<sven_oostenbrink> fullermd: 1) I'd like to use ssh based protocols for this
<sven_oostenbrink> fullermd: so probably I'll use ssh+bzr:// right?
<fullermd> bzr+ssh, yeah.
<sven_oostenbrink> fullermd: Thing is, AFAIU, there will be one .bzr directory on that server which will be the trunk repo, right?
<fullermd> The trunk _branch_, yes.  It may have the repo as well, or you may have that off in another .bzr/.
<sven_oostenbrink> fullermd: How can I do the merge then? Because, say, if I would be doing the merges for all 3 persons.. That would mean that on the server itself, Id have to BZR merge the changes from me, and the 2 other persons.. But then security comes into play, bzr somehow needs to get these changes from the other users...
<sven_oostenbrink> again, AFAIU, the other users will have local branches, so they'll commit there.. I can then go to that trunk branch and pull in their changes, right?
<sven_oostenbrink> am I making any sense here? :)
<fullermd> That would be one way, yes.  You're essentially acting as a human gatekeeper, so all commits to that central branch will be done by you.
<fullermd> So, you'd just own it.
<sven_oostenbrink> fullermd: if I, user "sven" want to access the changes from the other users, I could pull in those changes.. but that means there must be a user "sven" available on the machines of these persons, right? and that user sven should have read access to the BZR repo of those persons.. right?
<sven_oostenbrink> fullermd: yeah, I'd like to be the only one who can tree merge, to assure that the tree stays stable..
<fullermd> Well, it means you need to access them _somehow_.
<sven_oostenbrink> The thing is, I see security being a barrier here..
<fullermd> You could have ssh on all their boxes (and that user be allowed to read their branches), is one way.
<fullermd> They could publish them via http:// or bzr:// from their boxes.  They could have their own accounts on the central server that they push up to, then you merge from there.
<sven_oostenbrink> fullermd: so..
<fullermd> They could send you merge directives via mail.
<sven_oostenbrink> fullermd: I have the trunk.. from there i create branches A, B, C (Im A, the other two developers are B and C).. Then each of A, B and C branch from their server branch (Im counting 7 branches now).. they work locally.. wheneverthey have somehting, they push / merge to their server branch.. and I merge their server branches into the trunk branch..
<sven_oostenbrink> fullermd: that makes sense?
<fullermd> Well, it works.  Why make the A B C branches, instead of just letting everybody branch off the trnk?
<sven_oostenbrink> fullermd: I've seen the send by email option.. Though it sounds interresting, its not something I'd pick at first sight.. dunno, somehow it seems.. not pretty :)
<fullermd> It seems an unnecessary indirection.  And it will make it much harder for them to pick up change from trunk.
<sven_oostenbrink> fullermd: so they branch directly from the trunk.. Meaning they'll have the branch locally on their computer, right?
<sven_oostenbrink> Yeah, it would actually require that I send them trunk changes.. not a nice option..
<sven_oostenbrink> fullermd: I could let them branch directly to the trunk, but that would require the trunk to be on a location where A, B and C have write rights, correct?
<fullermd> Yeah, making the copy of trunk for each of them on the server and having them go from there isn't necessary, unless for some reason you don't want them even having read on trnk.
<fullermd> But that sounds like way too much trouble all around.
<fullermd> No, they only need read to branch from it.
<fullermd> (you may still want to branch trunk yourself into shared repos for each of them on the server, just to prime it with the existing revs and save them some upload, but that's unrelated)
<sven_oostenbrink> fullermd: but if they want to merge to the trunk directly, they need write access there, right?
<fullermd> Yes.
<sven_oostenbrink> fullermd: another question.. what if I don't want a central server for the trunk repo, I want to use my own laptop..
<fullermd> But you could give them _read_ on it, they branch from it, and pull/merge later changes made from it, and only you have _write_ and gatekeeper it.
<fullermd> Well, remember that 'trunk' is a social question, not a technical one.  On a technical level, all you have are a bunch of branches spread out over the world.
<sven_oostenbrink> fullermd: interresting problem that THEN shows up is that my laptop doesnt have a static IP.. How can I fix that? can they just push to an IP that I give them? Will BZR know that its my laptop even though the IP is different?
<fullermd> Treating one of them specially in various ways is just up to how you want to arrange it.
<fullermd> A floating laptop has the property that, generally, only you can do stuff straight on it.  So to have the 'trunk' there means that, generally, nobody else can even get at it to pull down new changes from it.
<sven_oostenbrink> fullermd: yeah, I understand that part (thank god... gotta hate SVN by now, hehehe)
<fullermd> So generally you want a 'trunk' branch to be somewhere always connected and reasonably stable.
<fullermd> Of course, you CAN develop without a trunk at all.  It's just tough to scale.
<sven_oostenbrink> fullermd: well, it needs to scale.. I was thinking, BZR being a DVCS, that it might not need a central place for all changes
<fullermd> It doesn't, but having a specific point of reference is, if not necessary, at least highly desirable in most development.
<lifeless> sven_oostenbrink: scaling is a human problem, tech wise we scale out
<sven_oostenbrink> fullermd: lifeless: Gottit
<sven_oostenbrink> fullermd: so Im pushing my just newly created BZR branch to the central server.. since there is nothing there, it will appear there as a new branch, right?
<fullermd> Yes.
<sven_oostenbrink> fullermd: the central server also requires BZR to be installed, right?
<fullermd> If you want to use bzr+ssh or ever work with the branch directly on the server, yes.
<sven_oostenbrink> fullermd: whats the difference then, practically speaking, between sftp:// and bzr+ssh://
<fullermd> You CAN use it simply as a dumb server via sftp or the like.  But if you can avoid it, you don't want to.
<fullermd> bzr+ssh is bzr talking to bzr.  sftp is bzr talking to a quirky and very slow filesystem.
<sven_oostenbrink> fullermd: Im avoiding it as we speak, installing bzr now :) but whats the difference anyway? just to know..
<sven_oostenbrink> fullermd: as in, bzr+ssh is way faster than sftp...
<sven_oostenbrink> both are secure anyway so..
<lifeless> sven_oostenbrink: server side operations
<lifeless> sven_oostenbrink: e.g. to consolidate two files over sftp = 'read file a, read file b, write file c, delete a, delete b'
<lifeless> over bzr+ssh, we send a single command
<sven_oostenbrink> fullermd: another thing.. Im about to up 40.000 files.. if the connection drops out half way, is there a "resume" option, or woud I have to start from 0 again?
<lifeless> and don't have to copy all the data over the network in both directions
<sven_oostenbrink> lifeless: understood
<fullermd> Well, you send revisions, not files.
<fullermd> I think if you're pushing a bunch of revs into an existing repository, they checkpoint every so often, so you wouldn't lose them all on a connection drop.
<lifeless> nope
<fullermd> But an initial checking is just one rev anyway, so it wouldn't.
<sven_oostenbrink> fullermd: so this first 40.000 files revision should pass without problem, or it will fail?
<lifeless> its atomic, all or nothing.
<sven_oostenbrink> in that case I better pray my new 3G network card will hold out..
<sven_oostenbrink> I had MANY problems with SVK in that aspect.. one network hickup, and I could start all over on large merges..
<fullermd> Well, in consolation, any future revs should be pretty small.
<sven_oostenbrink> fullermd: yeah, I know.. its just that Im in a datacenter now, all local.. but I have to leave in about 10 mins, and I still am updating the central server.. so I gotta do the first commit over my 3G card instead of over a 1Gbit network.. :)
<fullermd> Well, if you ssh'd over SCTP, you could make it a portable session, and relocate it to the new IP on 3G when you need to leave   :p
<fullermd> But if you can't move it across a gigabit network in 10 minutes, you probably shouldn't even try on 3G at all...
<sven_oostenbrink> fullermd: I can do it over 1Gbit in under a minute, sure, but the server isn;'t ready yet for another 30 mins.. there's the prob..
<sven_oostenbrink> fullermd: lifeless: Thanks lots to both, I'll start messing arounhd tonight to see how it will work..
<sven_oostenbrink> laters!
<fullermd> I should hope so.  A minute of gigabit time is about 7 gig.  That's a pretty sizable branch   :p
<lifeless> statik: do you know about package branches
<lifeless> statik: lp:~statik/ubuntu/lucid/bzr-explorer/ppa would be a better branch to use ;)
<gioele> I added a key to launchpad but I haven't configure ssh to search for that key. How come that bzr co lp:foobar does not complain?
<alefteris> I have a branch from a mirrored branch in lp, and I now want to host it in lp, what should I do, branch it and then push it in the new location? thanks
<alefteris> should I unbind it first or something?
<Peng> alefteris: Yes, push it to a new location on LP.
<Peng> alefteris: (You can even rename or delete your old branch so you can push it to the same URL. Bug and suscriber associatiosn will still be attached to the old branch, though.)
<Peng> alefteris: Ah. never mind.
<alefteris> Peng, thanks, that's what I did :)
<Peng> :)
<sjamaan> Is it possible to pull from multiple sources with bzr?
<sjamaan> For instance, I'm working in centralised mode on a project, which is a fork of drupal. I'd like to be able to keep merging in remote changes from drupal, but make my own changes and keep pushing those to my own repo
<sjamaan> anyone?
<Peng> You can "bzr pull" or "bzr merge" from any URL you want to..
<sjamaan> hm
<sjamaan> After merging, bzr told me "working tree is out of date, run 'bzr update'" and when I did, it started calling out lots of conflicts
<sjamaan> Nothing had changed in the upstream branch
<sjamaan> If I ignore the message, it works
<sjamaan> What is a "submit branch"?
<Peng> sjamaan: The branch "bzr send" defaults to submitting against.
<sjamaan> ok, but if I just bzr push or commit in bound mode, it will push the other branch?
<sjamaan> push to*
<Peng> "push" will push to your default push branch by default. You can supply an URL/path to push wherever you want to.
 * Peng has to go -- bye!
<sjamaan> thanks for the info. bye!
<sjamaan> Is it possible to create a standalone branch without working tree, or is that only possible within a repository?
<Peng> sjamaan: Sure, it's possible. "bzr branch --no-tree ...", or "bzr branch ...; cd ...; bzr remove-tree".
 * Peng goes away again.
<sjamaan> What about new branches? when using init
<sjamaan> I tried "bzr init --no-tree foo" but that gives me an error "no such option: --no-tree"
<rubbs> If you type in  " bzr help init-repo" it will give you the options you need.
<rubbs> I believe it's --no-trees with the 's' on the end
<sjamaan> rubbs: I know it works when using a repository. I asked about standalone branches
<rubbs> oh sorry. came in too late
<sjamaan> ah, I see
<sjamaan> No prob :)
<rubbs> Well, I'm unsure how to do it at init time, but you can remove the tree using bzr remove-tree
<rubbs> you could also try the command bzr init --no-trees
<sjamaan> no-trees doesn't work either, but remove-tree sounds like a good idea
<sjamaan> It would be useful if init could do that, though
<rubbs> Just curious, why would you want a stand alone branch without a tree?
<rubbs> You could create a treeless repo and push your updates right to the root of the repo.. I've done that by accident before.
<rubbs> you would just have to think of the treeless repo as your branch location without a tree
<sjamaan> For centralised mode, I don't need a full working copy on the server
<rubbs> Then I would suggest you do a repo. Even if there is only one branch on the server you would get the functionality you want.
<sjamaan> aye
<sjamaan> I'm doing that now, but I thought it seemed a bit overkill
<sjamaan> (I have only one branch)
<sjamaan> Of course, I could multiple entirely unrelated branches in one repo
<sjamaan> But that's a bit weird too
<rubbs> But that is more common than you might think
<sjamaan> hm
<rubbs> I'm  not an expert on the internals of bzr, but AFAIK creating a treeless repo doesn't have a whole lot more overhead than a branch anyway.
<sjamaan> I didn't think so. I was referring to cognitive overhead :)
<rubbs> haha. fair enough :)
<mindlace> how do I get bzrlib?
<sjamaan> It's part of bzr
<sjamaan> If you have bzr, you have bzrlib
<mindlace> hm. well i installed the os x bzr and "import bzrlib" fails. Maybe I need to change my python path.
<Tak> I don't know about osx, but I have to explicitly set my pythonpath on win32
<mindlace> How do I find out more about loggerhead? read the source? I don't find any docs on launchpad
<Meths> Can you merge a branch into a directory of another branch?
<nyu> Meths: I guess you can "bzr mv" + "bzr merge"
<Meths> Yeah, or just create the subdir in the branch anyway I suppose. Thanks.
<Peng> Meths: "bzr join".
<Peng> mindlace: Ehh. What do you want to know?
<Meths> Peng: Aha, just the job, thanks.
<Peng> Meths: It should handle merging nicely, too. :)
<Meths> yeah, looks like it from the help description
<mdke> I have a format:unnamed repository and a "Packs containing knits without subtree support" repository on Launchpad, is there any way I can push my commits to Launchpad? It's giving me an error.
<mdke> I have so much grief over different formats, for some reason
<lifeless> mdke: show us the error
<lifeless> [surely thats a reflex by now, to give details?]
<mdke> lifeless: yes, sorry - it's quite a standard error. http://paste.ubuntu.com/306229/
<MTecknology> This is weird... http://whybzrisbetterthanx.github.com/
<sjamaan> Weird?
<sjamaan> It's on github, what'd you expect? ;)
<MTecknology> good point
<MTecknology> I was trying to find a nice link that explains what makes bzr great
<sjamaan> Personally, I like bzr because it's so friendly and provides a smooth transition from svn
<lifeless> mdke: it means that the bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-docs/help.ubuntu.com  branch - the development focus - has been upgraded
<lifeless> mdke: probably to 2a
<sjamaan> hg is just as friendly, but it has no centralised development mode for those who want it, and it also doesn't support empty directories or proper renaming
<mdke> lifeless: so it's my repository that's behind, not Launchpad?
<lifeless> yes
<mdke> ok, I'll try an upgrade
<lifeless> mdke: one sec
<lifeless> bzr info nosmart+lp:~ubuntu-core-doc/ubuntu-docs/help.ubuntu.com/ -v
<lifeless> ^ thats a useful diagnostic to do (I'm running it now)
<lifeless> mdke: what do you see when you run that command?
<mdke> lifeless: http://paste.ubuntu.com/306246/
<lifeless> mdke: and what does 'bzr info -v' show, run from ~/ubuntu-docs/help.ubuntu.com
<mdke> lifeless: http://paste.ubuntu.com/306249/
<lifeless> mdke: note the 'repository' line in both cases
<lifeless> mdke: as it happens, launchpad is missing rich root support
<lifeless> but your local repo has it
<mdke> right
<lifeless> so you either need to redo your work in a non-rich-root repo
<lifeless> or get the ubuntu-docs stuff upgraded
<mdke> ouch
<lifeless> I'd suggest upgrading everything to 2a, its a lot faster and smaller
<mdke> is my local repo 2a?
<lifeless> no, its rich-root-packs
<mdke> I get rather confused with all the formats
<lifeless> which is the same as pack-0.92 with a little extra metadata
<lifeless> mdke: we know :(
<mdke> you mean that others are confused too?
<lifeless> its a confusing situation that we permitted to come about
<lifeless> multiple dimensions
<lifeless> different conversion rules
<mdke> ok, so the plan is to settle things down in the future?
<lifeless> oh yes
<mdke> good stuff
<lifeless> 2a is the first step of the settle down
<lifeless> there are no flavours with 2a, its just '2a'
<lifeless> you can convert to it from any of our older formats
<mdke> ok
<mdke> ok, I'd better redo my work in a branch without a repo
<mdke> lifeless: thanks for the help
<mdke> lifeless: actually one last question
<mdke> lifeless: I don't suppose there is a quicker way to redo the work without actually manually copying files or doing a diff?
<lifeless> bzr diff > foo.patch; patch -p1 < foo.patch P
<RenatoSilva> verterok: hi
<mdke> lifeless: yeah, I'm doing that with separate diffs for each revision. Thanks again
#bzr 2009-11-01
<amanica> I assume that the "left parent" is basically the mainline.
<amanica> does it have a fixed merge_depth=0 ?
<amanica> nevermind. figured it out. stupid question.
<mindlace> is it possible to create a "middleweight" checkout that has some, but not all, of the changesets?
<Peng> Stacked branches might store a bit more data locally.
<mindlace> might or do?
<mindlace> I want to implement/support a "gradual" fetch of history where I "fill in" historical data based on things like network availability
<Peng> Oh, interesting. How will you avoid locking problems? (I mean, the repo has to be write-locked while it's doing this, so it gets in the way of anyone trying to use it.)
<mindlace> aha https://blueprints.launchpad.net/bzr/+spec/shallow-checkouts
<Peng> mindlace: You might want to start with stacked branches, since they support only having partial history locally. Then code something up that gradually fetches more.
<mindlace> yah, just not clear yet on how to cause "gradual fetch" of more
<Peng> No idea!
<Peng> Like  Isaid, if you want it to be some sort of background process, locking will be an issue.
<mindlace> yeahâ¦ well, i'm not tremendously worried about that for the moment, as it wouldn't be working on 'active' repos ...
<mindlace> the idea is to auto-fetch repos 'nearby' - reported via zeroconf, for example
<mindlace> to support ad-hoc collaboration
<lifeless> mindlace: well, there is bzr share and bzr browse already via bzr-avahi
<lifeless> for precisely adhoc stuff
<Peng> Eh.
<mindlace> well, isn't that fabulous, i love it when things already exist. Thanks, lifeless!
<mindlace> basically I'm trying to build a non-programmer project management tool / CRM with VCS inside â¦ right now bazaar is the winner. (Started with git, moved to checking out mercurial, now I'm at bzr)
<mindlace> only bzr actually has a supported, documented api (bzrlib) and supports non-complete checkouts...
<lifeless> cool
<lifeless> I'm off, ciao.
<Peng> Why do you want shallow checkouts?
<Peng> lifeless: See ya. :)
<Peng> "See ya"? I never say that.
<fullermd> Well, obviously one of you is lying.
<mindlace> hmâ¦ well, I want to implement "search" across all repos who are using this cms-thingy â¦ and have results of search be auto-fetched
<mindlace> I had the idea that search results may return historical results but I guess I can simplify things by skipping that for the moment
<mindlace> (historical results - to fetch, then, you would need that historical revision -> present)
<mindlace> I guess I also want fragmentary checkouts ;P
<mindlace> hmâ¦ seems like sub-tree kind-of gets there...
<mindlace> oh hey, lifeless was robert collins
<mindlace> oh well guess i'll catch him when he's aboot
<Kamping_Kaiser> mindlace: I suspect you'll find he still is robert collins :)
<mindlace> just figured that out.
<waltercruz> Hi !
<waltercruz> I'm getting a error like that:
<waltercruz> bzr: ERROR: Revision {walter.php@gmail.com-20091019135859-x986fv0x73323qpy} not present in "KnitPackRepository('file:///home/walter/repositories/whissip-dev/.bzr/repository/')".
<waltercruz> I tried to bzr check, but it don't works
<waltercruz> can I just remove that entry from bzr index?
<waltercruz> withouth it, evertything is ok
<jelmer> waltercruz: when do you get that error?
<waltercruz> hum.. a lot of operations :( can't remember 100%
<waltercruz> I upgraded my repository with upgrade -rich root.. sent it to launchapd
<waltercruz> and when I tried to merge another branch.. I got this error
<jelmer> waltercruz: I mean, what operation prints that error exactly?
<waltercruz> bzr log
<waltercruz> but
<waltercruz> bzr log -r-1
<waltercruz> ------------------------------------------------------------
<waltercruz> revno: 1 [merge]
<waltercruz> committer: Walter Cruz <walter.php@gmail.com>
<waltercruz> branch nick: whissip-dev
<waltercruz> timestamp: Sun 2009-11-01 11:44:04 -0200
<waltercruz> message:
<waltercruz>   whissip merge
<waltercruz> ------------------------------------------------------------
<waltercruz> Use --include-merges or -n0 to see merged revisions.
<waltercruz> works
<waltercruz> looks like I have a entry in the index... but no commit with that ID.
<waltercruz> I suppose ;)
<jelmer> waltercruz: so "bzr log" immediately errors out saying that it doesn't have that particular revision?
<waltercruz> yes
<waltercruz> (bzr)walter@waltercruz:~/repositories/whissip-dev$ bzr log
<waltercruz> bzr: ERROR: Revision {walter.php@gmail.com-20091019135859-x986fv0x73323qpy} not present in "KnitPackRepository('file:///home/walter/repositories/whissip-dev/.bzr/repository/')".
<fullermd> Wait, revno 1 is a merge?
<fullermd> Oh, nm, it presumably just be getting that from missing that rev as the parent...
<fullermd> Try log -r-1 --show-ids
<fullermd> 'll probably say that missing rev is its parent.
<waltercruz> (bzr)walter@waltercruz:~/repositories/whissip-dev$ bzr log -r-1 --show-ids
<waltercruz> ------------------------------------------------------------
<waltercruz> revno: 1 [merge]
<waltercruz> revision-id: walter.php@gmail.com-20091101134404-9vahhw9duq5fjolg
<waltercruz> parent: walter.php@gmail.com-20091019135859-x986fv0x73323qpy
<waltercruz> parent: walter.php@gmail.com-20091031152550-jbf3xxslieifdpir
<waltercruz> committer: Walter Cruz <walter.php@gmail.com>
<waltercruz> branch nick: whissip-dev
<waltercruz> timestamp: Sun 2009-11-01 11:44:04 -0200
<waltercruz> message:
<waltercruz>   whissip merge
<waltercruz> ------------------------------------------------------------
<waltercruz> yes.
<waltercruz> my repository screwd up somehow.
<waltercruz> when I did a bzr check
<waltercruz> and after that a bzr reconcile
<waltercruz> I was with no revisions
<waltercruz> bzr log showed nothing.
<waltercruz> so I did a bzr merge 0..-1 theonethatIbranched.. after that, I stucked with that error in bzr log
<fullermd> The merge didn't cause the error, it just turned the existing screwup into a somewhat different screwup.
<fullermd> The problem existed the moment your tree base rev wasn't available from its branch's repo.
<fullermd> I don't know any way to make bzr do that, without trying to or poking around manually behind its back.  Disk corruption of some sort, maybe.
<waltercruz> hum...
<fullermd> You could try running 'check --repo', maybe, to bypass branch/tree checks and see if it turns up anything just in the repo.
<waltercruz> strange.
<waltercruz> will try!
<waltercruz> KeyError: ('hacks.php-20090901021751-ck5pvqni080475dt-1', 'walter.php@gmail.com-20090916150844-ky37u7u3erm116a0')
<waltercruz> bzr 2.1.0b1 on python 2.5.2 (Linux-2.6.30.5-linode20-i686-with-debian-5.0.3)
<waltercruz> arguments: ['/home/walter/.virtualenvs/bzr/bin/bzr', 'check', '--repo']
<waltercruz> encoding: 'UTF-8', fsenc: 'UTF-8', lang: 'pt_BR.UTF-8'
<waltercruz> plugins:
<waltercruz>   launchpad            /home/walter/.virtualenvs/bzr/lib/python2.5/site-packages/bzr-2.1.0b1-py2.5-linux-i686.egg/bzrlib/plugins/launchpad [2.1.0b1]
<waltercruz>   netrc_credential_store /home/walter/.virtualenvs/bzr/lib/python2.5/site-packages/bzr-2.1.0b1-py2.5-linux-i686.egg/bzrlib/plugins/netrc_credential_store [2.1.0b1]
<waltercruz> *** Bazaar has encountered an internal error.  This probably indicates a
<waltercruz>     bug in Bazaar.  You can help us fix it by filing a bug report at
<waltercruz>         https://bugs.launchpad.net/bzr/+filebug
<waltercruz>     including this traceback and a description of the problem.
<waltercruz> (just part of traceback(
<waltercruz> )
<RenatoSilva> It would be so nice to edit comments in history without uncommit
<RenatoSilva> Specially when you find out that you have been calling combo box a drop-down list for so long time o.O
<RenatoSilva> How to hack the bzr metadata to edit them?
<igc> morning
<Peng> Good morning. :)
<igc> hi Peng
<lifeless> hi igc, up early!
<igc> hi lifeless. yup. Crazy day today
 * igc breakfast
<lifeless> jelmer: bug 172360
<ubottu> Launchpad bug 172360 in bzr "branching from rich-root to non-rich-root gives confusing errors" [Medium,Triaged] https://launchpad.net/bugs/172360
<lifeless> jelmer: why did you change it from invalid?
<jelmer> lifeless: it was changed to incomplete without explanation, and the error message is still unclear
<lifeless> jelmer: it was changed to invalid after john said 'this is wont fix by design'
<lifeless> jelmer: I'm happy with it being open, but it needs an explanation as to what we're intending to do
<jelmer> lifeless: fair enough - I've commented
<jelmer> lifeless: fwiw it was changed to invalid before john said 'this is wont fix by design',
<jelmer> and john changed the importance to medium
<lifeless> oh right
<spiv> Good morning.
<igc> bbl
<poolie> hello spiv
#bzr 2010-11-01
<glyph> since I show up periodically to complain I figure I should stop by to say something nice too
<glyph> I have been working this week using bzr and rebase rather than working in svn branches
<glyph> and it has been fantastic.
<glyph> it has improved the quality of my development experience significantly.
<glyph> (now go fix all those bugs plz)
<spiv> Hooray!
<mkanat> glyph: That's awesome!
<spiv> jelmer: hey, the daily builds PPA looks nice!
<jelmer> spiv: Thanks :-)
<glyph> One thing I'm wondering about: is rebase supposed to be able to 'fix' merges that have gone in the other direction?
<lvh> Hi.
<lvh> Can anyone reccomend any good bzr-supporting project management packages that I can host in-house?
<lvh> I tried redmine, but it doesn't do multiple branches -- there's a patch, but that's basically broken.
<spiv> lvh: trac, maybe.
<lvh> spiv: :-(
<lvh> spiv: I was hoping you weren't going to say that, but okay
<spiv> lvh: there's also Launchpad
<lvh> spiv: I was under the impression lp is not something you're supposed to host in-house.
<lvh> (supposed to being distinct from 'possible')
<spiv> Well, I wouldn't really recommend it.
<spiv> Hard to say if the effort of deploying something as overkill as LP is better or worse than Trac ;)
<lvh> spiv: honestly I'd just use fossil if there was a bzr-fossil
<lvh> spiv: also http://trac-hacks.org/wiki/PeerReviewPlugin/Documentation C-f "to be written"
<spiv> lvh: hmm, for code review specifically there may be options
<spiv> I wouldn't be surprised to find that reviewboard or something has bzr support.  And there's also BundleBuggy, which bzr used to use before Launchpad.
<lvh> spiv: I had forgotten about bb, thanks
<mkanat> lvh: Bugzilla isn't a PM system, but it does have a VCS extension that supports bzr.
<spiv> mkanat: ooh, that's good to know
<mkanat> Yeah, http://code.google.com/p/bugzilla-vcs/
<mkanat> I just did another release of the VCS extension today, in fact, partially to improve bzr support.
<spiv> Yay :)
<lifeless> \o/
<mkanat> :-)
<jbowtie> jelmer:  bzr-tfs in trunk supports CodePlex.
<mkanat> And I'm pretty sure that my Perl module on CPAN is still the only Perl interface to bzr.
<jbowtie> So hopefully I'll be able to release that this weekend.
<glyph> is there a way to ask, during an interrupted rebase, 'what was the commit message for the revision that I am fixing conflicts on'?
<GungaDin> are there any diagnostic tools for criss cross merges? how can I know why and for which files they're caused?
<spiv> GungaDin: bzr qlog
<spiv> GungaDin: (or 'bzr viz' if you prefer bzr-gtk to qbzr)
<GungaDin> that doesn't tell me what file(s) specifically it was caused by..  does it?
<fullermd> What do you mean by "caused by files"?  Criss-cross refers to the revision history...
<GungaDin> yeah, but the revision history contains the history of file/dir changes, no?
<fullermd> I suppose.  It just seems like a weird way of looking at things.
<GungaDin> why's that?
<fullermd> I mean, you could build a of all the revisions at and after the cross, then list all the files that got changed, but what would that tell you?
<GungaDin> I just want to know why a criss cross is caused.
<GungaDin> what caused it.
<fullermd> It's not caused by any files, it's caused by the shape of the revision history.
<GungaDin> fine, then at which point that shaped changed to cause it.
<spiv> Right, that shape is the revision graph, and that's what qlog/viz show you.
<fullermd> I don't know of anything existing that can spit out "these are the crossed merges".  You can often spot them in something like qlog/viz if the affected area is small enough that they're nearly-enough on screen together.
<fullermd> If it spans enough revisions, it gets messy trying to parse visually.
<spiv> Yes, it would be nice to add something that can help users see and understand where the criss-cross happened.
<fullermd> I s'pose to somebody reasonably conversant with bzrlib, it would be fairly straightforward to rip out the bits of the 3-way merger that detect the cross to make a lister.
<spiv> Well it's basically just Graph.find_lca (or Graph.find_unique_lca if you want to force bzr to find just one... the hidden find-merge-base command calls this) to identify the revisions.
<spiv> But you'd also want to somehow describe which edges crossed, I think.
 * fullermd wishes revctrl.org were actively curated   :|
 * spiv too
<ultramage> hello, I wanted to try out Bazaar (windows, standalone). I installed it, ran 'bzr', then 'bzr help commands' to see what options there are.
<ultramage> and I got bzr: ERROR: Bazaar Explorer requires QBzr. Please install QBzr (https://launchpad.net/qbzr).
<ultramage> why does 'bzr help commands' tell me to install a GUI component that I don't want?
<ultramage> if it's a mandatory component before you can actually use the software, then include it in the base distribution
<ultramage> I will wait until you people wake up and are able to answer my questions
<jelmer> ultramage: It looks like you have bzr-explorer installed but not one of its dependencies, qbzr
<jelmer> ultramage: Did you install bzr-explorer, perhaps as part of the windows install?
<ultramage> ah, I see, that would be it
<ultramage> I can't recall seeing Qbzr as one of the options... but installing it separately solved that
<ultramage> it's weird that the commandline tool would just outright refuse to run, instead of failing gracefully and just displaying a subset of the commands or something
<Tak> doesn't the windows installer include bzr-explorer and all the deps?
<Tak> at least, it Worked For Me
<ultramage> lemme re-run it and see if I unchecked anything obviously vital
<jelmer> arguably it shouldn't let you install a combination of plugins that won't work, but I'm not sure how hard it is to forbid that in the windows installer
<ultramage> yes, I see now
<ultramage> I picked the bazaar explorer gui, but unchecked the qbzr plugin at the very bottom
<ultramage> "dialogs for gui applications and IDEs"
<ultramage> (doesn't say 'vital component of bzr commandline utility' though)
<ultramage> I guess that it's a component interaction issue
<ultramage> anyways, that's solved from my point of view
<ultramage> now to the questions... I'm looking to replace an existing version control application that I've been using so far, and I've got a few quick questions about Bazaar features, if you don't mind
<ultramage> * must each bazaar branch directory (which I consider a 'checkout') store its own clone of the repository it's using?
<Tak> from which vc are you coming? ;-)
<ultramage> svk
<Tak> ok
<ultramage> because what I'm doing right now is having the upstream repositories mirrored at a central location on a network share, and just doing lightweight checkouts against those (basically, a small directory with a human-editable config file)
<Tak> a bzr branch by default contains all the history for that branch
<Tak> what is it that you /want/ to do?
<LenZ> ultramage: bzr supports "lightweight" checkouts
<ultramage> well, for example, make four checkouts of the target directory
<ultramage> without having the entire history mirrored four times
<LenZ> ultramage: Take a look at "shared repositories" as well, to save disk space.
<ultramage> mmm okay :)
<Tak> if you create a shared repository locally, then branch into that, you'll get what you want
<ultramage> which part of documentation does this fall into?
<Tak> http://doc.bazaar.canonical.com/bzr.2.2/en/user-guide/organizing_your_workspace.html
<ultramage> :)
<ultramage> a suitable name
<Tak> the "feature branches" section seems relevant
<ultramage> hmm, 'bzr branch' and 'bzr checkout' seem to have produced the same result
<Tak> branch gives you an unbound branch which you can manipulate locally
<ultramage> ah
<Tak> checkout gives you a bound branch that requires connection to the remote server for most operations (very similar to an svk checkout)
<ultramage> no, svk checkout requires a local mirror to be available
<ultramage> er, prepared
<ultramage> so basically, the difference between a checkout and a branch is that you're not supposed to commit directly into a checkout?
<ultramage> (in svk, when doing a commit, it sends it to the remote repository, syncs the local mirror and then pulls the changes from there)
<Tak> the difference between a checkout and a branch is that commits to a checkout are immediately pushed to the remote repo
<ultramage> does the write first happen to the checkout, or to the remote repo?
<ultramage> maybe I should try it out more first... I'm still not at a point where I could say "yes, this is what I want to use"
<ultramage> I guess I'm still thinking in terms of one central svn repository
<maxb> IIUC checkouts provide a firm guarantee that the commit will not actually happen locally unless it succeeded remotely
<ultramage> what's pretty confusing is that I'm not used to thinking in terms of branches... most of the time, when I work on something, I have the entire repository mirrored and ready for access, not just one branch
<ultramage> yes, that would be good :)
<maxb> ultramage: Yes that is one of the philosophical quirks of Bazaar relative to other VCSes - to Bazaar, a branch is the primary object. That several might be stored near to each other in a wider repository is a mere detail
<maxb> Which is quite a contrast to git
<ultramage> so far I've been using a particular feature of svk, where if you make a dedicated mirror of the root, the revision numbers will align
<ultramage> so later on when you run svk annotate, or even just svk info, if it says r12345 you know you're talking about r12345
<ultramage> does bzr have the concept of sequential revision numbers?
<ultramage> Lamport clock and all that stuff
<ultramage> I read the 'feature branches' guide but haven't understood the concept
<ultramage> I don't think that's what I'm looking for... or the examples used there don't demonstrate it
<spiv> Yes, each branch has sequential revision numbers (but they aren't in general comparable between different branches)
<ultramage> that's okay if I can treat an entire repository checkout as a single brnach
<ultramage> (which it seems I can)
<ultramage> the feature branches example seems to imply a way to start a branch from another branch... not exactly sure
<ultramage> confusion levels are high :)
<maxb> "Lamport clock" ?
<maxb> OK, so first important thing - if you import svn into bzr via bzr-svn, each imported revision tracks the svn revno it came from (and this is displayed in bzr log)
<maxb> I'm a bit confused by what you mean  by "treat an entire repository checkout as a single brnach"
<spiv> ultramage: basically feature branches mean to do a new set of work on your code you: start a new branch (from the current version of your 'trunk', usually), perform the work on that branch (for however long it takes, minutes, days, months...), then when it is finished you merge the entire set of changes from that branch back into the original branch.
<spiv> ultramage: this avoids having half-done work on your main branch, where it can break things and interfere with other people trying to work on that code.
<maxb> By definition, a (non-lightweight) checkout *is* a branch - there is no "treat as"
<spiv> ultramage: as a logical extension of that, if during that feature branch there's some smaller feature that needs to be done, you can make a new feature branch for *that* (based off the first feature branch, or off trunk, depending on what suits you best)
<spiv> ultramage: e.g. everytime I start working on fixing a bug in bzr, I first make a new branch of bzr, and do that work in that branch.
<ultramage> in svk you can mirror into a subdirectory (mirrored branch) and make local branches next to them... and since they're all in a single local depot, you can merge across them
<ultramage> however I don't use that feature
<spiv> Right, bzr can merge between any branches that share history (regardless of whether they share a repo).
<maxb> ultramage: With bzr, think of the entire filesystem as your depot
<ultramage> if I have two independent things going on at the same time, I just make two quick checkouts
<spiv> ultramage: now imagine you can make multiple commits in those checkouts before those changes affect the original repo
<ultramage> I guess that approach is good if you want to make a bunch of local commits before you're done with everything
<ultramage> so I guess this is to avoid making a publicly visible dev branch in the remote repository
<spiv> Right, exactly.  If you only ever need a single commit to make a complete change ready for the main line of development that everyone is working on, then you don't need feature branches.  But if you e.g. want a development process where you develop a change, then it goes through code review or QA, then maybe gets further changes due to that, then a feature branch starts making lots of sense.
<ultramage> I have not used this approach because the extra commits make your local revision numbering go out of sync
<spiv> Well, using feature branches is orthogonal I think to whether you make the work-in-progress visible.  Certainly you can use them like a checkout that you don't share until its done, but you can also share your work-in-progress with them (rather than sharing it via landing half-done work on your trunk).
<ultramage> (so when I ran svk annotate later, I'd get local numbers instead of the remote ones... and even if I did get remote ones, I'd still have to figure out what the matching local ones are0
<ultramage> maybe bazaar tracks revision numbers for each branch individually  and this is not an isuse
<spiv> bzr has sequential revision numbers for convenience, and (although you rarely need to use them directly) unique revision IDs for when you need to refer to a revision independently of where it is in any individual revision history.
<spiv> Yes, a revision number is a per-branch attribute.
<ultramage> okay
<spiv> It's always "revision number X in branch Y"
<ultramage> hmm, question; if I check out http://svn.something.com/trunk, will my checkout's .bzr/repository directory only store data for the trunk branch?
<ultramage> I guess that's easy enough to test :D
<ultramage> yep, it does
<ultramage> so if I ever lose network connectivity and have the need to look anywhere past that branch, I'm out of luck
<spiv> You can use 'bzr init-repo' to make a shared repository; branches created under that directory will then share revisions.
<spiv> Or you can use 'bzr svn-import' to just mirror the whole SVN repo in one go.
<spiv> (and it takes care of making a shared repo for you)
<ultramage> I'll look at that :)
<ultramage> well, it looks exactly like a checkout, without the checkout :)
<ultramage> well, and it doesn't have the 'bound' attribute and has 'no-working-trees' and 'shared-storage'
<spiv> You can make a checkout with "bzr checkout BRANCH_DIR CHECKOUT_DIR".  If they're both on disk you can use --lightweight to avoid making a new copy of the revision history.  If you like, you can do "bzr co ." in the branch directory itself to just make the checkout at the same dir as the branch.
<spiv> Right, svn-import makes "branches" i.e. copies of the original repo, rather than checkouts bound to the original repo.
<ultramage> hmm.
<spiv> You could make checkouts directly from your SVN repo if you like in that repo made by svn-import.
<ultramage> I'm thinking
<spiv> They'll reuse the history store already present, but commit directly back to SVN.
<ultramage> how about a bzr checkout of root, and then bzr checkout --lightweight of that checkout?
<spiv> You'd have to fiddle with the settings of the bzr-svn plugin to make that work, it's not how bzr is designed.
<ultramage> that's probably the closest thing I can think of to my current setup
<spiv> I wouldn't recommend it, you'll be fighting bzr rather than working with it, and you're likely be dissatisfied with the result.
<ultramage> so I've yet to actually set up my files for testing... this is not good
<spiv> Why do you want a single tree containing the contents of every branch and tag (and trunk)?
<maxb> checking out the root of a svn repository using bzr-svn is not at all what you want to do
<spiv> The obvious reasons I can think of have better solutions.
<ultramage> yes, I know that doing an actual checkout of a project with 1000 tags is nuts
<ultramage> the idea of just putting a few select branches next to each other sounds nice
<ultramage> earlier you said "svn-import makes "branches" i.e. copies of the original repo, rather than checkouts bound to the original repo."
<ultramage> meaning that if I make a checkout of anything in there, and then commit from it, it will just corrupt my local imported data and never get to the original repo
<maxb> uh? no
<ultramage> I guess the main question is whether a commit operation into there is transitive
<maxb> oh, I see.
<ultramage> because starting an independent local fork of a project's central repository is not what I want to do :)
<maxb> Right, you'd want to checkout from the upstream repository
<ultramage> svk ensures I always have access to anything I need from the repository even when offline, so if I suddenly get the need to run svk annotate on some branch I normally did not check out, I can do that.
<ultramage> plus there's also the upside that all svk depots are simple svn repositories and can be hooked up to anything that reads svn repositories
<ultramage> the reason why I'm looking into bzr is that all svk development has halted years ago, it has data corruption issues on windows, it's perl-based and I never got it to actually install, and that none of the bugreports I submitted ever got taken care of
<ultramage> plus it can't handle svn:externals
<ultramage> ok, so first things first... is it possible to make two checkouts of the same remote branch, without occupying twice the disk space?
<maxb> Sure - the best way to handle this is a bzr shared repository (created with init-repo). Any branches / checkouts you create below the directory inited as a repository will store their revision history in the repository, not within the branch/checkout itself
<maxb> common data will be shared appropriately
<ultramage> I just made a basic checkout of a branch, and then ran bzr annotate on it
<ultramage> the revision numbers displayed are local to my checkout and have nothing in common with the original repository - so I cannot do anything with them unless I look them up in my checkout
<ultramage> it's the exact same issue as I had with svk's local depot approach - it makes the revision numbers go out of sync
<spiv> ultramage: if you look at the 'bzr log -r REVNO' for the bzr revision, it'll tell you the SVN revision
<ultramage> spiv: that would get very tedious very fast
<spiv> (it's possible that one of the GUI plugins like qbzr or bzr-gtk has integrated that into their annotate... it would make a nice improvement if it hasn't already been done)
<ultramage> I guess this is why noone uses revision numbers anymore when talking about revisions
<spiv> Hmm, I guess with qbzr's "bzr qannotate" when you click the line it shows you the revision in the lower pane, maybe that already includes the SVN revno
<jelmer> Yes, qbzr's qlog will show you foreign revision ids.
<spiv> (be nice to have an option to show the SVN revno in place of the bzr one though, I agree)
<ultramage> when I see a bugtracker entry saying "fixed in r17005", how do I determine which one that maps to in my checkout? or whether my checkout is older or newer?
<jelmer> loggerhead does as well
<spiv> ultramage: well, you can do "bzr log -r svn:17005" or whatever to talk to bzr in terms of svn revnos
<Tak> fewer people talk about revisions anymore because git and hg turned them into meaningless spam :-P
<ultramage> ah.
<ultramage> yes, it's why my first phase was throwing out all software that uses hashes
<ultramage> no total ordering, not even partial
<ultramage> I don't even want to imagine the hell it would be to do more complicated stuff without a GUI resolving those hashes for you
<ultramage> maybe that's why big projects' bugs take so long to fix - the developers are busy figuring out which revision is which
<spiv> Well, mostly you find it's enough to talk in terms of branch tips.
<spiv> But it depends on exactly what you're doing, of course.
<spiv> I wish that was the biggest problem with fixing bugs in large projects!
<ultramage> :)
<luks> there are projects without a mainline (e.g. linux), so I can see revision numbers not being useful there
<ultramage> yes, but I guess they worked around that by having artificial release numbers and use them as checkpoints
<ultramage> hah, even after checking out the root, the revisions are all shifted by 1, just like in svk
<ultramage> that's why they added a special root mirroring depot type
<ultramage> I guess this is the consequence of being able to add extra local branches into the same local repo as the mirrored data
<ultramage> question - when you people refer to some previous revision in your commit message, how do you refer to it?
<ultramage> do you open a second console window, ask bzr to look up the revision number you want, and copy-paste the revision id hash into your message?
<luks> I personally almost never use revision IDs
<luks> so, if necessary, I look up the revision number
<ultramage> ah, I see
<luks> I use append-only branches, so the numbers don't change once pushed to the central repository
<ultramage> this could be another artifact of centralized version control
<ultramage> usually when I'm fixing something, I leave a reference to the revision where the thing I'm fixing broke
<maxb> ultramage: It seems to me you are placing a little too much importance on revnos
<mgorny> hello
<mgorny> is it possible to get a unique identifier of a bzr tree (or at least revno --tree) without enforcing network activity?
<LenZ> ultramage: You may also want to look into tags for identifying specific changes. They are cheap in bzr.
<rubbs> when trying to do a bzr st I get this error on a parent branch. http://paste.ubuntu.com/523884/
<rubbs> basically says the dirstate file appears to be corrupt
<rubbs> the user was using bzr explorer when trying to merge files into this branch. He said he got a "Bad File Descriptor" error
<rubbs> here are the relevant log entries: http://paste.ubuntu.com/523895/
<rubbs> think I figured it out. I moved .bzr/checkout to .bzr/checkoutOld, did a lightweight checkout in another dir and copied the new .bzr/checkout dir to the old location. seems to have worked.
<vila> rubbs: That's indeed the blessed workaround
<vila> rubbs: It would be nice to better understand how this happened though
<rubbs> I'll dig around and find out if I can find more info for you. I'm not the one who had the issue, I'm just the janitor ;)
<rubbs> but I'll see what I can find, if I get enough info I'll file a bug
<rubbs> or add it to one of the others I found
<vila> thanks
<rubbs> np
<radix> Is there yet a tool that watches a bzr  branch for changes and sends notifications when it does (email, IRC, or whatever)?
<jelmer> radix: Hi
<jelmer> radix: Yeah, there was a daemon that does local branch monitoring and can send out emails.
<radix> jelmer: nice
<radix> jelmer: lp:??? :)
<jelmer> radix: I'm not sure where it lives, it was developed by a debian developer so I'm not sure if it's on Launchpad
<jelmer> radix: lp:bzr-hookless-email
<radix> jelmer: sweeet, thanks.
<radix> I'll probably hook up IRC notifications to that too
<Guest51764> Is there a merge method that ignores content changes (add / delete)? Some muppet made a branch in SVN by copying the folder, then SVN-deleting the sources, then SVN-adding the tree back again
<Guest51764> Ohh, guest
<jelmer> awilkins: no, there isn't anything like that (yet)
<awilkins> So when you merge this revision, you end up with a shower of conflicts (everything) as all the files get moved out of the way to make way for the "new" ones
<awilkins> git just works for this because it just views the before and after of the revision as the same content tree ; would there be a way to get around it by cherrypicking that revision and properly merging the rest?
<awilkins> Probably not, the file-ids are not going to match... bah
<jelmer> awilkins: yeah, that's the main issue. We need a way to make file ids converge
<rubbs> hrm... when I did the moving of checkout to chechout old thing. Now bzr explorer says there is no working tree.
<jelmer> awilkins: Otherwise you'll have to use this other magic merge indefinitely
<rubbs> fwiw I did copy a checkout into the .bzr directory from a lightweight checkout
<vila> rubbs: you copy the whole checkout dir or only the dirstate file in there ?
<vila> only the dirstate file is needed
<rubbs> whole checkout, should I just have done the dirstate?
<rubbs> oh, will fix that thanks
<vila> hmm, I fail to see what would change though... may be you should restart bzr-explorer ?
<rubbs> trying that now, as your suggestion didn't fix it.
<rubbs> I'm going to try branching from it and see if I can see the second branch.
<rubbs> if that works, I'll delete the original and branch to the original name
<rubbs> and rebind as necessary
<rubbs> weird. the new branch also reports as not having a working tree in B.E.
<rubbs> but it does.
<rubbs> should I try cleaning the tree and then doing a checkout?
<rubbs> when trying to clean the tree I get a "Nothing to delete" message, but it's got a working tree.
<rubbs> even weirder is that if I delete out the tree bzr st reports that i made changes by deleting everything out.
<vila> you did restart bzr-explorer ?
<vila> rubbs: Are you on windows ?
<rubbs> vila: yes restarted bzr-explorer, and I'm on Ubuntu, my coworker is on Windows. my instance of bzr explorer tells me I have no working tree
<rubbs> I've even tried branching directly from the branch it was bound too
<rubbs> to*
 * vila blinks
<vila> bzr info ?
<rubbs> vila: http://paste.ubuntu.com/523949/
<rubbs> it's bzr version 2.2.1 btw if that makes a difference
<vila> hmm, this shouldn't
<rubbs> yeah I'm getting stumped too
<vila> hmm, so I would try to trigger a dirstate update by doing some inocuous change
<vila> oh, or a bzr update
<rubbs> oh, i'll try that. (I should have thought about that
<vila> hmm, if you can afford such an update that is
<rubbs> all local network so shouldn't be a problem
<rubbs> ah... looks like a lock needs to be broken
<rubbs> I'll get him to do it as it's in his name. I'll let you know how it goes in a sec
<vila> k
<rubbs> k... got the lock broken, but bzr update still didn't fix BE problem.
<rubbs> BE still says the branch has no working tree
<rubbs> also, tried just did a "touch testing.txt" within the workign tree
<rubbs> bzr st correctly says it's unknown, but BE still thinks there's no working tree
<vila> rubbs: I'm lost :-/ Not being a BE user doesn't help iether :-/
<vila> rubbs: and you restarted BE after 'bzr st' saw the unknown right ?
<rubbs> yeah I'm not either, but coworker is. So this is somewhat important to figure it out.
<rubbs> yeah
 * vila scratches head
<rubbs> I'll do it again just to make sure
 * rubbs is banging his head against the desk.
<vila> because the problem disappears or because it's still there ?
<rubbs> still here. now I've got some permission thing when I try to merge, but I think I can figure that out
<vila> rubbs: you didn't copy the dirstate file between windows and ubuntu right ?
<rubbs> right, I did all my surgery on ubuntu
<rubbs> oh this is frustrating. I can browse the tree with bzr explorer, but hitting refresh still says the branch has no working tree
<benje> hello
<benje>  
<benje> i am using savannah and i would like to get help in use of bazaar explorer
<benje> i am creating local branch but when i try to run the command to internet branch i get tehe following message
<benje> bzr ERROR : Not a branch: "bzr+ssh://benje@bzr.savannah/nongnu.org/gxinterface/branch".
<benje> i cannot find the advanced in menu too as describ in documentation http://doc.bazaar.canonical.com/explorer/en/tutorials/foss-contribute.html
<benje> to log in to my account (but maybe only for launchpad )
<benje> i try the command in terminal but i get the same error
<maxb> You have a slash not a dot betweeen savannah and nongnu
<benje> how can we link project to internet server with bzr-explorer as i can work locally and put it once verified on internet server ? thanks
<benje> maxb: right, i get  it but i do a mistake on copy here
<benje> if i look to the savannah rep i see the .bzr
<benje> so why it's telling me not a branch ?
<maxb> I would imagine your URL is incorrect
<benje> i use this from savannah maxb
<benje> https://savannah.nongnu.org/bzr/?group=gxinterface
<benje> bzr branch bzr+ssh://<membername>@bzr.savannah.nongnu.org/gxinterface/branch
<rubbs> vila: ok, now this is weird. The windows guys are using bzr over an sshfs adapter (I'm going to change it so they use bzr+ssh from now on, as I think this was part of the problem). so on a whim, I mounted the drive to my local Ubuntu machine via sshfs, then I opened the "local" folder in B.E. and it seems to be working.
<benje> maxb you are right
<rubbs> but bzr+ssh:// does not work in B.E. at the same location.
<benje> maxb: if i try to got with http to bzr.savannah.nongnu.org/gxinterface no such file
<benje> ok rubbs but even i do this on terminal without explorer ;)
<benje> i try your method
<rubbs> benje: sorry was talking about my own problem not yours ;)
<benje> rubbs: but this seems the same ;)
<benje> to get access with bzr+ssh to a rep
<rubbs> not exactly. I'm having problems with a dirstate file being corrupted by B.E. seems like you're having "not a branch" issues
<benje> external dir
<maxb> benje: It is not working because that project does not have any branch there on the savannah server
<maxb> It just has a bare .bzr control dir with no content
<benje> yes i create it and try to commit my rep maxb
<benje> do you think i have to rsync first ?
<benje> rsunc ok
<benje> i don't understand what's happen :/ and what i am doing how can i make a brnahc on distant rep
<benje> brnahc branch
<benje> i just want to commit local to server
<vila> rubbs: I think you got something there and using bzr+ssh is certainly preferred (sorry for te delay, I EODed)
<rubbs> vila: yeah I think I'm going to try to kill the sshfs stuff and see if I can't do some magic with bzr+ssh. the problem is that it's the bzr+ssh that's not reporting the working tree correctly :/
<vila> rubbs: bzr+ssh is *not* supposed to handle working trees ! At least not today
<rubbs> vila: ah, so what I need to do is get them to have a local one and bind it to the dev server?
<vila> exactly
<rubbs> I c. I'll get that done
<rubbs> thanks for the advice
<benje> bye this was the problem https://bugs.launchpad.net/bzr/+bug/659763
<ubot5> Launchpad bug 659763 in Bazaar "bzr smart server can't handle UTF-8 user names, gives UnknownErrorFromSmartServer (affected: 1, heat: 15)" [Medium,Confirmed]
<mbt> I think I must just be a moron, but I have a merge that resulted in a conflict (which honestly I have never had happen before).  Is there somewhere online that explains what these conflict markers are and what they mean? The docs seem to skip that and just say that they're there.
<dash> mbt: conflict means there's two possible outcomes for each block of conflicted text
<dash> mbt: so one represents the change in the branch you're merging from, one represents the change in the branch you're merning into
<mbt> Right.  I understand the reason for the conflict.  What I don't understand is the format of this thing.  Which is which?  What are the >>>>> and <<<<< and ===== supposed to actually tell me?
<dash> the bit between >>>> and ==== is one block
<dash> the bit between ==== and <<<< is the other.
<dash> there are also .OTHER and .THIS files containing the entire contents of the conflicted files
<dash> and potentially .BASE, depending on your options
<mbt> I'm still not getting it.  http://pastebin.com/MJdchVSu <-- what block is what?
<mbt> Oops, incomplete paste, try this one: http://pastebin.com/VdCypxAg
<dash> the first block (2-12) is what's from your tree
<mbt> From which tree?  There working copy being merged into?
<dash> right
<dash> the second, 12-34, is from the merged-in branch.
<mbt> So that's as it was before the merge
<dash> same for 36-37 and 37-55
<mbt> Line 35 is identical to both branches, then?
<dash> right, it's not inside hte conflict markers
<dash> a lot of editors provide support for this format; what do you use?
<mbt> Emacs.  But I wasn't understanding what I was seeing, and it's all sorts of colorful, and I just wanted to know what I was looking at before I went any further.
<dash> mbt: so your modeline probably says SMerge
<mbt> Now the options for keep this and throw that away make sense though.
<dash> yep. hooray.
<mbt> Yes, it is in SMerge minor mode.
<fullermd> Well, technically, it doesn't mean it's identical.  Just that it merged without conflicts.  But in the case of a single line in the midst like that...
<mbt> Thank you muchly for the explanation, dash!
<dash> <3
<bob2> smerge is super awesome, aside from the default fruit salad colours
<mbt> lol, I don't know what the defaults are since I use a colored theme on my Emacs, but the yellow was painful to look at.
<bob2> I guess I mean 'the defaults are terrible and most color-themes don't fix it'
<mbt> Whoo.  I believe I have resolved all my conflicts successfully.
<mbt> Hopefully, I don't run into that again... but I guess now the next time I do, I know what I am looking at.
<GungaDin> how can I tell at what revision a line was deleted from a file? (I can see who initially wrote it with bzr qblame.. but not when it was deleted...)
<mbt> That sounds like a problem that could be solved with bisection.
<mbt> If you don't have it already, grab a hold of a copy of the bzr-bisect plugin (https://launchpad.net/bzr-bisect) and see if that does what you need.
<mbt> You can give it a starting point and an ending point (essentially, a revision known to have the line you're looking for, and a revision known to not have that line) and then you can bisect until you find the first version that doesn't have it.
<GungaDin> thx
<dash> hmm
<dash> i use bzr as a frontend to an svn repository and i'm trying to post diffs to a reviewboard instance. reviewboard seems to want svn style diffs, not bzr-style ones. i have seen mentions of an 'svndiff' plugin that might produce this, anbyody know where i can find it?
<bob2> http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-svn-projects.html#svn-diff-style-patches ? (I dunno how reviewboard fits in)
<dash> yeah i just saw that.
<dash> trying it now
#bzr 2010-11-02
<ToyKeeper> Hi.  Er, what's a good way to replay some revisions (but not all) into a new repo?  Like, if I wanted to build a new repo with only the odd-numbered revisions from and old repo?
<ToyKeeper> (or more accurately, copy the history for some files but not all)
<ToyKeeper> I don't care about preserving revision IDs, but I'd like to keep the original time stamps and commit messages and preferably info about the original committer.
<bob2> is fastexport still a thing?
<ToyKeeper> Yes, looks like fast-import / fast-export is still around, and includes a promising-looking filter command.
<ToyKeeper> (much better than last time I tried to filter its output manually)
<ToyKeeper> Now, if I can just get the fast-import command to produce a repo instead of a traceback...  I should be golden.  :)
<jbowtie> I want to build a cache of metadata for my foreign VCS (tfs, of course) - can I just put it in a file/directory under .bzr?
<lifeless> sure
<lifeless> .bzr/tfs
<lifeless> or
<lifeless> there is a per-tree plugin namespace - IIRC its bzr-meta/ in the working tree
<jbowtie> I know jelmer wanted to build something common for all the foreign VCS to leverage off of, but I've got a server that is giving me grief.
<jbowtie> lifeless: thanks; figured it was so but just checking
<spiv> Our version numbers in trunk seem a bit odd: doc/en/release-notes/bzr-2.3.txt says 'bzr 2.3b3', but __version__ in bzrlib/__init__.py says 2.3.0dev3
<tenchi> Hi everyone
<tenchi> Please help me: I updated a ubuntu server to which I connected with bzr explorer. I tried to push a new revision and got the following error:
<tenchi> ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
<tenchi> Permission denied, please try again.
<tenchi> It was working allright before the update
<tenchi> or is this missing on my computer?
<tenchi> YEAH
<tenchi> solved it
<tenchi> thanks anyway
<eagles0513875|2> hey guys :) quick question do i just install the bazaar package in the lucid repos and im good to go?
<henninge> Hi!
<henninge> What's this error message supposed to mean? I don't have a clue.
<henninge> henning@dustpuppy:$ bzr branch lp:chromium-browser/translation chromium-browser
<henninge> bzr: ERROR: Permission denied: "Cannot create 'translation'. Only Bazaar branches are allowed."
<fullermd> I think lp: branches are usually 3-level.  lp:user/project/branch
<henninge> fullermd: this is a series branch, I got the url straight off Launchpad
<henninge> maybe that's the error, though
<fullermd> Looks like.
<fullermd> % bzr info lp:chromium-browser/translation
<fullermd> bzr: ERROR: Permission denied: "Cannot create 'translation'. Only Bazaar branches are allowed."
<henninge> fullermd: never mind, I missed a character while coping ...
 * henninge feels silly
<henninge> the branch is called lp:chromium-browser/translations
<fullermd> Silly declensions.
<eagles0513875|2> hey guys is there a portable client of bzr or a portable cli for bzr?
<Tak> portable?
<eagles0513875|2> Tak: something i could install on a pendrive
<Tak> ah
<eagles0513875|2> would somethign like that be easy to develop for those developers who are constantly on the move so to speak?
<fullermd> Well, bzr by itself, as a pythong script, runs just fine out of a source tree.
<eagles0513875|2> does one already exist or is it something that would need to be coded
<fullermd> So on *nix it's trivial.
<fullermd> I don't know how much difficulty bundling it up with an interpreter makes it.
<luks> I think the windows package would work fine
<luks> but you would need some batch file to set up env variables with the config file location
<eagles0513875|2> im using launchpad to host my bzr but i have no way of pushing to it
<eagles0513875|2> thats why im asking if there is a portable app
<luks> https://answers.launchpad.net/bzr/+question/91004
<luks> see the accepted answer
<luks> the main idea is to set the BZR_HOME environment variable
<eagles0513875|2> thanks luks :)
<eagles0513875|2> will email that link to myself to setup when i get home
<maxb> When I have a MP in Approved state, am I supposed to ask someone to land it if the reviewer didn't, or will someone deal with it presently anyway?
<jelmer> maxb: The patch pilot will generally deal with it.
<jelmer> I think spiv's out sick today though.
<dash> it's really great that bzr-svn makes 'bzr merge' work in svn working copies
<dash> it's not so great that it wants to fetch 180M+ from the svn server in order to make it work
<dash> and doesn't seem to cache much
<dash> ok 200M+
<eagles0513875> hey guys if i install bzr on windows what would that allow me to do
<eagles0513875> does that give me bzr command like push to my bzr repo on launchpad?
<vila> eagles0513875: yes
<eagles0513875> ok sweet thanks vila i thought it was to host on your own machine a bzr repo
<vila> eagles0513875: well, that's only slightly harder than on *nix but possible too
<eagles0513875> i would rather have it hosted on lp tbh
<jelmer> dash: That's a disadvantage of lightweight checkouts (as svn working copies are)
<jelmer> dash: imho caching would be a bad idea, it would mean that we basically turn the local working copy into a heavyweight checkout which seems besides the point.
<jelmer> 'evening vila, eagles0513875
<vila> jelmer: _o/
<jelmer> vila: before you disappear, I wanted to ask you if you had any idea what's going on here: http://pastebin.ubuntu.com/524514/
<jelmer> I've been getting this error in bzr.dev for some time now
<vila> jelmer: I'm disapearing ? (Working from an unsual place, will be back at home Thursday (but off tomorrow))
<jelmer> vila: for dinner I mean :-)
<vila> jelmer: Ha ! My favorite failing test :-(
<vila> jelmer: maverick ?
<jelmer> natty, I live on the edge
<vila> jelmer: suffer from it then, kthkbye
<vila> cough
<vila> you're doomed until spiv provides a natty package from his PPA with his patch to paramiko
<vila> jelmer: 90% sure
<jelmer> ah, it's a paramiko bug?
<vila> jelmer: if I'm right that's paramiko trying IPV6 when it should try IPV4 and wrongly failing
<jelmer> vila: that would make sense as I have some amount of IPv6 set up here
<vila> given that paramiko upstream still haven't take spiv's patch into account, I guess he'd better propose it for Ubuntu itself
<jelmer> vila: do you know where his patch lives?
<vila> jelmer: you don't have to to hit the bug :-(
<vila> hmm, gimme a sec
<vila> spiv's PPA: https://launchpad.net/~spiv/+archive/packaging-test
<vila> bug #579530
<ubot5> Launchpad bug 579530 in Bazaar "paramiko does not try all available address families (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/579530
<vila> with associated branch
<jelmer> vila: Much appreciated, thanks
<vila> jelmer: let me know if it works for you or file a bug if it don't :-) I will add a natty slave on babune soon anyway so I *will* know too soon enough ;)
<eagles0513875> hey gusy i have a question why does my bzr url say +junk in it ? bzr push lp:~eagles051387/+junk/BRANCHNAME
<jpds> eagles0513875: Because it's not assigned to a registered project?
<eagles0513875> ahh ok
<eagles0513875> are there any restrictions to the types of projects one can register?
<vila> eagles0513875: I'm sure this is fully answered on the lp site itself, but roughly, as long as it's free, it's allowed
<vila> eagles0513875: https://launchpad.net/+tour and https://help.launchpad.net/ comes to mind
<eagles0513875> ok will look
<vila> eagles0513875: and don't get afraid by all the features, you can generally start by using only the ones you're interested in
<eagles0513875> vila: ok question for you. licensing what would i need to do for that since im not goign to be releasing this under the gpl or any other open source license
<vila> IANAL :)
<eagles0513875> ?
 * eagles0513875 confused as to there being a hidden innuendo
<vila> I have no idea about what the default is in this case, if your code is public... anybody can download it, but you should still retain the copyrights even if you don't explicitly says so
<mgz> you need to pay a fee to have a private, non-free launchpad branch
<vila> I Am Not A Lawyer
<eagles0513875> mgz: even if i dont register the project
<eagles0513875> vila: wouldnt recommend saying IANAL not very family friendly :p
<mgz> there are other places you can host code with bzr that don't cost anything, but you want fancy launchpad features but don't want to share your code, you need to pony up
<vila> eagles0513875: well, I'm not a native engrish speaker but I've read the acronym in many places ;)
<eagles0513875> lol vila
<mgz> just sticking your project under ~me/+junk and hoping other people don't branch it might be okay, but the source is available then, you may as well include a clear license
<eagles0513875> mgz: thats not my issue my issue is i would like to make some money off the project i have coded, so if i license it under the gpl i could charge people for support or something like that?
<mgz> you could. personally, I'd *either* worry about money now and do business plan before code, *or* start hacking now and worry about how you'll get fed later.
<eagles0513875> humm
<eagles0513875> ok
<vila> eagles0513875: hmm, yes you can, you can even charge them for selling your code, the GPL doesn't forbid that, it only requires that people can also get it for free, as amazing that it may sound, this has worked for decades
<eagles0513875> ya
<eagles0513875> i need to sit down and read the gpl
<vila> mgz: by the way: hi ! :-) And bye, I'm off ;)
<mgz> bye :)
<peitschie> mornin everyone :)
<spiv> Good morning!
<jelmer> hey peitschie, spiv
<spiv> jelmer: fwiw, I have submitted that paramiko fix to Ubuntu as well as upstream, but have got no response from either place :/
<jelmer> spiv: oh, ok
<peitschie> hi spiv, jelmer :)
<jelmer> I didn't see it in the upstream bts so I filed it there again and I filed a bug in Debian
<mgz> upstream paramiko were using launchpad for tracking bugs.
<mgz> even after they git switched.
<mgz> basically, the problem seems to be there is no more upstream.
<spiv> jelmer: https://bugs.launchpad.net/paramiko/+bug/579530 https://bugs.launchpad.net/ubuntu/+source/paramiko/+bug/638675
<ubot5> Launchpad bug 579530 in Bazaar "paramiko does not try all available address families (affected: 1, heat: 6)" [Medium,Confirmed]
<spiv> (I see your comment on the first one, justing listing here for completeness)
<jelmer> spiv: upstream no longer uses launchpad though
<mgz> nor "commit" apparently.
<spiv> jelmer: well, http://github.com/robey/paramiko/ says to use Launchpad for bugs
<jelmer> spiv: oh, I hadn't seen that. It has "issue tracking" enabled in the Github repo though
 * jelmer is confused
<spiv> Although I agree that as a matter of observed fact there doesn't seem to have been much activity on the Launchpad bug tracker...
<spiv> jelmer: I think it's basically as mgz says: upstream is basically inactive
<spiv> So the question of where the active bug tracker is is a bit academic.
<jelmer> there have been 3 issues filed on the github repo in the last week (including mine)
<jelmer> and robey's followed up there a couple of days ago
<spiv> Hmm, but only about the website being down?
<spiv> Still, some response is better than zero.
<spiv> Meanwhile https://bugs.launchpad.net/paramiko is still accumulating bugs, most recent open bug filed less than 2 weeks ago...
<jelmer> hmm
<mrfrenzy> anyone here uses bazaar with zend? I really can't find any docs about integration
<bob2> what is there to integrate?
<mrfrenzy> there are nice plugins for svn and cvs that lets you do commits etc from within zend
<AfC> system("bzr commit") ?
#bzr 2010-11-03
<wallyworld> often when doing a bzr switch to change to the working tree of a different branch, it says there are conflicts and copies a dir to foo.moved, but the files in that directory are only pyc files. should bzr be able to handle this better? ie know that pyc files are safe to delete and hence no conflict after all?
<lifeless> there is a wishlist bug for this.
<wallyworld> ah ok. thanks
<wallyworld> been seeing the issue a lot lately with the branches i am working on
<spiv> vila has been doing some work on this
<wallyworld> excellent. look like it's all under control :-)
<bob2> is that just due to some .pyc files being commited?
<abcminiuser> Hey all
<abcminiuser> I'm trying to make a public BZR mirror of a Subversion project of mine, for other's convenience
<abcminiuser> So far I've used bzr-svn to fetch the Subversion contents
<abcminiuser> And I'll push it to the public branch, but how can I make it fetch new subversion changes later on?
<abcminiuser> Do I run bzr-svn again to update, or something else?
<spiv> bob2: it's generally due to switch wanting to delete a versioned directory of .py files
<spiv> bob2: but the directory contains (ignored) .pyc files, so it can't.  Then switch back to the branch with the dir and bzr will try to re-add the directory but can't because it already exists, and you get dir.moved etc.  tla's precious/junk distinction is one way to solve this.
<spiv> Heh.
<peitschie> abcminiuser: you will want to run bzr pull <svn url> most likely
<peitschie> abcminiuser: is the bzr branch going to be getting commits independent of the svn branch?
<abcminiuser> Not svn-import?
<abcminiuser> No, straight mirror
<peitschie> abcminiuser: if it's a straight mirror, then from your own checkout of the bzr-svn mirror, running bzr pull should do the trick :)... you don't need to re-import after the branch has been created
<abcminiuser> Pushing it to Launchpad now, I'll do a test SVN change after that and see if my BZR mirror script works
<abcminiuser> Thanks!
<peitschie> abcminiuser: nps :)
<abcminiuser> Mmmm, seems to work great
<abcminiuser> Now I've got public SVN, GIT, HG and BZR mirrors
<mkanat> <glob> the 4.0 installer now includes bzr :)
<mkanat> So Windows users who install Bugzilla 4.0 will get bzr automatically. :-)
<lifeless> :)
<soren> I'm curious why bzr doesn't use setuptools?
<soren> (or distribute for that matter)
<maxb> It seems to me that plain old distutils is serving bzr's needs just fine
<soren> maxb: I just see bits and pieces in bzr's setup.py that would be simpler with setuptools and wondered if there was any particular reason not to use it.
<jelmer> hi Soren, Max
<soren> ...mostly because I'm having to make a similiar decision for another project, and looking at what bzr does is usually a good way to learn what the right thing to do is.
<jelmer> soren: I'm not sure what exactly the argument in Bazaar's case is, but I usually avoid setuptools because it's another dependency.
<jelmer> soren: What functionality in particular does setuptools provide that bzr's setup.py reimplements at the moment?
<soren> jelmer: For one, I find find_packages quite useful.
<maxb> I'm a bit unclear on the whole setuptools/distribute fork mess and future maintenance situation, which makes me shy away from them
<maxb> And I have found setuptools to be a mildly irksome extra dependency when installing python packages on older distros such as you tend to find on work servers
<soren> My project depends on python 2.6 anyway, so older distros aren't much of a concern :)
<soren> Do you guys have similar reservations about pkg_resources?
<jelmer> soren: Yeah, find_packages() is quite convenient. I By itself I don't think it's worth the extra hassle for users to install another package though.
<jelmer> Is distribute going to make it into the standard distribution?
<soren> My crystall ball is out for repairs, I'm afraid.
<jelmer> :-)
<jelmer> soren: bzr doesn't have any external (mandatory) dependencies at the moment, so pkg_resources isn't really useful for us. I can see the benefits of it, especially in Windows environments where not every other python library is packaged
<jelmer> Though I should say I have zero experience using pkg_resources.
<soren> I'm not going to use it to manage external dependencies, actually. I was meaning to use it to have a reasonably portable way to get access to some files I ship (templates for various things). In Ubuntu packages, they're in /usr/share/nova, if people install it themselves, they might be in /usr/share/local/nova or perhaps even in an egg. On Windows, who knows where they have to go?
<soren> ...and somehow I need to be able to read them from my python code.
<soren> That seems to be a problem pkg_resources solves.
<maxb> Doesn't pkg_resources entail dumping the resources into directories on sys.path?
<soren> I'm not sure yet.
<soren> I didn't bother looking to closely yet, since if bzr had good, philosophical reasons to not use pkg_resources, I woulnd't bother looking at it too deeply.
<soren> maxb: From what I can tell, bzrlib's resource_string does the same thing (requires dump resources in sys.path).
<soren> maxb: e.g. /usr/share/pyshared/bzrlib/help_topics/en/diverged-branches.txt
<soren> Maybe it's my debian packaging background speaking, but it just feels so utterly wrong.
<soren> lifeless: I'm sure you have an opinion on this?
<soren> Does bzr support being distributed as an egg?
<dash> soren: not sure why you'd want to
<soren> dash: I don't. :)
<soren> dash: I'm just curious, because if it does, there's some code I don't understand how will work in that environment.
<maxb> soren: hmm.... actually how does launchpad run it? I think it might run it from an egg
<maxb> Yes, I think it actually does
<soren> How would I go about building such an egg? "python setup.py bdist_egg" just says "error: invalid command 'bdist_egg'"
<soren> I'm specifically wondering how bzrlib.osutils.resource_string can work when the files live in a zip'ed egg.
<lifeless> soren: ?
<soren> lifeless: Let me dig up the context again.
<soren> lifeless: Ah, yes, bzr puts stuff like help topics in the python path instead of in /usr/share/doc or whatnot. That seems utterly wrong to me, and I was wondering if you had an opinion on it.
<lifeless> soren: python path is defined on windows; /usr/share/doc isn't.
<soren> lifeless: That doesn't make me feel less dirty putting things there on Linux. Perhaps I've turned into a bit of a purist. I'm not sure.
<soren> lifeless: Had it been anything other than bzr that did it, I would have considered it a bug. Now I'm not sure.
<lifeless> soren: IIRC there really wasn't any simple answer
<lifeless> soren: but if there is a defined protocol that we can use to make this work on win32/mac & [li|u]nix I'm sure folk would be happy to change.
<lifeless> soren: the big thing though, is that the abstraction really shouldn't live in bzr : this is a problem many many many packages face.
<soren> lifeless: I half started working on a utility function that would be able to use stuff embedded in an egg, or in sys.path or in /usr/share/project, but I lost my will to live halfway through.
<soren> lifeless: pkg_resources wants to be that abstraction, but it relies on this non-python stuff being in the python path and it really rubs me the wrong way.
<lifeless> soren: pkg_resources would be the place to fix it.
<maxb> I suppose that Python has borrowed the concept from Java in some ways, where it is considered normal for resources to lie next to code
<soren> Unfortunately, I'm in the Getting Stuff Done business, moreso than the Argue Over Every Little Pointless Detail business, so I'm just going to have to live with the status quo, I suppose.
<lifeless> soren: you're going to die a little inside.
<lifeless> soren: with every upload
<Glenjamin> hi guys, i'm having trouble getting bzr-svn to make a bazaar branch from my svn server
<Glenjamin> is there another approach I can take?
<maxb> Glenjamin: give details so people can help! :-)
<Glenjamin> halfway through loading revisions I get SSL negotiation failed: SSL error: parse tlsext
<jelmer> Glenjamin: hmm, I've seen that one before
<Glenjamin> although thinking about that error, it might not be related to bazaar
<jelmer> IIRC it had to do with packets that were too big
<jelmer> Glenjamin: can svn check out that revision without problems?
<Glenjamin> yes, and bazaar will happily interact with that as a lightweight checkout
<jelmer> Glenjamin: I don't mean the tip revision but the problematic revision
<Glenjamin> oh, lemme try and figure out which one it is
<Glenjamin> aha, managed to get that error from the svn client then
<Glenjamin> must be server related
<zyga> lifeless, could bzr homepage use canonical/ubuntu brand elements like many other ubuntu-affiliated sites do?
<lifeless> thats a good question
<lifeless> but not one I have an answer to
<lifeless> plus its kindof complex, what with bzr being a GNU project too - its somewhat more standalone
<zyga> lifeless, true but currently is showes a ubuntu-y affilitation in a bad (ugly) way
<zyga> lifeless, perhaps using ubuntu community theme + smallish hints of canonical support would look nice
<zyga> lifeless, another question is for bzr big brother, lauchpad
<zyga> lifeless, is a theme change something to consider?
<lifeless> zyga: jml will be discussing lp with the canonical design folk
<lifeless> its really a very separate discussion to bzr
<zyga> lifeless, who is jml?
 * zyga remebers you mentioned that nick earlier
<lifeless> LP product strategist
<lifeless> aka product manager
<lifeless> you might say that hes the 'what' guru for LP, and I'm the 'how'
<Tak> but who are the where and the why?!
<zyga> lifeless, thanks for the info, I look forward to changes in that regard
<gthorslund> lifeless: since you are the 'how', could you help me with some merges? got one for each of the bugs in https://bugs.launchpad.net/bzr-bisect . (but only one bug would end up being fixed, the other one just reproduced with a test case (or two))
<lifeless> gthorslund: of launchpad, not bzr.
<lifeless> gthorslund: however, I'm sure someone here can help you :)
<lifeless> perhaps jelmer
<gthorslund> lifeless: thx
 * gthorslund looks around for jelmer 
 * jelmer crawls out of his corner
<jelmer> gthorslund: is there an official maintainer of bzr-bisect? I don't remember who originally wrote it.
<jelmer> lifeless: you're up early!
<lifeless> jelmer: this isn't early - 0730
<jelmer> lifeless: Oh, ok - Sorry, I keep forgetting you're in NZ now
<lifeless> :)
<gthorslund> jelmer: can't find one. Jeff Licquia, Daniel Watkins, James Westby are in the log
<jelmer> gthorslund: ah, I guess Jeff is the original author.
<gthorslund> jelmer: Vincent Ladeuil fixed a minor bug for me once too
<gthorslund> yes, he had first commits
<jelmer> gthorslund: I'd be happy to do a review, can you add me to the MP as reviewer?
<gthorslund> jelmer: done now for https://code.launchpad.net/~gthorslund/bzr-bisect/539937-subtree/+merge/39785
<gthorslund> jelmer: https://code.launchpad.net/~gthorslund/bzr-bisect/538025-doc-script-exit-code is already approved by Martin Pool (but not merged)
<gthorslund> hi vila! I was about to annoy you a bit before, but since you where not here I annoyed lifeless instead who found jelmer for me in a corner :)
<vila> gthorslund: hehe, I'm glad they helped you ;) I just arriving from a whole day car travel so I won't be here long not very effective either ;)
<vila> ...but my tyop-fu is still strong ! s/I just/I'm just/ s/not very/nor very/
<gthorslund> vila: I'll head out helping my daughter with some homework so I'll not annoy anyone much more now ;)
 * fullermd hopes you drive better than you type...
<vila> fullermd: no problem, I drive with my feet
<fullermd> I always figured that was how you typed...
<vila> :)
<glyph> Normally if I mess up a commit message, I do 'bzr uncommit' and then do it again.  But I just noticed a wrong commit message that is about 5 revisions ago (although the revision is still not pushed).  How can I edit the log message?
<gthorslund> glyph: don't think you can, but it could be a nice feature to allow it and keep versions for log messages too.
<peitschie> mornin everyone :)
<jbowtie> Morning.
<jbowtie> I think my testing really did kill a Codeplex TFS server (TFS14)
<jbowtie> Hmm. Or maybe CodePlex is just having infrastructure issues.
<jelmer> 'evening
<jelmer> jbowtie: Ah, you're trying bzr-tfs against codeplex?
<jbowtie> jelmer: Yes, trunk has been working against it for the last couple of days.
<jelmer> jbowtie, nice!
<jbowtie> jelmer: Thought you'd be happy. But I seem to have killed one of their servers (or maybe they're just rebooting it?)
<jbowtie> Yeah, it seems to be some of their infrastructure stuff, might just have to wait a few hours for them to get it sorted.
<jelmer> jbowtie: oops..
<losing> Anyone familiar with this error: "bzr: ERROR: Tree transform is malformed [('versioning no contents', 'new-208')] "
<losing> happens after a bzr up
<spiv> Good morning.
<spiv> losing: which version of bzr?
<losing> 2.1.1
<losing> it's not the end of the world as that branch can be deleted and recreated, but I found it rather cryptic
<spiv> Hmm, it *might* be fixed in a later release: there are some possibly related fixes in 2.1.3 / 2.2.1
<spiv> So I'd try upgrading
<spiv> If that doesn't fix it, please file a bug
<losing> fantastic, thanks spiv
#bzr 2010-11-04
<mgz> http://retout.co.uk/blog/2010/11/03/gnash_from_git <- there was really no prospect of progress on savannah?
<mgz> losing: your earlier problem is bug 632704 perhaps?
<ubot5> Launchpad bug 632704 in Bazaar "Can't merge a directory deletion in a wt with a pending subdirectory deletion (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/632704
<peitschie> mgz: I thought they were getting help with savannah... any idea wats stalled?
<mgz> nope. will poke through the mailinglist archives see what's been said.
<losing> mgz: yep, you are correct
<mgz> peitschie: from January -> https://lists.ubuntu.com/archives/bazaar/2010q1/066291.html
<jbowtie> Strange. Just added support for checking out TFS branches, but bzr info shows me that I created a standalone tree instead of a checkout.
<mgz> losing: metoo it, vila may be interested
<losing> mgz: not sure what you mean.  Do you want me to add a comment with some useful details?
<mgz> well, if you have any that would be good. I just meant doing <https://bugs.launchpad.net/bzr/+bug/632704/+affectsmetoo>
<ubot5> Launchpad bug 632704 in Bazaar "Can't merge a directory deletion in a wt with a pending subdirectory deletion (affected: 1, heat: 6)" [High,Confirmed]
<peitschie> mgz: thats what I remembered seeing as well...so it seems  that the move to bzr+ssh has stalled somewhat... sftp would definitely be slow as 3-day old porridge...
<jbowtie> Maybe I'm missing some implementation for bind?
<losing> gotcha
<mgz> not an area I've looked at I'm afraid jbowtie, you probably need jelmer if you get really stuck.
<peitschie> mgz: http://savannah.gnu.org/support/?107077
<peitschie> mgz: (links to the discussion threads are down so I cant see what's progressed since march this year)
<jbowtie> mgz: It's good, I'm just walking myself through the code path for bind() to see if I'm missing any implementation.
<pifantastic> Today is not my day.  Just got the following error after committing to launchpad: http://pastie.org/1271091
<pifantastic> that commit hasnt shown up yet on launchpad
<pifantastic> I think it may be lost in the ether
<mgz> what fun.
<mgz> bug 304545 may be related.
<ubot5> Launchpad bug 304545 in Launchpad Bazaar Integration "ProtocolError for xmlrpc while pushing branch (affected: 0, heat: 0)" [Medium,Triaged] https://launchpad.net/bugs/304545
<mgz> diagnosis. suggests just trying again may work.
<pifantastic> trying again gave me a TooManyConcurrentRequests error
<pifantastic> I wonder if I could merge back and try and recommit
<mgz> ha. probably need to wait for the last process to give up.
<mgz> I'd file a new bug against launchpad-code with your traceback.
<pifantastic> in the mean time, where is my commit? :P
<pifantastic> im not sure how to recover it so I can try again
<mgz> safely on your drive, thanks to the wonders of dvcs.
<pifantastic> good point :)
<pifantastic> good heavens, now getting Server denied check_authentication  from launchpad
<pifantastic> I think im going to step away
<pifantastic> ah there we go
<pifantastic> commit looks find on lp
<pifantastic> Im guessing the error was in the XML returned from lp after the request
<pifantastic> maybe a malformed response
<peitschie> pifantastic: you really pissed off some computer god somewhere i think!
<pifantastic> it's been one of those days
<jbowtie> Hmm. bzr.bind fails silently.
<jbowtie> I would expect it to write something to branch.conf (bound_location=xxx)
<spiv> jbowtie: :(
<jbowtie> Oh, I'm not setting self.base in my __init__
<jelmer> jbowtie: have you tried running the ControlDir tests against the tfs control dir implementation?
<jbowtie> And branch.set_bound_location just swallows the exception, apparently by design.
<jbowtie> jelmer: I've only just started hooking the implementations to the various test suites; clearly I need to accelerate that.
<jbowtie> jelmer: checkout/bind/unbind was really the last piece I wanted to implement before the big testing push.
<jbowtie> Now I have some confidence that implementation is far enough along to be worth the testing/refactoring cycle.
<jbowtie> Yay, checkout/bind/unbind works!  Now on to hooking up the all the tests!
<jbowtie> "No module named layout.test_custom" running bzr selftest, any clues?
<jbowtie> nvm, it's a missing directory error I reported on the mailing list back when.
<glyph> Hey
<glyph> If I do some commits on a machine where I forgot to do 'bzr whoami'
<glyph> is there a way to edit history to change the revision author?
<beuno> glyph, there is not
<glyph> wow, really?
<glyph> is there a way to edit log messages?
<mwhudson> no
<mwhudson> well, you can fix both things by rebasing of course
<glyph> mwhudson: rebasing, or at least the rewrite plugin, doesn't seem to be sufficient
<glyph> it remembers the (wrong) author and introduces a distinct 'committer' field
<mwhudson> well, "some kind of rebasey operation"
<glyph> plus there is no way to edit log messages as you rebase
<spiv> glyph: in principle rebasing is the only way to do that, it may be the bzr-rewrite plugin is a bit lacking here though.
<glyph> spiv: Yeah.  I'm fine with rebasing
<spiv> You could use (abuse?) bzr-fastimport for this, it has tools for filtering/editing the exported revs.
<glyph> Basically I just want an easier way than copying patches to just do 'bzr uncommit; bzr uncommit; bzr uncommit; bzr ci; bzr ci; bzr ci;'
<glyph> spiv: I confess I've never really understood the purpose of fastimport
<glyph> in particular, I don't understand why bzr-svn isn't just fast by itself and it needs a whole other plugin to help it along
<spiv> glyph: fastimport isn't especially related to svn
<spiv> glyph: it's a reasonable request, and I think the rewrite plugin ought to accomodate it.
<spiv> (after all, the rebase plugin clearly already has most of the infrastructure required)
<spiv> glyph: tell you what, I think I can see a half-baked way to hack this into bzr-rewrite, give me a few minutes and let's see...
<spiv> glyph: to be clear, you want to take revisions that say 'committer: Foo' and rewrite them to say 'committer: Bar'?
<glyph> spiv: author: Foo to author: Bar, actually
<glyph> spiv: but yeah, that's the general idea.
<spiv> glyph: and leave the committer: alone?
<glyph> spiv: the committer: too
<glyph> spiv: basically it's a machine where somehow my 'bzr whois' somehow got to be 'glyph@localhost'
<glyph> but I am generally interested in rewriting / cleaning up history
<spiv> Ok, so it's rewrite 'glyph@localhost' anywhere it appears in committer/authors.
<lifeless> spiv: I would love for someone to turn my manifesto into a reality; I think it would meet a missing 'must have' component for bzr in a tasteful way :)
<spiv> lifeless: yes, it would be nice.
<glyph> lifeless: which manifesto is this?
<lifeless> glyph: history editing support
<glyph> lifeless: oh.  Yes, that would be great.
<lifeless> glyph: theres a cultural knee-jerk against it in bzr-land, which I tried to inject reason into.
<glyph> lifeless: you know what would be really extra great, would be integrating it into 'bzr qlog' (or a tool like it) so that revisions which have been pushed show up in a different color than ones which haven't
<lifeless> http://osdir.com/ml/bazaar/2009-06/msg00338.html
<glyph> lifeless: One use-case you don't talk about in there is the 'open source prep-work' case
<glyph> I have a proprietary repository, it has a bunch of proprietary crud in it, I start working on open sourcing it, and I need to delete the revisions which contain large proprietary opaque blobs, but I don't want to lose _all_ the history
<spiv> glyph: fastexport is currently an ok way to do that, IIRC.
<lifeless> glyph: that's covered really
<glyph> spiv: OK, good to know.
<glyph> spiv: where's the documentation for fastimport?
<lifeless> glyph: once you break the history chain, its a rewrite edit full stop - in any system
<glyph> lifeless: Yeah, I'm aware of that :)
<lifeless> glyph: and thus that use case is covered?
<glyph> lifeless: uh, I don't think so?  at least, *I* don't know how to do it with fastimport
<lifeless> glyph: so, I was saying in that doc - 'these are things we need to support'
<glyph> lifeless: anyway, the other use-case that I have is ... it's not really a direct use-case in a sense
<glyph> I am having trouble expressing it
<glyph> basically it's editing unpushed stuff
<lifeless> glyph: so use case being covered means : 'if the mythical software in that doc exists, what you want to do would be doable'
<glyph> lifeless: oh!
<glyph> lifeless: yes, absolutely
<glyph> lifeless: your proposal there covers the use-case completely, i'm just saying it's a very strong motivation to _do_ those things :)
<lifeless> editing unpushed stuff - thats a simple case of history-polishing + patch-management
<glyph> lifeless: Yes.. I don't have any unique requirements there either
<glyph> Just an observation
<lifeless> sure :)
<lifeless> You are right that I didn't directly talk about that combo
<lifeless> I think that I didn't because its generally known to be 'ok' - when folk are not collaborating on stuff
<lifeless> as in, its trivially ok to do destructive local edits
<glyph> The best way to describe my personal experience is to say that there is a sliding scale of how 'serious' a VCS commit is
<lifeless> 'uncommit' comes to mind
<spiv> glyph: lp:~spiv/bzr-rewrite/rewrite-committer-hack.  It's completely untested beyond looking at pyflakes output.
<lifeless> spiv: theres an older one for committer that I did
<glyph> spiv: You the man.
<spiv> lifeless: heh.
<lifeless> spiv: jelmer hasn't merged it :(
<spiv> glyph: it might be worth looking at lifeless' branch!
<glyph> lifeless: More serious == worse
<spiv> Ah well, time spent getting some familiarity with bzr-rewrite was probably time well spent anyway.
<glyph> The most serious kind of commit is to a CVS repository
<lifeless> glyph: -lol-
<glyph> Because your change gets mangled and basically lost, and HEAD becomes the truth for real
<lifeless> modern CVS has atomic commits
<lifeless> fwiw
<lifeless> with uuids
<spiv> glyph: I'm almost certain lifeless' branch will be more sensible than my hack, which really is a hack.  lp:~lifeless/bzr-rewrite/dev
<glyph> Second is svn; you can undo commits since they're atomic, and you can put stuff in branches, but it's still instantly public
<glyph> bzr is not very serious at all, largely because of the convenience of uncommit and rebase
<lifeless> spiv: I wouldn't underestimate the value of a hack ;)
<glyph> I can save a change knowing that is easy to undo it, or merge it, or reverse it ( I discovered the 'reverse cherry pick' menu item in qlog today and it is awesome)
<glyph> The direct consequence of this is that I commit MUCH more often
<spiv> \o/
<glyph> In particular, I typically commit before running tests, rather than after
<glyph> Which means that my whole development workflow is streamlined
<glyph> Anyway... If there were a good ui for editing unpunished history, I would probably just hook up a 'bzr commit' script to run after 'save' in my editor
<glyph> Unpushed, even.
<glyph> Having to think of a good descriptive change message *before* bzr will agree to save my work is the #1 thing keeping me from committing right now
<glyph> Is there a way to tell bzr about a default protocol?
<glyph> On several of my domain names, the protocol specification is now longer than the domain itself :)
<glyph> i.e. 'bzr pull foo/~/bar -> bzr pull bzr+ssh://foo/~/bar'
<maxb> protocol specification?
<maxb> Well, you could use a small custom plugin to implement certain aliases
<peitschie> whats the easiest way to drop into a debug session with python under debian?
<maxb> e.g. foo:bar where foo: is a shortcut for bzr+ssh://foo/~/
<peitschie> that is, running bzr under debian... drop into a debug python :)
<glyph> maxb: Hmm, I guess the launchpad plugin would be a good start for that
<glyph> maxb: any pointers as to where the relevant code is?
<maxb> glyph: http://paste.ubuntu.com/525434/
<maxb> That's what I have in my ~/.bazaar/plugins/
<maxb> actually come to think of it there's nothing special about the colon there, so you could alias foo/ if you wanted to, I guess
<maxb> it might be more confusable, though
<glyph> maxb: wow.  just that, in ~/.bazaar/plugins/something.py?
<glyph> I think I'll stick with a colon, don't want to do anything _too_ weird.
<maxb> yep
<jbowtie> Anyone know what this is about?  http://theironlion.net/blog/2010/11/03/favor-ask-everyday-bazaar-users/
<jbowtie> I'm intrigued by the promise not to be evil.
<peitschie> ahh... found it... kill -s SIGQUIT <bzr pid>
<jbowtie> Am I supposed to be seeing curl connection errors when running 'bzr selftest'?  (on Ubuntu if that makes a difference)
<spiv> peitschie: typically Ctrl-\ sends SIGQUIT to the currently foregrounded process
<peitschie> spiv: woah!  way easier :D.  Thanks!
<peitschie> now if only I could figure out why bzr/python suddenly has started hanging on os.access calls.....
<spiv> jbowtie: supposed to?  No.  IIRC there may be some known flakiness with those tests... vila would remember the details.
<jbowtie> spiv: FAILED (failures=8, errors=52, known_failure_count=48)
<jbowtie> spiv: Some of those are due to my plugin (so sort of expected) but most of them seemed to be due to pycurl throwing exceptions on https connections.
<jbowtie> Gah. Can't read test output, will have to re-run the suite with a redirection in place to capture it. That's another hour of my life.
<spiv> jbowtie: if you have a multicore system then try adding --parallel=fork
<jbowtie> spiv: Will do when I get home. Think I'm passing all the per_foreign_vcs repository tests now.
<lifeless> jbowtie: thats awesome
<spiv> Well, the New bug count is back down into single digits.
<spiv> That's EOD for me.
<lifeless> nice
<vila> hi all !
<spiv> vila: Good evening
<vila> spiv: hey ! Enjoy !
<spiv> vila: would you mind taking a look at https://bugs.launchpad.net/bugs/660935?  It might be a dupe, or something you can easily fix
<ubot5> Launchpad bug 660935 in Bazaar "bzrlib.errors.InvalidEntryName when resolving path conflict (affected: 1, heat: 6)" [High,Confirmed]
<vila> spiv: I will, conflict resolution is back at the top of my TODO list anyway
<vila> ach, no reproducing recipe :-/
<spiv> vila: of course not, that would be too easy!
<rocky> jelmer, just an fyi, looks like launchpad has bzr-svn 1.0.4 but http://wiki.bazaar.canonical.com/ForeignBranches/Subversion#releases only has 1.0.3 at this point
<jelmer> rocky: thanks
<jelmer> 1.0.4 is indeed the latest version, I'll update the wiki page
<rocky> jelmer, don't suppose it would be worthwhile to just remove the releases section on the wiki page and have it point to the launchpad download section? that way you don't have to maintain multiple references
<rocky> jelmer, and update pypi's download link to point to launchpad as well
<jelmer> rocky: I don't actually maintain the launchpad download section but it's very good at picking up new releases from http://samba.org/~jelmer/bzr/
<jelmer> which is why it's the most reliable source at the moment :-)
<rocky> jelmer, well either way, it seems like having to manually update the wiki page is a bad thing and it should just point to the most reliable download source :)
<rocky> most reliable download listing, rather
<vila> jam: hi
<jam> hi vila
<vila> jam: aren't you PP this week ?
<jam> I'd have to look at the page
<jam> looks like it
* jam changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | Release Manager: vila | 2.3b2 is officially released, test it! | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/
<vila> jam: did you get lp accept your emails again ?
<jam> yeah, finally
<jam> vila: question for you
<jam> "bzr config" doesn't seem to pay attention to "policy:appendpath" is that intentional?
<jam> vila: http://paste.ubuntu.com/525769/
<vila> jam: hmm, that's a good question...
<jam> And I think you already know about the bug w/ "bzr config push" not showing anything but "bzr config location" showing all *_location
<jam> http://paste.ubuntu.com/525771/
<vila> I can find arguments both ways
<jam> I thought I saw a bug from spiv about that one
<vila> push != *push* ?
<jam> vila: but location != "*location"
<jam> or IMO shouldn't be
<jam> if you aren't going to make it a general match, it shouldn't be a substring match at all
<jam> it is currently a 'tail' match which is a bit odd
<vila> that's a weird fnmatch side-effect anyway
<vila> hmm, or may be it's a search/match bug
<jam> vila: so you are using "search" which means find it as a substring, but fnmatch is turning it into a "foo$" style search
<jam> if you want *path* != path, then you should use "matching_re.match()" and not "search"
<jam> (and probably manually add $ at the end, because otherwise path == path*, while right now path == *path which IMO is much worse than either of the other options)
<jam> mgz: any chance you could update the review on https://code.edge.launchpad.net/~doxxx/bzr/mergetools/+merge/38663
<jam> I now poolie is on vacation this week
<jam> know
<jam> mgz: also, what's up with the testtools 0.9.5 stuff? do you know vila?
<jam> do we have 0.9.5 on pqm yet?
<vila> we still don't have it AFAIK :-/
<mgz> jam: he's covered most of the things I raised... except the non-ascii problem, which he's struggling to test because that's all screwed... which is blocked on pqm updating testtools :)
<vila> but 0.9.7 is out too I think
<jam> vila: yeah, I just checked your rt, and it looks blocked on having a .deb file, and that is blocked on backporting to hardy
<jam> which we can't upgrade because we want to support py2.4
<jam> which I personally want to keep until RHEL6 is out
<jam> at which point, everyone has at least an upgrade story, so I don't care anymore
<jam> though keeping 2.0/1/2 py2.4 compatible would be nice
<jam> mgz: I thought *successful* tests with non-ascii work, just when they fail they spew garbage at you
<mgz> generally, but that makes developing a decent test hard.
<jam> mgz: https://code.edge.launchpad.net/~gz/bzr/escape_selftest_console_output_633216/+merge/34890
<jam> that's also blocked on the 0.9.5 stuff?
<mgz> is that rt thing just a process failure? can install testtools the normal way for 2.4 no problem
<jam> (note that *I* only have 0.9.3)
<mgz> try running the test that branch adds then.
<jam> mgz: sys admins don't like to install anything without apt
<jam> since it makes system management quickly get out of hand
<jam> at least, AIUI, we could ask a l-o-s-a t o be sure
<mgz> okay, so it's blocked on lifeless? can't we have some less busy person handle that?
<jam> mgz: well, jml is also involved in testtools
<mgz> it's not hard (he says, largely in ignorance) to debianise a python package
<jam> I'm not sure if they realize it is blocked
<jml> mgz: I'm working on it in my copious spare time
<jam> mgz: also, you commented on https://code.edge.launchpad.net/~ryorke/bzr/140563-optparse-barfs-on-unicode/+merge/39222
<mgz> jml is hardly idle either.
<jam> any chance for a follow up, he seems to have added more work
<vila> jml: ha ! finally ! :-P
<mgz> ah, I wish lp would tell you when that happens, can forget to check back otherwise.
<jml> actually, I'm not working on it. sorry.
<jam> mgz: it is meant to happen via switching WIP => Needs Review
<jml> what I'm working on is daily builds of testtools
<maxb> <jam> vila: yeah, I just checked your rt, and it looks blocked on having a .deb file, and that is blocked on backporting to hardy
<maxb> What's wrong with the one in the ~bzr PPA?
<jam> maxb: just saw that on the rt as well
<mgz> okay, rorryy's change looks good now. I'll follow up on both those reviews... and try and get some of my own bits progressing too.
<jam> looks like the discussion got side-tracked and nobody realized we had a possible solution already
<jam> mgz: overall, don't fret too much. You've been doing great with reviews. I'm only poking here because I would have to start the review from scratch
<jam> so if you know what's up, it is a bit smoother
<vila> jam: I'm about to EOD, but thanks for the feedback about config, could you turn your pastebins into a bug so I don't forget ?
<mgz> Gordan's branch will want another thorough review, but perhaps poolie will continue on it when he gets back
<vila> jam: and do you know where poolie is ?
<jam> vila: poolie is on vacation in Disney World this week
<vila> oh, ok, I missed that
<jam> I don't remember an email
<jam> but he certainly told me in person last week
<vila> ok
<jam> vila: bug #670251 is already my basic bug
<ubot5> Launchpad bug 670251 in Bazaar "'bzr config pqm' does not find "pqm_email" setting (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/670251
<mgz> there was a very similar bug with qbzr on that
<mgz> the fix was adding '*' to the input string.
<mgz> fnmatch.translate behaviour changed at some point.
<vila> jam: meh... I didn't see this one...wth ?
<jam> mgz: well you could obviously always add "foo*" :)
<mgz> woho! my lazr.restfulclient mp just got approved.
<vila> I'll blame my perl background here, such bugs are... unexpected :)
<vila> ouch, bunch of bug mails ignored for... unknown reason :-/
<mgz> bug 575338
<ubot5> Launchpad bug 575338 in QBzr "qlog search not working correctly. (affected: 1, heat: 19)" [Critical,Fix released] https://launchpad.net/bugs/575338
<mgz> hm, not exactly the same, but the same approach for the fix would work.
<jam> vila: bug #671050 is the one about "policy:appendpath" not working correctly
<ubot5> Launchpad bug 671050 in Bazaar ""bzr config" ignores policy:appendpath (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/671050
<vila> kthk
<jam> vila: go be with your family now. :)
<vila> almost there :)
<vila> just one last selftest run ;)
<vila> to fix a bug that will allow me to fix a bug that will allow me resume working on conflict resolution ;)
<TresEquis> anybody here up to speed on the setuptools bzr plugin?
<roryy> mgz: hrm.  sorry about the spacing etc.  i moan enough about it in C code at others
<mgz> no worries roryy :)
<mgz> also, PEP 257 talks about always using triple quoted docstrings
<mgz> just to take the trivia even further.
<roryy> i think i've at least read pep 8, even if it was a while back.  never heard of 257
<mgz> when I'm reduced to formatting nitpicks, you must be on the right track.
<roryy> cool.  thanks for the review.  bed-time for me!
<mgz> night!
<cody-somerville> How can you make a pack file smaller?
<james_w> delete half the file?
<james_w> (not guaranteed to keep all of your data)
<mgz> `bzr pack` redoes the repo (and will happen periodically anyway), but if you've committed giant binary files in the past you may be reduced to rewriting history to get sane pack sizes
<peitschie> mornin all :)
<spiv> vila: I don't think 'bzr config' should use fnmatch.  jam's right, I did file a bug two days ago.
<doug> huloo
<doug> i want to claw back the last commit, add some more changes to it, and then commit the whole bundle...
<doug> there an easy trick for that?
<fullermd> uncommit?
<doug> that simple, huh
<fullermd> As long as nobody else has had a chance to get a hold of that revision, yah.
<doug> coolio
<doug> i was worried because of the message it gives
<doug> "The above revision(s) will be removed"
<fullermd> uncommit backs you up to the state right before you ran 'commit', so you'll wind up with a bunch of pending changes.
<doug> as long as that just means repo changes, i'm happy.
<fullermd> Well, that's what it does   :)
<doug> hm, now it says i can restore the old tip by running the given pull command
<doug> that just reverts the uncommit?
<fullermd> From 30k feet, yah.
<doug> right
<doug> fullermd++
<doug> thanks
<peitschie> did you just get incremented fullermd?!
<fullermd> Great, now I have to go punch a new hole in my belt...
#bzr 2010-11-05
<glyph> hey #bzr
<glyph> is 'bzr branches' supposed to work on remote svn repositories?
<glyph> I ran it on my SVN repo's /branches directory, and it's been going for about an hour now.
<fullermd> I'd guess that if it does, it has to do all the work of converting the repo to do it...
<spiv> glyph: hmm
<spiv> glyph: 'bzr branches' is pretty simple-minded, I wouldn't be surprised to discover it is pathologically slow with an SVN repo.
<glyph> spiv: well, consider yourself having discovered it :)
<vila> hi all !
<fullermd> Eep!
<vila> :)
<vila> spiv: Right, so, what *do* you think we should use then ? only regexps ?
<spiv> vila: something that feels the same as ignore rules, bzrmeta/rules, locations.conf wildcards..?  Not sure.
<vila> meh, those are globs AFAIK i.e. fnmatch, *I* don't mind using regexps, but it seem we tend to propose globs instead of regexps so I thought it was a deliberate choice
<vila> ignores can use regexps but you have to explicitly ask for them
<GaryvdM> Hi all
<GaryvdM> Is there a way to get bzr to use words, rather than lines when merging? I'm trying to merge  wikipedia article changes
<vila> GaryvdM: hi !
<GaryvdM> Or is there maybe some external app that I can pass THIS, BASE, OTHER to?
<GaryvdM> Hi vila!
<vila> GaryvdM: In theory, yes, in practice.. I don't think you can achieve that without coding something ;)
<vila> GaryvdM: there is a mp from doxxx about that
<vila> (about invoking external tools that is)
<GaryvdM> Ok
<GaryvdM> vila: but the question is what external app can do this for me
<vila> GaryvdM: several are mentioned in the mp, that's why I cited it :-p
<GaryvdM> oh - ok - I'll take a look
<vila> GaryvdM: *I* use emacs smerge-mode for that ;)
<GaryvdM> vila: ok - I've never used emacs before, but I'm going to give it a shot - thanks
<fullermd> Ogod, now look what you've done...   corrupting an innocent soul   :(
 * Tak tsk
<vila> mwhahaha
<GaryvdM> I ended up hacking bzrlib.merge.Merge3Merger.get_lines to return words, not lines.
<GaryvdM> (emacs still downloading...)
<GaryvdM> I'm using pipeline for the first time. I like it :-)
<gthorslund> jelmer: saw your comment on https://code.launchpad.net/~gthorslund/bzr-bisect/539937-subtree/+merge/39785 . want me to fix it for all doc strings or just for my additions? (it's just " everywhere from what I can see)
<jelmer> gthorslund: Ah, you were being consistent with the rest of the file.  I hadn't realized that.
<gthorslund> jelmer: yes, but I can fix it for all of the file if you like. or you could do it after. don't know what looks best.
<jelmer> gthorslund: It'd be nice if you could fix the rest of that file to use the """-style as well.
<gthorslund> jelmer: ok. I'll do that.
<jelmer> gthorslund: I'd also be fine with merging your current docstrings as is since they're consistent with the existing style.
<jelmer> but fixing the file to use the right style would have my preference of course :-)
<gthorslund> jelmer: so let's just keep it simple and not create a new bug + merge request for the change of docstrings :)
<loldrup> hi, I have a serious problem.. I get error 13 when trying to download code from my repository: sftp://brok.diku.dk/usr/local/projects/disk07/dirdiffsim/repo/trunk
<loldrup> bzr checkout sftp://brok.diku.dk/usr/local/projects/disk07/dirdiffsim/repo/trunk
<loldrup> bzr: ERROR: Permission denied: "/usr/local/projects/disk07/dirdiffsim/repo/trunk/.bzr/branch-format": [Errno 13] Permission denied
<Tak> your user needs read access to the contents of the .bzr dir
<loldrup> ah ok, will check that
<sladen> bzr branch lp:ubuntu-font-family-website    generates lots of warnings:
<sladen> Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored
<sladen> ...is that a feature, or a bug?
<spiv> sladen: bug
<spiv> sladen: https://bugs.launchpad.net/launchpad-code/+bug/668176 I think; needs bzr upgraded on codehosting to current lp:bzr/2.2
<ubot5> Launchpad bug 668176 in Launchpad Bazaar Integration "lp-serve infinite loop, development focus is empty bzrdir (affected: 1, heat: 11)" [Undecided,New]
<maxb> Hmm. hg 1.7 is out and current bzr-hg debs claim non-compatibility with that
 * sladen dupes  https://bugs.launchpad.net/bzr/+bug/671351
<ubot5> Launchpad bug 671351 in Bazaar "bzr branch: "maximum recursion depth exceeded in __subclasscheck__" (dup-of: 668176)" [Undecided,New]
<ubot5> Launchpad bug 668176 in Launchpad Bazaar Integration "lp-serve infinite loop, development focus is empty bzrdir (affected: 3, heat: 19)" [Undecided,New]
<jelmer> bzr-hg is in need of some attention :-/
<sladen> spiv: who do I knack to get it fixed.  Broken code-hosting is a bit useless
<sladen> spiv: and I've staggered at how that got paste unit/regression testing
<sladen> spiv: and I'm staggered at how that got past unit/regression testing
<spiv> sladen: the launchpad-code team; thumper is the lead there
<spiv> sladen: it got past because it involves a pretty unusual scenario that triggers an unexpected interaction between codehosting and bzrlib
<spiv> sladen: and AFAIK it's not a regression, it's always been lurking, so regression testing by definition wouldn't have caught it :P
<sladen> spiv: okay, I've re-read the bug, but can't see the cause/interaction listed, can you outline it so that I can add it to the bug report
<sladen> spiv: oh right, yikes
<spiv> Hmm, maybe it technically is a regression.
<spiv> But anyway,
<spiv> IIRC it's basically that some sort broken/unusual bzrdir on the remote side can cause codehosting's VFS to raise a slightly odd error (from bzrlib's perspective at least) in response to an open_branch request from the client.
<spiv> Arguably codehosting's VFS should be more careful to only raise filesystem errors from its functions, and arguably bzr should be more robust against unexpected errors.
<spiv> I've fixed the bzr side in lp:bzr/2.2 to be more robust.
<spiv> (i.e. not get stuck in an infinite loop of error handling callbacks)
<spiv> At this late hour I don't quite recall what the precise circumstances are.
<spiv> You can probably workaround it by using sftp or nosmart+lp URLs.
 * spiv -> zzz
<gthorslund> jelmer: pushed docstrings fix now.
 * gthorslund going for lunch
 * jelmer also goes to lunch
<jelmer> gthorslund: Thanks, btw!
<gthorslund> jelmer: you too! if I make another merge proposal, should I add you as reviewer instead of bazaar devs as default now? (guess I could ping you or someone here first too)
<jelmer> gthorslund: please use bazaar devs so any of us can review. You're always welcome to ping me individually in case nobody replies.
<gthorslund> jelmer: fine. I'll do so. do you see a work queue for everyone in the group to review?
<jam> gthorslund: stuff like: https://code.edge.launchpad.net/bzr/+activereviews
<jam> that, and we all get an email when a request for bazaar-dev is made
<jam> anyway, be back later
<gthorslund> thx jam (who left). https://code.edge.launchpad.net/bazaar/+activereviews was probably what I was looking for (since it was for plugins like bzr-bisect too)
* 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: jam | Release Manager: vila | 2.3b3 has gone gold, time to build the installers !  | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/
<DonDiego> moin
<DonDiego> why does 'bzr version-info' require network connectivity?
<vila> DonDiego: probably because you use a checkout so the history is not available locally
<DonDiego> i have it stalling and erroring out on me when my laptop has no inet
<DonDiego> hmmmm
<vila> DonDiego: use bound branches and unbind when you don't have net access
<vila> DonDiego: 'bzr info' will tell you what your configuration is and 'bzr reconfigure' will help you adapt it to your needs
<DonDiego> ah, that's a good hint, thank you, i will investigate tonight
<Bernardo> :)
<gthorslund> DonDiego: I like keeping a local repo doing something like "bzr init-repo foo; cd foo; bzr branch <location of foo>; bzr branch foo foo-with-my-edits; cd foo-with-my-edits" start hacking... "bzr commit -m "fixed bar". then you'll need to merge the changes into <location-of-foo> if someone else have done updates.
<DonDiego> so far i have done 'bzr init-repo hipl; cd hipl; bzr co lp:hipl'
<DonDiego> but i think i will switch to bzr branch lp:hipl
<gthorslund> DonDiego: s/co/branch/ then
<DonDiego> yes, like i wrote, thx :)
<jml> mgz: hey, yesterday you were talking about being blocked on lifeless to get some testtools stuff done
<jml> mgz: afterwards, it occurred to me to ask, "how can we change things so that you are blocked neither on lifeless nor myself?"
<mgz> jml: on that particular issue with the pqm setup I'm not really sure, it's a canonical infrastructure thing. In general on code things, dvcs and really pretty good responsiveness from you two means I don't really get blocked on coding things except by myself
<jml> mgz: thanks for saying so :)
<jml> mgz: on the pqm thing, maybe there is something we can do to unblock you. Have you sent mail about it?
<mgz> I've not, as I'm not sure where it should be going. I know of the existence of an rt, and found out yesterday the problem was lack of a debian package.
<maxb> mgz: For testtools? The problem is not the lack of a Debian package because there is one in the ~bzr PPA. Unless the Canonical sysadmins dislike that?
<maxb> Or did you need a newer version of testtools? In which case I can update the ~bzr PPA easily enough
<ScottK> maxb: For a lot of people it only counts if it's in $DISTROOFCHOICE.
<mgz> ScottK, I'd really hope they're using Ubuntu :)
<ScottK> bzr PPA isn't Ubuntu.
<mgz> maxb, your PPA would do, and I think jam said he mentioned it in the rt?
<maxb> The Canonical sysadmins use extra packages all the time. I imagine they'll just need to copy it into their private archive
<mgz> I'm not really in the right position to coordinate this.
<maxb> I have no visibility over the RT, but I'd like to hear any reasons why the PPA isn't an instant solution
<vila> mgz, jml, maxb: the magic word is: losa
<jml> vila: no it's not.
<mgz> I always thought it was please.
<vila> jml: well, that's where it's blocked so far AIUI
<Buttons840> i remember hearing that a uncommit doesn't actually remove the commit?  can someone explain this better, and does it really matter to me?
<GaryvdM> Buttons840: uncommit moves the branch tip back.
<GaryvdM> It matters if you have confidential info you are trying to hide.
<Buttons840> GaryvdM: so if i commit revision 5, and then uncommit it, revision 5 still exists but it's no longer know as revision 5 (as the next commit will become the new "revision 5")?
<GaryvdM> Or if you have committed large files.
<GaryvdM> Buttons840: Yes
<GaryvdM> Buttons840: You are able to see uncommited revisions by running bzr heads --dead
<Buttons840> GaryvdM: thank you
<dlee> Got a project that includes some large binary files (not my decision) and which is based in Subversion.  I mirror it in bzr, but on an old FreeBSD machine with (I think) 512 meg RAM.  I get a MemoryError in .bzr.log on some pushes containing large binary file updates.  Python 2.4 (hard to upgrade that box).  Anything I can do to avoid the memory errors?
<dlee> So far I've been rsyncing the shared repo from a box without such problems, then pushing the branch itself without incident.
<dlee> but rsync is way slower than push...
<vila> dlee: yup, rsync is way slower indeed...The trick you can try is:
<vila> 1) bzr pack the local repo
<vila> 2) rsync
<vila> 3) push
<vila> get some stats from rsync to get a feeling about when you need to repack,
<vila> dlee: I suspect the memory errors occur when you have to repack on the FreeBSD machine (smart server there ?)
<vila> dlee: If you avoid the remote repack (by repacking locally), you *may* workaround the problem then
<dlee> Not sure, it happens at the end of a long push... but the error does point to groupcompress.py if that helps
<vila> dlee: no, a full backtrace is needed to identify repack
<vila> dlee: but you use a smart server there ?
<dlee> So next time I can do local bzr pack and then retry bzr push, only rsyncing if that fails?  Oh yes, bzr+ssh protocol.
<dlee> Not all pushes fail, just the ones that seem large.
<MvG> vila: Bug #638451 seems to be caused by your commit http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/4597.7.11 . Do you have an idea where this goes wrong, just from looking at it again? Might save us a lot of time, as I'm pretty much fishing in the dark here.
<ubot5> Launchpad bug 638451 in Bazaar " bzr resolve --take-other bzr: ERROR: Tree transform is malformed [('duplicate', None, 'new-1', None)] (affected: 4, heat: 20)" [Medium,Confirmed] https://launchpad.net/bugs/638451
<vila> dlee: look into .bzr/repository/packs on the remote server, dates and sizes should make it clear when the repacks occurs
<vila> MvG: Is it the one where you added a reproducing recipe ?
<vila> yup
<vila> It's very high in my todo list (as in: can't be higher)
<vila> my *current* task is re-building a loom lost after a pull from a wrong source (yes, it hurts)
<MvG> vila: In that case I'll leave it to your competent hands, and stop trying to understand stuff that feels quite a bit over my head.
<MvG> also added a branch with a blackbox test, by the way.
<vila> MvG: welcome to my world :-} I haven't paged back the context yet, but this fix was.... tricky ? painful ? frustrating ? A bit of each...
<dlee> vila: I'm seeing a number of messages like this just before the backtrace:
<dlee> 728.556  Adding the key (<bzrlib.btree_index.BTreeGraphIndex object at 0x8b574ac>, 2467090, 34026528) to an LRUSizeCache failed. value 68764346 is too big to fit in a the cache with size 41943040 52428800
<vila> MvG: Wow ! You rock ! Link it to the bug ! Pretty please ?
<MvG> vila: Done so already, but I know those links are prety small, so I mention it here.
<vila> dlee: hmm, still not definitive, but you certainly have enough infos to file a bug from where we could either give you a workaround or a fix (but don't hold your breath on the later :-/)
<vila> MvG: Oh, sorry, I was on the bug #531967 page, silly me
<ubot5> Launchpad bug 531967 in Bazaar "bzr resolve --take-this or --take-other fails for PathConflict if a dir is deleted (affected: 1, heat: 0)" [High,Fix released] https://launchpad.net/bugs/531967
<vila> MvG: Excellent ! You did the part that is the most painful for me :) That will make my heart even lighter while fixing the bug :)
<dlee> vila: Ah, autopack spotted, so yes, packing.  And I doubt this is a bug; it works on reasonably up-to-date hardware/OS combinations
<vila> dlee: I meant a bzr bug :)
<vila> dlee: so, great, the workaround then is to avoid the remote repack
<dlee> vila: Me too :)  I mean I doubt it's a bzr bug because it only fails on really old stuff.
<vila> dlee: which means you should encounter it less and less
<dlee> vila: I bet bzr pack + bzr push makes push much slower, but I'll still take it, as it's also more atomic than rsync
<vila> dlee: requiring too much memory is the kind of bug I was referring to, 512M is significant, I don't know the size of the pack files involved, but *in theory* we could limit the size of the pack files (with an impact on performance)
<vila> dlee: no, it will be useless to repack without rsync, the remote repo doesn't care about how pack files your local repo has
<vila> the local and remote repos have separate lives
<dlee> Any helpful stats from server I can give you now?  And ah ok.
<vila> even using rsync can be dangerous if you don't check that you're the only one to use the remote repo
<dlee> right
<dlee> vila: rsync does atomically replace the dest files, but local commits during rsync would be a Bad Thing...
<vila> dlee: yup
<lifeless> dlee: other pushing during rsync would be bad
<dlee> lifeless: touche
<vila> well, exactly what lifeless said
<lifeless> dlee: because atomicicity matters at the repo level, not at the file level.
<vila> dlee: are you the only one using the remote repo ?
<dlee> In case it helps, .bzr/repository/packs contains 35 files, all but one 225 meg or less, but one 2.9 gig!
<vila> dlee: the question is: was it created locally or rsynced ? :D
<dlee> That was rsynced recently but then successfully pushed to a time or three.
<vila> dlee: look at the dates and you will see that the small ones are more recent than the old ones
<vila> dlee: each one is either a commit or a push (it may contain one or several revisions)
 * dlee realizes he didn't put --delete on his rsync command... and only 4 packs locally, but one is that big here too.  And yes, I see the point on dates/sizes.
<vila> lifeless: by the way, pulling a loom from an older version of itself => data loss (the pull updated my last-loom file)
<vila> lifeless: of course I didn't record...
<vila> lifeless: I'll file a bug
<lifeless> vila: you can recover via heads and -r, I expect
<vila> lifeless: that's what I'm doing, but my created threads are lost
<vila> lifeless: well, I'm grepping .bzr log right now so I may recover more this way
<lifeless> vila: they'll be in the repo; create-thread and a dance with a temp branch and pull
<vila> lifeless: yup
<vila> lifeless: no revisions lost (and I shelved before the pull), so no uncommitted changes lost either, just mentioning because you popped out ;)
<vila> lifeless: a bit freaky way to end my week ;)
<maxb> The main problem with looms, to me, is it took reading the sourcecode of bzr-loom for me to figure out what a loom actually was
<lifeless> maxb: thats a shame; had you read the docs [in-tree] ?
<maxb> Yes. Those docs are remarkably silent on what a loom *is*, and what on earth "bzr record" actually meands
<lifeless> k
<fullermd> 'bzr record' is like 'bzr cd', except it spins slower and hisses more.
<dlee> fullermd: Aren't we lucky it's bzr shelve and not bzr table...
<seiflotfy> hey guys
<seiflotfy> I am here because I have questions regardding the employment position
<seiflotfy> who can i contact
<thumper> seiflotfy: poolie is the hiring manager
<seiflotfy> thanks
<seiflotfy> i will need to wait form him to come onlne then
<seiflotfy> thumper, any idea when he is on
<seiflotfy> ?
<thumper> seiflotfy: poolie is in AU, and it is Saturday there
<thumper> I'm not sure if he is on often over the weekend
<seiflotfy> its ok
<jam> thumper, seiflotfy: he was also on vacation in the US this week, so he is likely still travelling/recovering from a flight.
<jam> I wouldn't expect an update before Mon AU time.
<jam> Probably best to email him
<gthorslund> <gthorslund> thx jam (who left). https://code.edge.launchpad.net/bazaar/+activereviews was probably what I was looking for (since it was for plugins like bzr-bisect too)
<jam> gthorslund: np. yeah  "bazaar" is the meta-project "bzr" is the actual vcs code.
<vila> lifeless: just a thought about looms: I understand why record is not called automatically on all operations like (commit, create-thread, combine-thread, switch), *yet* recording all changes to last-loom and *throwing* them away when record'ing would have save my ass today
 * gthorslund hopes vila got a backup of his ass somewhere...
#bzr 2010-11-06
<rockstar> If I want to hook into every single call to the bzr script, is there a simple way to do that?  For instance, let's say I want to log every command that is run.
<maxb> urgh. is anyone else finding dput ftp uploads hang?
<maxb> (and they use bzrlib code, btw)
<peitschie_> rockstar: I don't have any real clue... have you looked at http://doc.bazaar.canonical.com/development/en/user-reference/hooks-help.html ?
<rockstar> peitschie_, indeed I had, but I was hoping for something a bit more general.  It doesn't look like I'll find one.
<peitschie_> rockstar: ahh... doesn't sound like fun.  sorry i can't be more help :)... still quite new myself
<spiv> rockstar: you can probably do that
<spiv> rockstar: the get_command hook point of bzrlib.commands.Command.hooks would suffice I think
<spiv> rockstar: well, to some extent.  Other plugins could potentially interfere, but I think that's unavoidable to a degree
<spiv> rockstar: also a bit awkward as you would need to decorate the given command to be one that logs the arguments or whatever you want to do.
<dnivra> hello. I am using bzr on ubuntu 10.10. I have uploaded my public key to launchpad and created a branch. i try uploading to the branch but get the error "Permission denied(public key)". what is wrong?
<dnivra> i'm pretty sure i uploaded the key right(all contents of ~/.ssh/id_rsa.pub)
<peitschie_> dnivra: have you checked to ensure you have the right username defined for bzr launchpad-login
<dnivra> peitschie_, yes it is. i am logged into launchpad through the web interface using the same account.
<dnivra> is there a way to check if the login was successful?
<dnivra> logging in using "bzr launchpad-login <username>"?
<peitschie_> dnivra: the first time you branch sometime seems to be the only way it checks
<dnivra> peitschie_, sorry didn't get you. i have created and uploaded branches before. two branches exist in launchpad.
<peitschie_> dnivra: ahh... so it just suddenly stopped working for you?
<dnivra> peitschie_, i guess so. i am puzzled-all i generally do is register a branch through the web and then push to it.
<peitschie_> dnivra: how long has this error been happening for?  have you retried a few times?
<dnivra> peitschie_, yes. four or five times already. doing again now too.
<peitschie_> dnivra: other easy question just to check :)... is this the same computer you created the pub/priv key pair on?
<peitschie_> dnivra: occasionally launchpad will go a little funny for a while... but usually it clears up after a few minutes
<dnivra> peitschie_, i created a new key just now after the old ones didn't work and uploaded the new key. that didn't work so created another one.
<dnivra> peitschie_, i do have to create an ssh rsa key pair right?
<peitschie_> dnivra: yes... for each computer you access launchpad from you need an rsa key pair (or you need to ensure your private key is on all these computers)
<dnivra> peitschie_, imported my public key yet again. let me see if iti works.
<peitschie_> dnivra: are you on windows or linux atm (i'm guessing linux... but again, worth checking :) )
 * peitschie_ crosses fingers
<dnivra> peitschie_, ubuntu
 * dnivra doesn't have windows
<peitschie_> dnivra: consider yourself lucky then lol... ssh+windows=not fun
<dnivra> oh! I'm not so used to windows-all i have done is play a few games, sync iPod and watch a few movies/videos. i have not been so lucky with ubuntu either-this whole authentication thing is not working for me.
<vila> dnivra: the best way to debug this is: 'ssh -v bazaar.launchpad.net'
<dnivra> vila, now i try pushing to the branch from another terminal?
<vila> dnivra: this should show you which keys are proposed/accepted/refused
<dnivra> vila, yeah see that now.
<vila> dnivra: forget push for the time being, this is to debug the ssh connection without bzr being involved at all
<dnivra> vila, yeah ok done. reading the debug output.
<dnivra> two questions-why does it offer my private key "id_rsa" and two why does it say wrong user name when i logged in using a different username? http://ubuntu.pastebin.com/1cvaVciA
<vila> dnivra: that's the default behaviour of ssh
<vila> if your lp login is different than your local one, try 'ssh -v <lp_login>@bazaar.launchpad.net'
<dnivra> vila, offerring id_rsa as public key is default behaviour?
<dnivra> vila, http://ubuntu.pastebin.com/RX5M5Qnw is what happens when i try ssh -v <lp_login>@bazaar.launchpad.net
<vila> dnivra: yup, that's the key the server is supposed to know about
<vila> ha ! So your key is protected by a password but somehow ssh can't find a way to ask you about this password
<dnivra> vila, when it says "offerring public key: id_rsa", it does mean that id_rsa is my public key right?
<dnivra> vila, you mean passphrase?
<vila> you should have a 'id_rsa.pub' (the public key) along your 'id_rsa' (the private)
<vila> yeah passphrase
<vila> dnivra: do you have an ssh agent setup and running ?
<vila> 'ssh-add -l' will tell you about which keys are known and usable
<vila> 'ssh-add <path-to-key>' will add a new key asking for its passphrase if needed
<dnivra> vila, ssh agent is running. is there some specific setting up to be done? and I get an output using ssh-add -l. but that isn't what i need to upload right?
<vila> oh.... wait a minute, you re-recreated your keys using id_rsa without re-starting the agent right ?
<dnivra> vila, yeah. anything wrong there?
<vila> I went into this weird scenario and it took me a while to realize that the agent was still using the *wrong* key
<vila> i.e. the old one
<vila> since I used the same user@host inside the key I didn't realize what was happening, this sounds a lot like what you're experiencing right now
<vila> try 'ssh-add -D' to purge the agent and try again
<vila> check with 'ssh-add -l'
<dnivra> when i run 'ssh-add -D' and then run 'ssh-add -l', there should be no output right?
<vila> dnivra: for the record, ssh keys should be looked at like real physical keys, you define a key for each door your want to open and you duplicate this key if you need to use it from various computers
<vila> dnivra: yes, no output
<dnivra> vila, well i do get output.
<vila> hmm, may be it reload the default keys, try 'ssh -v ' again
<vila> otherwise you'll have to be more rude: logout/login
<dnivra> what should be the output of "ssh -v"?
<vila> you can also try 'ssh-add -L' and check
<vila> ssh -v <lp_login>@bazaar.launchpad.net' I meant...
<dnivra> vila, oh ok. and  I get the public key as output-the one i uploaded in launchpad-of 'ssh-add -L'
<dnivra> vila, i tried ssh -v and still get the same error.
<dnivra> let me try logging out and logging in again.
<dnivra> villa got it. it asked me for the passphrase this time
<vila> there you go
<dnivra> so it was the fact that the old keys were being used eh? thanks a lot vila!
<vila> dnivra: next time, give your key a different name like: dnivra@launchpad or something, that will make it easier to debug
<vila> also read the various man pages about ssh, once you understand the key metaphor they make more sense (ssh_config, ssh-add, ssh-key, ssh)
<dnivra> vila, giving a different name should be done during key generation right?
<dnivra> vila, oh yes will read the man pages.
<vila> yeah naming at ket generation time is the best way to avoid errors
<vila> s/ket/key/
<dnivra> vila, will keep that in mind. thanks a lot!
<sqwishy> My plugin isn't working, someone wanna help? A hook isn't working it seems.
<exarkun> I guess I did something wrong?  http://pastebin.com/jeWbEMuc
<lifeless> looks like a dpush bug
<exarkun> glyph said some words to me last week , I think "bzr" and "dpush" and "svn" and "branches" were amongst them, but I don't really remember
<exarkun> Am I supposed to be able to dpush a bzr branch to an svn branch?
<lifeless> yes
<lifeless> I think
<sirex> Is it possible to have two completely differend branches for one project in launchpad?
<sirex> now I getting this: http://ubuntu.pastebin.com/CzFNppBg
<lifeless> sirex: it is if they ahve the same format
<lifeless> sirex: the trunk is a very old format, it would benefit by being upgraded.
<sirex> lifeless, after thirt push, there was no error and finnaly new separete branch was create...
#bzr 2010-11-07
<glyph> lifeless: fwiw, it's not a dpush bug
<glyph> lifeless: it's a bug in the svn mac installer, which I've reported and yelled about in here like 5 times
<glyph> https://bugs.launchpad.net/bzr-mac-installers/+bug/621446
<glyph> please, somebody fix this
<ubot5> Launchpad bug 621446 in Bazaar Mac Installers "AttributeError: paths when trying to svn-import (affected: 6, heat: 46)" [Undecided,New]
<glyph> it's shipping with a prerelease bzr-svn that's broken.
<lifeless> ahh
<lifeless> exarkun: ^
<lifeless> glyph: perhaps you could drop a mail to the list; its more likely to catch the mac installer dudes eyes
 * exarkun arrives
<exarkun> btw the launchpad login experience sucks
<glyph> exarkun: what are you talking about, it's great.  It is super secure.  What if you accidentally informed launchpad.net of your launchpad.net credentials?  that would be terrible!
<glyph> (sorry, apparently in a snarky mood tonight)
<glyph> also, I may have asked this one before
<glyph> but is there any way to change qbzr's fonts?
<glyph> the code font it has selected for me is painfully ugly
<lifeless> glyph: no idea about qbzr, sorr.
<lifeless> exarkun: what about the experience sucks?
<glyph> lifeless: I suspect exarkun is complaining about the same part of the experience that I'm snarking about.
<exarkun> lifeless: The "did you actually mean to log in" page that comes after the log in page
<glyph> I'm on launchpad.net.  I click 'log in'.  I type my username and password, and hit 'continue'.  It then says "The following information will be available to Launchpad:", but clearly that information is _already_ available to Launchpad.
<glyph> Also, at the top of that page it says "Logged in as ..." even though I am (apparently?) not actually logged in
<glyph> Personally, having worked on federated authentication, I understand the difference between authenticating to the login service and relaying that authenticating to the application, but that is an extremely subtle distinction
<glyph> that I think is lost even on most programmers.
<lifeless> mmm
<lifeless> so it might be useful to file a bug or two here
<lifeless> we are working on allowing any provider
<lifeless> - becoming a general rp
<glyph> lifeless: That would be great.
<glyph> lifeless: I really, really want LP to be a general RP so I can throw these credentials in the garbage, along with all of my other random web credentials
<lifeless> yeah
<glyph> lifeless: actually, is there a launchpad bug for that?  I'd love to be notified when it's ready.
<lifeless> sure is
<glyph> but still, in that case, I want the LP login service to special-case the case where I am logging in *to* launchpad *on* launchpad :).
<lifeless> well
<lifeless> LP doesn't have its own provider anymore
<glyph> login.launchpad.net looks like a provider
<lifeless> it does
<lifeless> its login.ubuntu.com themed
<lifeless> different DB
<glyph> lifeless: it says "launchpad" at the top, that makes me think it's launchpad ;)
<lifeless> I know
<lifeless> we had one for a bit
<lifeless> then folk used it
<lifeless> then we move it to a different department ;)
<lifeless> le sigh.
<glyph> lifeless: when I said "is there a launchpad bug", what I really meant was" what is the URL for that launchpad bug" ;-)
<lifeless> I don't know
<glyph> lifeless: well, I spent about 20 minutes searching, and I found nothing.  So: <https://bugs.launchpad.net/launchpad-foundations/+bug/672004>
<ubot5> Launchpad bug 672004 in Launchpad Foundations "launchpad should be an openid relying party (affected: 1, heat: 6)" [Undecided,New]
<lifeless> glyph: https://bugs.launchpad.net/launchpad-foundations/+bug/210943
<ubot5> Launchpad bug 210943 in Launchpad Foundations "be an openid consumer (affected: 32, heat: 221)" [Low,Triaged]
<lifeless> glyph: its on the first page of a search for openid in launchpad
<lifeless> glyph: I'm sorry you spent so long looking
<glyph> lifeless: not for me it isn't
<glyph> "No results for search openid"
<glyph> http://bit.ly/9LDsKk
<lifeless> https://bugs.launchpad.net/launchpad-project/+bugs?field.searchtext=openid
<glyph> oh, I already found this bug
<glyph> ah
<glyph> not launchpad itself
<glyph> or launchpad foundations
<glyph> but launchpad project :)
<lifeless> we use launchpad badly
<lifeless> sorry :(
<glyph> (ok sorry for talking about launchpad so much in #bzr, I will go back to talking about bzr in here and join #launchpad if I want to talk about launchpad)
<lifeless> :)
<glyph> so, regarding qbzr
<glyph> there are a couple of places where it hard codes "Courier New, Courier"
<glyph> and you can just edit it
<glyph> and https://bugs.launchpad.net/qbzr/+bug/619301 is a bug about fonts, albeit maybe there should be more bugs
<ubot5> Launchpad bug 619301 in QBzr "Commit dialog: Font should be choosable (affected: 3, heat: 15)" [Undecided,New]
<luke-jr_> Can I reconstruct a Subversion repository from a bzr-svn branch of its root? âº
<jelmer> luke-jr_: No, as the zeroth revision in svn is immutable.
<glyph> jelmer: Can't you rebase onto an empty trunk?
<glyph> oh, wait, maybe not.
<glyph> luke-jr_: Why bother, though?  If you are in the happy situation of having lost your SVN repository but still having a bzr backup, sounds like it's time to just switch to bzr :)
<luke-jr_> jelmer: svnadmin can load over it â¹
<luke-jr_> glyph: bzr doesn't work nicely with subtrees
<luke-jr_> glyph: I'd want to at least import it back to Subversion, then branch from the trunk
<jelmer> luke-jr_: I think you might be able to do a push if you use svnadmin to change the uuid to match the original repo first, and get rid of your bzr-svn cache for that repo
<luke-jr_> hmm
<luke-jr_> any idea how to find the UUID? âº
<jelmer> it's part of the bzr revision id
<luke-jr_> hmm, does seem to be working
<luke-jr_> any idea if this is lossless? :P
<luke-jr_> or at least keep compatibility with the real original repo, in case it returns someday?
<jelmer> luke-jr_: yes, this would be lossless in terms of what bzr supports (otherwise bzr-svn would refuse to push)
<jelmer> so svn:externals and other custom properties would be lost but svn:executable will be kept
<luke-jr_> i c
<glyph> jelmer: I mentioned this yesterday but just got around to filing a bug on it: <https://bugs.launchpad.net/bzr-svn/+bug/672016>
<luke-jr_> so only lossless from Bazaar's limited view
<ubot5> Launchpad bug 672016 in Bazaar Subversion Plugin "'bzr branches' is pathologically slow with an svn+ssh URL (affected: 1, heat: 6)" [Undecided,New]
<glyph> but my main purpose is that I am trying to write a little shell script that synchronizes a whole repository, including all of its branches.
<glyph> I'd like it to work with a bzr repo or an svn repo.
<glyph> 'svn ls' isn't quite right if you've got things which aren't branches in /branches, so it would be nice if bzr branches worked right.
<glyph> is there a different suggested method for doing this?
<jelmer> glyph: hmm
 * jelmer tries locally
<jelmer> glyph: it looks like this is an issue with the way the branches command works
<jelmer> it just find all possible places with a control directory and then filters out the ones that have branches
<jelmer> in svn, every directory is a possible control directory
<glyph> jelmer: While it's theoretically possible to have a branch within a branch, it seems like you'd be pretty hosed if you tried that
<jelmer> glyph: it's perfectly possible in bzr
<glyph> really?
<jelmer> well, the branch inside the other branch wouldn't be versioned as such, but it can exist.
<jelmer> (ie the container branch wouldn't know about it)
<glyph> right
<glyph> Well, certainly this is up to you, but personally I think it would be fair to say that anything which has the metadata to suggest that it's a branch is the end of the line for searching for more branches :)
<glyph> and you could possibly have some configuration to disagree with that, for pathological repositories
<jelmer> glyph: it's not up to me :-)
<glyph> aren't you mr. bzr-svn?
<jelmer> glyph: I guess :-) But bzr-svn doesn't get into the picture here except to answer the question "does this control directory have a branch attached to it?"
<jelmer> so there's no way I can make it scale from within bzr-svn, bzr core has to be changed.
<glyph> jelmer: Doesn't bzr-svn also get asked "is this a control directory?"
<jelmer> glyph: Yes, but control directories can exist without branches.
<glyph> jelmer: It should be possible to at least look at the directory and say 'no' if it was copied from somewhere else (i.e. probably a branch)
<glyph> at any rate this is implementation, all I want is for 'bzr branches' to be super fast, just make it happen, etc ;-)
<jelmer> glyph: I don't think copies are a good indication of whether something is probably or not probably a branch. Also, finding out will have a performance impact too.
<jelmer> I'd like to fix this properly, by having bzr ask bzr-svn for the list of branches in a repository. I'm just not sure yet what the proper API for that is.
<glyph> jelmer: My understanding is that SVN's revision calculus makes it formally impossible to determine the list of branches in the repository.
<glyph> All you can do is look to see if a directory was copied from 'trunk' or something that looks like it.  Is that wrong?
<jelmer> glyph: yes, but bzr-svn has a mechanism for determining what is a branch and what isn't.
<jelmer> glyph: that's what e.g. "bzr svn-import" uses to determine what branches to import.
<glyph> jelmer: oh.  I always assumed that _was_ the mechanism.  What's the actual rule?
<jelmer> glyph: it uses heuristics to find out what repository layout a svn repository has and then uses that layout, which is usually path-based.
<spiv> mgz: http://washort.twistedmatrix.com/2010/11/unicode-in-python-and-how-to-prevent-it.html
<loldrup> ...how do I tell which revision my branch is currently at? Neither 'status', 'log' or 'info' tells
<lifeless> bzr revno
<lifeless> or bzr log -r -1
<loldrup> thanks :)
<gthorslund> loldrup: if you've done a bzr update -r<oldrevno> then you'll need bzr version-info to get it
<lifeless> gthorslund: bzr revno --tree
<gthorslund> lifeless: aha! I've missed that one. thx
<glyph> so, I'm getting on a plane in 15 minutes
<lifeless> \o/
<glyph> can anyone figure out why svn+ssh://svn.twistedmatrix.com/svn/Twisted/branches/modules-so-2871 thinks that it needs to branch 14341 revisions, in a shared repository with an up to date copy of svn+ssh://svn.twistedmatrix.com/svn/Twisted/trunk
<glyph> in less than that amount of time?
<glyph> (svn+http should work as an anonymous mirror of the same thing)
<lifeless> well
<lifeless> jelmer: probably can, but I'd expect tha tmost of the history is identical and the progress counter should do a huge jump and be done quickly.
<glyph> well, no
<glyph> I know what it looks like when it does that
<lifeless> ok
<glyph> and it's definitely not doing that now
<lifeless> don't stop the operation
<glyph>   4519kB    15kB/s | copying revision 1126/14341
<glyph> oh
<glyph> oh I'm a liar
<lifeless> but what does 'bzr missing svn+ssh://svn.twistedmatrix.com/svn/Twisted/branches/modules-so-2871 say, run from your trunk mirror
<glyph> I have an up to date copy of http://svn.twistedmatrix.com/bzr/Twisted/trunk
<glyph> who knows what the differences are there
<lifeless> if its the same bzr-svn version, it should be the same-same.
<lifeless> OTOH perhaps its building its bzr-svn cache first, if this is the first direct to svn operation you've done.
<lifeless> that can take a little time.
<mwhudson> jam: oops, i wish i hadn't subscribed to ~jameinel/launchpad/lp-service :-)
<glyph> lifeless: nope, not that either.  I just made sure that I did have an up-to-date trunk; branching trunk took no time at all
<glyph> there's something wonky with that branch
<glyph> I'll have to repro this when I have better network connectivity and more time, I guess.
<glyph> Maybe I'll get lucky and the plane will have wifi ;)
<lifeless> good luck.
<glyph> lifeless: thanks for the attempt at help, anyway :)
<lifeless> :P
<mwhudson> glyph: if the branch was branched at the wrong level in svn, it can behave like that
<glyph> mwhudson: it wasn't; it's right under /branches, it's a copy of trunk
<glyph> mwhudson: I mean, you have the appropriate credentials, go ahead and inspect it :)
<mwhudson> that's unlikely if combinator is being used
<mwhudson> glyph: well, i'm trying to reproduce at leat
<mwhudson> *least
<mwhudson> glyph: ok yeah, i see the same
<mwhudson> oh hang on, different versions of the svn mapping in effect?
<mwhudson> glyph: it seems lp:twisted contains a mix of the v3 and v4 bzr <-> svn revid mappings
<mwhudson> and when you import from svn, you just get the v4 mappings
<spiv> mwhudson: a mix?  That seems odd.
<spiv> Aren't they unrelated ancestries from bzr's point of view?
<mwhudson> spiv: it does a bit doesn't it?
<mwhudson> and it seems that bzr-svn is somehow smart enough to know that
<mwhudson> bzr log --show-ids svn+ssh://svn.twistedmatrix.com/svn/Twisted/trunk -r 14639
<mwhudson> should give a v3 revid
<mwhudson> but not smart enough to know that svn+ssh://svn.twistedmatrix.com/svn/Twisted/branches/modules-so-2871 -r 14639 should too
<mwhudson> ... no
<mwhudson> oh right
<mwhudson> yes
<mwhudson> i guess this is a bzr-svn bug
<spiv> mwhudson: how does bzr-svn know that 14639 should be svn-v3?
<mwhudson> spiv: magic jelmer sauce?
<mwhudson> spiv: actually, i guess that because there are revisions in tm.com svn that are actual bzr commits, this somehow forces all older commits to be of a known mapping
<spiv> hmm!
 * mwhudson wants to know what bzr log --show-ids svn+ssh://svn.twistedmatrix.com/svn/Twisted/branches/modules-so-2871 -r 14775 says, but it's taking freaking ages
<mwhudson> ah
<mwhudson> bzr: ERROR: Requested revision: '14775' does not exist in branch: svn+ssh://svn.twistedmatrix.com/svn/Twisted/branches/modules-so-2871
<mwhudson> i think maybe what's happening is that the revision that 'forces' the trunk into v3 mapping isn't present in modules-so-2871
<spiv> mwhudson: ah, that seems plausible
<mwhudson> i don't know what you could do about that
<spiv> nothing pleasant, I suppose...
<spiv> Well, Twisted could land branches faster? ;)
<mwhudson> yeah, that would definitely help
<peitschie> mornin all :)
<mgz> thanks for that link spiv.
<spiv> mgz: you're welcome!  I haven't actually tried ascii_with_complaints yet myself... I suspect the noise will be a bit overwhelming.
<mgz> I think part of the pain is there's no decent way to specify interfaces.
<spiv> As in âthe first arg of this function takes unicode not bytesâ?
<mgz> every time you write a function or method that takes some kind of string, you don't want to write a type check at the top.
<mgz> as generally that should have already been handled somewhere else anyway.
<spiv> Yeah.
<spiv> Well, it was handled somewhere else...
<spiv> That somewhere else being ~1970, where only ASCII mattered ;)
<NET||abuse> hi folks, i'm a bit confused, i have a branch on my local machine of a repo on my server, i also hhave a branch on the server for deployment, but i also made a sql backup to the server branch and checked that in on the server, but i can't get the updated sql back down on my local machin.e
<NET||abuse> hmm, never mind, backupappeared after i pushed tothe server...??? werid
#bzr 2011-10-31
<quotemstr> Does bzr have anything like git's rebase -i?
<bob2> bzr-rewrite?
<quotemstr> bob2: Looking at that now, but it seems more limited.
<poolie> maybe in bzr-interactive
<poolie> ah kirill is working on rebase-interactive
<poolie> docs for the 'judge' tool i mentioned the other day: http://judge.readthedocs.org/en/latest/index.html
<jelmer> 'morning *
<nigelb> jelmer: Its afternoon, so you need like "Good * *" ;)
<jelmer> technically speaking it's not a good morning either, as I am slightly jetlagged
<nigelb> Ah, in Orlando?
<jelmer> no, back home
<jelmer> I was in california/nevada last week
<nigelb> ah!
<nigelb> Nice :)
<poolie> hi jelmer, nigelb
<nigelb> o/
<jelmer> hey poolie
 * jelmer breakfasts, biab
<jelmer> being up before 7 can't be healthy...
<poolie> :)
<poolie> jetlag?
<jelmer> yeah
<jelmer> how are things in bzr land?
<poolie> pretty good
<poolie> the good thing is that we did the rollout to the buildds
<poolie> the bad news is that it seems to have not completely fixed things
<jelmer> poolie: I followed up the RT, as far as I can tell not all the builders are running the newer bzr-builder yet
<poolie> that might be it then
<poolie> the next thing i was going to do on it is to try to reproduce things locally under a ulimit
<poolie> perhaps while we're talking, i should make an update for the udd list
<poolie> ah, also i wrote up some docs for judge on the weekend and this morning in http://judge.readthedocs.org/en/latest/index.html
<poolie> now i think i just need to use in anger, or to hear from others who have
<poolie> jelmer, so what else have we changed that will impact ubuntu users?
<poolie> oh, jelmer, can you look at https://bugs.launchpad.net/launchpad/+bug/872077 some time
<ubot5> Ubuntu bug 872077 in Launchpad itself "Import of crosstool-ng from Mercurial fails with unknown revid" [High,Triaged]
* poolie 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: poolie
<jelmer> re
<jelmer> poolie: we've added a bunch of new variables for deb-version in bzr-builder
<jelmer> poolie: and bzr-builder can now build native packages
<jelmer> poolie: I'll have a look at that bzr-hg bug, but I suspect it's not a trivial issue (bzr-hg imports in general are still fairly unreliable)
<poolie> just knowing whether it's trivial or not is  useful
 * jelmer should give judge a try, this is the first time I hear about it
<poolie> _please_ do
<poolie> i just wrote it the other week
<poolie> when i realized 'i wish there had been such a thing'
<poolie> i haven't used it yet
<AuroraBorealis> bug: formats entire hard drive
<poolie> ?
<AuroraBorealis> i was making a funny
<AuroraBorealis> cause its new software and not tested...i'll stop xD
<poolie> ah i think that's pretty safe
<poolie> i should have said i have used it, but not really seriously
<poolie> though, that would be a good chance to add a 'judge --jury-and-executioner' option
<poolie> if the new version is slower, delete it
<AuroraBorealis> hahah
<AuroraBorealis> judge --thumbs-up -> delete everything
<AuroraBorealis> or something
<AuroraBorealis> annnd i'm tired. night all
<fullermd> judge --dredd -> deletes itself and pays damaged to anybody who accidentally saw it.
<poolie> ok night fullermd, jelmer
<jelmer> g'night poolie
<Merwin> hi
<maxb> hello
<jelmer> hi Merwin, maxb
 * lamont reopens 616878
<jelmer> bug 616878 ?
<ubot5> Launchpad bug 616878 in bzr (Ubuntu Natty) "bzr commit error because of no identity (should look at /etc/mailname)" [High,Fix released] https://launchpad.net/bugs/616878
<Darxus> bzr: ERROR: unknown command "dailydeb"
<Darxus> Automated build just failed with that.
<Darxus> https://launchpadlibrarian.net/84144464/buildlog.txt.gz
<Darxus> From https://code.launchpad.net/~spamassassin/+recipe/spamassassin-daily
<jelmer> Darxus: looks like this has something to do with the deployment of the new bzr-builder on the builders. let's take this to #launchpad
<mgz> jelmer: if you're still not asleep, we've posted things from the sessions today that would be great to get your thoughts on
<jelmer> mgz: hi
<jelmer> mgz: yes, I saw - thanks for doing so
<jelmer> mgz: I'm currently trying to debug an issue with the recipe builders and will be off to bed soon after that. I'll make sure to read them tomorrow morning though.
<jelmer> mgz: how are you finding UDS so far?
<mgz> great
<mgz> and UDS has been pretty good too
<exarkun> What happened?  http://buildbot.twistedmatrix.com/builders/py-select-gc/builds/565/steps/bzr/logs/stdio
<jelmer> exarkun: that's a known issue fixed in 1.1.0
<jelmer> exarkun: did you see my last comment wrt the memory bug ?
<exarkun> jelmer: Are you sure?  I thought this one wouldn't be related to bzr-svn at all.
<exarkun> (The URL is to a real bzr repository this time)
<jelmer> exarkun: it is originally caused by bzr-svn
<exarkun> I saw your last comment.  Haven't had a chance to do anything about it yet.
<exarkun> What state is in trouble on this traceback?  The shared repository?  Should I delete that?
<jelmer> exarkun: yep, it's the bzr repository
 * jelmer stoort zich vooral aan de nieuwe progress balken
<jelmer> (sorry, wrong channel)
<poolie> hi all
<jelmer> yo
<mgz> hey poolie
<poolie> hi there
<poolie> i don't normally see you in my morning
<poolie> how's it going?
<vila> poolie: hey !
<mgz> it's been a pretty busy day, but generally well
<vila> +1 on the busy qualification :)
<jelmer> vila!
<vila> jelmer: \o/ |o_ o= /o\
<fullermd> Nono, you don't need to wave him off, he just needs to raise his right wing a bit!
<mgz> poolie: we've posted a few things to different lists it would be great to get some feedback on
<poolie> mgz barry mentioned the other day 'from __future__ import unicode_literals'
<poolie> and i thought of you :)
<poolie> we could do it in 2.5
<poolie> it may either help or work or both
<poolie> hi there vila, how's UDS?
<vila> hehe, you really want to start him on that ? :)
<mgz> I look forward to the python 3 session
<vila> poolie: really good, I think we did a very good job with the two sessions despite my initial stress handling them :)
<poolie> vila, no, i'm not saying we have to do it, i was just wondering about it
<vila> poolie: as mgz said above, we've debriefed together trying to better explain what we get from the sessions and how to act from there
<poolie> i wonder if it affects just the rest of that module or the global interpreter state
<vila> poolie: yup, I've discussed it with mgz and... he was a bit hesitant ;)
<mgz> barry's post was interesting, and both launchpad and bazaar have had... issues... with unicode,
<mgz> but with the basic str type still being bytes in Python 2, wholesale use of unicode literals tend to break as many things as they fix
<jml> poolie: I think you should have called judge "amifastornot".
<mgz> I'm particularly thinking stringification of objects, and interacting with filesystem/environment on nix
<jml> poolie: but very cool idea nevertheless.
<poolie> jml, thanks
<mgz> mozilla would have yelled at us jml.
<jml> mgz: oh is that a thing?
<jml> mea culpa
<poolie> everything is a thing these days
<mgz> okay, so it's arewefastyet, but nearly.
<vila> win ! go for it poolie ;)
<poolie> jml, if you get a chance to use it for real please let me know how it goes
<poolie> i wanted to put this in to bzr-usertest
<poolie> and then i realized it would be pretty useful even just by itself
<jml> mgz: I was thinking of various attractiveness-rating websites
<jml> poolie: yeah, will do. can't think of a use case atm, but maybe we'll have to optimize pkgme
<jml> ooh
<jml> actually...
<mgz> as vila found out when he tried googling, jml
<jml> software-center needs some speed improvements
<mgz> he looked a little shocked
<jml> heh
<poolie> ?
<jml> I'm not the innocent little lamb that I appear to be.
<vila> social event starting soon for us, cu later all
<jml> poolie: USC starts too slowly, basically.
<jml> poolie: makes me want to dive deep into some stats stuff (again!)
<mgz> right, challenge for this social event is to find someone who understands why my laptop doesn't work with the ubuntu wireless network
<mgz> whereas the naffy hotel network over here is okay.
<mgz> I may just be too lo-fi and out of date.
<poolie> jml i was hoping to take some deep stuff and make it shallow
<poolie> mgz, btw thanks for the update mails, i will reply
#bzr 2011-11-01
<neale> I just did a "bzr co lp:mixxx/1.10" and it put it in ./1.10/mixxx.  Is there a way to get that into ./mixxx instead, without doing a new 15-minute checkout?
<lifeless> mv 1.10/mixxx ./mixxx
<neale> that would lose 1.10/.bzr though; wouldn't that be, like, bad?
<lifeless> is 1.10 a shared repo ?
<neale> I don't know what that means, sorry.
<lifeless> if so then:
<lifeless> neale: can you run bzr info 1.10/mixxx
<lifeless> neale: and pastebin ?
<neale> sure
<neale> http://woozle.org/~neale/tmp/pb.txt
<lifeless> neale: that looks like its entirely independent to me
<lifeless> neale: try mving it
<lifeless> neale: if you can run bzr log afterwards, its ok.
<lifeless> neale: if you can't, mv it back.
<neale> so I did "mv 1.10/mixxx . && cd mixxx ** bzr log"
<neale> and it said: bzr: ERROR: Not a branch: "/home/neale/src/mixxx/".
<neale> so, apparently it's not.
<lifeless> oh, I see whats going on
<lifeless> the thing you checked out has the 1.10 directory in it ? odd
<neale> yeah, 1.10 is the top level directory
<lifeless> so put the mixx back
<lifeless> then
<lifeless> mv 1.10 mixxx
<lifeless> that won't get rid of the included subdir that is on LP
<neale> right, that's what I want to do.
<lifeless> if you are a developer of it you can remove that
<lifeless> its a versioned directory:
<neale> oh, that's in the upstream source that way?
<lifeless> bzr mv mixxx/* .
<lifeless> bzr rm --delete mixxx
<lifeless> bzr commit -m "move everything to the root"
<lifeless> would accomplish this, if you want to do that
<lifeless> yeah - you can see http://bazaar.launchpad.net/~mixxxdevelopers/mixxx/release-1.10.x/files that its in the upstream source that wayt
<neale> a versioned directory, like subversion?
<lifeless> kindof
<lifeless> yes its a directory and yes its versioned
<lifeless> unlike subversion though, the root of the tree isn't a matter of convention, its part of the core data structure
<neale> huh.
<neale> I thought I'd done something wrong :)
<lifeless> not at all
<neale> okay, I can cd ~/src/mixxx/mixxx I guess
<neale> thank you!
<lifeless> anytime
<BlindWolf8> hello?
<poolie> hi
<BlindWolf8> Hi poolie!
<BlindWolf8> do you know about bzr dedicated servers? (only using bzr:// protocol)
<poolie> yes
<BlindWolf8> do you mind if I ask you a question?
<poolie> just ask
<BlindWolf8> well, I setup a bzr server on Ubuntu. It's dedicated, so it just uses the bzr protocol...how secure is this compared to bzr+ssh?
<poolie> it's much less secure
<poolie> it's much better to run over ssh
<poolie> unless there's some really compelling reason
<BlindWolf8> hmmm....
<BlindWolf8> understood, but I'm not sure how pleased my clients who run Windows will be when they need to install PuTTy Agent
<poolie> it would be better for them to have an ssh key with no passphrase
<poolie> then they don't need a putty agent
<BlindWolf8> they would still need to load putty agent to keep their private key in memory to macth up with their public key on the server though
<BlindWolf8> righ...?
<BlindWolf8> been awhile since I've done this...
<Peng> Think of bzr:// as plain HTTP security-wise. Completely unencrypted.
<BlindWolf8> looks like I'll be using bzr+ssh then as I have in the past
<BlindWolf8> for the "serve" command, is bzr+ssh a legit protocol?
<BlindWolf8> I ask since it's not documented in "bzr help serve"
<fullermd> You wouldn't run 'serve' for bzr+ssh, just have bzr on the server.
<BlindWolf8> ok, thanks
<poolie> jelmer: hi?
<jelmer> poolie: hi, sorry
<jelmer> poolie: mumble, skype?
<jelmer> poolie: nevermind, just saw your email
<BlindWolf8> hello?
<jelmer> hi BlindWolf8
<BlindWolf8> Hi jelmer
<BlindWolf8> I have another Bazaar question
<BlindWolf8> is bzr_ssh_path_limiter included in builds yet? I'm using 2.4.1 on Linux and it looks like it's still not included
<BlindWolf8> looking at builds logs on launchpad, it looks like it sould be included
<BlindWolf8> I go Bazaar via PPA
<BlindWolf8> *should
<BlindWolf8> *got
<jelmer> BlindWolf8: it should be in 2.4.1, but I think it's probably only included in the source package, as it's in contrib/
<BlindWolf8> where would I find it on launchpad?
<BlindWolf8> is there a direct link to the file or do I have to go download a zip?
<jelmer> BlindWolf8: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/view/head:/contrib/bzr_ssh_path_limiter
<BlindWolf8> Thanks! Do I chmod this file to 755, or...?
<jelmer> yep
<BlindWolf8> I was planning on using "bzr serve" instead of this route, but it doesn't support ssh, (e.g., bzr+ssh) right?
<jelmer> BlindWolf8: yeah, bzr serve doesn't do ssh at the moment
<jelmer> that'd be a nice feature actually
<BlindWolf8> it would...just a single line via a startup script and BAM!
<BlindWolf8> jelmer: do you know how secure bzr_ssh_path_limiter is vs the --directory flag for "bzr serve"?
<jelmer> BlindWolf8: isn't bzr_ssh_path_delimiter implemented using the directory option of bzr serve?
<BlindWolf8> they seem to serve the same functionality, but I didn't write the code :-)
<BlindWolf8> didn't know if extra security features were implemented in one vs the other
<BlindWolf8> all I know is that I can't use bzr serve since it lacks ssh support
<jelmer> BlindWolf8: you can't use bzr serve to start a ssh server, but you can if you're already running openssh or something similar on the remote machine
<jelmer> BlindWolf8: there is no need for bzr_ssh_path_delimiter in that case, just something like "bzr branch bzr+ssh://host/path/on/host" should work if host is running a ssh server
<jelmer> and has bzr instaled
<BlindWolf8> oh...I just point clients towards the SSH port instead of the bzr port, i.e., 22 vs 4511?
<jelmer> if you use bzr+ssh:// in the URL it will automatically use the SSH port
<BlindWolf8> ...unless I don't use the default SSH server port... :-P
<jelmer> BlindWolf8: right
<BlindWolf8> do I need to specify --protocol or --bzr when using bzr serve if I want to use bzr+ssh?
<jelmer> BlindWolf8: you don't need to invoke bzr serve yourself if you're relying on e.g. openssh
<BlindWolf8> oh...it'll auto-run if it's installed and onvoked remotely via a client?
<BlindWolf8> *invoked
<jelmer> yep
<BlindWolf8> yeah, but then I don't get to limit direcory access when it runs, right?
<BlindWolf8> ...unless I use bzr_ssh_path_limiter of course
<BlindWolf8> anyone here?
<jelmer> BlindWolf8: limiting the directory access in what way? It doesn't really provide additional security.
<BlindWolf8> I just really wanted to make paths short in the bazaar interface
<BlindWolf8> so path limiter should do that
<BlindWolf8> however...I'm trying to create a new repo through the GUI on Windows when using bzr+ssh on the Linux box...I'm able to auth correctly, but I'm getting a 123 error
<BlindWolf8> the command passed to the server is "bzr new --colocated-branches --format 2a"
<jelmer> BlindWolf8: in that case you would indeed want to use bzr_ssh_path_delimiter
<jelmer> BlindWolf8: do you have bzr colo installed on the server?
<BlindWolf8> "new" and "--colocated-branches" don't seem to exist
<BlindWolf8> I simply installed bazaar through PPA...the last time I did this I don't remember having to install colo
<BlindWolf8> so I guess that's a "no"
<jelmer> BlindWolf8: you don't need it, but bzr-explorer apparently relies on it
<BlindWolf8> why wasn't it included in the PPA package for 2.4.1?
<jelmer> BlindWolf8: it's not a part of core bzr
<BlindWolf8> ah
<BlindWolf8> how would I go about installing that?
<jelmer> BlindWolf8: install the bzr-colo package (not sure if it's in the PPA)
<sohmestra> I'm using bzr 2.4.1, and bzr-git 0.6.2.  When attempting to serve my bzr branch using bzr serve --git, I don't seem to be able make it listen on anything other than localhost.
<sohmestra> I've tried bzr serve --git --port myhosthere:9418
<sohmestra> bzr serve --bzr works as expected
<sohmestra> Is this a bug, or am I doing something silly?
<jelmer> hi sohmestra
<jelmer> sohmestra: let me have a look
<jelmer> sohmestra: you have to specify the port as well for it to work, but the --git support in "bzr serve" is still very experimental at this point.
<poolie> hi all
<jml> jam: can you please unplug my cable?
<fullermd> Now that's distributed development!
<poolie> hi jml, fullermd
<mgz> hey poolie
<poolie> hi there, how's uds?
<mgz> good, had quite a bit of variety today
<mgz> couple of testing related sessions, canonical new starter intro, python 3 planning, and qt future
<jelmer> hi mgz, poolie
<mgz> hey jelmer
<Noldorin_> hey jelmer
<jelmer> hi Noldorin_
<Noldorin_> jelmer, hey. saw you made a new release for bzr-git, and fixed the rmbranch stuff at least?
<jelmer> Noldorin_: yep
<Noldorin_> cool
<Noldorin_> jelmer, any closer to solving the 'database item not found' issue ?
<jelmer> Noldorin_: not looked at that one yet
<Noldorin_> ok sure
<Noldorin_> fair enough
#bzr 2011-11-02
<Noldorin_> jelmer, well, it looks like you've been working hard, so i can scarcely complain... looking forward to it is all i can say :-)
<poolie> jelmer: do you reckon i should add tests before landing this, after, or don't care?
<vila> jelmer, maxb: Thanks in advance for giving  some love to bzr-2.4.2 and 2.5b2 in debian and our various PPAs :-)
<jo-erlend> I use bzr-explorer. I don't know if it's ontopic for this channel or not, but one thing I really miss, is the ability to see line numbers in the diff view. Is that possible?
<jelmer> jo-erlend: I think that's actually part of qbzr
<jelmer> jo-erlend: it's on topic in this channel, though it's probably best to file a bug report against bzr-explorer/qbzr about that
<jo-erlend> great. Thanks.
<smacktoward> hey all
<jelmer> hi smacktoward
<smacktoward> got a question I could use some better minds' help with :-D
<smacktoward> seeing a weird crash when i try to run bzr update
<jelmer> smacktoward: can you pastebin the backtrace?
<smacktoward> sure, 1sec
<jelmer> I have to quickly run out for groceries, but back in 20 minutes or so
<smacktoward> k
<smacktoward> pastebin: http://pastebin.com/GwM57smq
<jelmer> smacktoward: as far as I can tell this should be fixed in newer versions of bzr - 2.0 is fairly old
<smacktoward> hm
<jelmer> bug 279680 looks related
<ubot5> Launchpad bug 279680 in Bazaar ""AssertionError: name already in parent" when running update" [Undecided,Fix released] https://launchpad.net/bugs/279680
<smacktoward> yeah, there's a few similar looking bugs in launchpad, but none with a clear resolution
<smacktoward> bug 377261 for example
<ubot5> Launchpad bug 377261 in Bazaar ""AssertionError: name u'COMPILING' already in parent" in _generate_inventory when running "bzr update"" [High,Confirmed] https://launchpad.net/bugs/377261
<smacktoward> was hoping there was a fix short of upgrading b/c the box is running debian lenny and lenny-backports' bzr is only 2.0
<jelmer> hmm
<jelmer> jam: ^
<jelmer> jam: you were the last to comment on that bug, do you hjave any idea what might be happening?
<smacktoward> there is a duplicate bug of that one (bug 504836) that suggests that the branch is somehow irretrievably busted
<ubot5> Launchpad bug 377261 in Bazaar "duplicate for #504836 "AssertionError: name u'COMPILING' already in parent" in _generate_inventory when running "bzr update"" [High,Confirmed] https://launchpad.net/bugs/377261
<smacktoward> but i dunno how it would have gotten busted
<jam> jelmer: logging of to go give a session, ping me when I get back
<Saviq> hi all, can I unstack a remote branch?
<poolie> hi all
<jelmer> hey poolie
<poolie> hey there
<jam> hi jelmer, can you link me what you linked earlier
<jam> hi poolie
<jelmer> hi jam
<jelmer> jam: bug 377261
<ubot5> Launchpad bug 377261 in Bazaar ""AssertionError: name u'COMPILING' already in parent" in _generate_inventory when running "bzr update"" [High,Confirmed] https://launchpad.net/bugs/377261
<jam> jelmer: what was the question again?
<jam> (I don't have any traceback at this point)
<jelmer> jam: the reporter had this traceback: http://pastebin.com/GwM57smq
<jelmer> jam: we already found a different bug report which was marked as fixreleased in 2009, but had a similar backtrace
<jelmer> then later we found bug 377261
<ubot5> Launchpad bug 377261 in Bazaar ""AssertionError: name u'COMPILING' already in parent" in _generate_inventory when running "bzr update"" [High,Confirmed] https://launchpad.net/bugs/377261
<jam> jelmer: it certainly sounds like it could be the same bug
<jelmer> jam: I was mainly just wondering whether you had a better idea of what was going on, and if we could help the reporter with a workaround
<jam> jelmer: I don't think I dug into it enough to do workaround/reproduce the bug.
<jam> Though from the comments, maybe 'bzr revert ??.moved' and then 'bzr remerge ??' might help
#bzr 2011-11-03
<poolie> jelmer (if any) thanks for putting up the SRU mp
<poolie> i guess i can merge it
<poolie> and then wait for an admin to allow the upload
<meoblast001> hi
<meoblast001> how do you change the default editor when "bzr ci" is run?
<meoblast001> oh strange
<meoblast001> just found the answer in the next link on Google
<ibizaman_> did someone managed using redmine as a bug tracker ? (using the --fixes feature)
<ibizaman_> hi btw ^^
<brian515> Hi everyoneâ¦ can anyone help me with this error when I try a pull? "Transport operation not possible: http does not support mkdir()"
<beuno> brian515, pull or push?
<brian515> pull
<fullermd> You're using a checkout of a http://something branch?
<brian515> I should be
<brian515> It should be pulling from Launchpad
<fullermd> Well, pull wants to write to the branch.  And if the branch is http://...
<brian515> Sorry, I'm new to Bazaar and have limited experience with other version control systems. How should I resolve this?
<brian515> FWIW I can't push either
<bob2> bzr up
<fullermd> Depends on what it is you're trying to do.  But bob2's is a reasonable guess.
<brian515> Ok, bzr up doesn't return errors, but I haven't committed my code yet because bzr commit returns the same error
<bob2> sounds like you got a bound branch
<brian515> Ok. What does that mean/how can I fix it?
<fullermd> It means you started out with a "bzr checkout http://....", which isn't going to be useful for anything where you're wanting to write.
<fullermd> You'll need a writable (probably new local) branch instead.  You can use reconfigure to turn that checkout into a standalone branch.  -standalone, maybe?
<bob2> --branch
<fullermd> No, probably --tree.
 * fullermd hates reconfigure's model.
<bob2> oh, you're right, I didn't read past the , in the help string
<brian515> All right, I'll give that a try
<fullermd> I wish it had options for edges instead of nodes.
<brian515> Cool, that worked!
<brian515> Thank you!
<taowa> hi
<poolie> hi
#bzr 2011-11-04
<GRiD> hello
<JoeJulian> When an upload pack is being generated, a read is done to the file while it's still open for writing, without attempting to flush the write. Is this a bug? On a networked filesystem, this seems to result in a short read: http://fpaste.org/ziBn/
<poolie> hi grid
<poolie> hi JoeJulian
<poolie> that's interesting
<poolie> wow that is very interesting
<poolie> the double read is a bit interesting too
<poolie> i don't know if it's illegal but it's certainly unusual for a unix filesystem to require some special action to read back a file that was just written
<GRiD> poolie, is there someone in particular who looks after the btree_index code?
<poolie> probably lifeless or jam know it best
<GRiD> ok thanks. i'll talk to lifeless, then. trying to wrap up this bug i was (slowly) looking at. it's regarding the bzr search plugin too, which looks like he also wrote.
<poolie> oh ok
<poolie> which one?
<GRiD> 720853
<poolie> bug 720853
<ubot5> Launchpad bug 720853 in bzr search plugin "bzr crashed with RuntimeError in normpath(): maximum recursion depth exceeded while calling a Python object" [High,Confirmed] https://launchpad.net/bugs/720853
<GRiD> had a patch to solve the recursion, but i think it wasn't quite right and a test or two might have been failing. going to look again.
<poolie> that would be good to fix
<poolie> oh i see your comment
<GRiD> i think it actually comes down to the bzr search plugin trying to index some data it shouldn't, and it's triggering a case in the index that's not caught right now when the key is too big.
<poolie> right
<lifeless> o/
<GRiD> hi lifeless :)
<poolie> JoeJulian, can you please file a bug?
<poolie> it seems like a gluster bug but we can possibly work around it
<poolie> you could try doing an fsync in there and see if it helps
<JoeJulian> poolie, will do. I've also opened a gluster bug.
<jelmer> good morning Orlando :)
<davi_> jelmer, hi, is it fine to copy .bzr/repository/git (specially the idmap) between copies of the same repository?
<jelmer> davi_: hi
<jelmer> davi_: as long as the source repository has only a subset of the revisions of the target repository, that should be fine
<davi_> jelmer, thanks
<jelmer> davi_: it *should* also work if that is not the case, but I don't think that is very well tested. bug reports welcome
<davi_> ok
<jelmer> there is also a bug open about having bzr-git hook into bzr's fetch to automatically copy cache data when it's fetching revisions
<jelmer> davi_: how's your attempts to use push going?
<davi_> jelmer, been working fine lately :)
<davi_> jelmer, there was one bug with pulling with fetch_tags, but i worked around it by pulling the revisions first and then pulling tags.
<jelmer> davi_: is that with actual push or some form of dpush?
<davi_> jelmer, push, well, bzr pull to be precise.
<davi_> i guess that's a slightly different code path
<jelmer> it's indeed slightly different, but the hard bit (mapping between bzr and git) is shared between push and pull
<maxb> bleh, bzr-gtk build failure on oneiric beta-ppa
<maxb> The wonderful world of GNOME 3 migrations as applied to nautilus extensions
#bzr 2011-11-05
<BlindWolf8> Hi all. Anyone here?
<BlindWolf8> Hi all. Anyone here?
<thumper> some
<thumper> but it is saturday
<thumper> so not really
<BlindWolf8> hey thumper
<BlindWolf8> still here?
<maxb> jelmer: Hi. The latest bzr-git hung during its testsuite on the maverick and lucid PPA build. Before I look into that, I don't suppose it's something you know anything about already
<maxb> ?
<StyXman> is tehre any graphic history browser? qbzr and bzr-gtk don't have it (anymore?)
<luks> what do you mean by a graphical history browser?
<StyXman> luks: something like http://i1-linux.softpedia-static.com/screenshots/gitg_2.jpg
<luks> both qbzr and bzr-gtk have that
<luks> bzr qlog / bzr viz
<StyXman> ah, log
<StyXman> didn't thought of that
<StyXman> yes
<StyXman> thanks
 * maxb hates conflicting tags
<jelmer> maxb: hi
<jelmer> maxb: I've seen it on one machine, but not on another
<jelmer> maxb: I'm not sure what's going on exactly, so if you feel like investigating it, that'd be great
<maxb> jelmer: Ah, hi
<maxb> btw, can you be sure to pull the bzr packaging branches from alioth? I've pushed some minor housekeeping, that I really don't want to end up --overwritten :-)
<jayoung> Hi, I'm having some trouble with bzr. Can anyone help me?
<LeoNerd> bzr diff allows --diff-options, so I can e.g. reduce the diff chunk context size, to split bigger chunks into more, smaller ones. This is useful. Can  bzr shelve  have the same option please? I want to shelve one of two unrelated line edits, but the diff tool "shelve" uses thinks they're one change
<maxb> Well, that's convenient :-)
<maxb> bzr-gtk has been NMUed in Debian, fixing the bzr-beta PPA oneiric FTBFS
#bzr 2011-11-06
<Noldorin__> err
<Noldorin__> bzr mv --after is still telling me the ssource file is not versioned...help please?
<Noldorin__> anyone around? :-)
<Noldorin__> anyone?
<Noldorin__> bah, never mind. my bad
<wgz> and back.
<jelmer> hey wgz
<wgz> hey jelmer!
<jimis> How can I see which revision of trunk I merged earlier?
<lifeless> bzr missing is the usual way
<lifeless> log -n2 (or -n0) will show you the merge in your local tree, but not the revno of that revision on trunk itself.
<jimis> lifeless: thanks, I didn't know about bzr missing
<jimis> so the revision I last merged is the last one bzr missing shows, minus one?
<jimis> (the reason is that I want to produce a diff of my tree versus that revision of trunk)
<jimis> nice, a new revisionspec syntax
<jimis> bzr diff -rrevno:112685:../gcc-lp-notrees/trunk
<lifeless> oh
<lifeless> for that you might like
<lifeless> bzr diff -r ancestor:../gcc-lp-notrees/trunk
<lifeless> or merge --preview can be good as well
<jimis> ancestor is nice thanks :-)
<jimis> merge --preview I think doesn't do what I need
<lifeless> merge --preview *into* trunk will show you the result of merging your branch into trunk
<lifeless> including conflicts
<jimis> *into* is the key word :-)
<jimis> I don't want to "bzr switch" because I have local changes :-p
<lifeless> so; pushd ../../gcc-lp-notrees/trunk; bzr merge --preview $!
<lifeless> or something like that
<lifeless> + popd
<jimis> hmmm pushd/popd
<jimis> didn't know
<jimis> aah you mean the shell command, not a bzr command...
<lifeless> ah
<lifeless> OLDPWD
<jimis> lifeless: as the name suggests gcc-lp-notrees is a --no-trees branch, which doesn't have contents. Can I still do that
<lifeless> pushd ../../gcc-lp-notrees/trunk; bzr merge --preview $OLDPWD; popd
<lifeless> ah, no
<jimis> And I do work on a single checkout, using "bzr switch" for a git-like workflow
<lifeless> but
<lifeless> you should be able to in principle - can you file a bug, or would you like me to ?
<jimis> please do :-
<jimis> and I'll try later to file one for showing the source revision for merges, in bzr log
<jimis> I think that would be extra useful
<jimis> In general bzr needs work for single-dir workflow
<jimis> and that's the only way to work on huge projects like gcc
<lifeless> oh totally.
<lifeless> https://bugs.launchpad.net/bzr/+bug/886906
<ubot5> Ubuntu bug 886906 in Bazaar "merge preview wants a working tree" [Undecided,New]
<jimis> thanks lifeless
<lifeless> de nada
<jimis> no connection with linaro though :-p
<lifeless> ah - I will fix that :)
<jimis> I started working on gcc this summer for GSOC
<lifeless> the linaro folk do quite some gcc work
<jimis> I don't know why I chose bzr but it made my life pretty hard :-p
<lifeless> fixed, thanks
<jimis> I have on my TODO to file 4-5 bugs about bzr single-dir workflow
<jimis> and pre 2.4 bzr was a _nightmare_
<jimis> at least now it's workable...
<lifeless> cool, please do!
<jimis> https://bugs.launchpad.net/bzr/+bug/886910
<ubot5> Ubuntu bug 886910 in Bazaar "bzr log should show source tree revision for merges" [Undecided,New]
<jimis> Also do you know if "bzr merge" has a "pretend" option? How can I know if conflicts will happen?
<lifeless> --preview :)
<jimis> lifeless: preview shows a diff if I'm not mistaken?
<lifeless> yes, including conflicts
<jimis> I want the exact output as merge, but without applying any changes
<jimis> so that I don't get lost in the thousands line diff
<lifeless> I'm not sure
<jimis> --pretend would be nice :-p
<lifeless> TBH what I do is just merge; bzr st; bzr revert if I want that sort of thing
<lifeless> even on large trees merge should be pretty fast these days
<jimis> it's manageable :-p
<jimis> 10min is fast enough
<jimis> pre-2.4 it was unmanageable :-p
<lifeless> 10min? wow :(
<jimis> "bzr status" needs badly to be speep up... It know takes ~1.5 min but such an operation should be less than 10s
<lifeless> thats slow
<lifeless> do you have the C extensions ?
<jimis> lifeless: I'm not sure, I only did a "setup.py install" thing
<jimis> how can I see?
<lifeless> IIRC - check ~/.bzr.log, it whines in there
<jimis> Sun 2011-11-06 22:16:44 +0200
<jimis> 0.292  bazaar version: 2.4.1
<jimis> 0.292  bzr arguments: [u'log', u'-n0']
<jimis> 0.491  looking for plugins in /home1/public/jimis/.bazaar/plugins
<jimis> 0.491  looking for plugins in /home1/public/jimis/dist/lib/python2.6/site-packages/bzrlib/plugins
<jimis> 0.620  looking for plugins in /usr/local/ActivePython-2.6.4.10-linux-x86_64/lib/python2.6/site-packages/bzrlib/plugins
<jimis> 0.640  encoding stdout as sys.stdin encoding 'UTF-8'
<jimis> 0.940  encoding stdout as sys.stdin encoding 'UTF-8'
<jimis> 109.609  Transferred: 0kB (0.0kB/s r:0kB w:0kB)
<jimis> 109.610  return code 0
<jimis> I don't see any whining, right?
<lifeless> seems fine
<lifeless> are you on MacOSX ?
<jimis> no, RHEL5
<jelmer> hi jimis, lifeless
<lifeless> hmm
<jimis> hey jelmer
<lifeless> cause 1.5 minutes is (IIRC) 10 times the duration I had when I was optimising status on trees of a similar size
<ephan> Hey
<lifeless> hi jelmer
<jimis> lifeless: My experience on this host tells me it's the NFS mounted home
<lifeless> jimis: hah. Yes, NFS will kill your performance
<ephan> I am getting "Permission denied (publickey)."
<ephan> Should I ask a question on Launchpad, I Found a lot similar like these, but none like mine
<jimis> lifeless: it uses synchronous stat() calls which means for every file a full round-trip
<lifeless> jimis: out of curiosity, how long does 'time find . -type f -type d' take
<lifeless> jimis: in principle those get cached by the local OS, and readahead can happen as well
<jimis> lifeless: I've done that, it's pretty slow I think
<jimis> lifeless: not the stat() metadata
<lifeless> jimis: yeah, bzr st cannot be faster than that.
<lifeless> its the lower limit
<jimis> that's only cached for 2-3 seconds as far as I know
<jimis> a solution would be asynchronous stat(), which doesn't exist :-p
<jelmer> I also think merge hasn't had much attention from our speed-meister yet
<lifeless> in practice emulating a single-user chatty environment on a shared high latency substrate is doomed to be painful
<lifeless> jelmer: its had a couple of base passes
<lifeless> jelmer: but there is probably plenty of room to improve
<jimis> The proper solution would be multiple lightweight python threads, blocking separately on stat()
<jimis> it's on my TODO :-p
<lifeless> mmm, that will be -very- slow on a non-NFS machine
<jimis> cause I see this slowness everywhere: find, rsync, but most annoyingly bzr
<lifeless> python and threading don't play all that well together
<jimis> lifeless: I don't think show, why?
<jimis> ah I see
<lifeless> python has a single threaded core
<jimis> hmmm
<glyph> lifeless: erm
<lifeless> executing code in two threads requires a full context switch every time one of them wants to execute bytecode
<jimis> isn't there a "threading" module or something? I remember an easy way for light threads
<lifeless> there is, and it works, and if you're blocked on IO its great; the problem I am pointing out is that on NFS you are combating latency
<glyph> jimis: they're heavyweight (operating system) threads, not lightweight (interpreter) threads, and they don't parallelize CPU work, since there is a single lock for executing bytecode
<lifeless> and on local machines you're not, because your page cache will be hot and doesn't have the same arbitrary time based locked + does decent readahead
<glyph> python and threading play together just fine as long as you don't care at all about performance :)
<lifeless> heh, I'm all about performance ;)
<glyph> the right solution of course is that bzr should use twisted!! woooooo
<glyph> (and then the bzr developers should spend like 2 years implementing a general purpose, fast, event-driven filesystem I/O layer)
<lifeless> glyph: while I love twisted, it still adds quite some overhead ;)
<glyph> lifeless: if it's a realistic possibility that bzr could use twisted to address some of these issues, I'd love to sit down at some point and talk about how to get the import time down to something acceptable to bzr
<glyph> lifeless: the runtime overhead is negligible, even negative :)
<jimis> glyph, lifeless: this threading model sounds fine for blocking on I/O...
<glyph> lifeless: mostly I was just trolling but whenever I go trolling I am ready to back it up with some discussion at least ;)
<lifeless> glyph: its an interesting question. Uhm, I don't see how the runtime overhead can be negative, you'd be doubling the object alloc/free rate at minimum, if every file statted returned a deferred
<glyph> lifeless: Hrm
<glyph> lifeless: that's not at all how I'd do it
<jimis> Anyway, it remains for me to implement it sometimes, and measure real numbers :-p
<lifeless> jimis: indeed :)
<lifeless> glyph: directory at a time?
<glyph> lifeless: on the other hand, the thing that would do the "right thing" is still kinda in development; I'll keep you posted when there's a prototype
<glyph> lifeless: no, Deferreds are the wrong abstraction for an arbitrarily-big stream of events
<glyph> lifeless: that's the mistake web2 made and that's why its performance was a disaster
<lifeless> glyph: ah, a producer of some sort :)
<glyph> lifeless: yes.  except our existing producer API is _also_ a disaster.  Hence the new thing :)
<lifeless> glyph: so, I'd like to see the right thing; in particular how you introduce file system concurrency w/out threading and without sacrificing the non-threaded case..... on linux, with its appalling non-threaded concurrent disk IO story.
<lifeless> hmm, that came out negative
<lifeless> 'I am interested'.
<lifeless> And suspect its hard.
<glyph> lifeless: it is hard, and it's basically impossible to get right (wouldn't it be nice if linux didn't suck) but the answer rhymes with "one thread per platter"
<lifeless> glyph: you might be interested in the disk IO work Alex Rousskov has been doing in squid3
<glyph> lifeless: you want one thread doing the work and one feeding it, and you want the feeder thread to get a little bit ahead of the other thread and build up a buffer, because its performance is going to be all over the map as different directories have different tree balances
<jimis> lifeless: the /proper/ way is posix AIO (see aio.h)
<glyph> jimis: hahahahaha
<lifeless> glyph: you may know this already but squid is a twisted-like program - nonblocking callback based core, some work threads and helper processes.
<glyph> jimis: oh that's a good one
<jimis> but stat() has no AIO hook
<lifeless> jimis: AIO is sadly sadly sadly broken.
<glyph> jimis: http://stackoverflow.com/questions/87892/what-is-the-status-of-posix-asynchronous-i-o-aio
<lifeless> the kernel implementation is atrocious, because abstractions leak.
<glyph> lifeless: the kernel implementation is mostly just atrocious because it's atrocious
<jimis> FWIW I've used linux AIO (not posix, linux kernel specific)
<jimis> it works, and it works fast
<jimis> but still no stat()
<lifeless> glyph: really? Cause at LCA a kernel dude was up saying how bad it was
<lifeless> glyph: and the next New World Order was going to fix everything.
<glyph> lifeless: I'm agreeing
<lifeless> glyph: ;)
<glyph> lifeless: I'm just saying that it's not because any abstraction leaked, it's because it sucks completely
<glyph> the abstraction _as designed_ is terrible, the POSIX guys were on crack or something when they came up with it
<glyph> I mean, come on
<glyph> here's an idea
<glyph> "select() works on regular open files, and recv() can give you a short read on an open file"
<glyph> why is _that_ so hard
<jimis> jelmer, maybe you know:  showing find the source revno in "bzr log" is easy, or it would need some kind of hack?
<lifeless> glyph: indeed
<lifeless> I have to pop out
<glyph> lifeless: In my experiments on this topic, worker processes fared better than worker threads, because the GIL has some messed up interactions with the weird way Linux uses I/O to bias scheduling
<lifeless> but look at alex's disker work
<lifeless> he's been tuning to interact well with the linux write daemon, tuning IO to match disk load, spilling requests when needed etc.
<glyph> lifeless: where is this?
<lifeless> glyph: the GIL...messed up...weird.
<lifeless> glyph: sounds familiar :)
<jelmer> jimis: what do you mean with the source revno?
<lifeless> glyph: http://wiki.squid-cache.org/Features/RockStore
<lifeless> bbiab
<jimis> jelmer: the source revno of merges, see bug #886910
<ubot5> Launchpad bug 886910 in Bazaar "bzr log should show source tree revision for merges" [Undecided,New] https://launchpad.net/bugs/886910
<jelmer> jimis: I'm not aware of any revspecs at the moment that do that; what are you looking to do exactly (perhaps there's some way of doing it without that?)
<jelmer> jimis: another thing you can do is to use "bzr log -n1", though that will get you more data
<jimis> jelmer: still the revno is missing
<jimis> for now lifeless helped, and I did "bzr missing"
<jelmer> jimis: sorry, I meant "bzr log -n2"
<jimis> aha
<jimis> I'll try
<jimis> still "bzr missing" wasn't perfect, I had to /guess/ the revision I needed was the last it reported, minus one
<jimis> jelmer: nope, -n2 doesn't show it
<jimis> anyway, I'll leave that bug there, I'll look into it myself sometime hopefully it's easy
<jelmer> jimis: it does here, perhaps I don't understand what you mean
<jelmer> jimis: -n2 isn't showing the revision number for nested revisions for you?
<jimis> jelmer:     revno: 109439.2.3244
<jimis> but I want the original revision that I merged
<jimis> which is 115532 for example
<jelmer> ah, you're looking for the revision number as it exists *in the original branch* ?
<jimis> right!
<jimis> maybe I should edit that bug :-p
<jimis> so I can diff easily
<jimis> jelmer: so is it easy or needs hack?
<jelmer> jimis: that's not easy, as you'll need to reference the original branch somehow
<jimis> I see, thanks
<poolie> hi all
<jelmer> hi poolie
<jelmer> did you have a good weekend?
<poolie> hi, yes thanks
<poolie> three parties 8)
<jelmer> :)
<poolie> the bbq sunday had some people i hadn't seen for ~9 years so that was a bit strange
<poolie> but nice
<poolie> how are you?
<jelmer> not as many parties, but still had a very good weekend :)
<poolie> it's unusual for me
<poolie> so i think i saw you took the bug about, um
<poolie> passing --allow-fallback, is that right?
<jelmer> yeah - there's an approved MP for it now, but I haven't landed it yet
<jelmer> not sure what your plans were regarding deployed of newer buildd changes
<jelmer> *deployment
<poolie> i'm going to try to get buildd building as a separate tree from launcphad
<poolie> i got approval for all the changes needed to make it disconnected while still being in the same tree
<poolie> with a new txfixtures project split out
<jelmer> ooh, neat
<poolie> yeah,  it's one small step towards easier deployment, perhaps
<poolie> some tests fail
<poolie> i am hoping to fix them today and then build a package and then try to get lamont to install it tomorrow, my time, his monday
<poolie> iwbni he could pair with say spm or some other losa so that other people get comfortable deploying things
<poolie> i wonder if we could at least trust them to deploy to staging buildds
<poolie> trust/teach
<jelmer> hmm, yeah. that would probably already make a huge impact on the amount of time it takes to get something deployed
<poolie> anyhow, that's my main thing for today
<poolie> i think you should merge https://code.launchpad.net/~jelmer/launchpad/buildrecipe-allow-fallback-to-native/+merge/81271
<poolie> or i can do it
<poolie> it will eventually clash with my split-out
<poolie> though, obviously it's trivial to move it across
<jelmer> poolie: ok, I'll land it. I just wanted to check with you in case you wanted to deploy anything separately before the new bzr-builder
<poolie> :/
<poolie> it's hard to decide
<poolie> deploying seems both expensive and risky
<poolie> so i'm torn between testing out small changes individually, and deploying larger batches so we're not stuck here until christmas
<poolie> i think on the whole doing this whole batch together is better, including trying to split out buildd stuff
<poolie> which may make things easier in future
<jelmer> +1
<poolie> jelmer, oh the other thing someone should look at
<poolie> is https://bugs.launchpad.net/udd/+bug/848064
<ubot5> Ubuntu bug 848064 in Ubuntu Distributed Development "Revision not present branching from udd-imported branches on lp" [Critical,Confirmed]
<poolie> i decided to stick with the buildd updates
<poolie> oh we need to work out the sru too
<jelmer> I uploaded a package to oneiric
<jelmer> we just need to do the verification
#bzr 2012-10-29
<fullermd> lifeless, jelmer: https://bugs.launchpad.net/bzr/+bug/1072513
<ubot5> Ubuntu bug 1072513 in Bazaar "log can show too few revs" [High,New]
<fullermd> Sorry, the desc is long maze of twisty little passages, all subtly different   :|
<fullermd> Urg, the online formatting robbed some of the whitespace that made it less unreadable too   :(
<fullermd> My "favorite" part (aside from the existence in the first place, anyway) is how the more extra revs you remove, the more "proper" revs show up in the result.
<mark06> hi, is it possible to add --fixes later to an specific commit, just like you can tag? also, the translated url (e.g. lp => http://launchpad...) is what goes on --fixes right? (that is, no chance to ever get "lp:" translated into something else)
<fullermd> Pretty sure not.  Fixes is part of the commit.
<fullermd> Whereas you don't add tags to a commit, you more add commits to a tag.
<lifeless> mark06: the translation is controlled by config
<lifeless> mark06: you can make --fixes lp:1234 become anything you want, but much better is to add your own mapping to your own bug tracker.
<lifeless> mark06: e.g. --fixes twisted:1234 and have that resolve to the twisted trac instance.
<lifeless> mark06: see the docs for info.
<AfC> mark06: I had to do that once for GNOME's bug tracker, but then the Bazaar developers added gnome: to the built-in configuration for us. But it is eminently do-able to define your own mappings.
<mark06> lifeless: I wanted to avoid the chance of it ever getting translated into something else, something like an on-the-fly macro translating tracker: into a raw url, or at least by allowing the branch to hold the mapping itself (and assigning it a higher priority in comparison to user or global configs)
<jelmer> mark06: the branch always stores the full URL if you use --fixes, it never stores the shorthand
<mark06> ah good!
 * mark06 has evil plans to map rev: into e.g. http://bazaar.launchpad.net/~renatosilva/+junk/trf/revision
<mark06> thanks all
<Guest40826> Is this a suitable place to ask questions about Loggerhead?'
<Guest40826> Or should I direct my question elsewhere?
<spiv> Guest40826: this is a good place.
<Guest40826> Alright, thanks.
<Guest40826> I've been trying to configure Loggerhead
<spiv> Guest40826: (but it's a bit quite atm, so if no-one answers I'd try the mailing list next.)
<Guest40826> okay
<Guest40826> I've gotten it working by running "serve-branches --port=8080 --host=127.0.0.1 file:///{location here}"
<Guest40826> but I'm trying to follow the documentation on setting it up in /etc/init.d
<Guest40826> I put the loggerheadd file there and modified it so I thought it matched what I was in the other command
<Guest40826> but now, when I run it (/etc/init.d/loggerheadd start) I get a message that says that "Loggerhead is running." but then it also says "This server is *not* listening on port 8080."
<Guest40826> What would cause that?
<bartio> does bzr has something like externals (subversion) or submodules (git)
<bartio> could I use nested style for this? http://wiki.bazaar.canonical.com/SharedRepositoryLayouts
<bartio> Could I use nested style for this? http://wiki.bazaar.canonical.com/SharedRepositoryLayouts
<LarstiQ> bartio: what do you want from it? bzr-externals might cover your needs
<Guest40826> I'm trying to use bzr in a centralized workflow, but I'm encountering an issue with permissions. Can someone tell me what the permissions should be set to for the repo and branch directories?
<fullermd> You're probably wanting +w for the group (and, on a SysV-ish filesystem, setgid on the dirs too).
<Guest40826> fullermd: Thanks, that did the trick!
<einalex> hi! can someone tell me how to create a new standalone branch in python using bzrlib?
<LarstiQ> einalex: how general do you want to be?
<LarstiQ> einalex: bzrlib/builtins.py, cmd_init has the full logic from the bzr command
<einalex> LarstiQ: thank you
<LarstiQ> einalex: possibly bzrdir.create_branch() might be enough for you
<esr> Can anyone explain why in a bzr tags listing some tags display as "?" rather than a revision number?
<fullermd> That would be tags that point at revs not on the current branch.
<esr> fullermd: Thanks, we suspected something like that.  We're adding bzr support to autorevision.  See #autorevision or http://www.catb.org/esr/autorevision/
<fullermd> "Extracts metadata about the head revision from your repository."  What's it do with mtn, when there are multiple head revs?   ;p
<dak180> fullermd: should read "Extracts metadata about the current revision from your repository."
<esr> fullermd:  We don't have mtn support yet.  We've heard of it, but does it acxtually have...users?
<fullermd> Oh, well, that just pushes the question back a step to when there are pending merges   8-}
<fullermd> Well, I work on at least one project that uses it.
<fullermd> I do love the genre of "VCS abstraction $foo" stuff, but it always seems to run into rocky waters.  There are just enough fundamental differences to trip you up, but few enough to keep you trying.
<esr> fullermd: Yes, I know.  I wrote reposurgeon :-)
<fullermd> Hm.  What does VCS_NUM do when there are multiple initial revs?  Count from one, or sum everything up?
<esr> fullermd: Depends on the VCS.  We'd have to look at what the reporting commands we use do in that case.
<esr> I don't thing that can happen at all with svn or a bzr branch.  But perhaps I'm wrong.
<fullermd> Probably not in svn.  But it certainly can in bzr; I do it all the time.
<fullermd> bzr/git/hg are all close enough in the revision data model that they should be the same in that.
<esr> We just use what bzr revno gives back.  Do you have a better suggestion?
<fullermd> Mmm.  Interesting.  revno is simple, and easy to describe.
<fullermd> The downside is that, depending on how you treat your revision graph, it won't necessarily be monotonically increasing.  Using it for a build num wouldn't get along well with that.
<fullermd> Of course, an argument could be made that in that case, you wouldn't be using a workflow that changes the mainline.  But then, Murphy usually has something to say about arguments like that.
<LarstiQ> esr: is bzr version-info useful to autorevision?
<LarstiQ> ah, already using it
<fullermd> A count of the total number of revs should (assuming you're not engaging in history rewriting) be monotonic.
<fullermd> 'course, it could make moves like "+1, +1, +2, +1, +683, +1, ..."
<fullermd> Doesn't inherently damage utility as a build num, but could freak out users.  Maybe it's a good idea just for that reason   :>
<fullermd> VCS_DATE reminds me of some thinking I was doing the other week about how VCS should store timestamps.  I got off into thinking about libtai for a while before I sobered up...
<fullermd> Though that did leave me with the unpleasant "there is to great solution" hangover.
<lifeless> fullermd: to great or no great
<fullermd> See?  The hangover  :p
<fullermd> Unfortunately, it lasts pretty much your whole life from the first time you get it.
<dak180> fullermd: counting the total number of commits outside of the vcs tends to be very slow for any large repo and thus better avoided if it can be done, but yeah total number of commits generally is what i have been going for since, as you noted, it generally will not go down
<fullermd> Yeah, I'm not aware of any non-silly way (grpe -c'ing log or the like) to get it through the bzr UI.  Probably could do it in a couple lines of bzrlib.
<fullermd> Would be rather less than instantaneous, but probably could be not deathly slow.
<fullermd> lifeless: BTW, I don't s'pose you glanced at that 'log' bug, and have a good answer for something I'm doing wrong, rather than it really being the nasty bug it looks like?
<lifeless> fullermd: I didn't no. Whats the # again ?
<fullermd> bug 1072513
<ubot5> Launchpad bug 1072513 in Bazaar "log can show too few revs" [High,New] https://launchpad.net/bugs/1072513
<lifeless> fullermd: (I'm now at HP Cloud Services, so even less involved in bzr day to day ;))
<dak180> fullermd: something like that is there as a fallback for git, on a repo with +1000 commits it gets verrry slow
<fullermd> Desc may have gotten long enough to call for a summary of the summary...
<fullermd> Oh, even better then.  Just run a copy of bzr through there; everybody knows that moving stuff into The Cloud fixes everything.
<lifeless> fullermd: it does
<fullermd> And all this time, people thought telling me I had my head in the clouds was an _insult_!
<lifeless> fullermd: so
<lifeless> fullermd: first glance I don't see anything wrong
<lifeless> fullermd: directories don't have a recursive change field
<lifeless> fullermd: so foo/ only changes when foo it self is merged with another parallel add, or renamed or reparented or kind-changed.
<lifeless> fullermd: foo/bar's changes should have no impact on 'bzr log foo'
<fullermd> Er.  I'm pretty sure it should; log was fixed several versions back for that, wasn't it?  'cuz anything else is "unuseful".
<lifeless> fullermd: foo/bar's graph doesn't change when foo/bar is merged into the mainline, and the -n0 codepath does fast deltas along the mainline in 2a using the common tree structure
<fullermd> But even if that's not the case, it should still show the revs that added the dir.  And shouldn't start showing the other revs it "should" when I take out some of the --unchanged "Nada" revs.  Or give the same bad result with -v on the file.
<lifeless> fullermd: oh indeed, you're right. See, i'm out of date :)
<fullermd> Yeah, the 6 rounds of editing I did on the desc as I tried taking out and adding things really confused it up   :|
<fullermd> There, I added a couple short comments summarizing the Wrong Answer(s).
<fullermd> The bit where removing the --unchanged revs one at a time makes the other "correct" revs show up in log one at a time is just extra freakiness I found along the way of reproducing it, not the base bug I hit.
<fullermd> And it's not a 2a shortcut tripping us up; does the same thing with pack-0.92.
<lifeless> fullermd: cool (not really ;))
<lifeless> fullermd: I wonder if its fallout from the change we did from downward to upward branch dotted decimal numbering
<fullermd> Wow, that would be a long-standing bug.
<fullermd> I have a hard time imagining that matters, but then you know that code better than I do.  My understand of it is "it does some lifeless stuff"   :p
<fullermd> Well, I'm sure it'll make a tasty treat for one of those guys working on bzr day to day...
<fullermd> What sorta stuff are you doing in The Cloud now?
<lifeless> fullermd: https://github.com/tripleo/demo/blob/master/README.md
<fullermd> Ew, they're making you post github links on #bzr?  That's just unnatural!
<lifeless> fullermd: you asked ;P
<lifeless> fullermd: my muscle memory is slowly adjusting, but I'm missing bzr's UI still in many subtle places
<fullermd> It builds character, I'm sure   8-}
<fullermd> I'd be interested in any "damn I miss this" and "wow I love this" notes you might scrawl out on the matter, if you get bored.  Could be useful info.
<lifeless> the index is a nuisance
<lifeless> its useful when you need it but its overhead 99% of the time
<lifeless> having to unbreak commit to actually capture your changes on every run is a pita
<fullermd> Yeah, that always seemed like such an odd mandatory thing.  So many people hold it up as the most awesome thing, and I keep thinking "Stockholm syndrome" every time I read about it...
<lifeless> I very much miss bound branches
<lifeless> I'm working with 6 folk on a single repo with ~ 5 files atm
<lifeless> so we stomp on each other all the time
<lifeless> recovery is fairly easy - you just save the commit message git pops up and then run rebase and then push
<lifeless> but its a big WTF each and every time.
<fullermd> Wuff.  And with that team/project, that probably happens every 3rd commit on average   ;p
<lifeless> yeah
<lifeless> we're rapidly expanding the surface area of working things, so that we can specialise for longer periods
<lifeless> but we're expecting another 5-8 folk to join in the near term
<fullermd> Think you'd need a rather thickier "branch" (for lack of a better word) data struct/model than git has to pull off adding that.
<lifeless> so I'm not sure thats going to be a big win
<Guest40826> I'm trying to use the automirror plugin, but whenever I do a checkin I get "bzr: ERROR: Server sent an unexpected error: ('error', 'JailBreak', "An attempt to access a url outside the server jail was made: 'file:///var/www/site/'.")"
<Guest40826> file:///var/www/site/ is the location that I am trying to send the code to on checkin.
<Guest40826> Does this have to do with permissions/ownership of the site directory or is there a bigger issue here?
<Guest40826> Anyone know?
<fullermd> I think that falls into "bigger issue", with the env that hooks run in not allowing access to arbitrary places in the FS.
<lifeless> Guest40826: do you have a repo at /var/www/site/ ?
#bzr 2012-10-30
<einalex> hi again! I have trouble using WorkingTree.move() to move a file to the root directory (of the branch)
<einalex> I get a BzrMoveFailedError telling me that the directory is not versioned...which is clearly nonsense
<einalex> what parameter am I suppsoed to use for to_dir to get it to work? (".", "/", "/path/to/bzr/repo/" all did not work)
<einalex> worked with "" ...
<mortrca> fullermd: ping?
<fullermd> Hmm?  (not really here right now)
<mortrca> I'm still trying to figure out the "bzr: ERROR: Server sent an unexpected error: ('error', 'JailBreak', "An attempt to access a url outside the server jail was made: 'file:///var/www/site/'.")" issue that I mentioned ~19 hours ago
<mortrca> To which you responded that "the env that hooks run in not allowing access to arbitrary places in the FS"
<fullermd> Yes, that's deep in innards/API space, where I don't play.  Hooks run in a jail that limits what they can do/where they can go in the filesystem; 's the limit of my knowledge.
<mortrca> According to the docs "Mirroring currently only works on local paths or URLs that imply ssh access to the remote machine (sftp://, bzr+ssh:// or svn+ssh://)."
<mortrca> Which says to me that this should be working
<mortrca> Do you have any suggestions for me? Another place/person that I should ask?
<fullermd> I don't, no.  On the high end, I've never looked at the plugin you're using, and on the low end, I don't know much of anything below the CLI.
<fullermd> jam or lifeless would know more, but I don't know when they're around to chat.
<mortrca> Alright, thanks.
<fullermd> Maybe vila too (though he's not even pseudo-online right now)
<mortrca> alright, I'll try again a little later.
<LarstiQ> mortrca: do you have a bzr branch at /var/www/site?
<LarstiQ> and/or repository
<LarstiQ> mortrca: because that looks like a containing-bzrdir search that doesn't find what it is looking for under /var/www/site
<jam> mortrca: please feel free to send an email to the mailing list with a bit more context. I'm not quite sure how things are trying to access the branches, or what triggers are happening on their behalf.
<jam> Is it via ssh, via http, via etc.
<jam> And how is the service configured.
<mortrca> LarstiQ: Yes, I do have a branch there.
<LarstiQ> mortrca: and its repository?
<LarstiQ> mortrca: `bzr info` will have the info
<mortrca> Standalone tree (format: 2a)
<mortrca> Location:
<mortrca>   branch root: .
<mortrca> Related branches:
<mortrca>   parent branch: <path>
<mortrca> Is that what you were looking for?
<LarstiQ> mortrca: yeah, that proves my theory wrong :)
<mortrca> okay
<mortrca> I guess I'm headed to the mailing list.
 * LarstiQ nods
 * LarstiQ can't think of what else it could be atm
 * lifeless is around
<LarstiQ> lifeless: hi!
<lifeless> LarstiQ: hi!
<LarstiQ> lifeless: belated congratulations on your new job
<lifeless> LarstiQ: thanks :)
<dobey> is there some special thing i'm perhaps forgetting to do, to make bzrlib.branch.Branch.open('lp:foo') work properly? just doing that gives me an 'UnsupportedProtocol' error: 'Unsupported protocol for url "lp:foo"'
<LarstiQ> dobey: bzrlib.plugin.load_plugins()?
<LarstiQ> dobey: the lp: directory service is implemented by the launchpad plugin
 * LarstiQ is guessing it isn't loaded
<dobey> thanks LarstiQ
<dobey> what's the simplest way to create a copy of a branch on lp? from lp:~foo/bar/baz to lp:~foo/bar/baz-2-0 for example
<dobey> old_branch.create_checkout(new_url) gives me an UpgradeRequired for the nwe branch, which is odd since it just created it and it is 2a
<LarstiQ> dobey: the target is on lp also?
<dobey> LarstiQ: yes
<dobey> and launchpad API has no copy operation on its branch objects
<dobey> i want to take a trunk branch for one project, and create a stable series and accompanying branch for it; with the new branch being unstacked.
<LarstiQ> dobey: hmm
<LarstiQ> dobey: .create_clone_on_transport?
<dobey> i'm looking at that now, but what is "to_transport" exactly? i suspect passing in a url will just give me an error
<LarstiQ> dobey: bzrlib.transport.get_transport_from_url(url) should help I think
<dobey> get_transport_from_url is giving me the UnsupportedProtocol error; and just passing in the url to create_clone_on_transport gives me an UpgradeError after it created an empty branch on lp :-/
<dobey> anyway, i need to run for a few. so bbiab
<dobey> sorry, back now
<dobey> this is just not working at all :(
<jelmer> dobey: hi
<jelmer> dobey: what is the URL you are passing to get_transport_from_url exactly ?
<dobey> UnsupportedProtocol: Unsupported protocol for url "lp:~ubuntuone-control-tower/dirspec/stable-4-2"
<dobey> and yes, i am calling load_plugins(), and bzrlib is happy to open the branch for lp:dirspec
<fullermd> I'm not sure directory services reach down that far.  g_t_f_u probably only takes a URL.
<jelmer> dobey: you have to resolve directory services first
<jelmer> dobey: that will translate lp:foo -> bzr+ssh://bazaar.launchpad.net/~owner/foo/trunk
<dobey> jelmer: how to do that?
<jelmer> dobey:
<jelmer> from bzrlib.directory_service import directories
<jelmer> new_location = directories.dereference(old_location)
<dobey> thanks jelmer. got something mostly working how i want now. :)
<jelmer> dobey: cool
#bzr 2012-10-31
<LarstiQ> dobey: ah, sorry about forgetting that dereferencing
<Lo-lan-do> Hi all
<Lo-lan-do> Is anyone still working on bzr-git? jelmer maybe?
<Lo-lan-do> I'm having to interact with a growing number of git repositories, and the pain of plain git is becoming a bit too much.
<AfC> Lo-lan-do: it works fine. Pushing back to Git is lossy, though
<Lo-lan-do> Yeah, I know about push/dpush, that's one of my concerns.
<jelmer> Lo-lan-do: I don't work on bzr-git anymore
<Lo-lan-do> jelmer: Sad. Does anyone else?
<jelmer> Lo-lan-do: not that I'm aware of, unfortunately
<Lo-lan-do> 'kay. Thanks for the information and the past work :-)
 * fullermd waves at vila.
<vila> fullermd: o/
<vila> fullermd: I noticed your bug about log but haven't dug it yet
<lduros> hello, I've used bzr tag mytag-4.9 for a given revision
<lduros> but now I would like to change it to a later revision
<fullermd> It's a lot of digging   :|
<vila> fullermd: I had network issues and just got "something" back
<lduros> it turns out i had to address a bug
<vila> fullermd: yeah, it's nightmarish
<fullermd> I added some extra comments yesterday trying to sum it up better.  The main desc got very long and twisted while I was trying to isolate and characterize it.
<vila> fullermd: I'm not even sure there is a good fix
<fullermd> lduros: You probably want something like 'tag --force' (or possibly two-stepping tag --delete, then re-tag'ing, but it's the same thing in the end)
<vila> fullermd: yup, saw that too, will have look next week (when I'm back home with real network and real hardware to work with :-/)
<fullermd> vila: I'm sorry, I don't like that answer.  Plz try again  ;p
<vila> fullermd: the semantics for what log should consider to be a directory change are unclear
<fullermd> Well, possibly.  There can be some discussion about what's "right", but what's happening now is certainly _wrong_.
<fullermd> The part where "taking out revs that don't touch anything change what shows up for `log dir`" I find particularly egregious...
<vila> there have been discussions in the past about whether they should include any change *below* the dir instead of just the changes to the dir itself
<fullermd> They do, and that was already changed some versions back.
<vila> morevover -v or not trigger different code paths :-/
<fullermd> Taking out 3 of the "bzr ci --unchanged -m 'Nada'" commits makes all 4 expected revs show up.
<vila> fullermd: were you able to find a bzr version where the behavior is different ?
<vila> yeah, that one is scary
<fullermd> Nyet, I tried the heads of all the 2.x branches and .dev, and tried 2.0 with --pack-0.92
<fullermd> It's something weird about that history shape that freaks things out.
<vila> ok, at least it's not a regression then
<lduros> fullermd: thanks!
<fullermd> (I didn't try pre-2.0, but I'm a programmer, not an archaeologist  :p)
<lduros> fullermd: --force worked
<fullermd> lduros: Note that if you've push'd the tag anywhere, you'll probably have to resort to more big hammers to update it in those places.
<fullermd> And if anybody else has pull'd it, things get even more complex.
<vila> fullermd: hehe, yeah, fair enough, thanks for trying all 2.x though
<lduros> fullermd: but now when I try: bzr push :parent it tells me there's a conflicting tg
<lduros> tag
<lduros> fullermd: yeh, you are right
<jelmer> Lo-lan-do: sure :-) I'm still hacking on Dulwich, and also still happy to provide help if anybody else is interested in hacking on bzr-git.
<lduros> fullermd: just read your line :-)
<fullermd> lduros: I think push --force will update it.  May be "safer" to tag --delete it from there directly, then try pushing (I can't remember if tag can do that remotely)
<lduros> fullermd: it says no such option as --force
<fullermd> But that still leaves you with the troubles of other people who've already pulled it.  Nothing you can do there but notify them to tag --delete it before they pull.
<fullermd> Oh, --overwrite I mean.
<fullermd> Of couse, they cna _pull_ just fine.  THey'll just get a warning about the difference, and their local tag won't move.
<lduros> fullermd: yay! Looks like it works!
<lduros> fullermd: nobody else is using
<lduros> :-)
<fullermd> Don't be so pessimistic   8-}
<lduros> hehe
<fullermd> vila: (also, note the notes about the branch of the script where it makes a foo file rather than a foo/ dir, and how it does the same thing with -v.  So we can't just blame the whole thing on dirs  :|  )
<lduros> I'm curious, what made Bazaar a GNU project? :-) Is it because of the fact that it is a fork of GNU Arch?
<vila> fullermd: ack, then somehow it's better as it means it could be easier to fix
<fullermd> It's not really a fork, it just inherited a few ideas and a lot of people who worked on arch before.
<lduros> ah ok
<lduros> :-)
<fullermd> I'm not sure what the background behind GNUification was, I just woke up one day and there was some antlered thing running around.
<lduros> hehe
<lduros> fullermd: well the reason I started using bzr is because it became gnu and thus became the vc tool of choice for gnu projects, so I guess it helped gain a few users! :-)
<fullermd> Ooh, maybe that explains why there are people who use emacs, too.  I can't think of any _other_ reason why anybody would...
<lduros> :-P
<lduros> fullermd: I wasn't saying i'm using bzr just because of that, but it got me acquainted with it :-)
#bzr 2012-11-01
<AfC> I have no wish to stop using bzr, but it's becoming less and less optional to not be on github with my code.
<AfC> I'm trying to understand what a workflow could be, but since dpush did a rewrite of all my history, am I supposed to throw my old bzr (only) branches away, or...
<AfC> ?
<jelmer> AfC: you shouldn't have to throw your old branches away - a new 'bzr dpush --no-rebase' from your old branches should be compatible with what's on github
<AfC> Huh
<AfC> jelmer: So you use `dpush` once and only once, then always `dpush --no-rebase` from then on?
<jelmer> AfC: you should be able to always use --no-rebase I think
<AfC> jelmer: oh, interesting
 * AfC tries that
<AfC> jelmer: so, er, why wouldn't that be the default command?
<AfC> s/command/option setting/
<jelmer> AfC: it's the default, because it's not useful for what dpush was meant for (contributing to upstream projects in git)
<AfC> I see
<jelmer> AfC: an option setting to disable rebasing would make sense, though you can also add a 'dpush = dpush --no-rebase' alias in ~/.bazaar/bazaar.conf
<maxb> Presumably publishing to git via dpush --no-rebase works wonderfully until someone tries to submit changes to you via github....
<jelmer> right, it works if you have a mirror but it makes it impossible to merge from git since the histories will be completely unrelated
<AfC> maxb: that's the other thing I'm wondering about, though frankly that's secondary
<AfC> maxb: I really just want to get my code up somewhere more visible than self-hosting
<AfC> jelmer: right. So, if I `dpush` alone, then the branch gets rebased
<AfC> that's fine.
<jelmer> AfC: yep
<AfC> I then continue developing locally
<AfC> making [bzr] commits
<AfC> then I ...
<AfC> er
<AfC> um
<AfC> use dpush again, and accept that the branch keeps getting rebased?
<AfC> I guess I'm trying to understand how that will work vs
<AfC> bzr branch a b
<jelmer> AfC: that's one way of working
<AfC> cd b
<AfC> comit, commit,
<AfC> bzr missing --line ../a
<jelmer> AfC: as long as you dpush before you push the changes anywhere else
<AfC> jelmer: [Robert has told me I'm foolish for keeping trying to use Bazaar against a Git storage backend, but :(]
<AfC> jelmer: ah
<AfC> yes, that makes sense
<AfC> so dpush to github [or even just a local throw-away?] and *then* push to my "official" public branches on our webserver
<AfC> jelmer: [as always, thanks for your advice]
<jelmer> AfC: FWIW I'm just using Git for projects that are in Git these days too
<AfC> jelmer: so, I sorta said it before, but the critical need for me is to get my code onto github
<AfC> jelmer: it's really just a PR thing
<AfC> jelmer: but it's getting to the point where people judge your resume by your github account. I've been challenged for it in an interview once already.
<AfC> jelmer: that, cross product
<fullermd> Pfft, how hard can it be to hack github and setup bzr hosting on the server?   :p
<AfC> jelmer: the language I'm working in these days is *extensively* active on github
<AfC> fullermd: :)
<AfC> fullermd: I wish
<bob2> just using git means you also get to use magit
<jelmer> AfC: ah :-( That's a pity, especially the fact that it's about a specific propietary service.
<bob2> which is awesome
<AfC> jelmer: I know. But the community is there.
<fullermd> Well, it could be worse.
<AfC> jelmer: [that would, essentially, be the same conversation if we were talking about Twitter vs Identica]
<fullermd> Imagine if the important community coalesced around ClearCaseHub instead.
<jelmer> AfC: only slightly; Git has the advantage of being distributed, but we then still stick all our repositories on Github
<AfC> jelmer: yeah
<AfC> jelmer: though, I'm less worried about that; *I* know how to host my code elsewhere :)
<jelmer> AfC: :-)
<AfC> jelmer: the fact that it's a single point of failure for everyone else who thinks DVCS are centralized is their problem :)
<jelmer> AfC: So, I think I agree with lifeless here.. maintaining a copy of your work in two DVCSes is a lot more pain than in one, especially given the somewhat beta state of bzr-git's dpush support.
<AfC> jelmer: don't be saying that. You're my last shred of hope that I can keep using bzr in the face of overwhelming numbers of employers/clients who otherwise have no idea what I'm talking about
<fullermd> Funnily enough, I've got a bzr project somebody else put on github  ;p
<fullermd> Though that went the other way; they used git-bzr to yank it in.
<AfC> fullermd: hm
<jelmer> AfC: if you don't care about pulling in contributions from github then bzr-fastexport+git-fastimport (which is basically what git-bzr is) is certainly also a good option
<AfC> jelmer: well, I wouldn't want to be hostile to contributions from there
<AfC> jelmer: reality is, that's where they're going to see the code
<jelmer> AfC: dpush (with rebase) should indeed be quite suitable in that case
<jelmer> AfC: without somebody actively maintaining bzr-git it's likely to break at some point though, as is happening with some repositories because of new git features
<mgrandi> hey, does anyone have any experience with bzr serve? i'm messing around with it
<AfC> mgrandi: sure. What's your question?
<fullermd> You're not supposed to mess with it, it doesn't have any sense of humor at all.
<mgrandi> im not sure how im supposed to use it, is the ssh server supposed to be listening on 4155 (the default port), but then bzr serve can't bind to that address
<mgrandi> and if ssh isn't listening on 4155 and bzr serve is, then i get "bzr: ERROR: Unable to connect to SSH host mgrandi.no-ip.org:4155; Error reading SSH protocol banner"
<jelmer> mgrandi: the plain bzr server listens on port 4155
<AfC> Running bzr [serve] as a daemon is not SSH protected
<jelmer> mgrandi: the ssh server is basically just 'bzr serve' executed over the ssh protocol, on the regular port
<mgrandi> yeah i noticed that, is that basically waht its intended for?
<jelmer> mgrandi: yep
<mgrandi> that the client just runs bzr serve?
<mgrandi> and then it exits?
<mgrandi> seems like that would be slower
<jelmer> mgrandi: there is some overhead involved, but starting up bzr isn't that slow, especially compared to the ssh handshake
<mgrandi> but either way its faster then using sftp?
<AfC> mgrandi: hugely so
<AfC> SFTP is a disaster zone
<fullermd> Again, could be worse; could be FTP...
<mgrandi> well on my remote host i can't install stuff to root, is there a way to modify what path of bzr it asks for?
<fullermd> (that's what's great about the internet; there's always a worse idea somebody's gonna force you to use sooner or later...)
<jelmer> mgrandi: you can set the 'BZR_REMOTE_PATH' environment variable
<fullermd> Or just put where it is in your remote $path.
<mgrandi> oh thats true
<mgrandi> there is just little documentation about serve, its mystical~
<mgrandi> so after it calls bzr serve how does it tell tell the computer (running bzr serve) what it needs?
<spiv> fullermd: updating your remote $PATH won't help, unless you mean via some system-wide mechanism (/etc/environment?)
<fullermd> Sure it will, it just runs 'bzr'.
<spiv> fullermd: right, and it doesn't run .bashrc (or whatever your shell of choice is)
<spiv> So if you try to update your PATH for your account the way you usually do, it won't help.
<mgrandi> doesn't ssh do that when it connects? i know putty does
<fullermd> That's a shell specific thing.
<fullermd> I don't know offhand what config file weird-ass shells like bash load on non-interactive sessions, but there is one.
<fullermd> For me, it does work just fine, since I use a sensible shell  ;p
<fullermd> e.g.: % bzr ping bzr+ssh://localhost/      [...]  Headers: {'Software version': '2.6.0dev3'}
<fullermd> Unless'n you think I'm nuts enough to system-wide install bzr.dev...
<fullermd> (and in fact, in this case, it's not even $path; 'bzr' is a shell alias getting invoked, pointing over to .dev)
<spiv> fullermd: the point is that sshd *won't run your shell*, IIRC
<spiv> Because the SSH client is not requesting a shell.
<spiv> It's asking to run a command.
<fullermd> Er.  Yes it does.  It has to; that's how the login process works.
<fullermd> Otherwise setting your shell to /usr/sbin/nologin or similar artifacts would have no effect, as you could just 'ssh host /bin/sh' or the like to bypass them.
<fullermd> The shell is what runs the command you ask for.
<fullermd> It runs the shell in _non-interactive_ mode, which means if you're using a shell that reads different rc files based on that you'd need to know it and set things in the right place, but that's a separate matter.
<spiv> I may be getting confused with subsystems...
<fullermd> Possibly.  Subsystems are a whole different ball of mud.
<Tolstoy> When my colleague does a bzr diff, we see a revid on the files that have changed. When I do it, I get a date. Is there some way I can change that?
<Tolstoy> bzr 2.5.1
<Tolstoy> bzr diff rebid plugin was the trick.
<youlysses> Now obviously you guys may be a bit biased, but how comparable is bzr to git speed-wise?
<fullermd> I'd say somewhere between "indistinguishable" and "terribly slower", depending on the cases you're comparing.
<fullermd> It probably averages out to moderately slower, day to day.
<youlysses> fullermd: But it's not a *huge* deal, assuming you aren't doing a ton at a time?
<fullermd> Probably not, unless you hit degenerate cases.
<fullermd> Seems the usual case we hear about is initial branching on giant projects.
<youlysses> fullermd: Yeah for my current needs, I have nothing "massive" to really worry about... or alteast I hope-so. :-P
<ZyX-I> Hello. How can I know what statuses may be shown in âbzr statusâ output? Except for reading âbzr help statusâ (it is incomplete) and bazaar source code (it is hard to find out the answer there).
<lifeless> ZyX-I: its incomplete?
<ZyX-I> lifeless: Yes.
<lifeless> ZyX-I: a little more detail would be useful, or perhaps file a bug. I was not aware that it was incomplete.
<ZyX-I> lifeless: There are at least three statuses that are not listed there: missing (donât remember how to reproduce), ignored and unexistent (just supply bzr status ignored or unexistent paths). It looks like there are also two merge-related statuses.
<lifeless> hmm - please do file a bug
<lifeless> help status is where it is *meant* to be documented.
<ZyX-I> lifeless: For missing: add a file using âbzr addâ and then remove it using just ârmâ.
<lifeless> ZyX-I: yes
<ZyX-I> It is for bzr-2.5.1.
<ZyX-I> I like the idea of telling me about invalid password when it was meant that I have not activated my account.
#bzr 2012-11-02
<mathrick_> hiya
<mathrick_> I'm setting up a workflow for a company that hasn't used any VCS before (ew), and I need to make things simple enough to have them use it
<mathrick_> one of the things I want to get is to have a "submit" command, which takes changes not present in the submit branch yet, and *merges* them in as a new revision, so that the submit branch, which serves as a central repo / coordination point always receives merges corresponding to logical "features", rather than just having revisions pushed from the dev branches
<mathrick_> that's both for internal organisation purposes, as well as because they interact with an external SVN repo maintained by a customer; they want the customer to receive changes, but only in coarse "feature" chunks and not the fine-grained revisions the development actually happened in
<mathrick_> and I want to set it up in a way which doesn't require having two different dev/ and submit/ (to perform the merges in) in addition to bzr://server/repo/central
<mathrick_> only dev/ and bzr://server/repo/central
<mathrick_> for that reason I'd like the "submit" tool to do something like create an internal .bzr/branch/submit if it doesn't exist yet, and then use that for merges in a transparent way
<mathrick_> so, the question: does something comparable exist so that I could set it up with appropriate aliases and plugins, or do I need to cobble up my own plugin for that?
<Wiz_KeeD> hey guys, what are the graphical methods in which you can view a branch evolution using ubuntu?
<Wiz_KeeD> there were two ways and i was using one forgot what the package was called
<Wiz_KeeD> anyone?
<jml> what's the fastest way to get the files in the tip of a branch over https? export? branch? checkout? checkout --lightweight?
<mathrick_> jml: I don't really understand your question. If there's no smart server, then no method is particularly faster than the others, since you still need full history to build the files
<mathrick_> assuming you mean faster in wallclock time spent on transferring things
<mathrick_> *in the sense of
<jml> mathrick_: yes, faster in that sense.
<mathrick_> then all should take roughly the same time
<mathrick_> branch and checkout are identical, except that checkout will automatically push local changes to the parent branch, which doesn't make sense with https
<mathrick_> I'd suggest plain branch, since that gives you most bang for the same buck. In case you need to do anything more with it, branch will have everything locally already, and the others won't
<LeoNerd> If you do anything other than "export" then you'll have a local branch you can update later on, without needing a full pull again
<mathrick_> with a lightweight checkout it's not really true
<mathrick_> since it's very little more than just the working tree
<mathrick_> well, you can update it of course
<mathrick_> but it needs network access
<mathrick_> but yes, it will definitely be faster than re-exporting
<fullermd> I'm not sure about that...
<fullermd> Especially over a dumb server.
<mathrick_> at the very least, it can skip over files that haven't changed
<mathrick_> bu hmm\
<mathrick_> you're right, a dumb server probably won't see benefits of a lightweight checkout
<fullermd> In theory maybe.  I'm not sure it works out that way in practice.
<mathrick_> yeah
<fullermd> Even with a smart server, I'd hesitate at lesat 6 times before even considering a light checkout over anything slower than a 2ms/1gbit pipe.
<mathrick_> oh it's not that bad
<mathrick_> I've used lightweight checkouts many times for things like plugins which I don't want to work on
<mathrick_> even ones with rather extensive history
<mathrick_> btw, any comments on my question re: "bzr submit"?
<jelmer> mathrick_: I think I might have missed the question
<mathrick_> oh, lemme pastebin it
<mathrick_> http://pastebin.com/p3YAVsCv
<mathrick_> jelmer: ^
<mathrick_> if there is some other workflow which'd make it easy that I haven't considered, I'm of course also interested
<jelmer> mathrick_: I don't think such a command exists at the moment.
<mathrick_> I see
<mathrick_> I think it'd be a worthwile addition
<mathrick_> it seems sensible to me to use merges as a history organisation tool
<jelmer> patches welcome? :)
<mathrick_> writing as we speak? :)
<jelmer> heh, OK
<LarstiQ> jml: hmm, my guess would be export, for a one off
<felipec> what is wrong with this? http://pastie.org/5173618
<felipec> I get ImportError: No module named fastimport
<felipec> but it's there
<fullermd> You sure you're looking for the right one?  The bzr 'fastimport' plugin relies on the python 'fastimport' library.
<felipec> yeah... just realized that
<felipec> what is the status of the bzr <-> git compatibility?
<felipec> I see quite a few plugins, but I hear a lot of them don't work reliably
<fullermd> I'm not really the one to ask, since I've never used any of them.
<fullermd> My impression is that the various fast-import solutions work fine for one-way conversions/mirrors/etc.
<fullermd> And bzr-git does a reasonably good job with caveats for the "use bzr as a git client" sort of uses.
<felipec> fullermd: you think fastimport is reliable?
<fullermd> I've not heard about any major issues with it.  Which, to be sure, proves little, but...
<fullermd> It probably won't much help you if you're trying to _work_ in both VCSen.  But for working in one and maintaining a copy in the other, I'm given to understand it does fine.
<fullermd> (or one-time conversion of course, though that's just a degenerate case)
<felipec> branch.iter_merge_sorted_revisions(0, -1) the same as branch.iter_merge_sorted_revisions(None, None)?
<felipec> er: 1, -1
<felipec> or rather: builtins._get_revision_range([0, None], ...
<felipec> s/0/1/
<felipec> I guess rev1 = RevisionSpec.from_string(str(tip)), RevisionSpec.from_string(None)
<felipec> wow, the git-remote-bzr in bzr-git is in really bad shape
<jelmer> felipec: in what way?
<felipec> jelmer: many ways... but for starters I can't push
<jelmer> felipec: FWIW git-remote-bzr in bzr-git is experimental
<jelmer> felipec: how does push break?
<felipec> jelmer: let me try again
<felipec> jelmer: but also, it's not tracking the properly... a 'master' branch should appear in git
<felipec> I'm writing a simple git-remote-bzr that already does that
<jelmer> felipec: I think it already does that, at least in trunk
<jelmer> felipec: either way, patches welcome :-)
<felipec> jelmer: the code is too complicated and it's doing many things that are not neccessary
<felipec> jelmer: http://pastie.org/5174396
<felipec> also, the push seems to be fetching _all the objects_ again, which is certainly not needed
<jelmer> felipec: ah, that's happening because you're pushing into a bound branch I think
<felipec> jelmer: what is that?
<felipec> jelmer: in my remote-bzr I'm able to push to the same branch just fine
<felipec> although only once
<jelmer> felipec: what is your remote-bzr ?
<felipec> jelmer: http://pastie.org/5174415
<jelmer> felipec: ah, so that's essentially the same thing as git-bzr is doing?
<felipec> jelmer: yeah, but git-bzr doesn't use git's remote helper functionality
<jelmer> felipec: I'm pretty sure at least one of its incarnations does
<felipec> jelmer: you mean bzr-git?
<jelmer> felipec: no, git-bzr
<jelmer> (I'm involved in bzr-git/bzr-fastimport)
<felipec> and actually I'm seeing the same issue mentioned in git-bzr-hg: AttributeError: 'BTreeBuilder' object has no attribute '_find_ancestors'
<felipec> well, I don't see it here: https://github.com/pieter/git-bzr, or here https://github.com/termie/git-bzr-ng
#bzr 2012-11-03
<jelmer> I remember seeing it, but I'm not sure which version of it that was
<felipec> jelmer: I'm wondering if I should depend on bzr-fastimport or not... I'm not sure if it's reliable
<jelmer> felipec: what else should it depend on?
<felipec> jelmer: nothing... write my own
<jelmer> ah, sure
<felipec> jelmer: that's what I did for mercurial
<felipec> jelmer: the first push works fine... but not the second: http://pastie.org/5174454
<felipec> smells to me like an issue in bzr-fastimport
<jelmer> felipec: apart from the _find_ancestors bug (which is an issue in core bzr) bzr-fastimport's exporter works really well, and has been around for a long time
<felipec> jelmer: I see... but that bug is rather important
<jelmer> felipec: sure, but probably easier to fix than to NIH bzr-fastimport
<jelmer> ... and it doesn't seem unlikely you'll hit it too if you implement your own exporter
<felipec> jelmer: yeah, but how long has it been there? It seems like several years
<felipec> jelmer: and yeah, maybe I'll hit it... but maybe not :)
<jelmer> felipec: I think it's mostly the git-bzr folks that have hit it; I certainly have never come across it
<felipec> jelmer: well, I hit it
<felipec> 100% reproducible
<felipec> jelmer: http://pastie.org/5174655
<felipec> er, rather check the raw one: http://pastie.org/pastes/5174655/text
<felipec> ./test.sh bzr-fastimport
<felipec> bang!
<jelmer> felipec: sorry, I meant I never hit it when using bzr-fastimport myself; I did manage to reproduce it after reports from users
<jelmer> I've never had the time to investigate further though, and have since moved on to other things
<felipec> riight
<felipec> so there's no hope of somebody actually fixing this bug
<felipec> also: fastimport.errors.UnknownFeature: Unknown feature 'done' - try a later importer or an earlier data format
<jelmer> felipec: it's a bug in bzr core, I think there were people working on that
<felipec> jelmer: how do you know it's a bug there?
<jelmer> felipec: I debugged this stuff earlier; bzr-fastimport is using the appropriate APIs, it's breaking deep in the bzr index handling code.
<felipec> jelmer: can you point me the the point where bzr-fastimport is using those APIs?
<jelmer> felipec: it should be in the backtrace
<felipec> jelmer: the backtrace only shows trying to access something on the index
<felipec> not what puts things there
<felipec> jelmer: also, if this is not related to bzr-fastimport, there should be a standalone test  that reproduces this... and where is the bug report?
<jelmer> felipec: https://bugs.launchpad.net/bzr/+bug/541626
<ubot5> Ubuntu bug 541626 in git-bzr-ng "'BTreeBuilder' object has no attribute '_find_ancestors'" [Undecided,New]
<felipec> jelmer: that says the fix is released
<jelmer> felipec: there is some talk at the bottom of that bug report refuting that
<jelmer> felipec: also, this was fixed pretty recently - are you running bzr from trunk?
<felipec> jelmer: and all the comments after that saying that the bug is still there were ignored
<felipec> jelmer: 2..5.1
<jelmer> felipec: that's definitely from before the change that claimed to fix it (which was 3 months ago)
<felipec> jelmer: so you want me to download the lastest when in fact the people in there say the problem is  still there?
<jelmer> felipec: It's worth a shot - I don't know if the people who are saying that are running the latest version.
<felipec> lets see
<felipec> jelmer: do you have any comments in how the bzr-fastimporter API is used? http://pastie.org/5174765
<felipec> export_branch() and do_export()
<felipec> also, you shouldn't assume the prefix is 'refs/heads', I see some temporary branches are created where they shouldn't
<jelmer> felipec: that's not my code :-)
<felipec> jelmer: 'you' as 'you guys'
<jelmer> felipec: I'm no longer really involved.
<jelmer> felipec: anyway, what would you suggest as alternative place for termporary branches?
<felipec> jelmer: well, I don't know what are temporary branches, but they should use the same namespace
<felipec> jelmer: for example, I pass ref='refs/bzr/origin/master', and I would expect 'refs/bzr/origin/tmp'
<felipec> hmm, bzrlib/_static_tuple_c.c:35:33: fatal error: _simple_set_pyx_api.h: No such file or directory
<felipec> all right, hacked setup.py to disable that warning
<felipec> jelmer: still fails
<felipec> a shorter version of this? bzr log -r X --show-ids | grep 'revision-id:' | sed -e 's/revision-id: //'
<fullermd> bzr version-info --custom --template '{revision_id}\n' -rX
<felipec> fullermd: thanks
<felipec> jelmer: hmm, fatal: Missing > in ident string:  <Alexander Belchenko <bialix@ukr.net>> 1172879596 +0200
<felipec> jelmer: fatal: Path bzrlib/tests/per_repository/test_merge_directive.py not in branch
<felipec> how can I go back to a previous version?
<felipec> bzr update -r bzr-2.4.0 leaves the whole working directory in a bad state
<felipec> is there shallow clone support?
<fullermd> To the former, update pull or revert, depending on just what you want in "go back".  If the changes end up running across unclean bits of the tree, "bad state" is not unexpected.
<fullermd> For the latter, that would be stacking.  But I'm not sure you want to mess with that.
<felipec> jelmer: how am I supposed to export only a subset of revisions? bzr fast-export --baseline bzr-2.3.4 -r "bzr-2.3.4..bzr-2.4.2" <- this is definitely not working worrectly
<felipec> fullermd: bzr revert -r bzr-2.3.4; bzr pull -r bzr-2.3.4; bzr status <- I still see a lot of stuff there
<fullermd> I said 'or', not 'and'   ;p
<fullermd> And yes, doing backwalks from a non-pristine tree is likely to lead to fewmets lying around.
<felipec> fullermd: I know, but I tried both to make sure :)
<felipec> bzr update -r X && bzr revert
<felipec> damn it, I don't inderstand why bzr log -r bzr-2.3.4..bzr-2.4.0 wouldn't show bzr-2.3.4
<fullermd> You need -n0 since the 2.3.4 tag doesn't wind up on the mainline.
<felipec> fullermd: thx
<felipec> fullermd: the first revision I see is 5609, the second is 5609.48.4
<felipec> but there's tons of changes in between
<fullermd> I don't.  Bottom of the list is 5609.51.2, which is the one with the bzr-2.3.4 tag on it.
<felipec> fullermd: do a diff
<fullermd> Of the tags?  That's not gonna tell me much about any revs...
<felipec> fullermd: bzr diff -r 5609..5609.48.4
<felipec> but I guess this is what I want: bzr log --exclude-common-ancestry -n0 -r bzr-2.3.4..bzr-2.4.0
<fullermd> Well, that tells me "here's a big diff", but I'm not sure what else to take from it   :p
<felipec> found the bug
<felipec> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/5757.2.1
<felipec> jelmer: it was you
<felipec> jelmer: the bug was in bzr-fastimport: https://launchpadlibrarian.net/121914657/bzr-fastimport.patch
<felipec> it has to repack on every run? that seems like overkill
<Fandekasp> hi there
<Fandekasp> I have a big issue with yum. basically I need bazaar>=2.4.1 to use the -d option, and the best version I find through all my repositories is 2.1.2 : http://sprunge.us/KHcg
<Fandekasp> Any yum/rpm user here who knows what's going on ?
<bob2> not a yum or rpm issue
<bob2> you can just install it from source if you like
<felipec> jelmer: found the bug
<felipec> this time for real :)
#bzr 2012-11-04
<AfC> Yet another bad day trying to use Git.
<bob2> it's not so complicated nowadays
<AfC> bob2: I just discovered Git is incapable of tracking empty directories. #lame
<bob2> yeah
<bob2> it tracks files and symlinks only
<felipec> AfC: at least it's capable of tracking more than one branch
<bob2> all useful vc systems can do that though
<felipec> bob2: and by branch I don't mean a repository
<bob2> yes I know what a branch is
<bob2> are you whinging about bzr-colo not existing or something?
<felipec> bob2: I don't know what bzr-colo is, but I meant that bzr branch != git branch, more like git clone
<bob2> ok!
<bob2> anyway, bzr-colo or just use git
<felipec> I'm looking at bzr-colo, and it looks like it's more like mercurial branches... still not the same
<bob2> it's not
<felipec> origin/master <- that I like
<lifeless> felipec: bzr-colo is nearly identical to git's model of branches
<lifeless> its not at all like mercurial
<bob2> I think that's a complaint about branch identifiers not the branch model
<felipec> lifeless: so, I can have master, devel, feature-a, origin/master, origin/next, bob/master, alice/feature-b, etc.?
<lifeless> felipec: yes, they sit in a subdirectory of off the root
<lifeless> and AIUI can have arbitrary names
<felipec> lifeless: it's not about the name, it's about tracking a remote repository
<felipec> it looks like there's support for a single remote repository, or workspace... I guess that's better than nothing
<lifeless> felipec: each branch tracks a remote branch
<lifeless> felipec: and there is a (not optimised) plugin to track entire repos
<lifeless> gluing the two together should be fairly easy, if you want to do that
<felipec> all right, my git-remote-bzr is looking good :) http://pastie.org/5179942
<AfC> Yet another bad day trying to use Git.
<AfC> I just discovered `git status` writes a file somewhere
<AfC> Unreal
<bob2> are you running it over fuse
<AfC> bob2: no. It's .git/index.lock that gets {..., CLOSE_WRITE, CLOSE}.
<Wiz_KeeD> hey guys
<Wiz_KeeD> if i made a commit and i would like to change the title of the commit...how do i do that?
<jelmer> Wiz_KeeD: bzr uncommit && bzr commit
<Wiz_KeeD> aww i have to uncommit :(
<Wiz_KeeD> i have to revert to that revission
<Wiz_KeeD> uncommig
<Wiz_KeeD> commit
<Wiz_KeeD> then head back
<jelmer> Wiz_KeeD: yep - you can't really edit existing revisions, just create new ones
<Wiz_KeeD> heh
<Wiz_KeeD> thanks man
<Wiz_KeeD> i'll be more careful then
<maxb> It would be quite nice to have a 'bzr commit --amend' that implicitly based its parent revision on the parent-of-the-parent and preloaded the old commit message in the editor
<jelmer> indeed - there is a bug report open about that I think
<SamB_MacG5> okay, what the heck ... I have to deal with stale locks on *launchpad* now?
<jelmer> SamB_MacG5: only if connections actually got interrupted, etc?
<SamB_MacG5> jelmer: I don't know how it came to exist, really ...
<SamB_MacG5> but it was like a hundred days old
 * SamB_MacG5 doesn't check his cron mail very often ...
 * SamB_MacG5 thinks the SVN protocols ought to add a FAST-EXPORT <path> type of command ...
<fullermd> If we just replace all SVN usage with some DVCS or other, we can bypass that whole problem   8-}
<SamB_MacG5> yeah, but while people are still using various DVCSes with SVN repositories ...
 * SamB_MacG5 discovers debianlp:; doesn't remember seeing that in the bzr docs ...
<felipec> jelmer: I was able to import/export to/from bzr without bzr-fastimport: http://pastie.org/5186077
<felipec> still missing a few features, but not bad for a couple days of work :)
#bzr 2013-10-29
<dobey> hi all
<dobey> if i am using bzrlib as a library in another python process, and i have a Branch and/or a WorkingTree object opened, is there a way i can export the branch with uncommitted changes, via the API?
<lifeless> dobey: I presume you mean the tree?
<lifeless> dobey: and yes, totally
<dobey> yes
<dobey> yeah, i found the bzrlib.export.export function used by cmd_export. am having some trouble with the test suite now though :(
<dobey> ah, i think i got that fixed now, by adding a dep on mock
<dobey> thanks anyway :)
<tuxiano> Hi, I need help to access a bazaar server in a local network with bazaar explorer. My problem is, that I dont know how to type correctly the url. I tried: http://IP/repository/user and brz://IP/repository/user, but there is always an error message.
<tuxiano> it says: Unable to change to /home/user/bzr:/IP/home/bzruser/repository - closing page.
#bzr 2013-10-30
<mark06> does bzr store timezone identifiers as branch metadata? for example the commit dates have a numeric indicator such as -0300 or -0200, but I wanted to know if it was ever possible knowing "from where" the commit was made, e.g. from Japan or South Africa
<mark06> this is because bzr does not work with msys, due to msys not implementing timezone support properly
<mark06> this causes for the commit dates indication wrong numeric timezones, and if it was possible to know the commit location, then a third-party library could be used to check if the numeric timezone indicators are actually correct
<spiv> mark06: IIRC probably just the UTC offset, but it's been a quite while since I lookedâ¦
<spiv> So I could very easily be wrong.
<fullermd> I'd be pretty sure.  It's the rightest (or at least least wrong) thing to do.
<fullermd> 'm pretty sure there's nothing at the _branch_ level about it one way or the other anyway; it'd all be in the commits.
<mark06> yeah it actually wouldn't make much sense not being in each commit, since every commit could have been done from a different location
<fullermd> Like those nuts committing stuff while they fly across the Intl Date Line.
<mark06> like merging contributions from whatever in the globe
<fullermd> That's way less interesting than my story   :p
<fullermd> vila: Hithere.  Is that note() you added in r5887.3.1 actually meaningful for anything?  It smells like dev droppings...
<mark06> thanks all anyway
<lifeless> fullermd: love the imagery
<fullermd> I always say, if you can't be useful, at least be visceral   :)
<lifeless> fullermd: I feel you
<vila> fullermd: wut ? I can't see any note() added in 5887.3.1. The diff shows an existing note('Nothing to do.') in the neighborhood but bzr doesn't blame me ;)
<vila> fullermd: 5887.3.1 revid:v.ladeuil+lp@free.fr-20110525204316-j9mjhu9usylbey06 that is, may be you're looking at a different one ?
<fullermd> Oh.  Hm.  I guess not, it's jriddell's fault when he merged it.  Guess I didn't recheck the diff, when I saw it was just a merge of 1 rev.
<fullermd> note("merger: " + str(merger))
<fullermd> (5887.2.6)
<fullermd> 'm thinking that should go
<fullermd> % bzr merge asdfawr
<fullermd> merger: <bzrlib.merge.Merger object at 0x8070c2ed0>
<fullermd> bzr: ERROR: Path(s) do not exist: asdfawr
<fullermd> Doesn't really add much  :p
<vila> fullermd: ha ! ok, let me find that
<vila> fullermd: hehe, it's even i10n'ed !
<vila> fullermd: removed in my local trunk, will find its way upstream with the rest of the ~200 uncommitted changes there :-/ when time permits...
<fullermd> Funny, it sounded like you said "somebody please hack into my system and liberate these changes"   ;>
<fullermd> Yeah, I got a kick out of tracing that back and seeing where somebody had gettext()'d it.
<fullermd> Why should English speakers get all the fun, after all?
<vila> fullermd: hehe, yeah, almost ;)
<vila> bbiab
#bzr 2013-10-31
<mark06> so, a follow-up to my uncommit discussion from the other day, how about bzr heads --dead-only?
<mark06> ok it will not show all uncommits, only last one, but it's a good start no?
<mark06> is there any case where this might be problematic? bzr branch a b; cp a/.bzr/branch/branch.conf b/.bzr/branch/branch.conf?
<mark06> i.e. invalid configuration that doesn't really apply for the new branch?
<lifeless> shouldn't be; its equivalent to cp -a a b
<lifeless> modulo some rules about what revisions are cloned in the repo etc
<mark06> ok, thanks!
<mark06> although I'm not sure if it's equivalent to filesystem copy, since unreferenced commits (uncommitted commits) will not exist on target branch
<lifeless> 'modulo some rules about what revisions are cloned in the repo etc'
<lifeless> mark06: they don't exist in the source branch either
<lifeless> mark06: only in the source repo
<lifeless> mark06: and if you have a shared repo, branch a b within it won't be cloning revisions at all
<mark06> I only use standalone branches, sorry
<lifeless> mark06: doesn't worry me; just pointing out some of the subtleties
<mark06> I mean they exist in source branch cause it's standalone, containing the repo
<mark06> I didn't get modulo
#bzr 2013-11-01
<Wiz_KeeD> hey guys, if I pull off a branch and then check a bit later if the repo which I've got the branch from has changed or not, basically comparing revision numbers, how would I go about that?
<Wiz_KeeD> bzr revno parent?
<Plouj> how can I view specific files in this repo in my browser: http://anonscm.debian.org/bzr/pkg-ssh/openssh/squeeze/ ?
<Plouj> Or this repo: http://bzr.debian.org/pkg-ssh/openssh/trunk
<mark06> http://i.imgur.com/UHntlRD.png
<mark06> http://bazaar.launchpad.net/~renatosilva/+junk/scripts/revision/148
<mark06> http://bazaar.launchpad.net/~renatosilva/+junk/scripts/revision/149
<lifeless> cool
<mark06> thanks!
#bzr 2013-11-02
<Wiz_KeeD> hey fellas
<Wiz_KeeD> I want to determine if the repo where I pulled my branch from is a older revision of the one I have currently how do I do it?
<Wiz_KeeD> I
<Wiz_KeeD> I'm doing a deployment script and want to push only if neccesairy?
#bzr 2013-11-03
<DarkLinkXXXX> So, I recently submitted this bug report... https://bugs.launchpad.net/bzr/+bug/1247536
<DarkLinkXXXX> But then I found this comment on a similar bug... https://bugs.launchpad.net/ubuntu/+source/bzr-stats/+bug/1040560/comments/1
<DarkLinkXXXX> Apparently get_ancestry was deprecated a while ago. Does this mean the bug was in the plugin I was using rather then bzr?
<ubot5> Ubuntu bug 1247536 in Bazaar "bzr crashes when running fast-import plugin. `AttributeError: 'CHKInventoryRepository' object has no attribute 'get_ancestry'`" [Undecided,New]
<ubot5> Ubuntu bug 1040560 in bzr-stats (Ubuntu) "AttributeError: 'CHKInventoryRepository' object has no attribute 'get_ancestry'" [High,Fix released]
<spiv> DarkLinkXXXX: yes, probably.
#bzr 2014-10-28
<lifeless> vila: so hi
<lifeless> vila: dunno if you saw my post on g+ - will be in paris next week
<vila> lifeless: oh hey !
<vila> lifeless: I hope you'll enjoy your stay, too bad I won't be there ;-)
<lifeless> vila: ah well
<vila> lifeless: ODS right ?
<vila> lifeless: but if you feel to come to Strasbourg, you'll be warmly welcome ! Room available even ;)
<lifeless> vila: sadly non-modifiable tickets - you know the drill :(
<lifeless> otherwise I'd love to
<vila> lifeless: yeah, too bad I didn't went there but we'll meet again no doubt ;)
<lifeless> +1
#bzr 2015-10-28
<niluje> hey, any help would be appreciated.. how is merge working with bzr?
<niluje> my coworker, ed, has a branch. He wants to merge my work on it. bzr merge <my branch> doesn't merge the commits but only the changes
<niluje> is it possible to merge the commits and their messages?
<niluje> or does he have to merge & commit for each of my commit?
<fullermd> merge _does_ merge the commits.
<niluje> fullermd: http://pastie.org/10513117
<fullermd> Thus the pending merge tip  :)
<jelmer> niluje: "bzr merge" just stages the merge; you need to run "bzr commit" to commit it.
<niluje> oh
<niluje> yeah
<niluje> but if I run "bzr commit -m 'whatever'"
<jelmer> niluje: "bzr merge" just stages the merge; you need to run "bzr commit" to commit it.
<niluje> there only one commit with "whatever" as message
<fullermd> Merged revs are hidden away by default.  Use -n0 to expand them out.
<niluje> on which command should I use -n0?
<fullermd> log
<niluje> oh, indeed
<niluje> is there a great GUI tool on osx?
<niluje> thanks a lot :) as a git user, I'm a bit confused with bzr :p
<niluje> -n0 answers my questions
<fullermd> How well/deeply do you know git?
<niluje> well :p
<fullermd> 'k.  So in gittish terms, 'bzr log' by default only follows the first parents.  Revs with more parents do get marked [merge], but you need -n[something] to expand those branches.
<niluje> yep
<niluje> so there no equivalent to fast forward merges, right?
<fullermd> The operative theory is...   well, OK, the _proximate_ operative theory behind the change that made that happen, is that it's faster/not as painfully slow to do that.
<fullermd> But the _other_ operative theory is that generally, you don't care about the details of something merged.  Merges tend to be stuff like "merge trunk [into this feature branch I'm still working on, to keep caught up]", or "land feature X [into trunk]".  In either case, most of the time, just the fact of what happened is all you really care about.
<fullermd> It's only when you need to look at some detail along the way that you care about the individual revs inside it, so collapsing them away makes it easier to look at the history and find the bits you _do_ care about.
<fullermd> 'bzr pull' does fast forwards [only].
<fullermd> There's also a 'merge --pull' that does fast forwards if it can.
<fullermd> It's a bit confusing using it IMO, though, since that means that sometimes it'll FF and you don't have to commit anything, but sometimes it can't and so you do have to commit the merge.
<niluje> ok
<niluje> what about rebasing?
<niluje> if I'm on my feature branch and I want to rebase on the master branch, should I merge?
<fullermd> There's a 'rewrite' plugin that does [some subset of] that.  I'm not sure how well it works.
<fullermd> In bzr world, people generally just merge stuff.
<niluje> ok :)
<niluje> thanks a lot for the explainations fullermd
<niluje> what about a GUI on OSX? do you know a good one?
<fullermd> I don't think there's an integrated one.  I imagine the bits of qbzr work there, which gives GUI's for certain commands.
<fullermd> There is/what a bzr-gtk too, that was similar.
<niluje> let's stick with cli then :p
<fullermd> (is/was; at one point it fell into near-total disrepair, I don't recall if it was resurrected or not)
<niluje> kk, thanks!
 * fullermd pulls vila's plug a few more times, just for kicks.
<vila> fullermd: hehe, try again, I switched from desktop to laptop for an upgrade ;)
<fullermd> Upgrade?  You mean you switched out that "Lunix" thing for a _real_ OS?   ;>
<vila> hehe, real ? What's real and what's virtual... Do I still know...
<fullermd> Real is stuff you can eat.  Virtual is just little bytes.
<vila> ha right, I should stop that diet then ;)
#bzr 2015-10-29
<glen> i don't understand how to use break lock
<glen> help does not give any clues
<glen> http://sprunge.us/SRfi
<glen> wtf i'm supposed to add as argument?!
<glen> what is the definition of LOCATION?
<glen> fine. created bug https://bugs.launchpad.net/bzr/+bug/1511372
<ubot5> Launchpad bug 1511372 in Bazaar "break lock help is useless" [Undecided,New]
<Peng> glen: LOCATION is bzr+ssh://bazaar.launchpad.net/~glen666/eventum/po/ :-\
<Peng> > Using saved push location: bzr+ssh://bazaar.launchpad.net/~glen666/eventum/po/
<Peng> $ bzr help push | head
<Peng> Purpose: Update a mirror of this branch.
<Peng> Usage:   bzr push [LOCATION]
<Peng> In this case, you could also use `bzr break-lock :push` (see `bzr help location-aliases`).
<Peng> I'm assuming breaking the lock is actually a good idea in your situation, ~shrug~
<Peng> Which is a large assumption, but whatever.
<Peng> Is this a case of... what's that bash.org quote.
<Peng> http://bash.org/?152037
<Peng> (urgh, is there a version of that quote without any slurs?)
<glen> Peng: haha
#bzr 2017-11-02
<renatosilva> jelmer: hi, can you please fix the "either version 3 of the License" in http://bazaar.launchpad.net/~bzr-git/bzr-git/trunk/view/head:/revspec.py ?
<renatosilva> you seem to be the sole author so you could do it, that little statement is bringing gpl3+ infection to this otherwise gpl2+ project
