#bzr 2007-10-15
<lifeless> moin moin AfC
<AfC> lifeless: Gutten tag
<AfC> So I've had it bashed into me that revisions (in Bazaar speak) are not patches (in the Darcs sense of the word) but rather state markers, which explains somewhat why attempting to cherry pick "a revision" makes no sense in bzr
<igc> morning all
<lifeless> hi igc
<AfC> I am, however, still left with the ... desire ... to backport a series of patches which happen to be uniquely identified by the revision (in pseudo Bazaar speak revision-1..revision I guess)
<igc> hi lifeless
<lifeless> AfC: right, we have 'before:REVISION' as a way to grab the delta from the left most parent of a revision to the revision
<AfC> and wondering how to actually articulate this. Is `bzr merge --force -r $whatever` for a series going to work?
<AfC> before:
<AfC> huh
<lifeless> bzr help revisionspec
<luks> there is also -c in 0.92
<AfC> lifeless: I gotta tell you that that page isn't as helpful as you gentleman and ladies seem to think it is. It makes perfect sense as a reference once you already know what everything there does.
<lifeless> oh hmm, before: doesn't give you a delta, it just gives you the -1
<luks> which is just before:R..R
<lifeless> luks: only in some commands
<AfC> lifeless: although I suspect I feel that way because I still find myself fighting the definition of a revision versus the change that happens between that revision and its predecessor.
<AfC> Ah. So `bzr diff -r before:374..374` is what I need to type when I'm mentally thinking "bzr diff -r 374"
<AfC> Hm
<jelmer> AfC: or "bzr diff -c 374"
<jelmer> argh, I should read backlog
<jelmer> never mind me
<AfC> jelmer: :)
<AfC> that's ok
<AfC> I was actually about to dig to find out what -c was short for
<lifeless> bbiab, train.
<igc> lifeless, poolie, spiv: my plan for today is reviews, reviews, reviews
<igc> any preferences on order?
<igc> reviewing the Repository.is_write_locked patch now
<lifeless> back
<lifeless> no mail or browser for now;
<poolie> hello
<jml> hello poolie
<i386> lifeless: http://wiki.mozilla.org/JavaScript:ActionMonkey
<ubotu> New bug: #152811 in bzr "typeerror in globbing.match" [Medium,New]  https://launchpad.net/bugs/152811
<lifeless> i386: your project?
<i386> no
<i386> useful for mine
<lifeless> ah
<i386> its basically a JIT engine for JS
<lifeless> cool
<poolie> hello jml,
<poolie> i386
<i386> due out for FF 4
<i386> hey poolie
<lifeless> spiv: yo
<spiv> lifeless: yoyo
<lifeless> reconcile performance; are you across that or want to talk?
<spiv> lifeless: I seem to have it running tolerably quickly, at the expense of memory.
<spiv> lifeless: (15 minutes, 700MB for bzr.dev @ revno 2000)
<lifeless> 700MB wow
<lifeless> thats immense
<spiv> Yeah.
<lifeless> where is it all going
<spiv> That's a good question.  I haven't dug; I'm not sure how much of that is the explicit caching I do of get_text_version/get_inventory/get_parents/get_heads, and how much is lost elsewhere (the transaction?).
* spiv hmms
<spiv> I can probably improve the memory consumption by clearing the get_text_version cache after checking a file-id.
<spiv> lifeless: most of the memory appears to be due to holding all the inventories in memory.
<lifeless> the actual inventories, or the summary you create ?
<lifeless> the former is huge, the latter should be significantly smaller
<spiv> Hmm, I was just dumbly holding onto the actual inventory.
* spiv fixes that
<spiv> Reading in ~14000 inventories takes a while.
<spiv> Memory use seems a lot more reasonable on this run, though.
<spiv> (Also, strace shows lots of calls to open the inventory.knit file, and to our good friend futex...)
<lifeless> you should use the iter_inventories or even iter_inventories_delta calls
<spiv> lifeless: I can't seem to find those
<spiv> lifeless: memory use now down to about ~110MB.
<lifeless> yay tuning
<spiv> Hmm, it's creeping up a little, but I doubt it'll exceed ~130MB.
<spiv> I think that's good enough for now.
<lifeless> iter_revision_*
<spiv> iter_rev_trees?
<lifeless> probably
<lifeless> will open the inventory knit less often
<lifeless> and be massively faster
<AfC> poolie: ping
<spiv> It's down to 6m37s already with the memory consumption reduced.
<spiv> I'll try out iter_rev_trees now.
<poolie_> spiv: hi
<poolie_> afc, hi
<AfC> poolie: regarding 139478, I think we hit it last weekend when trying to do bzr push (!) ... the remote repo would suddenly stack trace and then we had to remote break-lock
<poolie_> bug 139478
<ubotu> Launchpad bug 139478 in bzr "UnlockableTransport running update in checkout of readonly branch" [High,Triaged]  https://launchpad.net/bugs/139478
<poolie_> so, not with that awn branch?
<spiv> lifeless: repo.revision_trees actually :)
<AfC> poolie_: no, it was 0.91
<poolie_> i mean, i presume you were using bzr on your own branch, which is unrelated to the awn window manager?
<AfC> poolie: (correct)
<AfC> poolie: I got him to c&p the stack trace; I'll see if I can get him to post it somewhere.
<AfC> poolie: anyway, just FYI
<ubotu> New bug: #152826 in bzr "order-dependent test failure in test_add_reports" [Low,Confirmed]  https://launchpad.net/bugs/152826
<lifeless> igc: new version up
* spiv goes to the optometrist
<spiv> (and lunch)
<poolie> thanks afc, it's useful to know it's not just that branch
<spiv> lifeless: saved another 40s.  5m 37s/120M to reconcile ~14000 revisions now.  I think that's good enough; I'll mail the list.  Thanks for your help.
<lifeless> np
* #bzr  [freenode-info]  if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
<lifeless> uhm seriously
<igc> yes ...
<lifeless> I can't see your review yet
<lifeless> oh nope, there it comes
* Starting logfile irclogs/bzr.log
<lifeless> igc: one thing comes to mind, but I don't know if the code is clean enough yet to tackle
<lifeless> igc: which is, when code working with a pack repo encounters NoSuchFile
<lifeless> it should:
<lifeless>   - refresh the pack-names list
<lifeless>  - check if the file it couldn't access is one that belongs to a pack dropped from the list since it last read it
<lifeless>  - if not, raise
<lifeless>  - otherwise, add new packs, and drop the dropped packs as needed
<lifeless> this should be bounded at the pack repository layer
<lifeless> e.g. implemented by try: blocks in knit.PackAccess, knit.KnitGraphIndex, pack_repo.create_pack_from_pack
<lifeless> this is the sort of error we'll see if that is not done:
<lifeless> Using saved location: sftp://rookery/~/public_html/baz2.0/integration
<lifeless> bzr: ERROR: No such file: u'/home/robertc/source/baz/.bzr/repository/packs/7790115835933f890290c0367db37b93.pack': [Errno 2]  No such file or directory: u'/home/robertc/source/baz/.bzr/repository/packs/7790115835933f890290c0367db37b93.pack'
<lifeless> igc: call me on my moobile in 3 minutes?
<lifeless> ~.
<poolie> igc: ping?
<igc> hi poolie
<lifeless> poolie: any luck debugging ?
<poolie> lifeless: no breakthrough yet
<igc> poolie: you after me earlier?
<lifeless> does my bzr work on your data?
<mwhudson> wow, the packs branch has some crazy revnos :)
<poolie> no, it doesn't
<mwhudson> "changes from 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.14"
<lifeless> mwhudson: weeeee long lived branches
<lifeless> mwhudson: is it faster  ?
<poolie> i think we should truncate them when they get too long
<poolie> lifeless: i'm trying to determine if there's actually a problem on disk
<lifeless> poolie: I would do the following
<lifeless> with my bzr branch
<mwhudson> lifeless: not sure yet
<poolie> or just in loading it in
<lifeless> grab both repos
<poolie> i think the problem has occurred in moving data from your pack branch into my knit repo
<lifeless> then grab the same knit object from both
<poolie> because in my other repo, the problem is not evident
<lifeless> set intersection to get the versions in common
<lifeless> then compare the raw_data blocks
<lifeless> theres an api to give you the raw gzipped
<lifeless> data
<lifeless> one expects them to be the same, except if you've run andrew's reconcile
<lifeless> aarons/andrews
<lifeless> I'm calling it a day; you should head to that bbq :)
<poolie> have a good night
<mwhudson> lifeless: first impressions of loggerhead w/packs performance are pretty good
<mwhudson> seems a bit faster than knits
<lifeless> sweet
<mwhudson> will measure and post numbers to the list later
<igc> bbl
<lifeless> mwhudson: thanks!
<lifeless> night all
<spiv> Looks like reconciling bzr.dev takes exactly 300MB of memory.
<poolie> hm, that's not so great
<poolie> for larger trees
<spiv> Yeah.  I suspect it can be better.  I'm hoping this is Good Enough for now.
<mwhudson> hm, producing the annotate view of builtins.py with packs takes over two minutes
<poolie> not so good
<poolie> how about from the command line?
<mwhudson> seems about the same
<mwhudson> oh no, about a minute
<mwhudson> still not exactly snappy :)
<yogesh> hello, I have installed bzr through eclipse update manager. I am using eclipse3.1. After finishing successfully, when I go to preferences->team->bazar getting error,plug-in in " org.vcs.bazar.eclipse.ui"  was unable to instantiate class  org.vcs.bazar.eclipse.ui.bazarpreferences page
<mwhudson> spiv: you forgot something
<lifeless> mwhudson: expected fallout, for now
<sabdfl> why is annotate slower with packs? is it because we no longer cache the relevant data?
<spiv> mwhudson: oh?
<spiv> mwhudson: oh, gar.
<yogesh> hello, I have installed bzr through eclipse update manager. I am using eclipse3.1. After finishing successfully, when I go to preferences->team->bazar getting error,plug-in in " org.vcs.bazar.eclipse.ui"  was unable to instantiate class  org.vcs.bazar.eclipse.ui.bazarpreferences page
<Odd_Bloke> Verterok: ^ is related to you, I think?
<abentley> mwhudson: ping
<mwhudson> abentley: hi
<abentley> Did you get my mail?
<mwhudson> oh, about loggerhead/cart integration?
<mwhudson> yes
<jdub> lifeless: http://www.cs.lth.se/home/Calle_Lejdfors/pygpu/
<abentley> mwhudson: Any suggestions about the right approach?
<abentley> I assume you want loggerhead to remain independant of Cart.
<mwhudson> abentley: no particular feelings
<mwhudson> abentley: yes
<mwhudson> abentley: do you think you'll be making changes to loggerhead itself, or just plugging its views in somewhere?
<abentley> Well, I expect to make some changes.  How much will depend on Loggerhead's data model.
<sabdfl> where can i find the best pack branch for testing?
<abentley> sabdfl: http://people.ubuntu.com/%7Erobertc/pack-repository.knits/ is the latest in knit format
<sabdfl> thanks abentley
<mwhudson> abentley: bits of the code will probably make your eyes hurt :)
<abentley> Once you have that, there's a pack version that's more up-to-date.  But I forget where that is.
<mwhudson> ~robertc/baz2.0/repository i think
<abentley> But you prolly have to bootstrap with the knit version.
<mwhudson> on the same server
<Peng> http://people.ubuntu.com/%7Erobertc/baz2.0/repository/
<Peng> Err, right.
<abentley> mwhudson: Yeah, no worries.
<abentley> I think I'll start by just importing loggerhead, and see how far I get.
<mwhudson> abentley: let me know of any particular problems you find
<abentley> Okay, will do.
<mwhudson> abentley: so you're aware, i plan to redo the css and general look pretty soon
<mwhudson> and at some point redo the templates in genshi
<mwhudson> and maybe dump turbogears, though i'm not so sure about that
<mwhudson> cherrpy has it's annoying bits
<abentley> Okay.  I have mixed feelings about genshi.  I really don't like what they did with match rules
<abentley> But the error handling is lots nicer.
<mwhudson> and it appears to not have "being extremely slow" as a design goal :)
<abentley> Anyhow, I should get back to work, but thanks for the chat.
<mwhudson> abentley: no worries, sorry for not replying to the mail
<abentley> mwhudson: no worries.
<GaryvdM> Hi
<GaryvdM> I've been thinking about how to solve the can't update a remote tree problem
<GaryvdM> I put an idea together, and would like to get some opinions.
<GaryvdM> Very brief spec here:  http://bazaar-vcs.org/DraftSpecs/RestingTree
<sabdfl> jdub: that pygpu stuff looks awesome
<johndo> Is there a way to have bzr include cvs style headers in files?
<jdub> sabdfl: almost worth buying nvidia!
<johndo> is there a way to get bzr to support ident?
<sabdfl> abentley: once i've merged in the pack stuff from those two addresses, how do i upgrade or create a repo in pack format?
<abentley> sabdfl: Use --format=experimental with init/upgrade/init-repo
<sabdfl> thanks abentley
<Solarion> pardon my ignorance, but I have the following scenario I need to make work: I have a branch of an svn repo, and a body of code (and revision history) I wish to merge into it.  How do I go about doing so?
<Solarion> "body of code" is in bzr
<Solarion> nobody?
<Odd_Bloke> Solarion: You'll want to look at bzr-svn.
<Solarion> Odd_Bloke: the svn portion is more or less irrelevant.  bzr's support of svn is supoerb.  The problem is that I want to merge in a new sub-project into a larger project, complete with its revision history.
<Solarion> (the svn part is there for completeness, and as a wrinkle in case svn messes up. :)
<Odd_Bloke> Solarion: OK, I'm not entirely sure what you're asking and am not familiar enough with bzr-svn to know how to go about much.
<Odd_Bloke> If jelmer were about, he'd be the person to ask...
<Solarion> Odd_Bloke: The foremost matter would be how to merge two disparate codebases without losing revision history
<Lo-lan-do> Odd_Bloke: I think jelmer is hiding from me...
<Odd_Bloke> Solarion: TBH, I'm not sure if it's possible.  _However_, I don't want to make that statement because I'm not sure.
<Solarion> Odd_Bloke: that would make me sad.  :(
<Solarion> hey bratsche
<bratsche> Hi Solarion
<Solarion> merging two disparate branches would be a nice feature, FWIW
<ubotu> New bug: #152974 in bzr "merge should allow merging in a wholly new codebase" [Undecided,New]  https://launchpad.net/bugs/152974
<Solarion> yeah, that one's mine.  :)
<Solarion> So why am I getting errors from a failed operation?
<Solarion> it only seems to happen when I have -r0..-1, as recommended in the bug
* Starting logfile irclogs/bzr.log
<abdelrahman> hello
<abdelrahman> I have a question
<abdelrahman> can bazaar restrict access to the code by username and password?
<jam-laptop> abdelrahman: we generally do that using the system permissions
#bzr 2007-10-16
<jam-laptop> such as filesystem permissions
<jam-laptop> and or ssh login permissions
<jam-laptop> (but generally it is at the level of a 'branch' not at the level of individual files inside that branch)
<jam-laptop> also, someone can certainly edit things on their own machine
<jam-laptop> it is just when you go to copy it elsewhere
<abdelrahman> so, this works for the hosted version on bazaar-vcs.org?
<jam-laptop> I'm not sure what you mean by the "hosted version"
<abdelrahman> I don't know if I am understood correctly..can I host code on bazaar-vcs?
<abdelrahman> or it is just the project page ..
<jam-laptop> abdelrahman: you can host on Launchpad
<jam-laptop> or you can host on anything that gives you sftp/ftp/etc access
<jam-laptop> (such as SourceForge or other free sites)
<abdelrahman> I need something that would allow me to restrict access to the code for the time being
<abdelrahman> I know sourceforge doesn't
<jam-laptop> abdelrahman: so you don't want people to be able to read the code?
<abdelrahman> for the time being yes
<jam-laptop> All the free sites I know of (off hand) are for hosting public stuff
<jam-laptop> I know LP is working on having 'private' branches
<jam-laptop> but I don't think that is available yet
<jam-laptop> You may not need to host the project somewhere, though.
<jam-laptop> for example: https://answers.launchpad.net/bzr/+question/15152
<jam-laptop> You can have a local branch, and they have their own branch
<jam-laptop> and you can send changes back and forth over email
<jam-laptop> rather than needing to have the code uploaded to an http site
<abdelrahman> but in this case, both machines have to be up and running at the same time !
<jam-laptop> abdelrahman: no they don't
<jam-laptop> you send the patches over email
<jam-laptop> the idea is that each side just keeps a copy of what the other side has
<jam-laptop> so it knows what to send
<igc> morning all
<lifeless> sabdfl: yes, thats why annotate is slower
<lifeless> sabdfl: we'll be added a cache that is cheaper to maintain than that that was present in packs
<lifeless> sabdfl: and will make it toggleable
<lifeless> sabdfl: so big projects - turn the cache off
<lifeless> s/big/projects where commit speed matters more than anything else
<Peng> Don't projects where commit speed matters more than anything else use hg?
* Peng ducks.
<AfC> I did some cherry-picking backporting yesterday
<AfC> It wasn't necessary, but it was real world, and I wanted to try what, in effect, I am putting my contributors through.
<AfC> I must still be battling the "Bazaar's idea of revisions" != "changesets" thing, as I am having a hard time justifying to myself why the revisions I backported with `bzr merge -r 123` don't show up as a pending merge of revisions with perfectly good commit messages
<AfC> (sic)
<lifeless> AfC: they will, when we have enough breathing room on the performance side to come back to the 'doing the best possible job' stuff we actually pride ourselves on
<AfC> Does seem a bit of an inconsistency, though - you merge a branch and you (sic) shlurp in all its diffs and commit messages, but if I cherry pick a revision or three I get its diffs but not those revisions commit messages
<AfC> lifeless: ah
<AfC> lifeless: brilliant
<lifeless> Peng: no, thats the point of this performance sprint
<Peng> lifeless: I know. :)
<AfC> lifeless: (it's sometimes difficult to tell what is deliberate and what is not-done-yet)
<lifeless> jam-laptop: morning
<lifeless> AfC: I can understand that :(
<lifeless> jam-laptop: should we have a chat about things-to-do ?
<lifeless> sabdfl: where you using a copy of launchpad in pack format?, or just the packs code on a regular launchpad branch?
<lifeless> sabdfl: also, what revno of the packs branch ?
<lifeless> blah
* Peng wanders off.
<igc> I'm having a look at the executable flag bug right now
<lifeless> igc: did you look at packs last night ?
<igc> lifeless: I run into problems grabbing the latest pack code
<igc> I'm got the latest pack.knits though ...
<igc> and I'm looking at it now ...
<igc> well after I look into this issue wrt executable fliags
<lifeless> oh, what sort of problem ?
<igc> I'm got I feeling I know when that is
<igc> the problem pulling the packs code I sent to the ML
<igc> looks like poolie is having it as well
<igc> lifeless: it's buried in my email re bzr.dev problems btw
<lifeless> I'm guessing its a bug in your reannotate code
<igc> lifeless: I'm thinking that the executable bit bug on Windows is actually due to changes made in 2862 ...
<igc> in particular, path_content_summary in workingtree.py
<igc> I'll dig a bit more
<lifeless> igc: well, I think the bzr.dev problem is more severe
<lifeless> and I strongly suspect you caused it :(
<igc> ok - I'll look into that instead
<lifeless> I've replied to the thread
<lifeless> basically, that revision was introduced in a pack repo
<lifeless> so the knit version of it went through your unannotated->annotated code path
<lifeless> and apparently code serialised incorrectly
<lifeless> ipso facto there is a bug
<igc> ok - your reply hasn't arrived yet
<lifeless> its <possible> that the bug is in packs, like something claiming to be annotated when its not, but I have no reason to believe that that is the case.
<lifeless> I'd expect many more problems if that *was* the case
<igc> I remember the annotated knit changes pretty well so I'll dig into it now
<lifeless> we're going to have to identify all possible corrupt revisions
<lifeless> and write some logic that can be run to purge them
<lifeless> or find and dump them
<igc> yup
<lifeless> bbiab, picking up tickets for uds
<poolie> igc, hi
<igc> poolie: I think I know what it is
<igc> just now literally
<poolie> can i call?
<igc> do you have a shared repo with one branch packs and others knits?
<igc> yes
<poolie> igc, you should try
<poolie> rsync -avPz people.ubuntu.com:~robertc/packs.knits .
<poolie> in some appropriate directory
<gdoubleu> anyone here have experience installing the trac-bzr plugin?  I am getting the following error: TracError: Unsupported version control system "bzr"
<gdoubleu> tracbzr is importable on the python prompt, In trac.ini I've set repository_type = bzr and I've set repository_dir
<gdoubleu> I've added a [component]  section and added tracbzr.* = enabled
<gdoubleu> restarted apache
<gdoubleu> I turned on DEBUG level logging, but see no output other than the traceback
<gdoubleu> This is with Trac 0.10.3.1 and TracBzr-0.2
<gdoubleu> I wasn't sure if the TracBzr-0.2-py2.4.egg needed to be copied into the trac environment's plugins directory, but I've tried it with and without
<poolie> gdoubleu, sorry, i don't
<poolie> abentley is (one of) the authors, he's sometimes around at this time of day
* igc food
<poolie> lunch for me too
<igc> back now - rsync finished too
<lifeless> back
<lifeless> poolie: its ~robertc/public_html/pack-repository.knits that you want
<lifeless> igc: ^
<igc> thanks llifeless
<igc> my pull of packs.knits is good - 2813 is the latest version there I have
<lifeless> public_html/baz2.0/dot_bzr_pack
<lifeless> public_html/baz2.0/dot_bzr_pack2
<lifeless> they are different editions of the repository, at points where I converted
<poolie> lifeless, about that hypothesis:
<poolie> when you changed the pack format from being annotated to not,
<poolie> did you change the format string or not?
<lifeless> no
<poolie> ok, thanks
<igc> poolie: I can branch from the main bzr.dev trunk into a fresh repo without problems
<igc> lifeless: yes - I think the damage is isolated to us
<igc> maybe not for identical reasons ...
<igc> or identical sequences of events but the net effect is ..
<igc> some unannotated things in an annotated repo
<poolie> heh
<poolie> would you believe, the first revision to have this problem is
<poolie> revno: 2786
<poolie> revision-id: robertc@robertcollins.net-20071002070507-wjjfev3by9eufdga
<poolie> parent: robertc@robertcollins.net-20070925220517-giar8zbt8r6fyjmi
<poolie> committer: Robert Collins <robertc@robertcollins.net>
<poolie> branch nick: repository
<poolie> timestamp: Tue 2007-10-02 17:05:07 +1000
<poolie> message:
<poolie>   Change the packs format to be unannotated.
<igc> that's a while ago
<poolie> lifeless, ping?
<lifeless> hi
<poolie> may i call?
<lifeless> sure
<lifeless> I just piked running the review meeting
<poolie> lifeless, do you expect to make any format changes other than the format string?
<lifeless> I think we have a good enough format to make it widely available
<lifeless> I think there are many changes to make, just not this week.
<poolie> because despite that outstanding item i'd like to use it myself for my new repo
<lifeless> well
<lifeless> if you're happy to manually change the string
<lifeless> gopher it
<poolie> i think i can just about manager that
<poolie> heh, freudian slip :)
<lifeless> rofl
<lifeless> spiv: grrr. I don't like this current relpath behaviour
<lifeless>     Path "/tmp/testbzr-gAkSjl.tmp/tmpAD2mCE/work/.bzr/repository/packs" is not a child of path "/tmp/testbzr-gAkSjl.tmp/tmpAD2mCE/work/.bzr/repository/upload"
<lifeless> thats from relpath
<lifeless> I would like to get '../packs' as the answer, not an exception :(
<poolie> lifeless, i've noticed in a couple of places, including packs
<poolie> that it would be easier if you could have a transport pointing at a file, rather than needing a (transport, relpath) pair
<poolie> this came up again with knits
<lifeless> hmm
<lifeless> I think theres room for something like that, but not a full transport IMO
<lifeless> its the old 'are directories files' question
<poolie> maybe not precisely a transport
<poolie> i'm just observing there seems to be an incipient object there
<lifeless> agreed
<lifeless> jml: don't forget to link the minutes into the meeting page
<ubotu> New bug: #153191 in bzr "command to get annotation for one line" [Wishlist,Confirmed]  https://launchpad.net/bugs/153191
<jml> lifeless: oops. other pages have an automatic thing.
<lifeless> hi jam-laptop
<lifeless> jam-laptop: is it you, or your laptop?
<poolie> typing break..
<lifeless> poolie: have you run spivs reconcile ?
<lifeless> poolie: you should do that before you move to pack format
<lifeless> later all
<vila> hmm, can't remember who I should ping for a request in loggerhead mrevell or mwhudson ?
<vila> anyway, we have decided to track the specs with bb instead of the wiki (roughly), when using launchpad blueprints, it's now a bit difficult to set the right specification URL
<vila> bialix gave a hint when using an URL right into a branch hosted on launchpad, but the urls are ugly and quite impossible to predict (they use revid and file-id), I'd like to use (revno, path)
<vila> where should I report that ?
<vila> mwhudson: are you the one I should ping about loggerhead or is it mrevell ?
<mwhudson> it's me
<vila> lol, just made a test, you read my mind :-)
<ubotu> New bug: #153201 in bzr "bzr v0.91 - ERROR: Unable to delete transform temporary directory ../.bzr/checkout/limbo." [Undecided,New]  https://launchpad.net/bugs/153201
<vila> anyway, we have decided to track the specs with bb instead of the wiki (roughly), when using launchpad blueprints, it's now a bit difficult to set the right specification URL
<vila> bialix gave a hint when using an URL right into a branch hosted on launchpad, but the urls are ugly and quite impossible to predict (they use revid and file-id), I'd like to use (revno, path)
<vila> I just realized http://codebrowse.launchpad.net/~jw+debian/bzr/bzr.0.90/revision?start_revno=2700 works already :)
<mwhudson> :)
<vila> that will solve my immediate problem may be better than (revno, path)
<vila> mwhudson: codebrowse.launchpad.net is public right ? Not restricted to launchpad beta testers ?
<mwhudson> vigneswari: https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/138021
<ubotu> Launchpad bug 138021 in launchpad-bazaar "loggerhead should generate links based on revision numbers and file paths" [Undecided,Confirmed] 
<mwhudson> vila, even, sorry
<mwhudson> vila: yes, totally public
<vila> great !
<vila> great !
<vila> I subscribed to the bug so I can monitor the changes, is it still considered ? No urgent need, just curious
<vila> mwhudson: ^
<mwhudson> yes, it's something i'd like to do
<mwhudson> not scheduled yet, as you can see
<vila> mwhudson: ok, good to know, I'm too busy to even dream scratching that one, but please receive my moral support :)
<mwhudson> vila: ok :)
<alla> So.. what's a good reason for picking bzr over hg?
* igc dinner
<poolie> alla, i think we do better merging in some cases, and we support storing branches on sftp or ftp servers, and i believe bzr has better windows support
<poolie> however, i haven't used hg recently
<mlh> via reddit: http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
<mrevell> abentley: ping
<mrevell> abentley: ping
<Lo-lan-do> jelmer: You around?
<jelmer> Lo-lan-do, hi
<Lo-lan-do> Hi
<abentley> mrevell: pong
<Lo-lan-do> Sorry to bother you again... did you have time to look at the bzr-svn pushing bug?
<mrevell> hi abentley - do you have a few minutes to help me come up with a good way to describe merge directives for the five minute guide?
<jelmer> Lo-lan-do, not yet - but I just got back to working on bzr-svn so there hopefully should be some news in the next day or so
<Lo-lan-do> That would be great :-)
<Lo-lan-do> (But I can bug you about bitlbee for a change, if you prefer :-)
<abentley> mrevell: A merge directive is a machine-readable request to perform a particular merge.  It usually contains a patch preview of the merge, and either contains the necessary revisions, or provides a branch where they can be found.
<mrevell> abentley: Thanks :-)
<mrevell> abentley: Do you think we should avoid mention of bundles in that section? Is it a distraction?
<abentley> I'm inclined to think that detail isn't important for a 5-minute tutorial, but do what you think makes sense.
<mrevell> Let's go with merge directives. I'll reply to your post on the list.
<weigon> can I merge changesets between two unrelated trees (at least diff | patch with keeping the commit msg) ?
<weigon> I have a bzr tree from svn2bzr and another one from bzr-svn and want to merge between them
<_jaalto> What is the last version that supported Python 2.3? I need one for the OS, which isn't upgradeable
<jelmer> _jaalto: Python2.4 has always been the earliest python version supported
<dato> revno: 982
<dato> committer: Martin Pool <mbp@sourcefrog.net>
<dato> timestamp: Wed 2005-07-27 10:11:28 -0300
<dato> message: - we need python2.4 now, so update the statup check for that
<dato> so practically as jelmer said
<jelmer> weigon: You should be able to do something like that using rebase
<weigon> now that you say it ... right.
<weigon> now I "diff | patch + commit"ed it by hand
<jelmer> weigon: sorry :-/ are you migrating between the two?
<_jaalto> jelmer: Not at all, I've installed bzr to Python 2.3, just don't remember the version. Does r982 refer to release 0.16?
<weigon> jelmer: first I svn2bzr'ed the tree locally and committed against it for testing and playing around
<jelmer> _jaalto: r982 started warning about needing 2.4, I bet it's been a while before that that 2.4-specific features were used
<jelmer> _jaalto: afaik it's more like 0.0.7
<weigon> now I wanted to 'rebase' the changes against the original svn-tree
<jelmer> _jaalto: r540 refers to it depending on set() from python2.4
<weigon> so, setting up a svn-bzr bridge with bzr-svn and applying the same patches against the svn-tree
<jelmer> weigon: ah - yes, rebase should be able to do that
<weigon> I will try it out as an exercise
<jelmer> _jaalto: 0.0.7 is r1175
<jelmer> weigon: you should probably use bzr-rebase 0.1, trunk is broken atm
<_jaalto> jelmer: ok
<jelmer> _jaalto: what OS are you trying to run it on?
<_jaalto> jelmer: SunOS/Solaris, It's production environment and Blastwave package for Python is only 2.3.5
<jelmer> :-/
<_jaalto> No fun at all
<Verterok> moin
<Verterok> maybe I jut felt asleep
<beuno> Verterok, :D
<bwinton> How is the trunk broken?
<bwinton> Is it something with annotated knits?
<bwinton> jam: you there?
<jam-laptop> bwinton: yes
<bwinton> Do you have a couple of minutes to talk about the outfile.write patch?
<jam-laptop> sure, I'm going over it more line by line now
<bwinton> So, it sounds like print has some hideously complex behaviour built in to that trailing comma...
<jam-laptop> yeah
<jam-laptop> if it ends in 'whitespace' it won't print a new whitespace
<jam-laptop> It isn't horribly complex, but it is a bit surprising
<bwinton> I'm surprised...  ;)
<CardinalFang> Python 3 should help with some of that.
<bwinton> Here's hoping.
<jam-laptop> Well, since they get rid of "print" as a command ... :)
<jam-laptop> I especially hate how it gets really messy if you are printing with arguments
<jam-laptop> something like
<bwinton> But there's no telling what they're going to add as a parameter...  "magical_trailing_space=True"  :)
<jam-laptop> print >>foo, "string one %s" % (something,),
<jam-laptop> I think the last comma is in the right spot
<jam-laptop> but what about
<bwinton> Heh.  I'm so glad that that one didn't appear in the lines I was changing.
<jam-laptop> print >>foo, "string one %s" % (something,), another_thing, another,
<jam-laptop> Which I think is legal
<jam-laptop> even if it is awful
<CardinalFang> Yeah, does "," bind after "%"?
* CardinalFang programs too much C.
<bwinton> So, along the same lines when I'm writing out the "i"s, does it matter if there's a trailing space there?
<bwinton> i.e.
<bwinton>             for i in mininc:
<bwinton>                 f.write(i + ' ')
<bwinton>             f.write('\n')
<jam-laptop> Well it does, but there won't be any spaces in the 'i'
<jam-laptop> Just because we know what 'mininc' contains
<bwinton> for some value of "we".  :)
<jam-laptop> I am a little concerned about when there is only 1
<jam-laptop> So it might be better to do:
<jam-laptop> f.write(' '.join(mininc))
<jam-laptop> or
<jam-laptop> f.write(' '.join(str(i) for i in mininc))
<CardinalFang> f.write(" ".join(mininc) + "\n")    ?
<CardinalFang> :)
<bwinton> But surely a test would catch that case, no?
<jam-laptop> maybe
<jam-laptop> I would guess if a test doesn't fail
<jam-laptop> then we don't actually care about the trailing space
<jam-laptop> but that doesn't mean it should be there :0
<CardinalFang> Stay out of my head, j-l.
<bwinton> FAIL: test_bundle.V4WeaveBundleTester.test_alt_timezone_bundle
<bwinton>      . <file file_id="newfile-20071016165753-jq7208edlvy372tb-174" name="newfile" parent_id="root-id" revision="tz-1" text_sha1="40a09aa320b3f12f99593ccd887eea724c34dd4b" text_size="20" />
<bwinton> is there a "bzr selftest -v --fail_on_first" type of option?
<jam-laptop> bwinton: --one
<jam-laptop>   -1, --one             Stop when one test fails.
<CardinalFang> Those srite() syscalls are way more expensive than creating a new string, I bet.
<bwinton> Cool.
<jam-laptop> CardinalFang: yeah, but then again, I don't care much about optimizing the old weave.py code
<bwinton> bzr: ERROR: Unable to import paramiko (required for sftp support): No module named paramiko
<bwinton> :P
<bwinton> Okay, that looks better...
<bwinton> (I've merged both of your suggested changes.)
<jam-laptop> bwinton: I have a couple more I'll send you in a second
<jam-laptop> Most notably
<jam-laptop> you don't need a trailing '\' to continue onto the next line
<jam-laptop> when you are inside ()
<jam-laptop> And 'stream.write(\' looks funny
<bwinton> Yeah, I thought about that, but the original code had it...  It was a tough call.
<bwinton> I'm happy to change it, though.
<jam-laptop> It had it because
<jam-laptop> print 'foo' \
<bwinton> D'oh!
<jam-laptop> cannot wrap a line
<bwinton> It's true, but the next line started with a (, which could have been moved to the previous line...
<bwinton> What's the line length limit?
<bwinton> (Those lines are 82 characters, and I'ld like to know if I can just join them up...)
<jam-laptop> it is technically 79 characters
<jam-laptop> we can be lenient here and there
<jam-laptop> but we do try to stay <= 79
<bwinton> Anything else while I'm here?
<bwinton> (Yes, I'm trying to reply to your tweak vote before you send it.  ;) )
<jam-laptop> bwinton: that is all I saw
<jam-laptop> well, everything I saw is in the tweak :)
<bwinton> Cool.  I'll throw those in and resubmit.
<bwinton> Is revision.revno a string or an int?
<bwinton> And the same for revision.rev.revision_id?
<jam-laptop> .revno is an integer
<jam-laptop> .revision_id is a string
<jam-laptop> .revision_id should be a utf-8 encoded string (for what it is worth)
<bwinton> Can I just use %s for both of them?
<jam-laptop> though all current examples are restricted to ASCII
<jam-laptop> bwinton: '%s' is python's universal "do whatever it takes to makethis a string"
<jam-laptop> so yes, you can always use '%s'
<jam-laptop> (%d exists so you can do %4.4d type formatting)
<bwinton> Okay, so I think I have one last question before this passes all the tests...
<bwinton> Line 1070(-ish) of the patch looks like this:
<bwinton>              elif l[-1]  == '\n':
<bwinton>                  assert l.find('\n', 0, -1) == -1
<bwinton> -                print >>f, '.', l,
<bwinton> +                f.write('. ' + l + ' ')
<bwinton> But that's probably not correct, given the behaviour of the trailing comma...
<bwinton> I think I could just remove the trailing space, since we know that l ends with '\n', because of the first line I quoted.
<bwinton> Does that sound near-correct to you?
<jam-laptop> Remove the trailing space seems correct to me.
<jam-laptop> I would be happier with
<jam-laptop> assert l.count('\n') == 1
<jam-laptop> But that is a different change
<bwinton> Yeah.
<bwinton> Well, that wasn't quite it.  The next error I'm getting is:
<bwinton> ERROR: test_bundle.V4WeaveBundleTester.test_binary_bundle
<bwinton>     sequence item 0: expected string, int found
<jam-laptop> that sounds like
<jam-laptop> write(''.join(mininc))
<jam-laptop> you probably need the
<jam-laptop> write(''.join(str(i) for i in mininc))
<jam-laptop> Which can also be written as
<jam-laptop> write(''.join([str(i) for i in mininc] ))
<bwinton> I like the generator expression better, assuming it's in the versions of python we support...
<bwinton> (Uh, which versions of Python does Bazaar support?)
<jam-laptop> >= 2.4
<jam-laptop> Because we already use generators elsewhere
<jam-laptop> And we use "@" syntax
<jam-laptop> (decorators)
<bwinton> Yeah?  I haven't noticed any of those...  What do we use them for?
<jam-laptop> @needs_write_lock
<jam-laptop> and
<jam-laptop> @needs_read_lock
<jam-laptop> is all over Branch.py
<jam-laptop> @staticmethod
<jam-laptop> @classmethod
<jam-laptop> are also rather common
* Starting logfile irclogs/bzr.log
<Verterok> beuno: there are only three unitttests left: log, annotate and info. I plan to finish by thrusday/friday
<Verterok> beuno: s/unittests/testcases/g
<beuno> Verterok, great, those might come in handy when we try and get the code into bzr itself
* beuno eyeballs the bzr devs
* jam-laptop hides behind food
<Verterok> beuno: yes, hope they'll
* Verterok join beuno's 
* beuno waits patiently for jam-laptop's food to run out
<Lo-lan-do> jam-laptop is made of food.  And electronics.
<jam-laptop> actually 'jam' is made of food, 'laptop' is made of electronics
<beuno> heh
<Lo-lan-do> Yes, that was more or less what I was hinting at.
<Lo-lan-do> I guess I shouldn't try to be witty when I'm sleepy.
<Odd_Bloke> You get a jam-laptop if you spread jam on your laptop keyboard and close the lid. .
<jam-laptop> not quite as good as a PB&J, but it has a bit of crunch to it
* Starting logfile irclogs/bzr.log
<gotgenes> What is the recommended tool for migrating repositories from SVN to bzr?
<jam-laptop> I think the #1 converter is bzr-sv
<jam-laptop> bzr-svn
<gotgenes> I see there's Tailor, svn2bzr, and bzr-svn
<jam-laptop> followed closely by svn2bzr
<jam-laptop> Tailor is a far distant third or fourth or fifth even
<jam-laptop> gotgenes: If it is an open source project, you can also use Launchpad to do the conversion
<jam-laptop> with the advantage that they will keep it up to date
<jam-laptop> but I have the feeling it is your own personal stuff
<gotgenes> jam-laptop: it is a couple of personal repositories, only a few of which are software
<jam-laptop> I believe bzr-svn receives the most attention
<jam-laptop> but it doesn't let you do some things that svn2bzr does
<jam-laptop> (it is focused more on providing a way to inter-operate with svn, than to just convert)
<jam-laptop> so svn2bzr will let you filter out stuff you don't want any more, etc.
<gotgenes> Well I want all of the repositories, that's for sure
<gotgenes> what does "ids: non-deterministic" mean?
<jelmer> I think svn2bzr does deterministic ids these days
<gotgenes> jelmer: are these revision IDs? or file IDs?
<jelmer> both
<gotgenes> and does it really matter if it's deterministic?
<jam-laptop> If you want 2 people to convert and get the same results, yes
<jam-laptop> If it is just you planning on switching from using svn
<jam-laptop> to using bzr
<jam-laptop> then no
<jam-laptop> If you were planning on continuing to use bzr
<jam-laptop> and svn at the same time
<jam-laptop> then yes
<jelmer> jam-laptop: afaik the only difference between svn2bzr and svn-import at this point is the fact that svn2bzr doesn't depend on python-subversion
<jam-laptop> For *you* I'm guessing the answer is no
<jelmer> svn-import also does filtering these days
<jam-laptop> jelmer: how do you reconcile filtering with determinism?
<jelmer> jam-laptop: you can filter which branches to convert
<jam-laptop> Sure, but not what revisions in those branches
<jam-laptop> like you can't filter out the accidental commit of a CD ISO
<jelmer> jam-laptop: svn2bzr doesn't allow more filtering than that, either
<jam-laptop> I thought svn2bzr worked on svndump
<jelmer> afaik
<gotgenes> These are my personal repos so it sounds like deterministic IDs should matter
<jam-laptop> and you could edit that as you wanted
<jelmer> sure, but you can do that with bzr-svn as well
<jam-laptop> gotgenes: jam-laptop: For *you* I'm guessing the answer is no
<jam-laptop> I didn't realize bzr-svn worked from an svndump
<jam-laptop> and it makes me a little concerned with the extra deterministic ids...
<jelmer> jelmer: it can, but will simply load the svndump and then work on the resulting repository
<jelmer> jam-laptop: svn2bzr also does deterministic ids
<jam-laptop> any time you can change the source and get the same id makes me a bit concerned
<jam-laptop> but hey
<jelmer> so I don't see how bzr-svn's situation is worse..
<jam-laptop> It most likely won't be *my* repository which gets  corrupted accidentally
<gotgenes> I would prefer an uncorrupted repo, as well
<jelmer> jam-laptop: there's not really a way to work around people modifying their svndumps or svn repositories without changing the repository UUID
<jelmer> jam-laptop: unless I would use a sha1 of the entire tree contents + revision metadata as revision id
<jelmer> jam-laptop: heck, even Subversion clients break if you change the contents of the server by dumping it out and loading it in again
<jam-laptop> sure
<jam-laptop> but SVN has only 1 place that breaks
<jam-laptop> if I merge a patch from you
<jam-laptop> after you have a different conversion
<jam-laptop> it can break my repository
<jam-laptop> anyway, hopefully people don't mess with things too badly
<jam-laptop> it is pretty rare to have random people doing the conversion
<jam-laptop> versus everyone working from an 'official' one.
<jelmer> jam-laptop: I think that's why bzr should check the sha1 of the remote repository
<jelmer> (against the local stored sha1)
<jelmer> in the case of a merge, just the base revision sha1 should be sufficient I think
<jelmer> even in the non-bzr-svn case, that would be useful
<jelmer> for example, if I clone some-evil-users' branch into my local repository
<jelmer> but he had an evil copy of a revision that was already in bzr.dev, but which I hadn't pulled from there yet
<jelmer> and I then pull from bzr.dev
<jelmer> I end up with a corrupt revision, but without any errors
<james_w> jelmer: hi. Is it true that bzr-svn never has to handle an svn revision with mulitple parents.
<james_w> I am looking at InterFromSvnRespository.
<jelmer> james_w: it does have to handle those, but there is at most one non-ghost parent
<james_w> jelmer: thanks.
<james_w> I am looking at implementing InterFromGitRepository, and so it needs the multiple parent case.
<jelmer> james_w: is this in bzr-git?
<james_w> I'm stuck on what to tell the target repository to do to transfer the revisions.
<james_w> jelmer: yes.
<jelmer> cool
* jelmer is also interested in bzr-git
<james_w> that's one reason why I'm looking at it, with your experience it should be easier to do.
<james_w> The InterRepos in bzr core are mostly specialised. I am looking at the Generic one now to see what I should od.
<james_w> jam-laptop: do you have a moment for a few pointers on interrepo operations?
<gotgenes> Where is the documentation for bzr-svn?
<siretart> hi james_w
<jam-laptop> in a bit
<jam-laptop> james_w: how can I help
<james_w> jam-laptop: sorry, I was eating.
<jam-laptop> bah, no eating for anyone but me
<jam-laptop> :)
<james_w> Having looked a bit more it seems like calling Repository.add_revision() for each revision in the ancestory that we care about, with the inv kw parameter set to the inventory for that revision is sufficient, am I correct?
<Odd_Bloke> If jam-laptop eats, he'll just become 'jam'...
<james_w> hi siretart. How are you?
<jam-laptop> james_w: This is after you've copied over the file texts?
<jam-laptop> But yes, that should work
<jam-laptop> though I think it *might* be better to call add_inventory() first
<james_w> ah, file texts. Whats the API to copy them?
<jam-laptop> I've done it a couple different ways,
<jam-laptop> I'm not sure that we have a great way to do it
<jam-laptop> but doing
<james_w> and, yes it appears as though add_inventory would be more efficient, as there is a check for whether the inv is present the other way.
<jam-laptop> weave = repo.get_weave_or_empty(file_id)
<jam-laptop> weave.add_lines(...)
<jam-laptop> bzr-hg might have a decent way to explain it
<jam-laptop> in the InterRepoX.fetch() function
<jam-laptop> at least, that is what I've copied for some things that I've done.
<james_w> ah, I hadn't even thought about file_ids yet.
<jam-laptop> Part of it is finding the 'parent revisions' so that you get the file graph correct
<jam-laptop> james_w: bzr-hg just uses "hg:path/to/file"
<jam-laptop> for the file id
<jam-laptop> since that *is* the hg file id
<jam-laptop> though it won't follow renames, etc
<jam-laptop> but prior to 0.9.2 or so, neither did hg
<jam-laptop> you *might* want to use something like
<jam-laptop> git:<hash of path>
<jam-laptop> (the problem with raw path is that it gets really long on some projects)
<jam-laptop> I've run into file-ids that were longer than the 256 character limit per filename on Linux
<jam-laptop> (you can have a really long total path, but each chunk needs to be shorter than ???)
<james_w> thanks for the tip.
<jam-laptop> so does git provide a way to do a reverse mapping?
<jam-laptop> (to make it easy to push bzr revisions into git)
<jam-laptop> svn has properties (on just about everything)
<james_w> I'm not sure I follow.
<jam-laptop> You want a way such that bzr-git can detect that this git revision matches that bzr revision
<jam-laptop> so that you can push, and have pull be a no-op
<james_w> ah yes, I see.
<jam-laptop> (see jelmer's "True Push" bzr-svn support)
<jam-laptop> One thing you could consider...
<jam-laptop> having a versioned file that records the mapping
<james_w> There is talk of 'notes' which are annotations to revisions, but it is not merged yet.
<james_w> (annotations is an overloaded word, hence the choice of 'notes').
<james_w> if that is not merged or not applicable then I will try the versioned file.
<james_w> The other possibility is attributes, but I don't think they fit well.
<siretart> james_w: thanks! - looking forward to UDS :)
<james_w> siretart: me too.
<james_w> siretart: I have submitted https://blueprints.launchpad.net/ubuntu/+spec/bzr-for-packaging-tutorial
<siretart> james_w: interesting. Subscribing myself as essential :)
<james_w> siretart: thanks. Would you be willing to help with it?
<siretart> james_w: of course! - I think we should take some time to discuss details in person at UDS
<siretart> james_w: I assume you have noticed the recent discussion on the dpkg devel list?
<GaryvdM> Is  John Meinel arround?
<GaryvdM> I don't know what nick he uses.
<radix> jam-laptop
<GaryvdM> Ah!
<jam-laptop> hi GaryvdM
<GaryvdM> Hi
<GaryvdM> I tested you patch for bug 149113
<ubotu> Launchpad bug 149113 in bzr ""KeyError: None" in Dirstate._entry_to_line when commiting" [Critical,Confirmed]  https://launchpad.net/bugs/149113
<jam-laptop> thanks, any luck?
<GaryvdM> I get ERROR: exceptions.TypeError: 'tuple' object does not support item assignment
<GaryvdM> line 335 of bzrlib\repository.py
<GaryvdM> content_summary[2]  = False
<jam-laptop> foey
<jam-laptop> I'll fix that, then
<jam-laptop> I'm working on a test case anyway, I'll post it when I get it
<GaryvdM> Thanks
<james_w> siretart: no I haven't, let me look.
<siretart> james_w: JoeyH has proposed a patch for managing source packages in dpkg
<siretart> james_w: Kamion has then ported his patch for bzr
<james_w> siretart: thanks for the pointer, it's interesting. I don't really get it yet, but if Joey wrote it, then I would say that it is probably useful.
<james_w> siretart: and I'm very keen to discuss things at UDS, I don't have any other activities to do there yet, so I'm going to try and get as many people interested as possible.
<siretart> I'll help you with that as good as I can! :)
<james_w> great :). Have you seen we already have a slot in te provisional timetable?
<siretart> james_w: that's not decided yet. the schedule will be updated daily, even after conference start
<siretart> so don't pay too much attention at the current schedule
* siretart heads to sleep. good night!
<james_w> oh yes, I realise that, it was just the first time that I had seen there was already a slot assigned to discuss these issues.
<james_w> night siretart.
<james_w> jam-laptop: thanks for your help.
<jam-laptop> james_w: happy to help
<james_w> I'll think about file-ids, and leave true-push until later I think.
<lifeless> jam-laptop: hi
<jam-laptop> hi
<jam-laptop> james_w: certainly, walk before you can run
<jam-laptop> just keep it in mind
<lifeless> re exec bit on win32
<jam-laptop> since it may be easier to do it up front
<jam-laptop> rather than after the fact
<lifeless> changing commit builder is the wrong place; it will not be duplicated in other repo commit builders
<jam-laptop> lifeless: actually I have a test which requires them to
<lifeless> commit builder is repo specific serialisation, not tree specific, and this bug is tree specific
<jam-laptop> but I still feel it is wrong
<jam-laptop> but you had a specific comment saying that None was the right thing to return
<james_w> jam-laptop: yes, I agree. Thanks for putting it in my head.
<lifeless> I wanted to avoid having to do a lookup in path_content_summary
<lifeless> certainly the fix should only execute any code on win32
<lifeless> e.g. be a variation of a method chosen at load time
<lifeless> or be a decorator put on on win32
<lifeless> I'd be ok with a decorator around the commit builder
<lifeless> and I'd be ok with a path_content_summary_win32 that does a lookup, with
<lifeless> path_content_summary = _path_content_summary_win32
<lifeless> at the class level, on win32
<jam-laptop> so, I'm a little confused....
<jam-laptop> It seems like we are using the WT.path_content_summary for WT4 trees
<jam-laptop> since the WT4 version
<jam-laptop> returns entry.executable
<jam-laptop> which *should* be correct
<jam-laptop> Or are the tests only failing for WT3 trees
<lifeless> I know bialix often uses wt3 trees
<lifeless> because of locking problems in ?win98?
<jam-laptop> yeah, and I guess he had ~1000 failures
<jam-laptop> lifeless: and some issues with locking failures on WinNT+
<jam-laptop> I know 'merge' used to have a problem with double locking the tree
<jam-laptop> I think Aaron fixed that, though
<lifeless> so today
<lifeless> I'm going to finish the pack object cleanup
<lifeless> and send in a branch for review
<lifeless> change the format string to a supported one
<lifeless> register the branch as visible etc
<lifeless> Mark had a performance glitch he's asked me to lookat
<lifeless> abentley: you pointed mark at packs the other day?
<lifeless> abentley: which branch of mine did you point him at ?
<abentley> http://people.ubuntu.com/%7Erobertc/pack-repository.knits/
<lifeless> k, thanks
<abentley> And then someone else pointed him at the pack version.
<lifeless> jam-laptop: you asked me about things to hack on; did you want to chat about that ?
<lifeless> jam-laptop: or was my answer sufficient
<GaryvdM> jam-laptop: I think you forgot to attach the patch in your latest mail.
<jam-laptop> GaryvdM: thanks for the heads up
<jam-laptop> lifeless: I would like to chat about it at some point
<jam-laptop> I'm just trying to finish this one up
<jam-laptop> as I see it as a fairly large regression
<lifeless> indeed it is
<lifeless> regression's R us
<GaryvdM> jam-laptop: Is http://bzr.arbash-meinel.com/branches/bzr/0.92-dev/dirstate_error_149113/ the same as the missing patch?
<jam-laptop> GaryvdM: yes
<jam-laptop> It should also be registered in LP
<lifeless> abentley: what should we do about better merges then; I agree you are right that three-way, full-tree base selection, with many-branches-in-play is dangerous when conflicting decisions are being made.
<jam-laptop> though that may not have updated yet
<jam-laptop> GaryvdM: I'm also thinking to fix it in a different way
<GaryvdM> Ok - I'll still give it a test.
<lifeless> abentley: (if we don't go back to a unique root)
<lifeless> jam-laptop: well, I'm around all day (har har), so am happy to chat at your convenience
<abentley> lifeless: Well, per-file LCAs does help, but not in every case.
<lifeless> I'm not going to really start work for another hour and a bit, at 9.
<abentley> So I'd focus on making annotate-merge better.
<lifeless> abentley: there is a question; its going to be slow on packs, but you had the idea we only needed to annotate the differing lines, and only back to the common ancestor
<abentley> Annotate merge is similar to picking a merge base for every line in the file, so it's like per-file merge bases taken to an extreme.
<lifeless> yup
<lifeless> so, I'll start using that always
<lifeless> and see if it plays nicer
<lifeless> bbiab
<abentley> I know it has some wacky corners, but we haven't really figured them out yet.
<abentley> i.e. what's causing them.
<abentley> I'm still confident that we only need to annotate back to a common base.
<GaryvdM> jam-laptop: That branch does work.
<jam-laptop> GaryvdM: good to hear
<jam-laptop> As robert and I agree, it is fixing it in the wrong place
<jam-laptop> but at least it works for now :)
<jam-laptop> I'm trying to fix it more correctly
<GaryvdM> Cool
<lifeless> remind me why we ever missed that knits would perform badly ?
<jam-laptop> hmm.. I take it back, it is a weird interaction with WT4
<jam-laptop> otherwise we wouldn't be getting the Dirstate failure
<jam-laptop> when it tries to set_state_from_inventory
<jam-laptop> and ie.executable is None
<jam-laptop> which is just weird....
<lifeless> its probably a badly formed inventory
<GaryvdM> I'm looking for some advice on how to implement something.
<lifeless> ie.executable = None is invalud for kind is 'file'
<GaryvdM> I want to create my own type of tree
<jam-laptop> lifeless: well, record_entry_contents is setting ie.executable
<lifeless> jam-laptop: to non-None?
<jam-laptop> which is why I was fixing it there
<jam-laptop> lifeless: well it was setting it to content_summary[2]  unilaterally
<lifeless> GIGO though
<lifeless> I think thats fine
<lifeless> GaryvdM: go on
<jam-laptop> sure, but I can't quite find the GI when it is WT4
#bzr 2007-10-17
<lifeless> moin
<vila> night ;)
<lifeless> hah, my string.find() bug is getting 'me toos' :)\
<lifeless> thanks for the email patch vila
<vila> lifeless: you're welcome
<jelmer> 'morning lifeless
<lifeless> hi jelmer
<vila> lifeless: when you say "This format was introduced in bzr.dev" you intend to update with the current bzr version when merging I hope ?
<vila> s/merging/landing/
<lifeless> yes
<mtaylor> I'm getting this: bzr: ERROR: exceptions.MemoryError
<mtaylor> when I try to do any bzr operations on a branch
<mtaylor> using bzr 0.91 on gutsy
<Odd_Bloke> mtaylor: That is normally a sign that there's a particularly large file in the branch.
<mtaylor> Odd_Bloke: yeah - I shouldn't have any of those
<mtaylor> Odd_Bloke: and it happens on bzr status, too
<Odd_Bloke> mtaylor: No ulimits of any description?
<mtaylor> Odd_Bloke: nope
<mtaylor> the whole tree is at 11M
<Odd_Bloke> mtaylor: Nothing else huge resident in memory?
<mtaylor> and I get the memory error almost immediately
<mtaylor> I have 786M free
<mtaylor> I can try kiling firefox and eclipse
<mtaylor> Odd_Bloke: now I have 1.6G free, and it still gives me the error
<mtaylor> I've tried 0.90 and 0.91
<mtaylor> both to no avail
<mathrick> hey
<mtaylor> Odd_Bloke: it's only in that one branch, too
<mathrick> is there a way to see exactly what's causing rejects when unshelving?
<Odd_Bloke> mtaylor: Has the branch ever had any large files committed but later removed?
<mtaylor> Odd_Bloke: no.
<Odd_Bloke> mtaylor: Does even 'bzr check' fail?
<mtaylor> Odd_Bloke: bzr check works
<mtaylor> Odd_Bloke: I'm able to branch from that branch and then operate in the new branch just fine
<mtaylor> Odd_Bloke: but I can't run bzr diff to see if there were any uncommited changes in the old branch I'd forgotten about
<Odd_Bloke> mtaylor: You could run a standard diff?
<mtaylor> Odd_Bloke: yes. that works - except for needing to filter out all of the autoconf crap
<mtaylor> :)
<Odd_Bloke> mtaylor: Also, can you tar up the branch, and extract it elsewhere retaining the issues?
<Odd_Bloke> mtaylor: Ah, yeah, that'd be a problem. :p
<mtaylor> Odd_Bloke: well, it's in a local repository
<mtaylor> Odd_Bloke: so I think if I tar up just the branch, it won't be complete, right?
<mtaylor> Odd_Bloke: but I could try creating another repository, branching from one to the other to get the revisions and then copying over the borked branch
<lifeless> wow
<lifeless> mwhudson: mmm, its possibly a bug in diff matching, e.g. pythons standard libary at one point recursed waaaay to much
<lifeless> mtaylor: ^
<lifeless> sorry mwhudson :)
<mtaylor> hm.
<lifeless> mtaylor: is there a backtrace in ~/.bzr.log ?
<mtaylor> lifeless: well, I get one on the screen
<mtaylor> is there a pastebin somewhere I can stick it?
<lifeless> sure
<lifeless> http://rafb.net/paste
<mtaylor> http://rafb.net/p/uUVwBB87.html
<lifeless> ok
<lifeless> this may be a C extension bug
<lifeless> MemoryError may be sigsegv
<lifeless> hmm, I'm not sure offhand of how to disable the C extensions in a packaged bzr
<lifeless> so -
<lifeless> _dirstate_helpers_c.so
<lifeless> find that file
<lifeless> (e.g. locate _...)
<lifeless> rename it out of the way (as root)
<lifeless> then try again
<lifeless> mtaylor: ^
<mtaylor> k
<mtaylor> lifeless: now I get an AssertionError
<mtaylor> http://rafb.net/p/3QbwaA82.html
<lifeless> mtaylor: looks like a damaged dirstate file
<lifeless> did you have a power failure or some such during commit, or si this on NFS?
<mtaylor> lifeless: nope. not on nfs. and I don't remember any power failures
<lifeless> anyhow, your current tree state has been damaged
<mtaylor> lifeless: I did recently try to use the bzr eclipse plugin... perhaps that screwed something up
<lifeless> it shouldn't be accessing this file directly
<mtaylor> lifeless: ok. well I'll just browse around and look for uncommited changes
<mtaylor> I don't think I had any
<lifeless> you could try:
<lifeless> bzr branch . ../clean
<lifeless> diff -Nrup -x .bzr . ../clean
<lifeless> [sorry that you're having to do this]
<mtaylor> hey - no problem!
<fullermd> You could tar up your working files, rm them and .bzr/checkout/, re-checkout the tree, blow away the files, and untar the old ones.
<lifeless> fullermd: simpler:
<lifeless> bzr branch . ../clean
<fullermd> (I dunno if remove-tree would work if the checkout metafiles were wonky)
<lifeless> cp ../clean/.bzr/checkout/dirstate .bzr/checkout/
<lifeless> mtaylor: ^
<lifeless> that will discard knowledge of renames
<lifeless> and of pending merges
<lifeless> but will be otherwise good
<mtaylor> lifeless:  turns out I don't have any ditry files... so the bzr branch . ../clean
<mtaylor> gives me a tree that's got everything
<mtaylor> *phew*
<mtaylor> now - if only I knew how the dirstate got screwed
<lifeless> abentley: the graph is the problem, I'm adding a HeadsCache to graph.py
<lifeless> abentley: we do 1M key lookups to commit a merge of bzr.dev.
<abentley> Do we really need to be doing that many?
<lifeless> one hopes not :)
<mtaylor> lifeless: thanks for the help!
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/153749
<ubotu> Launchpad bug 153749 in bzr "dirstate C helper MemoryError on bad dirstate file" [Undecided,New]
<lifeless> filed as a result of your problem
<mtaylor> sweet. glad to help ;)
<mtaylor> lifeless: would my working tree be helpful at all?
<lifeless> uhm
<mtaylor> I can tar it (and the repos it's in up) if it would be
<lifeless> it *might* help figure out the nature of the corruption
<lifeless> the only file we'd need is .bzr/checkout/dirstate
<abentley> Well, I'm really asking if it's the caller's fault or the callee's fault.
<lifeless> abentley: we do one heads() call per file being committed
<mtaylor> HAHA
<mtaylor> lifeless: you gotta love it when you get a launchpad oops while uploading an attachement to a bug :)
<ekimus> hi, just wanted to start playing around with baraar and ubuntu/feisty has this in the description "Unless you have a pressing reason to use bazaar you should use some other revision control system as upstream development has ceased." - is that remotely true or just a bad incident that it is an outdated version?
<Odd_Bloke> ekimus: You want 'bzr'.
<mtaylor> ekimus: ^^
<lifeless> mtaylor: we're having a postgresql glitch right now, admins are on it.
<lifeless> mtaylor: just try again please :)
<mtaylor> lifeless: it worked the second time
<lifeless> ekimus: thats a bug in the packaging - the 'bazaar' package is not bzr. 'bzr' is the package name.
<lifeless> mtaylor: cool
<ekimus> Odd_Bloke: thanks, looks a lot better :)
<ubotu> New bug: #153749 in bzr "dirstate C helper MemoryError on bad dirstate file" [Undecided,New] https://launchpad.net/bugs/153749
<lifeless> abentley: its taking 10+ seconds to answer heads(('robertc@robertcollins.net-20071017014801-c6u8dl03zk1gko3r', 'andrew.bennetts@canonical.com-20071012052646-wl95idld3ijjy714')
<lifeless> )
<lifeless> abentley: so I'm thinking its graph's fault.
<ekimus> hmm the bzr ignore is a per location setting/command right? (still scanning the docs and no hands on experience yet)
<fullermd> ekimus: It gets set in the branch you run it in, yes (it all goes in a '.bzrignore' file in the root of the branch)
<lifeless> ekimus: there is also a global ignore you can set
<lifeless> in ~/.bazaar/bazaar.conf|locations.conf
<lifeless> I should say 'local ignore'
<ekimus> yup i can set the ignores in a central place but the setting is local to each repo (somehow like this should be correct)
<lifeless> you can set ignores in three places:
<lifeless> bazaar.conf
<lifeless> affects all use of bzr on your machine
<lifeless> locations.conf
<lifeless> affects use of bzr by url matching
<lifeless> .bzrignore
<lifeless> affects that one branch
<lifeless> (and propogates via merge operations to other branches)
<fullermd> Don't you mean ~/.bazaar/ignore?
<lifeless> oh, perhaps I'm confused
 * fullermd didn't know you could set ignores in locations.conf...
<lifeless> *ignore me*
<fullermd> echo lifeless >> .bzrignore    8-}
<lifeless> ekimus: generally though, its just 'bzr ignore NEWS' and it DTRT
<ekimus> http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#ignore seems to be that a .bzignore file is used also (just thru the ignore command)
<fullermd> Right.  'bzr ignore' just adds lines to the .bzrignore file in the branch.
<ekimus> hmm something i'm missing is some more docs about the how to run a bzr:// server and what options there are for access control. then again, a) i just have to try it b) it's python and the hooks seem to be easy to do (if they are as simple as plugins - which i just found out that i read the docs for instead of hooks)
#bzr 2007-10-18
<fullermd> Well, I think with bzr:// your access-control options currently reside in your firewall...
<ekimus> and filesystem hopefully
<ekimus> time for bed today, time for bzr tomorrow :) - thanks for clarifications
<fullermd> Oh, I guess.  I'd assumed you wouldn't have anything under bzr://'s root except what you wanted to serve.
<lifeless> bzr has a soft chroot facility
<lifeless> you can limit it to a branch/repo easily
<lifeless> and auth is done via the protocol
<lifeless> e.g. ssh, or http provide authentication
<lifeless> raw bzr:// does not currently have authentication, so its only suitable for anonymous access
<lifeless> abentley: ping
<abentley> ping
<lifeless> looking at this graph thing
<lifeless> I'd like to change heads() to use a single parents() call each iteration
<lifeless> rather than having a set of searchers
<abentley> So then how do you know when you're done?
<lifeless> I'm decoupling the points we're at search wise from the parents() lookup
<lifeless> so there would still be a searcher concept but its not being used to retrieve data
<kiko> hey guys
<lifeless> this means that each iteration will have just one parents() lookup, rather than one per side
<kiko> lifeless, do we need medusa to run the bzrlib tests?
<lifeless> the ftp ones yes
<kiko> lifeless, were these enabled recently?
<lifeless> they auto enable if they can
<lifeless> if you'
<kiko> odd
<lifeless> if you're running the tests via bzr selftest it won't error if its absent
<kiko> bzr: ERROR: exceptions.UserWarning: You must install medusa (http://www.amk.ca/python/code/medusa.html) for FTP tests
<kiko> bzr 0.18.0 on python 2.4.3.final.0 (linux2)
<kiko> arguments: ['./bzr', 'selftest', '-v']
<kiko> ** please send this report to bazaar@lists.ubuntu.com
 * kiko scratches head
<lifeless> if you're running make check, which we use for regression tests on pqm, then it requires all optional modules to be present
<kiko> no
<kiko> it's being run like this:
<kiko> python -Werror ./bzr selftest -v
<lifeless> well
<abentley> lifeless: Well, my inclination would be to have the searchers conspire to reduce lookups.
<lifeless> remote the -Werror if you want to be able to not have medusa installed
<abentley> But I wouldn't oppose your approach.
<lifeless> ok
<lifeless> I'll spend some time grokking the code more
<abentley> i.e. you do next(), and it causes all searchers to buffer their next output.
<lifeless> I think there are really three concepts here
<lifeless> A 'reachability cache'
<lifeless> or 'searched revisions' or something like that
<lifeless> 'getting parents'
<lifeless> 'choosing what revisions to examine next'
<lifeless> I'll fiddle somewhat. Firstly I'm going to instrument it slightly to figure out what its looking at at the moment
<lifeless> oh, hmm. just notced
<lifeless> KnitParentsProvider looks up single parents at a time
<lifeless> I'll fix this first
<lifeless> abentley: btw, a note on the api, if I might
<lifeless> get_parents(["x", "x"]) seems to be awkward, it might be nicer to do the self-associating style of result I've done in the index layer
<poolie> kiko, lifeless, that does seem to be a bug that it's giving a warning not a missing dependency - just old code i guess
<abentley> yes?
<poolie> lifeless, it looks like the packs megapatch still needs more reading, so i'm going to do that today
<poolie> unless something else comes up...
<lifeless> abentley: yah, if you cast the query into a set, or want to gather answers by the best IO pattern, you have to buffer and do housekeeping in the parents provider; but the caller actually doesn't really care AFAICT.
<abentley> I'm just doubtful that, in general, splitting the "searcher" part from the "parents retrieval" part is actually going to lead to more readable code.
<lifeless> I'll be careful ;)
<lifeless> for now, I'm just implementing _make_parents_provider and get_parents directly on PackRepository
<abentley> Yes, that will be much nicer.
<lifeless> its a necessary step
<lifeless> it may not be sufficient, we'll see
<lifeless> much better
<lifeless> still kinda slow
<lifeless> but much better
<lifeless> (it was fast enough I didn't have time to ctrl-C it)
<lifeless> poolie: yes, reading the packs patch is good
<igc> morning all
<lifeless> hi igc
<lifeless> bbiab, getting food
<igc> hi lifeless
<lifeless> while this test runs
<lifeless> poolie_: igc: incremental patch 2842 sent to bazaar-commits, and pushing now
<igc> thanks
<lifeless> hi nDuff , how are you ?
<nDuff> busy.
<nDuff> interesting times.
<nDuff> yourself?
<lifeless> You live in China ?
<nDuff> heh, no.
<lifeless> Busy - putting the polish on our new repo format.
<fullermd> Which also has a negative effect on times, one hopes   ;)
<ubotu> New bug: #153774 in bzr "Unreachable network raises an AssertationError (bzr+ssh)" [Undecided,New] https://launchpad.net/bugs/153774
<nDuff> How are 'yall doing performance-wise these days in comparison with mercurial? I'm looking for a way to track the upstream portage tree we're using to build our servers; it's over 100,000 files, there are lots of removes and adds of similar files on a regular basis, but we don't care about much in terms of functionality beyond basic snapshotting.
<lifeless> on my laptop
<lifeless> with crypted disk
<lifeless> committing a 55K tree with a few changes, without specifying those files, is 20 seconds
<nDuff> hmm.
<nDuff> I'll probably want to benchmark current bzr for my use case, then
<lifeless> we're working on bring that down by a factor of four in the next month
<lifeless> you'll want to benchmark with the packs repository format
<lifeless> this drops the number of files in your repository [for your scenario] from 200,000 to 5 * log10(commits) * 10 as an upper bound
<lifeless> specifically a 100000 file repo with 10000 commits will have 5 data files. 10001 commits will have 10, as will 10010 etc, 10002 will have 15 data files.
<nDuff> is that included in 0.91?
<lifeless> nope.
<lifeless> its what I'm polishing right now, the patch is being reviewed at the moment.
<lifeless> I can throw up a tarball easily for you
<nDuff> if you could do that, or just point me at somewhere I can pull from.
<lifeless> the place its hosted is in pack format already - I'm dogfooding :)
<nDuff> ahh.
<nDuff> a tarball, then, yes.
<lifeless> http://people.ubuntu.com/~robertc/packs.tar.bz2
<lifeless> you need pyrex to build the C extensions, which you'll want for benchmarking
<lifeless> what else, oh yeah, committing a merge is currently pathologically slow; its a bug in the logic in the new format that I'm fixing right now.
<lifeless> (by pathologically, I mean 180 times slower than a non-merge commit)
<lifeless> you can run from source, just 'make' in the source dir, then symlink something to 'bzr'
<lifeless> oh, and the last thing is that we currently don't remove the obsoleted files - the .bzr/repository/obsolete-packs/ directory - in production this will be not used
<lifeless> to make a pack branch, do 'bzr init --experimental'
<nDuff> I'm not worried about merging, so that WORKSFORME.
<nDuff> I'll be sure to exclude the contents of obsolete-packs when determining space efficiency.
<lifeless> yah
<lifeless> we haven't optimised for space yet
<lifeless> thats probably another month or two down the track
<lifeless> we've got some very promising research figures though
<lifeless> jelmer: I think I've found one cause of additional reads
<lifeless> so, merge commits are improved lol ... 45 times slower
 * lifeless codes some more
<lifeless> 15 times slower
<fullermd> Hm.  I estimate that given your current rate, if you can keep that up for another 2 hours we'll be about 50x as fast as cp   ;)
<lifeless> rofl
<fullermd> Extrapolation FTW!
<piedoggie> I tried upgrading an ubuntu 6.06 system to the latest bzr using apt-get banned it only knows about version 0 .17.  Is this the latest release supported for dapper or am I doing something wrong?
 * igc food
 * piedoggie tosses pizza
<ubotu> New bug: #153786 in bzr "pack repositories do not retry when concurrent operations pack" [Undecided,New] https://launchpad.net/bugs/153786
<ubotu> New bug: #153787 in bzr "annotation is slow in pack repositories" [Undecided,New] https://launchpad.net/bugs/153787
<ubotu> New bug: #153788 in bzr "pushing from packs to knits is slow and does not indicate why" [Undecided,New] https://launchpad.net/bugs/153788
<ubotu> New bug: #153789 in bzr "old packs are kept indefinately" [Undecided,New] https://launchpad.net/bugs/153789
<lifeless> abentley: still around ?
<lifeless> abentley: I've found the bug
<lifeless> abentley: find_seen_ancestors accesses 1000's of revisions
<poolie_> lifeless, to confirm, there's no good reason why our pqm needs to use https?
<lifeless> poolie_: ack
<lifeless> hows the review going?
<poolie_> interruptedly, but getting more into it now
<poolie_> one more question, about the bug of problems when retiring packs
<poolie_> would it work better, i wonder
<poolie_> to not move the packs, but instead keep a journal of retired packs
<poolie_> and just exclude them from the index
<lifeless> two problems with that
<lifeless> one is reconcile/gc operations where you want to change the data clients see
<lifeless> the second is that it becomes a clock synchronisation problem
<lifeless> (if you do it by count of operations a fast client breaks slow clients, if you do it by clock a bad clock results in clients being broken)
<lifeless> not to say its the wrong solution
<lifeless> but I don't think its any more complete, just will have some impact on frequency
<poolie_> hm
<lifeless> spiv: is the search order of a set stable in a single process?
<lifeless> spiv: that is if I have a set S, and do list(S) == list(S) is that guaranteed true ?
<spiv> lifeless: I don't think so.
<spiv> lifeless: because values with colliding hashes might come out differently, iirc.
<spiv> lifeless: http://rafb.net/p/WV5cRP27.html demonstrates a case where s_a == s_b, but list(s_a) != list(s_b).
<lifeless> spiv: I don't care about different list instances
<lifeless> spiv: just repeated iterations of the same list.
<lifeless> I have an API to use that returns a list for the things in an iterable; if I pass in a set to it, I need the same iteration order to zip them back up again
<spiv> If the two sets are constructed the same way, and are manipulated the same way (so have the same sequence of additions, removals, etc), then in CPython you're probably safe.
<lifeless> no
<lifeless> SAME INSTANCE
<spiv> Or if you're asking about the same set object, with no changes to the state of that set object between listifications, that's probably safe as well.
<lifeless> sorry for shouting but it was clearly not getting through
<spiv> But I don't think that's guaranteed.
<lifeless> I'm looking for more than "probably"
<spiv> Shouting on IRC doesn't hurt ears, I'll cope :)
<lifeless> :)
<lifeless> still somewhat rude :0
<i386> Your so polite lifeless, yet irc so vile..
<i386> wait, ive been drinking with you before. I take it all back
<spiv> lifeless: yeah, I cannot find any guarantees on that in the documentation (or source) for set or for frozenset.  It strikes me as something that it might be uncontroversial for frozensets to guarantee, but I doubt python-dev would extend that to sets.
<lifeless> i386: :)
<lifeless> spiv: thanks
<Tesla|Work> sabdfl: hi, man :-)
<poolie_> lifeless, hi, more than half done
<poolie_> lifeless, several of the methods changed to return tuples- can you remind me why?
<lifeless> two reasons
<lifeless> historical data isn't meant to be mutable, so tuples are a better fit
<lifeless> GraphIndex, which backs mapped knits returns tuples
<lifeless> so the test was broken as some repo's returned lists and some tuples, so I had to coerce it one way or the other
<lifeless> and I chose tuples
<soren> If I have some code that I'd like automatically contain the revision number of the bzr tree it's in, how would I do that? Should I add a call to "bzr revno" somewhere in my build system to save it, or is there something like CVS' magic $Revision$ markers or something entirely different?
<mwhudson> i'm pretty sure there's nothing like $Revision$
<mwhudson> you could probably write a post-commit-hook to put it in a file somewhere, i guess
<spiv> There's no $Revision$ magic at the moment.  Keyword substitution leads to awkward problems that we haven't tackled yet.
<soren> Ah, bzr has post-commit-hooks? I did not even know that. /me blushes
<mwhudson> at least, i think it does :)
<poolie_> soren, you should use the version-info command to write it into a file
<soren> poolie_: Ok.
<soren> poolie_: How about commit hooks? Does bzr have anything like that?
<poolie_> soren, yes, though at the moment they're exposed as python hooks not as shell commands
<soren> poolie_: Oh, ok.
<poolie_> basically, you should write a python module in ~/.bazaar/plugins/
<poolie_> and have that call
<poolie_> Branch.hooks.install_hook('post_commit', your_hook_here)
<poolie_> we know many people would like to just specify a shell command and we will try to do that soon
<soren> poolie_: Right. I'd especially like the commit hooks to be part of the source repository so that anyone using the source tree will have them.
<sabdfl> spiv: does your "speed up reconcile" patch also speed up check?
<spiv> sabdfl: it does, but it would only speed up the new checks added by the reconcile work.
<spiv> sabdfl: so I expect it will still be very slow.
<sabdfl> thanks spiv. i had to ^C a check on LP yesterday after 5 hours when it hit 1.7GB RAM
<spiv> Ouch.
<sabdfl> any prospect of cutting that down easily?
<spiv> I don't know of any good reason why it needs to consume unbounded memory, so quite possibly.
<spiv> That does smell a bit funny.  The check/reconcile code is a bit ugly, it has to delve into the sorts of details I didn't even know existed until quite recently :)
<spiv> But I would not be surprised to find there's something grossly inefficient lurking in that code.
<fullermd> Does seem like a section of the code that hasn't gotten much optimization attention.
<fullermd> After all, only pessimists would run check in the first place   ;)
<mwhudson> you would think that check could work one revision at a time and so that memory use shouldn't really grow
<mwhudson> maybe that's naive though
 * fullermd points and laughs at mwhudson's naivete.
<zerok> hi :)
<Slant_Laptop> I checked out a Subversion repo using bzr. Then branched it to do some work. Now I can't remerge my work... apparently the repository formats are incompatible. Can anyone help me merge my code back upstream?
<Lo-lan-do> What's your error message?
<niemeyer> Would you guys have anything to do with this spam: Britney Spears poses nude in Bazaar
<Slant_Laptop> bzr: ERROR: Repository KnitRepository('file:///home/scott/Projects/transit/move-to-paste/.bzr/') is not compatible with repository KnitRepository3('file:///home/scott/Projects/transit/transit-svn/.bzr/')
<Slant_Laptop> Lo-lan-do: Sorry, that was to you.
<Lo-lan-do> How recent is your bzr-svn?
<Lo-lan-do> You may have to do "bzr upgrade --format=dirstate-with-subtree"
<Slant_Laptop> Lo-lan-do: On which repo?
<Slant_Laptop> Lo-lan-do: Bazaar (bzr) 0.90.0
<zerok> no release this month? ;)
<jelmer> Lo-lan-do, the non-bzr-svn one
<jelmer> zerok: been delayed a bit in order to have packs (new, much faster, format) in
<Slant_Laptop> Grr.
<Lo-lan-do> Slant_Laptop: I think "<jelmer> Lo-lan-do, the non-bzr-svn one" was for you
<Slant_Laptop> Now it appears to have forgotten the common ancestor.
<Slant_Laptop> :-\
<jelmer> Slant_Laptop, was the original branch created using bzr-svn 0.3?
<Lo-lan-do> jelmer: Will bzr-svn use that packs format, or will it keep its own non-documented format?
<Slant_Laptop> jelmer: I don't know. Whatever is in gutsy. How can I check?
<jelmer> Lo-lan-do: dirstate-with-subtree is not bzr-svn specific
<jelmer> it was meant to be the next format (as part of the move to nested trees)
<Lo-lan-do> jelmer: I know, but apparently only bzr-svn uses it...
<jelmer> Lo-lan-do: bzr-svn requires a format that supports subtree data
<jelmer> there will be a variant of packs that supports subtrees as well
<Slant_Laptop> Ok, so now I'm trying to merge the branch back into the svn checkout...
<Slant_Laptop> How can I manually specify the common ancestor?
<Slant_Laptop> (Which I happen to know is rev 80)
<jelmer> I think you should be able to do something like 'bzr merge -r80..'
<jelmer> but that will just do a cherrypick, not track history
<Slant_Laptop> It says "all changes applied succesfully" but no changes have actually been made.
<jelmer> perhaps "-r80..-1" or something
<Slant_Laptop> Wee.
<Slant_Laptop> Exception.
<Slant_Laptop> That was fun.
<Slant_Laptop> My X session died.
<Slant_Laptop> I missed anything that may have been said, sorry.
<Lo-lan-do> Slant_Laptop: You didn't miss anything
<Slant_Laptop> Darn. ;-)
<Slant_Laptop> Well, then it does seem I'm kinda screwed. There isn't any way to get these patches upstream?
<jelmer> Slant_Laptop: What exception did you get?
<Lo-lan-do> You can always try a bzr diff -rsomething and commit the patch to SVN by hand
<Slant_Laptop> jelmer: One sec, I'll pastebi.
<Slant_Laptop> jelmer: http://pastebin.com/d168541a8
<jelmer> Slant_Laptop: if this is a public project, please file a bug.. that shouldn't happen :-)
<Slant_Laptop> jelmer: It's not, sorry. :-(
<jelmer> other than that, I'd recommend just using diff and patch like Lo-lan-do says
<jelmer> or perhaps version 0.1 of the rebase plugin
<Slant_Laptop> There's an awful lot of patches and logs. Darn.
<Slant_Laptop> Rebase?
<Lo-lan-do> jelmer: By the way, current bzr-svn refuses to work with bzr 0.91.  Is that deliberate?
<Slant_Laptop> Lo-lan-do: I thought there was a way to export a series of patches with the version information attached to them, and then merge that into a tree?
<Lo-lan-do> That may be what's referred to as "bundles", but I haven't tried that yet.
<jelmer> Slant_Laptop: yes, but that uses the same mechanism as merge
<jelmer> Lo-lan-do: yes, there were incompatible changes so the next version of bzr-svn will only be compatible with 0.92
<Lo-lan-do> I see.
<Slant_Laptop> jelmer: Oh, darn.
<jelmer> Slant_Laptop: rebase (a plugin) just replays the commits while retaining commit metadata
<jelmer> Slant_Laptop: You may be able to use 0.1 of that (http://bazaar-vcs.org/Rebase)
<Slant_Laptop> jelmer: Checking that out.
<zerok> jelmer, cool :D (sorry for the late reply... too many windows open :S )
<zerok> faster is great ... on my 12" powerbook bzr is dead slow :(
<jelmer> mwh: your push bug should be fixed now
<Slant_Laptop> Is there a way to install plugins without needing root?
<Slant_Laptop> :-\
<dato> sure. install them under ~/.bazaar/plugins/name_of_the_plugin
<Slant_Laptop> dato: Cool. Thanks.
<dato> Slant_Laptop: just note that the directory names should not contain hyphens. eg. install bzr-svn under plugins/bzr_svn or plugins/svn
<Slant_Laptop> jelmer: Umm. Haha, I'm getting the same error. :-D
<jelmer> abentley: ping
<jelmer> abentley: do you have any idea what could be causing the error at http://pastebin.com/d168541a8 ?
<Slant_Laptop> jelmer: How do you tell rebase the ... uh, base?
<jelmer> Slant_Laptop: sorry, I have a class to attend right now
<Slant_Laptop> jelmer: Ok. Thanks for your help thus far.
<jelmer> if you'd rather fix this than use diff+patch, please send me an email (jelmer@samba.org)
<Slant_Laptop> jelmer: I kinda need to commit several hours ago. ;-) So I'll be writing a script to diff+path now. Thanks, though.
<sabdfl> does one need to run bzr check before bzr reconcile, or can one just run bzr reconcile?
<zeasier> need some help with bazaar advocacy
<zeasier> discussing using it at work
<zeasier> been using it a while personally and don't have much experience with svn
<zeasier> some one mentioned atomic commits
<uws> zeasier: bzr has those as well
<zeasier> where if part of the commit goes wrong the whole commit gets rolled back
<zeasier> yeah i thought it did
<uws> zeasier: cvs had per-file revisions, which sucks since it can leave you in an inconsistent state afaik
<zeasier> yeah that's why i wasn't prepared for that question, never used cvs
<uws> zeasier: and you can also use bzr in a centralised way, i.e. you have to be up-to-date to the "main" branch before you can commit
<sabdfl> zeasier: you can use it both distributed, and centralised like SVN
<zeasier> yeah i've heard of this
<zeasier> mostly been using it decentralized so far
<zeasier> making good progress though only our sys admin needs convincing
<uws> zeasier: server requirements are NONE.
<zeasier> bosses seem to be alright with it
<zeasier> yeah that's very apealing
<uws> zeasier: but you can run a smart server for performance
<uws> but sftp/ssh access is enough
<zeasier> i was pretty happy with the built in ssh support in the fiesty release
<uws> that's the recommended way to use it indeed
<zeasier> though looks like we'll be using the central bzr apt repo, because of days like today
<zeasier> where half of the office has time to upgrade and the other doesn't
<zeasier> don't know how picky bzr is about different versions
<zeasier> but don't want to push our luck
<uws> latest versions are pretty compatible with each other
<zerok> small question regarding the centralized approach: when commiting to the central repo, are there some hooks that could be used on the server to for example send update mails or update a feed?
<zeasier> that sounds like a plugin issue (don't know the answer) might try to find some docs on plugin apis
<zerok> yeah, i was just wondering since i found some docs on the hooks but everything smelled very client-sidey ;)
<zeasier> one thing you could do is create a wrapper script
<zeasier> like zbzr or something
<zeasier> intercept commit commands and send what you want
<zeasier> then forward the rest to bzr
<zeasier> in anycase i'd imagine any solution you use would have to be client side
<zeasier> unless the smart server has hooks or something
<zerok> yeah. tnx :)
<zeasier> (again don't take my words as authority)
<zerok> ;-)
<zerok> anyway: time to go home. cu later :-)
<hsn_> bzr on windows is using builtin ssh client?
<hsn_> i need to setup public key auth
<jelmer> yes, it's using paramiko
<jelmer> it should be able to talk to pageant, for example
<hsn_> oh, it works
<hsn_> how to reference user home directory in sftp url? sftp://hsn@10.0.0.2/~hsn/java-devel/ dont works
 * zerok wants to thank whoever insisted on making the api that simple :D http://dpaste.com/22802/
<james_w> zerok: we tried to stop them.
<zerok> i can imagine :)
<dato> oh, dpaste.com is pretty
<jam-laptop> yeah, though it breaks all the indentation
<Peng> dpaste.com sucks. When you reply to a paste, it doesn't link them together.
<jam-laptop> unless there isn't any
<jam-laptop> But it is a little weird to iterate over all entries just to take the last one
<dato> jam-laptop: really? that'd be, uhm, bad.
<jam-laptop> I suppose it is a little bit prettier than http://rafb.net/p/a6VXmd22.html
<dato> I use rafb.net, but it annoys me when I have to paste non-ascii stuff: always serves my utf8 as latin1
<Peng> http://paste.pocoo.org/ ?
<zerok> jam-laptop, sure, it was just a quick-hack :)
<mwhudson> rafb only seems to keep pastes for about a day
<dato> jam-laptop: indentation seems to work here?
<jam-laptop> dato: yeah, I just misread the initial post, it didn't indent anything
<dato> ok
<zerok> jam-laptop, and i couldn't find a simple way to get the last changelog entry for that specified file without iterating over all the revisions in the first place ;)
<jam-laptop> I can't say I like the color scheme of: http://paste.pocoo.org/show/6556/
<jam-laptop> but it seems to have the same level of syntax highlighting as dpaste
<zerok> looks like the default pygments
<jam-laptop> zerok: try this one
<jam-laptop> zerok: http://paste.pocoo.org/show/6557/
<jam-laptop> ie.revision is the last revision that modified the file
<jam-laptop> I think the difference between that and the log stuff
<zerok> ah thanks :)
<jam-laptop> is that the log will also track down entries that merged it
<jam-laptop> (So if I change setup.py and you merge it without changing, ie.revision points to me, but log will also include your merge)
<zerok> requires an explicit read-lock i guess :)
<jam-laptop> zerok: yeah
<jam-laptop> But i would do that anyway
<jam-laptop> http://paste.pocoo.org/show/6559/
<zerok> yeah sure, this was just more or less a quick hack to find out if this would end up like that expedition i had with hg in the same territory :P
<jam-laptop> Otherwise it has to read the working state for the path2id
<jam-laptop> and then read it again for the .inventory
<jam-laptop> zerok: was it better or worse ?
<zerok> well, i'm still on the whole hg thing so bzr beat it by an hour so far :P
<zerok> bzrlib.errors.InvalidRevisionId: Invalid revision-id {None} in KnitRepository('file:///Users/zerok/projects/rstsuite/.bzr/') :S
<jam-laptop> ... oh, that is because this is the working tree.
<jam-laptop> sorry, you want the basis
<zerok> np, speed isn't really an issue with this project when it comes to determining that timestamp :)
<jam-laptop> http://paste.pocoo.org/show/6560/
<jam-laptop> zerok: you could also look into "bzr version-info --all --format=python"
<zerok> O_o
<jam-laptop> It dumps the state of the whole tree
<zerok> well, it will be used inside of a python program :-)
<jam-laptop> and some basic information about the revisions to this poin
<zerok> thanks again :)
<jam-laptop> point
<jam-laptop> There is also a --format=rio
<jam-laptop> and I think we are about to merge a --format=C
<zerok> O_o
<zerok> there shouldn't be any problem with unicode in changelog messages, right?
<jam-laptop> zerok: We support Unicode messages
<jam-laptop> Problems are up to you :)
<zerok> ah ok, just wanted to make sure :)
<jam-laptop> For example, trying to commit a iso-8859-1 formatted message and your LANG=C
<jam-laptop> or LANG=en_US.UTF-8
<jam-laptop> The one we see the most often is someone trying to use Unicode
<jam-laptop> but their system claims to be ASCII
<zerok> :S
<jam-laptop> (thus we have no way to interpret it)
<zerok> i had some problems a while back thanks to probably a broken bash or simply a missing font for my terminal and just switched to a VEDITOR ;-)
<ubotu> New bug: #154021 in bzr-eclipse "Reverse odering of revisions in Bazaar Log window" [Undecided,New] https://launchpad.net/bugs/154021
<gotgenes> What's the syntax to rolling back changes on a file using bzr merge?
<james_w> gotgenes: you want to make the contents of a file the same as it was a few revisions ago?
<james_w> or you want to remove the changes made by a commit a few commits back in the history?
<gotgenes> james_w: that would be a bzr revert
<james_w> yes
<gotgenes> james_w: is there a way to strip out changes from a particular revision?
<gotgenes> the second item
<hendrixski> hey is this a good chanel to ask questions, or is it a dev channel?
<james_w> gotgenes: bzr merge -r -3..-4
<james_w> and then bzr revert the files that you want to keep the same.
<ubotu> New bug: #154023 in bzr-eclipse "Missing message in Push progress dialog" [Undecided,New] https://launchpad.net/bugs/154023
<james_w> I think that should work.
<james_w> hendrixski: this is a perfect place to ask, go ahead.
<hendrixski> james_w, cool
<james_w> though it might not be the best place to get answers :)
<hendrixski> I'm joining a startup. and we're contemplating cersion control
<hendrixski> I heard a talk by Linus about git, and why people who use SVN or CVS are "stupid and ugly"
<gotgenes> haha
<gotgenes> I love that talk...
<hendrixski> and I heard bzr was easier to use
<james_w> hendrixski: I wouldn't listen to that too much.
<Lo-lan-do> According to Linus, half of the people on Earth are stupid and ugly.
<Lo-lan-do> And it's not always the same half, even.
<hendrixski> gotgenes, yeah, he was telling Google developers that they're stupid
<gotgenes> hendrixski: I think Bryan O'Sullivan's talk on Mercurial was much more informative
<gotgenes> per DSCM
<gotgenes> or DRCS
<james_w> hendrixski: bzr does aim to be easier to use than git yes. with it is is up to you though.
<hendrixski> Lo-lan-do, lol  everyone except him
<gotgenes> or however you like to call it
<hendrixski> gotgenes, ah, I'll add that to list of things to research
<hendrixski> so... the question then is... for a business, that will be developing on top of some open source applications, and also makeing some proprietary components is bzr something we should consider?
<gotgenes> hendrixski: check out some of my del.icio.us links http://del.icio.us/gotgenes/dscm
<gotgenes> the mercurial talk is in there
 * hendrixski check out gotgenes stuff real quick like
<gotgenes> after reading through, I decided on Bazaar
<james_w> hendrixski: I would say consider it definately, it might suit you perfectly.
<hendrixski> gotgenes, now, DSCM stands for?
<james_w> hendrixski: first I would work out how you are likely to want to work, and see which systems allow you to do that.
<zerok> hendrixski, distributed source code management
<hendrixski> zerok, ah, makes sense
<james_w> hendrixski: then, as there will be at least one that can do what you want try them out and have a play, and see how they feel.
<james_w> hendrixski: I am assuming as you are a startup you will have developers that are happy using advanced tools, would I be correct?
<hendrixski> james_w, yeah, that's part of what we're trying to decide... if we're going to be working in the "there's only one official branch, and one lead dev who merges" or if we'll have everyone merge...
<hendrixski> james_w, that would be correct.  We're all about the latest tools.  Ubuntu, Xen, etc. etc.
<james_w> hendrixski: yeah, bear in mind that a distributed system allows you to defer that decision somewhat.
<hendrixski> james_w, although, bzr is kind of a new tool as well, and "all the rage"
<gotgenes> hendrixski: What I like about Bazaar is that it still allows the centralized model to be used until the dev team has figured out how to move to the distributed model
<hendrixski> james_w, ah, that is a benefit
<james_w> hendrixski: also Bazaar allows you to work in a SVN style, where you don't even have to worry about merging, and then when you want to do more then you can go for it without affecting the other team members.
 * gotgenes points to james_w
<gotgenes> what he said
<zerok> hendrixski, well, basically all candidates imo are still quite young :)
<gotgenes> zerok: exactly
<gotgenes> but my impression with Bazaar is that the project has direction
<zerok> hendrixski, linux-only or do you also plan to support various operating systems?
<hendrixski> james_w, gotgenes, so basically one can set bazaar to "svn mode" and it has the look and feel of a centralized system... just with easier merges?
<james_w> hendrixski: many people prefer lots of branches and plenty of merging, but some feel that gets in their way.
<hendrixski> zerok, mostly linux... it's for an appliance, and long term we'll need to make windows programs to interface with it.
<james_w> hendrixski: yes, for the core commands then 'alias svn=bzr' almost works.
<hendrixski> nice
<james_w> (i.e. bzr checkout, bzr commit, bzr update, bzr revert etc.)
<zerok> hendrixski, in this case it will probably also be a criterium how easy the dvcs is to install on the platform
<james_w> hendrixski: do you have existing codebases?
<hendrixski> yeah, the too many branches thing scares me too.  When linux said " everybody has their own branch, sometimes many"... that sonuds like too much work
<gotgenes> hendrixski: http://doc.bazaar-vcs.org/bzr.dev/centralized_workflow.html
<james_w> once you get used to it it can be very empowering, but it does make you keep a lot in your head.
<hendrixski> zerok, my understanding is that any ftp server will do, right?  plus you can host a branch off your laptop, no?
<gotgenes> hendrixski: http://bazaar-vcs.org/Workflows
<zerok> hendrixski, yes, but i'm talking more about the "client" :)
 * hendrixski checks out the workflow link really quickly
<zerok> for example there are some tools that are quite a pain to install on windows
<hendrixski> zerok, ah. that's good to know
<zerok> also some require additional tools for merging
<hendrixski> zerok, such as?
<zerok> hg requires a 3-way-merging tool since it does no merging by itself
<zerok> or conflict resolution that is
<hendrixski> james_w, about your code-base question: we have two open source projects that we'll be working with, those code bases exist... and we have a few things we've tinkered with, but for the most part... no, no code base of our own yet.  very early stage
<hendrixski> zerok, hg?
<zerok> mercurial, hg http://www.selenic.com/mercurial
 * hendrixski check out link
<hendrixski> zerok, ah... hg = mercury,  so it's the company name... lol
<zerok> more the product name, but yeah :)
<zerok> as has been said, there are 3-5 options you have and you will probably do best by just checking them all out ;)
<hendrixski> james_w, so does bzr also work well for pulling from upstream svn servers and making our downstream modifications?
<james_w> hendrixski: you don't have to say what they are, but how large are the codebases? (no of files in working tree).
<james_w> hendrixski: the marvellous bzr-svn does that.
<hendrixski> zerok, yeah.  we may just do that, I just have a TON of questions to help me know what to expect. :-)
<hendrixski> james_w, and that's still beta, right?  is it industry deployment ready?
<hendrixski> one is about 15,000 files,  one is probably 4,000 files
<james_w> yeah, I guess it's still beta. jelmer is very responsive, and it works well on a lot of things, but I wouldn't embed it in a product or anything yet.
<hendrixski> very little of it will be modifying that code base... more just building on it.
<jelmer> pulling data out of svn works pretty well, pushing data into it has a couple of open bugs
<gotgenes> james_w: Do you know where the documentation on how to use bzr-svn to convert a Subversion repository to a bzr repo is? I successfully installed bzr but am not sure how to use it.
<james_w> hendrixski: you've probably heard that bzr isn't the best for performace, and those sizes are quite large, but things should be getting better.
<gotgenes> er, installed bzr-svn
<jelmer> (none very big though)
<james_w> gotgenes: bzr branch svn://whatever/trunk/
<hendrixski> james_w, ah, and that just made me realize, bzr itself is not at version 1.0 yet... is it production-ready?
<james_w> gotgenes: there is also svn-import if you want a full import of everything.
<hendrixski> actually... how do I check the number of files in a directory?
<jam-laptop> hendrixski: well, we have 8k+ unit tests which make sure we don't do anything foolish
<zerok> hendrixski, including subdirectories?
<jam-laptop> I would argue that we have been more stable than most for a long time
<zerok> hendrixski, find . | wc -l
<hendrixski> zerok, yeah
<gotgenes> james_w: how does svn-import work? bzr svn-import is an unknown command
<jam-laptop> We are also approaching 1.0
<hendrixski> ah, nice
<jam-laptop> (hence the jump to 0.90+)
<hendrixski> oh... wow, way smaller than I thought... they're both at about 5K files
<james_w> there have been a few of regressions recently, so it's not perfect, but generally it is stable.
<james_w> hendrixski: jam-laptop will be able to give you and idea of the performance of that better than me.
<james_w> hendrixski: there are many people who run of the tip of bzr.dev (i.e. always running development code), and there are few problems that hit.
<jam-laptop> james_w: yeah, well we made some pretty major changes recently, and part of that ended up jumping from 6k tests to 8k :)
<hendrixski> jam-laptop, james_w, ah, so _mostly_ stable, would there be anything that would be considered a "show=stopper" like, it eats your code base if you misspell something?
<jam-laptop> hendrixski: not that kind of bugs
<hendrixski> ok
<hendrixski> well.  from everything I'm hearing here it sounds like I'll tell the coworkers that we should try it out
<hendrixski> now, I can just apt-get it in Ubuntu and try it out, right?  with that svn command james_w mentioned up above.  no other major headaches?
<jam-laptop> hendrixski: sure, though you may want to add the new apt repository
<jam-laptop> http://bazaar-vcs.org/releases/debs/
<jam-laptop> with fiesty,edgy,dapper depending on what you are using
<jam-laptop> (We are on a monthly release cycle, so you can usually get something a bit better from there)
<jam-laptop> 0.15 specifically was one of the ones with some regressions in our rename tracking
<jam-laptop> (The biggest regressions we've had are that sometimes Bazaar gets confused about the working tree, we've never, to my knowledge, had data loss from committed data that wasn't hardware problems)
<hendrixski> ah, well.. gonna be switching to gutsy as soon as we verify (on a VM) that it doesn't break anything... but that repo you listed will always have a newer version?
<jam-laptop> I'm not sure which version gutsy has, but it obviously had a freeze a month or so ago
<hendrixski> yeah, .15 is the one I see on the feisty repo's now.  By regression, you mean a step back where things went afoul, right?
<jam-laptop> just a "echo deb http://bazaar-vcs.org/releases/debs/gutsy ./ >> /etc/apt/sources.list"
<jam-laptop> hendrixski: something that worked in 0.14 stopped working in 0.15
<jam-laptop> (regression)
<hendrixski> oh, I just added it using vim... I guess it's faster to echo, huh
<jam-laptop> 0.16 fixed almost all of them
<jam-laptop> 0.17 squashed the last ones I knew of
<hendrixski> I C
<hendrixski> good thing I'm not gonna be test driving .15 then :-)
<hendrixski> that probably saved me a headache and a half.  thanks jam-laptop :-)
<jam-laptop> yeah, I know we wanted to get an update into the official Feisty repos
<jam-laptop> but they are pretty strong about not abusing "Security"
<jam-laptop> since it wasn't a strictly security issue
<jam-laptop> And I'm not sure what the other issues were with the other 'backports' or whatever
<hendrixski> and they didn't want to put in a few dpatch's into the packages to fix the regressions?
<jam-laptop> Well, the fixes came long after Feisty was released
<jam-laptop> well, after
<jam-laptop> only like a month :)
<hendrixski> well, in a 6 month release cycle, a month is a long time
<jam-laptop> 0.15 was a pretty massive upgrade over 0.14 in other respects, it just brought a lot of code in
<jam-laptop> and there were a couple bits that weren't correct
<jam-laptop> mostly on handling projects with lots of files.
<jam-laptop> 5k shouldn't be a problem
<hendrixski> :-/  oh, the sources.list thing... had to change it to **vcs.org/releases debs/  for apt to accept it :-/
<jam-laptop> hendrixski: sounds like you are still missing some bits
<jam-laptop> it *should* be
<jam-laptop> deb http://bazaar-vcs.org/releases/debs/gutsy ./
<jam-laptop> or
<jam-laptop> deb http://bazaar-vcs.org/releases/debs/feisty ./
<jam-laptop> in your case
<hendrixski> and I'm missing a gpg key
<hendrixski> yeah, I cw'ed gutsy to feisty
<hendrixski> meh, I'll figure it out
<jam-laptop> I think it is a
<jam-laptop> gpg --recv-key XXX
<jam-laptop> gpg --export XXX | sudo apt-key add
<jam-laptop> sorry
<jam-laptop> gpg --export XXX | sudo apt-key add -
<hendrixski> I gotta get back to "real work" and not "dicking around on IRC" ... even though I solve more problems on here than anywhere else
<jam-laptop> hendrixski http://bazaar-vcs.org/DistroDownloads
<hendrixski> ah, right, gpg --export
<jam-laptop>  gpg --keyserver subkeys.pgp.net  --keyserver-options http-proxy --recv-key EEA6AD6A
<jam-laptop>     gpg --armor --export EEA6AD6A | sudo apt-key add -
<james_w> hendrixski: sounds like 'research' to me, I'd class that as real work.
<hendrixski> man, I have to comment out all the ubuntu repositories in my sources. list 'cause they're slow as balls... I guess their servers are going at a snails pace due to gutsy frenzy
<hsn_> there is new ubuntu release?
<jam-laptop> yeah
<hendrixski> james_w, I would too, I guess my coworkers went on IRC a few times and talked about... whatever, porn or something, so they think it's a bunch of neck-beards talking about useless crap
<jam-laptop> gutsy is out
<hendrixski> hsn_, yeah, 7.10 hit servers today
<jam-laptop> I thought 'apt-get install' was a bit slower than usual
<james_w> jam-laptop: is .get_weave_or_empty going to stick around. It sounds weave specific. Is it just an unfortunate name to get something with a generic interface?
<jam-laptop> According to the other channel
<jam-laptop> Ubuntu is going at about 7Gb/s
<hendrixski> yeah, those servers are handling about 6 million people downloading an entire distro... in one day
<jam-laptop> And if you count mirrors
<jam-laptop> it is something like 18 Gb/s
<jam-laptop> Apparently to be an official US mirror you need >50Mb/s
<jam-laptop> (just reading this from the other channel)
<hendrixski> sweet. got it to show up version .16
<ubotu> New bug: #154045 in bzr-eclipse "Add support for bound branches" [Undecided,New] https://launchpad.net/bugs/154045
<sohmestra> I've got bzr-svn (0.4) installed, along with python-svn, and subversion on debian etch. However, when I attempt to branch a subversion branch, it tells me that the python svn bindings aren't installed.
<sohmestra> see: http://dpaste.com/22833/
<jelmer> sohmestra: you need python-subversion, not python-svn
<sohmestra> doh!
<ubotu> New bug: #154047 in bzr-eclipse "Add push after commit checkbox into commit dialog" [Undecided,New] https://launchpad.net/bugs/154047
<dato> (http://chistera.yi.org/~adeodato/code/scripts/web/dpaste/)
<jelmer> dato: after some more thought
<jelmer> dato: I don't think merges can be rebased at all
<jam-laptop> jelmer: why couldn't you rebase them?
<jam-laptop> I suppose it should have human intervention
<jam-laptop> but it would just be repeating the merge with a new parent
<jam-laptop> Or it could even be implemented as replaying the diff
<jelmer> jam-laptop: right, so you'd be replaying a merge
<jam-laptop> and just setting the merge parent
<jelmer> rather than reapplying the diff
<jam-laptop> I would guess that is actually more what users would want (replaying the diff)
<jam-laptop> since it is likely to have whatever fixes they did
<jam-laptop> At least in my head "rebase" is redo what I did over here
<jam-laptop> So replaying the diff is reasonable
<jelmer> but if the branch on top of which you're rebasing already has a part of the changes you are trying to rebase things blow up
<jam-laptop> (I would actually implement it as a cherrypicked merge over and over again)
<jelmer> and that's usually the case
<jelmer> yes, a cherry picked merge is what it's doing at the moment
<jam-laptop> If the branch you are rebasing above already has the changes you are rebasing you have the same problem
<jam-laptop> I suppose that is less common
<jam-laptop> than if you had a merge
<jam-laptop> jelmer: I think it is common if you are rebasing against Trunk and you have done some merges against trunk
<jam-laptop> It is not common if you are merging a 3rd party's changes
<jelmer> jam-laptop: the situation here is
<jelmer> where you have done some hacking of your own
<jelmer> then merged trunk and committed that merge
<jelmer> than ran 'bzr rebase'
<jelmer> s/than/then/
<jam-laptop> You could use ancestry checks to determine which is reasonable
<jam-laptop> (if the merged revision is already present, skip it, else redo the diff and set the merge)
<jam-laptop> http://rafb.net/p/Fc4Gny15.html
<jam-laptop> Certainly it doesn't make sense to set A as the merge parent of C
<jelmer> right
<jam-laptop> but http://rafb.net/p/7z0Slc86.html
<jam-laptop> If you are rebasing C on top of B
<jam-laptop> (ignore F in that graph)
<jam-laptop> You would want to keep D
<jam-laptop> merging into E
<dato> jelmer: mmm, was your comment actually directed at me?
<jelmer> dato: yes, because of bug 126743
<ubotu> Launchpad bug 126743 in bzr-rebase "failure rebasing a merge" [High,Triaged] https://launchpad.net/bugs/126743
<jelmer> jam-laptop: thanks
<dato> ah, thanks for the pointer. as if I could remember that. ;-)
<jelmer> vila: ping
<poolie> good morning
<mwhudson> hello poolie
<abentley> jelmer: It looks like that cherrypick is trying to add a file to a directory that isn't versioned.
<jelmer> abentley: Is it ok for it to fail that way or is this a sign one of the trees is broken or perhaps a bug in merge?
<abentley> I'd call it broken handling of an obscure conflict.
<abentley> Definitely a bug in merge.
<jelmer> abentley: ah, thanks
<jam-laptop> poolie: good morning
<poolie> jam-laptop, hi
#bzr 2007-10-19
<thumper> morning bzr dudes
<igc> morning all
<jelmer> jam-laptop: there's no guarantee though that a revision with multiple parents contains only merges
<lifeless> jelmer: what do you mean?
<jelmer> lifeless: we were talking about rebasing "merge revisions"
<jelmer> and how you could skip them during rebase if the rhs parent has already been merged in the branch you're rebasing
<lifeless> jam-laptop: ping
<lifeless> jelmer: surely its a topo sort of the revisions and rebase them all; merges too
<jelmer> lifeless: rebasing a commit with a rhs parent that has already been merged is most likely going to cause conflicts
<jelmer> https://bugs.edge.launchpad.net/bzr-rebase/+bug/126743
<ubotu> New bug: #154119 in bzr "Repository.item_keys_introduced_by should not lock Repository" [Medium,Triaged] https://launchpad.net/bugs/154119
<ubotu> New bug: #154129 in bzr "pack does not optimise layout" [Undecided,New] https://launchpad.net/bugs/154129
<lifeless> igc: poolie: first round of fixen pushed
<lifeless> jam-laptop: ping
<lifeless> hi igc
<igc> hi lifeless
<igc> working thru pack_repo.py today FYI
<lifeless> cool
<jeremy_c> will bazar launch a merge tool for me?
<lifeless> do you mean a gui conflict-resolving tool ?
<jeremy_c> lifeless, yes, such as Meld on Linux, or TortoiseMerge on windows?
<lifeless>  / per-file merge tool ? e.g. meld ?
<lifeless> Yes, there are some plugins that do this
<jeremy_c> I'll look in the plugin section on the wiki. thanks.
<lifeless> np
<poolie> ok i've read the whole patch
<poolie> i'm going to trim out the boring parts and post my comments
<lifeless> woot
<poolie> mm?
<lifeless> your having read the entire patch
<lifeless> I've just replied to all the reviews so far
<lifeless> and actioned nearly everything I agreed with
<lifeless> spiv: ping
<spiv> lifeless: pong
<lifeless> theres a gem in my patch for you
<lifeless> insert_data_stream
<lifeless> where ith da docstring
<spiv> lifeless: heh, just read that a few seconds ago.
<lifeless> i386: also where were you last night? release party one block from atlassian?
<spiv> lifeless: I'll write one and send it to the list.  Thanks for the poke.
<i386> lifeless: asleep!
<larsl`> Is there a way to get 'bzr send' to use a readable patch format?
<i386> Ive been drinking heavily for the last two weeks and Ive been kinda sick
<lifeless> larsl`: it's got a human copy of the patch by default
<lifeless> larsl`: if you're not seeing that, what parameters are you giving it ?
<lifeless> i386: :(
<lifeless> i386: we put a few back for you :O
<larsl`> lifeless: No other copy here. I just do 'bzr send --mail-to some@address'
<lifeless> larsl`: that should fire up your mail client
<lifeless> larsl`: with an attached patch
<larsl`> lifeless: It does.
<lifeless> larsl`: the attached patch should be human readable with a base64 tail
<larsl`> But the patch looks like a block of uuencoded something. There is no readable text.
<lifeless> larsl`: thats strange; is this open - can you pastebin the patch for me to look at ?
<larsl`> Sure, it's just a test.
<larsl`> lifeless: This is the contents of the sole attachment in the mail: http://rafb.net/p/MFCGVY79.html
<larsl`> ...oh. I need to commit locally before sending.
<larsl`> That was just an empty patch.
<lifeless> :)
<lifeless> I was just finishing extracting the data to examine
 * igc food
<larsl`> Trying to push a branch to a FTP server, but I keep getting the error message "FTP temporary error: 451 /bzr/bzzr/.bzr/repository/inventory.knit: Append/Restart not permitted, try again. Retrying."
<larsl`> "bzr: ERROR: exceptions.AttributeError: 'FtpTransport' object has no attribute 'get_credentials'"
<lifeless> oh hmm
<larsl`> It seems to do something, because there are directories added on the FTP server, but I can't checkout.
<lifeless> Our FTP maintainer is probably asleep right now
<lifeless> vila: ^
<lifeless> anyhow, the knit repository format requires APPE/REST be available, and they appear to be disabled on your server.
<larsl`> Hm.
<lifeless> the get_credentials thing is a bug
<lifeless> but probably only occuring as a side effect
<larsl`> Would any of the other formats work?
<lifeless> packs should
<lifeless> they are currently being reviewed, should be merged later today
<larsl`> Ah. I'm using 0.91.0 from Debian Testing.
<abentley> lifeless: Would weaves require APPE/REST?
<lifeless> abentley: yes, for the history file in the branch object
<abentley> How clever of me to have removed that requirement.
<spiv> lifeless: here's a docstring for Repository.insert_data_stream: http://rafb.net/p/9bcOyO41.html.  Any comments or should I just merge it?
<lifeless> I think its too vague
<lifeless> you say e.g. bencoded
<lifeless> is it or isn't it?
<lifeless> is it allowed to vary by repo
<lifeless> is there a version marker?
<lifeless> or is it self delimited by a version?
<lifeless> why why why basically
<spiv> lifeless: I was afraid you'd ask the hard questions :)
<spiv> I'm not sure of the answers to a lot of them to be honest.
<lifeless> there's a list
<lifeless> I hear smart people subscribe to it
<larsl`> So none of the current repository formats would work on a FTP server that doesn't allow Append/Restart?
<spiv> I'll start a thread there, then.
<ubotu> New bug: #154173 in bzr "pack reconcile does not correct for the fix_text_parents problem" [Undecided,New] https://launchpad.net/bugs/154173
<lifeless> larsl`: sorry, no :(
<larsl`> I guess there is no write support for HTTP?
<lifeless> there is a webdav plgin
<lifeless> plugin
<lifeless> and there is bzr+http too
<lifeless> there is also SFTP
<lifeless> which is more secure than FTP
<larsl`> Yeah, but FTP and HTTP is all I have for now.
<larsl`> What's bzr+http? Is there any documentation for it? Google only finds code.
<lifeless> try googling for 'serving bazaar with fastcgi'
<larsl`> Seems to be read-only.
<lifeless> or http://doc.bazaar-vcs.org/
<lifeless> latest, user guide,
<lifeless> if you set auth up, then you can make it read write
<gotgenes> Can I create a patch just using 'bzr -r REVNO.. > mypatchfile' ?
<lifeless> sure
<lifeless> that will go from revno to your current tree
<gotgenes> and then the person I send that patch to just does 'patch -p0 < mypatchfile' right?
<larsl`> Hm. I don't think I have mod_python either.
<lifeless> gotgenes: if they are not using bzr yes
<gotgenes> gotgenes: they aren't
<lifeless> gotgenes: if you and they are both using bzr you are much better off committing and using 'bzr send'
<gotgenes> ha
<gotgenes> lifeless: ah, that's good to know!
<lifeless> bug 154204
<lifeless> bug #154204
<ubotu> Launchpad bug 154204 in bzr "revision specs do not lock branches appropriately." [Critical,Triaged] https://launchpad.net/bugs/154204
<ubotu> New bug: #154204 in bzr "revision specs do not lock branches appropriately." [Critical,Triaged] https://launchpad.net/bugs/154204
<igc> heading off a bit earlier today to catch up with some people
<igc> might be back later tonight
<igc> if not, have a good weekend all
<spiv> igc: me too.  Have a good weekend.
<igc> thanks spiv
<vila> jelmer: pong (looks like being in the same TZ doesn't help us to get in touch ;-)
<fullermd> TZ?  You mean those things some weird people actually obey?  ;>
<vila> fullermd: yeah, especially children you insensitive clod !
<vila> :)
<fullermd> Ah, you just plow a few double espressos into 'em, they'll adjust.
<vila> fullermd: obviously you don't know my daughters, they are already too much and too often awake for our taste :)
<vila> they leave us sleep sunday mornings since a few years though...
<fullermd> See, if you could just get them to use some of that awake time for bzr hacking...
<vila> why do you think there are so many bugs in my submissions ?
<fullermd> I see.  Kids these days...   no QC.
<vila> Sheesh, and don't start me about jam on the keyboard...
<fullermd> Hah.  My first thought to that was "Doesn't John have his own keyboard?"   :p
<zerok> morning :)
<sabdfl> hey all
<sabdfl> lifeless: nearly, nearly there?
<Kinnison> Good moring bzr hackers
<ubotu> New bug: #154259 in bzr "traceback on temporary ftp error" [Undecided,Confirmed] https://launchpad.net/bugs/154259
<fullermd> I wonder if that error has EVER been temporary...
<lifeless> sabdfl: very very close
<Olberd> Hi. I'm trying to install bzrsvn in windows and can't make it work
<Olberd> I have installed the python-svn requirement, but apparently not so that bzrsvn can locate it
<Olberd> or could it be that the win32 package linked to on bzrsvn's homepage isn't new enough?
<Olberd> jelmer, maybe you know?
<jelmer> Olberd, Did you install the python-subversion bindings linked fomr the wiki page?
<Olberd> yes, if you mean http://bazaar-vcs.org/BzrSvn
<ubotu> New bug: #154283 in bzr "indexerror in Knit._get_components_positions pulling in pack repo" [Undecided,New] https://launchpad.net/bugs/154283
<jelmer> Olberd: What exactly doesn't work?
<Olberd> jelmer, it says in bzrsvn's readme that the svn should be at least 1.5. But the link on the wiki has the version 1.4.3.
<jelmer> yes, but the .exe linked from the wiki has got the required patches backported
<Olberd> When I try to run bzr bzrsvn prints: "no python bindings for subversion installed..."
<jelmer> can you start python and run "import svn" ?
<Olberd> yes, no errors
<jelmer> is the same python interpreter used by bzr ?
<jelmer> or did you perhaps install a bzr that included its own python?
<Olberd> I used the standalone 0.91 windows installer
<jelmer> you probably need the python-based installer
<jelmer> I'll add a link to the wiki page
<Olberd> ok, I'll try using the other installer
<vila> jelmer: pong (looks like being in the same TZ doesn't help us to get in touch ;-)
<jelmer> vila: :-)
<jelmer> vila: What exactly did you with your comment to bug 141105?
<vila> you mean mean ?
<jelmer> I consider the svn+ prefix a hack, ideally bazaar should just handle SSL certificates properly
<vila> hrm
<vila> jelmer: feel free to reopen the bug then
<vila> what I meant was that bzr now gives a proper error message instead of KeyError: 77
<jelmer> ah, ok
<vila> Handling SSL certificates is on my TODO list, python 2.6 will provides an ssl module for that
<vila> problem solved :)
<jelmer> :-)
<vila> kidding, there is a module that can be installed for python 2.[45], I'm looking into integrating it into bzr or making bzr depend on it
<jelmer> Ah, I was confusing this bug with bug 82086
<jelmer> sorry
<vila> np, better two brains than none on any subject :)
<vila> that module will allow us to also have a proper https server, but there is a bit of work to get there
<vila> and then, we can just deprecate pycurl and drink some champagne :)
<jelmer> Yeah, that'd be nice
<ryanakca> Is there a way to make a useable diff? I know 'bzr diff', but you can't really apply === modified file 'template.htm' (properties changed)
<Kinnison> bundles
<Kinnison> they're more what you want
<Kinnison> I think
<ryanakca> thanks :)
<Kinnison> Specifically the 'bzr send' command I think
<Kinnison> aah or the 'bzr bundle-revisions' command may be of more use
<ryanakca> :)
<ryanakca> Kinnison: any idea for http://pastebin.ca/742241?
<Kinnison> odd
<Kinnison> make the bundle --no-patch?
<Kinnison> does that work?
 * ryanakca tries
<ryanakca> Kinnison: bzr: ERROR: no such option: --no-patch
<jelmer> Olberd, any luck?
<Kinnison> ryanakca: odd, because it's there for m
<Kinnison> +e
<ryanakca> hmmm...
<ryanakca> what version?
<ryanakca> 0.90.0?
<ryanakca> Kinnison: hmm... I'll be back in 8 hours or so, school. See you ;)
<danigm> hi, i have a question. When two developers push in one branch, and each developer has his own local branch, the log is overwrite. There is a method for push, or something similar that log well?
<danigm> i mean, i push, and in the log appear danigm has changed ..., and when other developer push, must appear only his changes, not his branch log
<jelmer> danigm, not sure I'm following
<danigm> when i change something in my own branch, the log say that i make, and i merge with the main branch, and log it as "merged with main branch". And then push my branch, and the log of main branch dissapear, and appear my own log. I upload my own branch, the main branch is dessapear, is merged.
<danigm> I think it's possible having two locals branch, my branch, and the main branch. When I want to publish my chages in main branch, I should merge that with mine, and push main
<dato> I *think* he wants append_only = True, lemme re-read
<danigm> but I need to branch from main, everytime that i want to push my changes
<dato> oh, he was spanish
<Olberd> jelmer, other error now
<Olberd> it simply says: unable to load plugin u'bzrsvn' from u'.../plugins'
<Olberd> I've run 'bzr selftest'
<Olberd> It returns error: ... no module named svn.transport
<jelmer> the plugin has to be named 'svn'
<Olberd> ok
<jelmer> rather than bzrsvn
<Olberd> does it say that anywhere?
<jelmer> it's only necessary for the testsuite afaik
<Olberd> ok
<Olberd> well, not only for the selftest
<Olberd> Renaming it solved my problems it seems
<mrevell> Hey - what version was pushing using bzr+ssh introduced? According to the release notes, I think it might 0.11 but then it says smart server didn't come until bzr 0.16.
<quicksilver> bzr+ssh isn't smart server
<quicksilver> bzr+ssh is just using ssh isn't it?
<mrevell> Ah right, thanks.
<radix> quicksilver: no, it's the smart server
<radix> quicksilver: You can't do much with "just ssh" :)
<radix> bzr+ssh connects on ssh and immediately starts up a smart server on the other side to handle the connection
<quicksilver> radix: You could. You use use ssh and then shell out to commands like 'cat' and 'chmod' to build/alter the repo.
<quicksilver> radix: I have used other systems which work like that.
<quicksilver> but fair enough if that isn't what it does :)
<radix> quicksilver: that's "ssh and cat and chmod", not "just ssh" :P
<radix> but that's enough pedantry from me :-)
<james_w> When using VersionedFile.add_lines() the parents argument is the previous revision-ids in which the file was modified, rather than the parents of the current revision, is that correct?
<james_w> so 3 revisions, with revids rev1, rev2, rev3, and a file a that is created in rev1 and modified in rev3.
<james_w> You would add lines for rev1 with no parents, and then rev3 with rev1 as parent, with nothing for rev2, is that correct?
<jam-laptop> james_w: Correct
<jam-laptop> (It is part of setting the per file graph, and also making sure the delta is built against an existing revision)
<james_w> jam-laptop: thanks.
<james_w> jam-laptop: also, any suggestion for what the tree root id could be for bzr-git. I am going with hash(path) for the ids, but this means that all trees would have the same root. This doesn't seem ideal, but I'm not sure what the impact would be.
<jam-laptop> james_w: At the moment, I think all bzr trees use 'TREE_ROOT'
<jam-laptop> which is also not ideal
<jam-laptop> but it turns out that older versions of bzr didn't handle other values properly
<jam-laptop> so we had to wait for a format bump to introduce unique ids
<james_w> it's unambiguous though :)
<jam-laptop> I believe Knit3 uses unique ids
<james_w> yeah, it does for what I have seen
<jam-laptop> (And bzr since about 0.14 or so is able to handle it)
<jam-laptop> actually, maybe all the way back to 0.10
<jam-laptop> and it is just 0.8 that can't
<jam-laptop> anyway
<jam-laptop> The *reason* to have unique tree roots
<jam-laptop> is so that if you merge 2 trees into 1
<jam-laptop> then when you do further merges
<jam-laptop> it knows where to put files that show up in the root dir
<jam-laptop> I'm guessing Git doesn't have any concept of project id
<jam-laptop> etc
<jam-laptop> so I would just go with hash('')
<jam-laptop> and live with it
<jam-laptop> you *could* use TREE_ROOT
<jam-laptop> if you wanted
<james_w> I'll go with the hash, thanks.
<james_w> I was wanting to make it unique, as git supports submodules, and so we should map them on to nested trees at some point, and it seems non-unique would get in the way.
<james_w> but they don't want to be too unique :)
<jam-laptop> well, if you made them random
<jam-laptop> then 2 people using bzr-git couldn't interoperate
<jam-laptop> we'll have to handle the nested tree case anyway for our own data
<jam-laptop> since we already have all trees with non-unique root ids
<jam-laptop> plus bzr-git is going to have issues with all the same path directories looking alike anyway
<jam-laptop> (so having 'src/' is going to collide with every other project that has a src/)
<james_w> ah, of course. I'll just use that solution when you find it.
<jam-laptop> of course
<jam-laptop> if you had a way to come up with a unique tree root
<jam-laptop> you could incorporate that into all the other directories
<james_w> yeah, one solution could be to have a project-id passed to bzr-git that is just introduced in to the hash.
<jam-laptop> but I can't think of a way to do it
<james_w> but that would require an extra argument added to branch, checkout, init etc.
<jam-laptop> if you wanted to be minorly evil
<jam-laptop> you could double hash the first commit
<jam-laptop> (take the commit's hash, and hash it)
<jam-laptop> that would most likely be unique
<jam-laptop> if a bit odd
<jam-laptop> and might have problems after joining projects
<jam-laptop> since then you have multiple rev1 nodes
<jam-laptop> (you could sort them and just always pick the 1st one)
<james_w> yeah, using the root commit as the root id did occur to me. You would get collisions occasionaly, but they would be far less.
<jam-laptop> certainly far less than using the same value for everything :)
<james_w> There are going to be a massive number of fork+execs to make this work it seems.
<jam-laptop> well, that is how git is written, right?
<Keybuk> wing-commander upstart% bzr bundle
<Keybuk> Using saved location: bzr+ssh://keybuk@bazaar.launchpad.net/%7Ekeybuk/upstart/main/
<Keybuk> bzr: ERROR: exceptions.AttributeError: 'RemoteRepository' object has no attribute '_make_parents_provider'
<Keybuk> ^ d'oh
<jelmer> Keybuk: IIRC that's a known bug
<jelmer> high on the list for 0.92
<Keybuk> ok
<jam-laptop> spiv: I still haven't heard the status of chunked encoding: http://bundlebuggy.aaronbentley.com/request/%3C20070903172153.GC22003@steerpike.home.puzzling.org%3E
<jam-laptop> I think Martin pinged you on it the other day, but I didn't see a response
<ryanakca> bzr merge foo.bundle : any idea for http://pastebin.ca/742241?
<AnMaster> bzr+ssh push protocol seems to ignore ~/.ssh/config
<AnMaster> because it doesn't try to connect on the port I set it should in ~/.ssh/config
<AnMaster> so pushing doesn't work as server use non-standard port
<AnMaster> can anyone confirm this?
<AnMaster> this bug*
<AnMaster> ryanakca, tabs/spaces mixup?
<ryanakca> AnMaster: yes, but why should bzr crash (other than python not liking mixtures of tabs/spaces)
<AnMaster> ryanakca, no idea
<AnMaster> any idea about my problem?
<poolfool> AnMaster: https://bugs.launchpad.net/debian/+source/bzr/+bug/146715
<ubotu> Launchpad bug 146715 in bzr "bzr+ssh broken for non standard ports." [High,Fix committed]
<AnMaster> yes just found it a bit before
<poolfool> AnMaster: Sorry didn't take the time to read it ... I was just lurking.
<AnMaster> no problem
<jam-laptop> ryanakca: it seems to be doing the merge using a patch
<jam-laptop> not a bundle
<jam-laptop> and it is requiring the source to be an exact match
<jam-laptop> The traceback is probably because that code path isn't used yet
<jam-laptop> I can't say I've seen it before
<jam-laptop> I could be wrong
<jam-laptop> AnMaster: known bug
<jam-laptop> It has been fixed in bzr.dev
<jam-laptop> so it will be fixed in 0.92
<jam-laptop> ryanakca: The "crash" is probably because we would rather fail safe than continue, so we would at least give an error that the patch does not match
<jam-laptop> It probably should be a simple refusal
<jam-laptop> and not a traceback
<ryanakca> jam-laptop: so, how to I make the requiring source an exact match?
<ryanakca> jam-laptop: bzr revert?
<lifeless> moin
<jam-laptop> hi LarstiQ
<jam-laptop> lifeless:
<jam-laptop> ^^
<jam-laptop> come to think of it, I haven't seen LarstiQ in a while
<jam-laptop> ryanakca: it sounds like your bundle was munged
<jam-laptop> and it is trying to ensure that the bundle you merge is the same as the patch you see
<jam-laptop> (so that you don't look at the preview and approve that, but the actual merge merges something else)
<jam-laptop> ryanakca: so it is *possible* that you could just edit the bundle to change the lines back to what it thinks they should be.
<jam-laptop> (if they are now spaces, try making them tabs, etc)
<ryanakca> Aha... I see.
<ryanakca> jam-laptop: recreating the bundle fixed it... methinks it has something to do with copy-pasting.
<jam-laptop> that would do it
<jam-laptop> if it had tabs in it
<jam-laptop> and you copy pasted it from a terminal
<jam-laptop> that would probably turn it into spaces
<jam-laptop> bzr send -o foo.patch is your friend :)
<jam-laptop> (As would be bzr send --mail-to=joe@foo.com)
<ryanakca> :)
<ryanakca> Or just a plain old wget (since the bzr branch is in /var/www ) :D
<ryanakca> jam-laptop: thanks!
<jam-laptop> ryanakca: no problem
<lifeless> ryanakca: well, if the branch is wgettable, just 'bzr merge' :)
<lifeless> laters
<ryanakca> lifeless: oh yeah, hehe :)
<gotgenes> I can't connect to my server's svn repo using bzr-svn because it's through https with a self-signed certificate. Is there a workaround?
#bzr 2007-10-20
<vila> gotgenes: did you look at bug #141105 ?
<ubotu> Launchpad bug 141105 in bzr "Crash with authenticated https checkout" [High,Fix released] https://launchpad.net/bugs/141105
<gotgenes> bzr: ERROR: Unsupported protocol for url "svn+https://gotgenes.com/svn/csbs/trunk"
<gotgenes> hmm, but I should have bzr-svn installed, it's under /usr/local
<gotgenes> any ideas?
<gotgenes> right, I suppose I didn't install the plugin properly, considering the README says to just copy the directory as ~/.bazaar/plugins/svn
 * gotgenes sighs
<ubotu> New bug: #154670 in bzr "bzr can delete a user's working directory, resulting in subsequent errors" [Undecided,New] https://launchpad.net/bugs/154670
<thumper> pinging poolie or spiv or lifeless
<fullermd> Oh my!
<spiv> thumper: pong
<thumper> spiv: call?
<thumper> it'll be quick
<spiv> thumper: you can try my mobile.  Not sure how good the reception will be... (I'm at my parents' place, it has iffy internet and iffy phone coverage)
<thumper> spiv: :)
<spiv> thumper: irc is fine too ;)
<fullermd> Communication is always difficult across generations   :p
<lifeless> thumper: yo
<thumper> lifeless: hi
<lifeless> whats up?
<thumper> lifeless: mostly sorted now
<thumper> spiv has sorted it out
<lifeless> ok
<lifeless> ciao
<thumper> bye
<thumper> spiv: see privmsg
<thumper> spiv: ping
<thumper> spiv: ^^^
 * thumper does it all incase there are special ping rules...
<fullermd> OK, so is the "xyz inconsistent parents" line that just showed up in check to do with that reconcile thing that's been going around?
<thumper> fullermd: I think so
<thumper> fullermd: you'd know (I think) - how do I apply a bundle?
<thumper> say one that is attached to an email
<fullermd> 'pull' or 'merge' should eat it.
<lifeless> thumper: save hte mail to disk, bzr merge filenameofmail
<fullermd> lifeless: Should I be expecting rather large number of those 'inconsistent parents'?  I've got, like, twice as many as I have revisions...
<lifeless> thumper: well you can have many per revision
<lifeless> wel
<lifeless> fullermd: ^
<lifeless> sorry thumper didn't mean you
<fullermd> Well, I thought they were fallout from really old versions.  All the revs here are fairly young (post-0.16, mostly post-0.18)
<weigon_> hmm, I'm missing a piece here:
<weigon_> $ bzr pull
<weigon_> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<weigon_> $ bzr merge
<weigon_> ... (patches)
<weigon_> $ bzr status
<weigon_> ...
<weigon_> pending merges:
<weigon_>   Jan Kneschke 2007-10-20 fixed test-case to start the field-indexing at 1 instead of 0
<weigon_> how can I use the old commit msg as new commit msg ?
<weigon_> "$ bzr commit" asks me for a new one
<Peng> I guess you'd just have to copy and paste it.
<Peng> Usually people use a message like "Merged <branch>".
<Peng> You don't really need to repeat the message -- 'bzr log' will show it.
<weigon_> *doh* now that I see it
<weigon_> I assumed there would be a obvious thing I missed :)
<weigon_> jelmer: where do you want to have bugs reported to for bzr-svn ?
<jelmer> weigon_: on launchpad please, https://launchpad.net/bzr-svn
<weigon_> -> bzr: ERROR: libsvn._core.SubversionException: ("File already exists: filesystem '/svnroot/mysql-proxy/db', transaction '265-1', path '/trunk/tests/suite/base/r/query_analizer1.result'", 160020)
<jelmer> weigon_: please report that on launchpad :-)
<jelmer> weigon_: This was during a push?
<weigon_> jelmer: yes
<weigon_> jelmer: it was a mixed merge + files added
<weigon_> a partial commit failed with:
<weigon_> $ bzr commit lib/proxy/strict.lua lib/proxy/Makefile.am
<weigon_> bzr: ERROR: Selected-file commit of merges is not supported yet: files trunk/lib/proxy/strict.lua, trunk/lib/proxy/Makefile.am
<weigon_> so I tried to commit and push everything afterwards
<jelmer> weigon_: ah, ok
<jelmer> weigon_: I'm actually working on that bug right now
<weigon_> I run 0.91 + bzr-svn 0.4-bzr right now
<weigon_> just tell me and I'll test it
<jelmer> this is bug 145148
<ubotu> Launchpad bug 145148 in bzr-svn "svn and bzr-svn clash on commit" [Medium,Triaged] https://launchpad.net/bugs/145148
<jelmer> weigon_: ok
<weigon_> this is my paste http://p.caboo.se/109159
<weigon_> I tried to register on launchpad, but it didn't seem to like my mailhost
<jelmer> weigon_: thanks - that does indeed look like bug 145148
<ubotu> Launchpad bug 145148 in bzr-svn "svn and bzr-svn clash on commit" [Medium,Triaged] https://launchpad.net/bugs/145148
<danigm> hi all again, yesterday I send a question about the distributed development, and the push. dato, ana` says me that you'll respond me, but I go before. Can you help me??
<dato> oh well.
<Lo-lan-do> jelmer: Is bug #145148 the same as Debian #444775, do you think?
<ubotu> Launchpad bug 145148 in bzr-svn "svn and bzr-svn clash on commit" [Medium,Triaged] https://launchpad.net/bugs/145148
<ubotu> Debian bug 444775 in bzr-svn "bzr-svn: Can't push to SVN when a file has been created there" [Normal,Open] http://bugs.debian.org/444775
<Lo-lan-do> (If so, I'll mark the latter as forwarded to the former)
<jelmer> re
<jelmer> Lo-lan-do: I think so, but I'm not 100% sure
<jelmer> should have a fix soon
<Lo-lan-do> The backtraces look remarkably similar in structure
<Lo-lan-do> Mine has several calls of _dir_process, but I suspect that's because I'm seeing the bug on a file that's not in the top-level directory, contrary to the test case.
<jelmer> yeah, indeed
<jelmer> yours is a little bit more complex though - because of the messing around with the property contents
<Lo-lan-do> Ah yes, I had forgotten about that.
<jelmer> weigon_: can you please try again?
<schierbeck> hello lads
<schierbeck> jelmer: ping?
<jelmer> schierbeck, pong!
<schierbeck> hehe
<schierbeck> so, i'm trying to pull the treeview out of branchwin
<schierbeck> do you have an opinion on what the base class of the new widget should be?
<schierbeck> i'm thinking either just the treeview, the scrollwindow surrounding it, or an entirely new widget
<schierbeck> with a new widget, we could have more control of what signals were sent, and simplify the interface
<jelmer> re
<jelmer> schierbeck: ... and perhaps embed it in new places
<schierbeck> jelmer: well, we could do that with a scrollwin, too
<schierbeck> i'd just like to keep the interface as simple as possible
<jelmer> schierbeck: yeah, agreed
<schierbeck> it's possible to add your own signals, right?
<jelmer> schierbeck: yeah
<schierbeck> okay
<schierbeck> i'll work on it a bit
<jelmer> schierbeck: either treeview or scrollwindow as base class sounds fine
<schierbeck> i'll start with scrollwin -- if we need more encapsulation we can always change that later
<lifeless> moin
<nekohayo> hi folks, I have a basic VCS question. Between two revisions, only the changes are saved right?
<nekohayo> for example, if I have a repository that is very heavy in filesize, it will not be duplicated?
<lifeless> nekohayo: yes, bzr delta-compresses the repository
<lifeless> nekohayo: though conceptually we work with full texts
<schierbeck> jelmer: ping
<jelmer> schierbeck, pong
<schierbeck> :)
<schierbeck> okay, it seems to be working now
<schierbeck> i started off conservatively
<schierbeck> wanna have a look?
<schierbeck> http://bazaar.launchpad.net/~dasch/bzr-gtk/treeview
#bzr 2007-10-21
<lifeless> -
<lifeless> hi AfC
<lifeless> did you get the laptop ?
<AfC> lifeless: yes we did.
<lifeless> does it work well ?
<AfC> It's going mostly well, although get this: a livecd boots it almost no problem, but when I tried my tried and true kernel from *my* laptop, the SATA disks don't come up
<AfC> {sigh}
<lifeless> :(
<lifeless> You still running gentoo ?
<AfC> lifeless: yeah
<AfC> lifeless: The UK guys just helped me out
<AfC> It turns out its a regression in newer kernels
<AfC> the newer SATA code causes the old IDE code (present for cdrom) to knock out the bus or whatever
<lifeless> ouch
<AfC> (the really misleading thing was that it *worked* in the livecd's 2.6.19, but failed in my transplanted 2.6.22)
<weigon_> jelmer: would the 0.4-tree work against 0.91 ?
<weigon_> jelmer: or do I have to upgrade to bzr 0.92-bzr too ?
<jelmer> weigon_, no, only 0.92 at this point
<jelmer> (bzr.dev0
<lifeless> okies, I'm off to yum cha
<lifeless> laterz
<bagueros> please help!!!!!!!!!!!! my friend did a normal commit to bzr, it gave him a permission denied error, and then ERASED all of his files that were changed
<bagueros> so we lost all these files with all these changes
<bagueros> where did they go?!
<beuno> bagueros, a commit shouldn't erase any files
<beuno> are you sure he just did a commit?
<bagueros> yes
<bagueros> positive
<bagueros> it didnt erase them
<bagueros> it replaced them with older versions
<bagueros> and got rid of all the new chnages
<beuno> bagueros, have him execute:    bzr status
<beuno> and let's see what's the current state
<beuno> (commit shouldn't modify the working tree at all)
<bagueros> it shows a list of modified files when i do bzr status
<bagueros> one of the files is one that got overwritten with a previous version
<bagueros> but other files that happened to arent on there
<beuno> bagueros, and does "bzr log" output the revision you commited?
<bagueros> bzr log doesnt show any of this
<bagueros> last thing it shows is a commit from yesterday
<beuno> bagueros, I'd recommend first to duplicate the folder, so we can try and work with a copy and don't risk loosing more information
<beuno> then, I'd try   bzr revert
<beuno> and see if that leaves the version you want
<beuno> and if you could paste somewhere the output of the error, that would help
 * beuno goes to eat something
<ubotu> New bug: #155281 in bzr "bzr diff causes exception (cannot load dispatch table from expat)" [Undecided,New] https://launchpad.net/bugs/155281
<lifeless> hmm interesting bug there
<weigon__> jelmer: with (v0.4) r742 I stuff have the clash. Keep in mind that I already have my changes committed and only want to push
<weigon__> SubversionException: ("File already exists: filesystem '/.../mysql-proxy/db', transaction '265-1', path '/trunk/tests/suite/base/r/query_analizer1.result'", 160020)
<jelmer> weigon: this is part of a series of commits you're trying to push?
<jelmer> weigon: if so, one of the earlier commits was probably not pushed right
<weigon> the file was committed with SVN to that tree already. I merged it to the local tree, adjusted it and wanted to push it back again
<jelmer> weigon: right, but was the push already halfway finished when the error occurred?
<jelmer> (will "svn log" show any revisions that originated from bzr?)
<jelmer> LarstiQ: hi!
<jelmer> LarstiQ: what's the status on nested trees?
<weigon> jelmer: r265 is the same in svn log and bzr log, r266 is the faulty one
<weigon> nothing of the stuff I want to commit seems to appear in the svn log
<weigon> "$ bzr missing" shows only the r266
<weigon> how can I provide more (and useful) information
<jelmer> is this a public project? if so, the bzr branch you're trying to push and an svndump of the repository would help
<jelmer> otherwise, the current "bzr log --show-ids" (for the last few revisions) and "svn log -v"
<weigon> jelm.. http://p.caboo.se/109322
<weigon> jelmer: http://p.caboo.se/109322
<jelmer> weigon: thanks
<jelmer> weigon: it looks indeed like it pushed r265 incorrectly and now anything on top of that breaks as well
<weigon> how can I get it corrected ?
<jelmer> redoing the commits in a new branch (perhaps using "bzr rebase")
<jelmer> weigon: I'll be back in a few hours
<GaryvdM> jelmer: Hi
<jelmer> GaryvdM: Hi!
<GaryvdM> http://145.97.196.157:8089/request/%3C1192969205.16037.4.camel%40dasch.egmont-kol.dk%3E has been approved, but has not been merged
<GaryvdM> Is there a log or something that I can look at to see why?
<jelmer> Thanks, I'll merge it
<GaryvdM> Is it not automatic?
<jelmer> No, it will be (once the pqm is set up)
<GaryvdM> Oh - ok I thought it was
<jelmer> GaryvdM, merged now
<GaryvdM> Cool
<lifeless> ight
<lifeless> night
<Edulix> what's the best way to install bzr-svn 0.4.2 in ubuntu?
<Edulix> I see no deb package...
<Edulix>  I get this http://pastebin.ca/744429
<Edulix> can anyone please enlighten me?
<kiko> hey there
<kiko> lifeless?
 * Edulix is still alive
<dato> 15:28 <lifeless> night
<Edulix> oh
<Edulix> :P
<Edulix> my bzr is the one without life
<kiko> no, I can't branch from launchpad either
<weigon> Edulix: just place it (or a symlink) in ~/.bazaar/plugins/
<weigon> Edulix: I run it directly from the branched bzr-svn tree locally
<Edulix> well I've noticed that my problem is not with bzr-svn
<ubotu> New bug: #155398 in bzr-eclipse "refresh log window after pull/commit" [Undecided,New] https://launchpad.net/bugs/155398
<jelmer> Edulix, see https://bugs.launchpad.net/bzr/+bug/141105
<ubotu> Launchpad bug 141105 in bzr "Crash with authenticated https checkout" [High,Fix released]
<jelmer> hi weigon
<jelmer> weigon, any luck getting you branch fixed?
<Edulix> jelmer: I've seen it, but that's when using bzr-svn and I'm not using it Â¿?
<jelmer> Edulix, no, that's not specific to bzr-svn
<jelmer> Edulix: for bzr-svn there is a workaround
<jelmer> for other situations I'm not sure
<Edulix> ok
<Edulix> I refered to that bug in the email I've sent to bazaar@lists.ubuntu.com
<jelmer> Edulix, that bug has been fixed in bzr.dev, the fix will be in 0.92
<schierbeck> jelmer: hello
<jelmer> hi schierbeck
<jelmer> schierbeck, sorry for not responding yesterday
<schierbeck> oh, no problem
<jelmer> schierbeck, I hadn't seen your messages until about an hour later
<schierbeck> :)
<schierbeck> i've worked some more on the viz -- i think it's pretty good now
<jelmer> cool
<jelmer> I would still very much like to see some sort of switch to turn off the brokenlines behaviour
<schierbeck> i think we should wait until the revision history view (the treeview part) is completely encapsulated
<schierbeck> preferable in its own package
<schierbeck> or whatever the python term is
<jelmer> schierbeck, ok
<mdke> hi there. can bzr-svn be used for importing svn repositories and creating bzr branches from them?
<mdke> ah, jelmer, my lucky day
<jelmer> schierbeck, I think we should hold off releasing until that is fixed though
<jelmer> mdke, hi
<jelmer> mdke, yes
<jelmer> mdke, importing all branches in a repository can be done using the 'svn-import' command
<mdke> jelmer: I'm looking to import different svn branches in a repository to different bzr branches. I've started doing "bzr branch local/path/to/svn/checkout"
<mdke> is that the right sort of thing?
<jelmer> mdke, yes, that's what it does
<mdke> rock
<mdke> and is this better than using svn2bzr?
<schierbeck> jelmer: that's okay with me
<jelmer> mdke: same thing, different codebase
<AnMaster> how do I roll back a merge, that is I did merge now I want to revert it, I haven't commited it yet
<AnMaster> so revert files and remove list of pending merges from bzr st
<schierbeck> jelmer: i'll see if i can get it fixed
<jelmer> AnMaster: bzr revert
<mdke> jelmer: ok, fine. After the above command can I just push straight to Launchpad, or is there an intermediate stage required?
<AnMaster> jelmer, doesn't remove the pending merges list though
<AnMaster> I tried it
<AnMaster> it does revert the files
<jelmer> AnMaster: bzr revert without any arguments
<AnMaster> jelmer, ah ok thanks
<jelmer> mdke: yes, the created branches should just be like any other bzr branch
<mdke> jelmer: lovely. Thanks a lot for working on that tool
<schierbeck> jelmer: okay, i've sent in another merge request, this time removing duplicate window logic
<schierbeck> when that's merged into mainline i'll sort out the other issue
<jelmer> schierbeck: cool, thanks
<schierbeck> np
<Edulix> jelmer: is there any deb package with the bug fixed?
<weigon_> jelmer: let me branch and try again
<weigon_> jelmer: hmm, I use a shared repo containing 2 branches branched from the bzr-svn branch
<lifeless> moin
<weigon_> *hmm* wait. looks that I don't get what rebase is all about
<weigon_> jelmer: if I rebase to another (new) branch, shouldn't the bzr info show me the new "parent" location ?
<lifeless> abentley: ping
<abentley> lifeless: pong
<lifeless> hi
<lifeless> I have a neighbour with a loud car that left at 5:30 this morning. Blech.
<lifeless> So I'm working on graph query rate
<lifeless> To fix the key bug, I'm changing the _search_revisions set to a dict
<lifeless> which maps key:keys_that_reached_key
<lifeless> This doesn't help find_seen_revisions, but it makes it possible for stop_searching_any() to take points that are not the tip
<abentley> What do you mean by tip?
<lifeless> thus a question for you - do you think it is ok to allow stop_searching_any to be expanded to 'stops searching any revisions that the searcher is or has examined
<lifeless> oh, the tips of the search, _search_revisions.keys() in my new code; _search_revisions in bzr.dev.
<abentley> It was not able to take them before?
<lifeless> indeed
<lifeless> heads() currently does a find_seen_revisions() call
<lifeless> which does a new graph search to calculate them
<abentley> Are you sure it had to use tip revisions before?  That seems entirely useless.
<lifeless> its the second last function in graph.py
<lifeless> and its 3 lines long; please feel free to check I'm reading it right :)
<lifeless> You can pass it more than the current search tips, but it doesn't stop search if it had seen something you pass unless it is a search tip.
<lifeless> the other thing I wanted to run past you
<lifeless> is either changing get_parents, or adding a get_parents_dict/get_parents_2 which returns the key it was looking up as part of the answer, rather than being purely positional, so callers don't have to izip() things back together again
<lifeless> e.g. it could return [(key, parents), (key, parents), ...]
<lifeless> or {key:parents, key2:parents, ...} which is easier to use but slightly more expensive to create
<abentley> Stop searching any will stop searching any of the specified revisions that are still being searched.
<abentley> So you want to change it so that you can pass in an ancestor of a revision being searched, yet stop that revision from being searched?
<lifeless> yes
<lifeless> for those ancestors this search has seen only
<abentley> Well, I made a guess about the time/space tradeoff there.  It's possible the guess was wrong.
<abentley> I'm just very aware that if you track reachability, it's easy to scale with the square of the number of nodes.
<lifeless> right
<lifeless> at the moment we have nodes^2 repeated queries
<lifeless> and I want to change that to nodes^2 obj references in sets
<abentley> Isn't it better to be slow than to run out of memory?
<lifeless> its better to be slow when you run out of memory
<lifeless> let me just do some quick math
<lifeless> I expect that for a 50,0000 rev square graph, which peaks at 25,000 search tips this will hold a depth of 223 revisions per tip
<lifeless> if each was a straight line, this is 20MB
<lifeless> erm, mistake, brb
<lifeless> 50K nodes
<lifeless> if thats in a square, which is the worst case for traversing non-manually generate graphs
<lifeless> (it can fan out faster, it can't join faster)
<lifeless> then we'll have 224 active search tips at the widest point of the square
<lifeless> with an area of 25K-224 or 24.7K nodes each
<lifeless> or 5.5Million items in sets
<lifeless> all the content is shared key values
<lifeless> so the overhead is just the set overhead
<abentley> I.e. the length of revision-ids is irrelevant.
<lifeless> >>> for y in xrange(224):
<lifeless> ...   for x in xrange(25000-224):
<lifeless> ...     sets.setdefault(y, set()).add("%d" %x)
<abentley> Bazaar has 2.9 K nodes, so 50K isn't a very high number.
<lifeless> this will setup a toy of that scenario
<lifeless> 844m is the result for that. heh.
<lifeless> but it may not have shared nodes. doing it again
<abentley> Actually, Bazaar's graph has 14 K nodes.
<lifeless> >>> keys = {}
<lifeless> >>> for x in xrange(25000-224):
<lifeless> ...   keys[x] = "%d" % x
<lifeless> ...
<lifeless> >>> sets = {}
<lifeless> >>> for y in xrange(22):
<lifeless> ...   sets[y] = set()
<lifeless> ...   for x in xrange(25000-224):
<lifeless> ...     sets[y].add(keys[x])
<lifeless> ...
<lifeless> 31369 robertc   15   0 75632  53m 2080 S    0  2.7   0:01.05 python
<lifeless> this is on a 64-bit machine
<lifeless> so I'd expect that to be half on a 32-bit machine
<abentley> So I would think that we should be aiming at more like 5M nodes.
<lifeless> startup of python on its own
<lifeless> 31376 robertc   16   0 24812 3836 2080 S    0  0.2   0:00.02 python
<lifeless> ok, let me see
<lifeless> thats 2237 across the middle
<lifeless> and 2500000 in the paths worst case
<lifeless> 31376 robertc   16   0  107m  39m 4148 S    0  2.0   0:00.67 python
<lifeless> thats the size to hold the keys
<lifeless> now adding the sets
<kiko> vila, lifeless: ping?
<kiko> lifeless, why is bzr branch lp:python failing?
<lifeless> hmm?
<kiko> bzr: ERROR: pycurl.error: (60, 'server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt')
<kiko> is it a pebcak?
<lifeless> you don't have the lp certificate installed for pcurl
<kiko> lifeless, when did this change? it did work at some point
<kiko> did we start using pycurl under the covers?
<kiko> lifeless, also, the lp certificate isn't self-signed
<lifeless> we've used pycurl for ages
<lifeless> but its optional
<kiko> so what has changed?
<lifeless> you can remove it at it will use httplib
<kiko> hmmm
<lifeless> I don't know the answer to your question
<kiko> is it on by default on gutsy maybe?
<lifeless> yes
<kiko> and it wasn't the default in feisty, perhaps?
<lifeless> it was recommended in feisty too
<kiko> odd.
<kiko> I had never seem a complaint, and today I've seen quite a few
<lifeless> so
<lifeless> I don't know why the validation is failing
<lifeless> it may be you don't have the right ca roots available ?
<lifeless> abentley: ok, I killed that a 2mumble gig
<kiko> it's weird, I agree, but I shouldn't need to do anything to get it to work, I expect
<kiko> so uninstalling pycurl would be a workaround for a problem I don't yet know of
<lifeless> yes
<lifeless> the only difference for us, in 0.91 is that httplib doesn't do cert validation
<kiko> aha
<kiko> I don't have the ca-certificates file
<kiko> lifeless, do you have one?
<kiko> /etc/ssl/certs/ca-certificates.crt?
<lifeless> no
<kiko> hmmmmm
<lifeless> this is a clean install of gutsy
<lifeless> let me check fisty
<lifeless> I have one on fisty
<kiko> this is highly suspicious
<lifeless> I am not aware of creating one by hand
<kiko> me neither
<kiko> hmmm
<kiko> lifeless, "bzr branch lp:python" doesn't work for you either right?
<lifeless> dpkg -S that file reports nothing
<lifeless> so its not package owned
<kiko> same here
<lifeless> (on fisty, where the file exists)
<kiko> hmmmmmmm
<lifeless> bzr: ERROR: Connection error: curl connection error (problem with the SSL CA cert (path? access rights?))
<kiko> hmmmmm
<kiko> does it work on feisty?
<lifeless> waiting for it to tell me :)
<kiko> heh
<lifeless> looks like it, link is saturating
<kiko> odd.
<kiko> update-ca-certificates
<lifeless> yeah working on feisty
<kiko> it doesn't work on /my/ feisty box
<kiko> so it's definitely related to the presence of that file (as the error message does point out kindly)
<lifeless> abentley: so, looks like my smallest-approach fix, while it will work for all our current users, will blow up nicely on 500K revision scenarios.
<abentley> Hmm.  It seems like it should be possible to combine the two approaches: only list some revisions in the reachability index, and then do a breadth search on those.
<abentley> That would allow us a fixed size for the reachability index, and mean that we'd trade speed for size as we exceeded that.
<lifeless> I've just instrumented next()  alittle
<lifeless> highest figure I'm seeing with bzr is 120 on a merge commit so far
<lifeless> 200
<lifeless> I agree that some tradeoff is reachable
<lifeless> this is a cache thrashing nightmare though
<lifeless> an interesting observation or two
<lifeless> one is that for a given breadth first search, many of the revisions in each search tip should be common
<jelmer> Edulix: of bzr? not yet
<jelmer> weigon_, no, rebase won't change the parent location
<lifeless> a bit array would be useful
<weigon_> jelmer: but the idea was that I do branch from the svn-tree again and throw the old branch away, right ?
<weigon_> I don't see the full picture yet to get it all running smooth again
<jelmer> weigon_: if you can do that, there's no need for rebase
<jelmer> simply rebuild your branch and then push it again
<weigon_> I have svn -> (local) svn-bzr for pushing -> 2 bzr branches for development
<weigon_> the svn-tree itself is remote and not under my control. The svn-bzr one and the other local bzr trees are
<weigon_> I can throw the svn-bzr tree away and run bzr branch svn+ssh://... again, no problem
<jelmer> the 2 bzr branches are based on the svn-bzr one I guess?
<weigon_> yep
<jelmer> and the svn-bzr one is up to date with svn?
<abentley> lifeless: I think my reasoning for the get_parents return value was that it handled ghosts clearly.
<weigon_> currently it is the one I can't push back from
<abentley> If you query about a ghost, you'll get None back in the corresponding location.
<Vantage13> is there a way in bzr to switch your current working tree to another branch w/o creating a new directory to keep the two branches in?
<weigon_> so it is up to date (bzr pull), but not pushable
<jelmer> weigon_: you may be able to run 'bzr rebase <svn-url>' to fix the local branch
<abentley> Returning a dictionary where ghosts keys mapped to None seemed confusing, as did returning a dictionary where ghost keys were not present.
<weigon_> on the bzr-svn'ed branch ?
<jelmer> weigon_: you may have to get rid of r265 though, and that would mean having to recommit r265 and all revisions that followed it..
<jelmer> weigon_: yes
<Edulix> does bzr branch https://launchpad.net/dark-extermination works for you? I get "bzr: ERROR: Connection error: curl connection error (problem with the SSL CA cert (path? access rights?))"
<jelmer> weigon_: bzr-rebase 0.2 (or the current version in bzr)
<Edulix> i'm using bzr.dev by the way
<weigon_> jelmer: I run trunk
<jelmer> weigon_: ok, that should be fine
<weigon_> I usually just symlink the bzr'ed plugins into .bazaar/plugins/
<Edulix> (oh and that project is in revision 0, not many files to download ;))
<abentley> In principle, a different value than None could be used for this situation, and I think that would work pretty well.
<weigon_> jelmer: bzr: ERROR: Already rebased on SvnBranch('svn+ssh://... isn't that expected ?
<jelmer> weigon_: yeah, kinda :-/
<weigon_> let me trash the svn-bzr tree and check it out again
<jelmer> weigon_: looks like you'll have to get rid of r265 by recommitting r265 and all revisions that followed it
<hmeland> Vantage13: You want "bzr switch", but I think that assumes you are working with lightweight checkouts.
<weigon_> jelmer: no problem
<jelmer> weigon_: in the svn-bzr tree and the bzr trees
<Vantage13> hmeland: thanks
<weigon_> jelmer: getting rid of == uncommit ?
<jelmer> weigon_, yes, that should be sufficient
<lifeless> abentley: I can see some callers caring; doing a dict with key:None, or tuples (key, None) will also handle that.
<lifeless> I don't think a dict mapping to None is any more or less confusing than None as a positional return value
<lifeless> I'm going to go draw on the whiteboard for a bit
<Vantage13> Workflow question.  Let's say I'm a developer working on multiple features for a release of a projects.  So I make a branch of our most recent version to record my changes that will go into the next release.  Now let's say I've got 5 features I'm adding.  I get them done, commit them all locally, but then let's say a feature gets pulled.  Is there a way to identify code belonging to a feature so that it can be easily added/removed without creating a b
<lifeless> abentley: I think I have a good answer no
<lifeless> *now*
<lifeless> abentley: heads() is basically defined as 'find what is reachable from each other'
<lifeless> so rather than a breadth first searcher, I propose a class that is able to answer reachability efficiently, and a single breadth first search across all nodes at once
<lifeless> which search needs to give all the parent data back to update this reachability answering class
<lifeless> for answering reachability, one answer is to cache the key:parent answers as we get them
<lifeless> and I'll do this in the initial refactoring, which will make knits and packs the same speed here, if we cache that in the repository state or somewhere.
<lifeless> I'll then move onto a more complex answer, which is to turn 'reachable' into a range query
<mdke> if bzr-svn breaks in the middle, is there a way to carry on where it left off, rather than starting from scratch? it takes rather a long time...
<abentley> lifeless: That sounds good.
<lifeless> where a key X is reachable from Y, if X is > y0 and <y1
<jelmer> mdke: just running the same command again should make it continue
<lifeless> so we start with a forest of range structures, and then as nodes find each other we join them
<mdke> jelmer: I'll try again, it didn't seem to work last time
<jelmer> mdke, what version of bzr-svn are you using?
<abentley> I don't know what y0 and y1 are.
<lifeless> oh
<lifeless> in a range query solution each key is in the vector twice
<lifeless> a low value and a high value
<mdke> jelmer: whatever is in gutsy
<lifeless> I think it becomes 2N times, where N is the number of branches made from it actually. I'm still sketching this specific bit.
<mdke> or, to be precise, 0.4.1-14
<lifeless> anyhow, I'll start with the suppport refactoring first.
<mdke> cough. 0.4.1-1
<jelmer> mdke: what exactly doesn't work? It starts over?
<mdke> seemed to, yeah. I'll just try it again
<mdke> jelmer: now it says that there is a lock
<jelmer> mdke: try running 'bzr break-lock' on the bzr repository
<mdke> jelmer: it hasn't returned me to the prompt yet, should I wait?
<lifeless> abentley: its simple to describe for trees, so I'll do so. Do you know what an Euler tour is ?
<jelmer> mdke: 0.4.1 is not the latest, but I don't think there's any bugs fixed wrt svn-import since
<jelmer> mdke: yes
<mdke> ok, waiting
<weigon> jelmer: looks like I'm fine now
<jelmer> cool
<jelmer> it pushed ok?
<weigon> I uncommitted and now have to reapply the patch
<weigon> should be fine now
<weigon> but first I'll upgrade to 7.10 :)
<weigon> after the uncommit the push was empty (as expected)
<lifeless> abentley: anyhow, an euler tour is the record of the nodes a depth first search goes to
<lifeless> so for A:[] its 'A->A'
<lifeless> for A:[B], B:[], its 'A->B->A'
<lifeless> A:[B,C], B:[C], C:[] its 'A->B->C->B->A->C->A'
<lifeless> (this is a slightly modified tour'
<mdke> jelmer: hmm. perhaps it is carrying on. It says "copying revisions" and it started at 1/x but x is a lower number than it was when I ran the thing before.
<lifeless> anyhow, if you put the keys in an array: [A,B,C,B,A,C,A] and index into that from the keys: A:[0,4,6], B:[1,2], C:[2,5]
<lifeless> we need to annotate this data a little more, because this double-entry is what I'm thinking about still
<lifeless> but in principle, C is reachable from B because 2>1 and 2<3
<lifeless> (the B list there should be B:[1,3]
<mdke> jelmer: oh dear, now a backtrace :(
<mdke> I'll try and get a dump of the repository and do it on that rather than doing it from the remote server
<jelmer> mdke: yes, that's the way it continues
<jelmer> mdke, can you paste it somewhere?
<jelmer> that'll use the same logic
<mdke> jelmer: I can't paste it right now, I can't seem to scroll up in my terminal, and it's past my bedtime. I'll try running it overnight, but I might end up asking the LP guys to do the import for me if I struggle...
<mdke> jelmer: thanks for all your help so far
<jelmer> k
<jelmer> goodnight :-)
<mdke> night
<jelmer> mdke: in either case, I would be interested in seeing the backtrace
<jelmer> I don't think there are any listed pull bugs in bzr-svn at the moment
<igc> morning
<lifeless> abentley: and I know know why we access to much history
<lifeless> abentley: you stop searching a node (and its children) when all searches reach a node; this is wrong. We should stop considering a search *relevant* when we reach it from all start points, but we have to keep reading it to avoid hitting all history
<lifeless> consider:
<lifeless> A:[CD], B:[D], C:[E], D:[E]
<lifeless> first round lookup gives D in common
<lifeless> but if we dont get D's parents, we'll follow E all the way to the origin
<abentley> Well, I knew it was wrong in terms of giving inaccurate results, but I didn't realize it would also cause this problem.
<abentley> But which algorithm are we talking about?
<abentley> Or which method specifically?
<lifeless> heads()
<lifeless> the results are accurate
<lifeless> but it accesses too much data
<lifeless> in the current code; stop_searching_any() is the culprit
<lifeless> it should remove the nodes given as reasons to continue searching
<lifeless> but it should not remove them from things to continue querying
#bzr 2008-10-13
<jonoxer> http://pastebin.com/d3b0caad4
<jonoxer> I've seen references to a couple of other tools that specifically do repo conversion, but not found the scripts themselves (docs point to defunct pages, etc)
<lifeless> 32 or 64 bit python build ?
<jonoxer> 32
<lifeless> ok
<jonoxer> Aha, I hadn't thought of that
<lifeless> so, it physically can't fill swap to run out of memory
<lifeless> it could be
<lifeless> a) some form of fragmentation; in which case continuing from where it left off may work
<lifeless> b) a single object too big to handle (we currently require any single text to be < ~1/3 usable memory)
<jonoxer> Mmm, I'll give it a try on a 64 bit machine
<lifeless> c) a bug
<jonoxer> It'll take half the day to find out if that helps though!
<lifeless> jonoxer: I'd try continuing in the first instance
<lifeless> jonoxer: did you run 'bzr branch' ?
<lifeless> jonoxer: if so, cd to the output dir, run 'bzr reconfigure --branch', then 'bzr pull svn://.....'
<jonoxer> lifeless: problem is I don't know what commit it failed on. The progress bar vanishes when it does the traceback, and unless I was looking at that exact moment I wouldn't know. Is there a way to find out?
<lifeless> jonoxer: you don't need to know :P
<jonoxer> Ahh, I see
<lifeless> thats the sort of housekeeping bzr is meant to do for you
<Peng_> In the future, you could also set up a loop to pull, say, 1000 revisions at a time.
<jonoxer> Woot! It started again, and thinks it only has 8435 revs to pull, so it must be going from the point it died. Thanks lifeless
<jonoxer> Peng_: good idea
<spiv> jonoxer: if you're not already doing so, you could try running the latest bzr-svn release.  I think some major memory leaks have been fixed.
<spiv> jonoxer: did you figure out your problem from Friday?  (file permissions?)
<Peng_> That's right. (The leaks were more svn's fault than bzr-svn's, but in any case, the situation has been improved with svn 1.5 or the latest bzr-svn release.)
<jonoxer> spiv: not yet, the sftp error was a good clue but I was away in Sydney on the weekend shooting a new TV show (lots of fun) and just got home at 1am today, so I haven't had a chance to try again yet
<lifeless> poolie: you've marked 282402 as invalid; I don't think its invalid - its just a faulty try:finally: rather than a try:finally:except: block on WT.commit.
<poolie> bug 282402
<ubottu> Launchpad bug 282402 in bzr "bzr losing track of file in aborted commit of rename" [Undecided,Invalid] https://launchpad.net/bugs/282402
<lifeless> poolie: this may have contributed to other commit bugs, where exceptions damaged the dirstate
<poolie> are you sure?
<lifeless> mutabletree.py has @needs_write_lock\ndef commit(...)
<lifeless> I think that should be altered to call
<lifeless> (looking for method name)
<lifeless> uhm, I think its self._reset_data()
<lifeless> in the event of an exception
<lifeless> poolie: I am sure that we shouldn't save changes to the dirstate if the commit is cancelled; I'm reasonably sure the same applies to errors
<poolie> yes, you're right
<davidstrauss_> I have a question about the "decentralized with shared mainline" workflow. After branching, it seems like "bzr commit" would only be local, but the diagram on the workflows page shows "bzr commit" going back to the central repository.
<davidstrauss_> Is there a page with clearer documentation of the workflow?
<spiv> aaaa
<spiv> davidstrauss_: well, if the users have a checkout of the shared mainline (in addition to their other branches), then commit in that would go back to the central location.
<davidstrauss_> spiv: But what if it's a branch?
<lifeless> davidstrauss_: the point of a branch is not to flow back automatically
<davidstrauss_> http://bazaar-vcs.org/Workflows#head-ca3ccf73574776b36453b2213789731549e54167
<davidstrauss_> lifeless: yes, but what's the proper way to send your changes back from your branch to the shared mainline?
<lifeless> davidstrauss_: have a checkout of the mainline; merge your changes and commit
<lifeless> davidstrauss_: (which is exactly what a maintainer of a non-shared mainline would do, but you're able to do it yourself because its shared)
<lifeless> why does bzr.dev only have an IMPROVEMENTS section in NEWS?
<davidstrauss_> Is there a way to have Bazaar default to local commits?
<lifeless> davidstrauss_: I am going to guess that you're trying to avoid having both a branch and a checkout of the mainline
<davidstrauss_> lifeless: yes
<lifeless> davidstrauss_: probably because of disk space used/wanting to reuse build products
<davidstrauss_> lifeless: no, it's mostly an interest in limiting complexity
<lifeless> davidstrauss_: anyhow, 'bzr unbind' will temporarily convert a heavyweight checkout to a regular branch
<lifeless> just 'bzr bind' will restore the binding
<lifeless> myself, I'd use a single working tree but still have two branch objects, because its handy when offline to be able to see exactly what the mainline looked like
<davidstrauss_> lifeless: thank you. your comments really help develop my team's bazaar workflow
<lifeless> davidstrauss_: my pleasure
<davidstrauss_> lifeless: What is the process for improving this documentation on the Bazaar website?
<lifeless> davidstrauss_: I believe that that page is versioned in the bzr tree, in doc/ somewhere
<davidstrauss_> ok
<lifeless> davidstrauss_: *if* it is, then a patch to that. If its not, then edit the wiki page directly/mail the list if you are not sure you'd be improving it :>
<ferringb> lifeless: don't suppose you know what gurantees there are for revision_history()?  specifically ordering of the resultant sequence?
<lifeless> ferringb: Branch.revision_history ?
<ferringb> yep
<lifeless> ferringb: its strictly the left hand history
<ferringb> ok
<lifeless> ferringb: its a bad api to use though -
<ferringb> alternatives?
<lifeless> -Devil will report on its use
<lifeless> ferringb: Repository.get_graph()
<ferringb> guessing that's not just left hand?
<lifeless> ferringb: there are various other alternatives; what are you doing, perhaps I can be more specific :P
<ferringb> trac-bzr
<lifeless> timeline view?
<ferringb> among other things
<lifeless> so the graph object returned should have enough methods on it
<lifeless> but there are also iter_ methods on branch and repository
<ferringb> one thing I was playing with for speed reasons was pulling revision_history, finding the rev from the inventory object I get file path2id, then limiting the revs I inspect for changes via starting at that rev
<ferringb> don't suppose oyu have a specific method to recommend in that case?
<lifeless> well
<lifeless> iter_revision_deltas should be solid
<lifeless> but the basic speed problem is deep within bzrlib
<ferringb> heh.  my next question was going to be "how fast is it" ;)
<lifeless> the inventory representation is not conducive to fast delta generation
<lifeless> see log -v for instance
<lifeless> anyhow, I'm working on that at the moment, in my repository branch
<ferringb> yeah, I skanked my current code out of log -v's implementation actually
<ferringb> then got bit by the lefthand nature of revision_history
<ferringb> aside from loggerhead, any other sources you're recommend (alternatively api walkthroughs rather then docs)?
<ferringb> *you'd.  english and I are not getting along it seems
<lifeless> log -v and loggerhead are likely the most tuned things around today
<lifeless> oh
<lifeless> bzr-search too
<lifeless> bzr-search has some stuff thats ten times faster than regular bzrlib
<ferringb> delta searching, or
<lifeless> it generates multiparent deltas on every revision to determine what to index
<ferringb> denormalizes it into a cache I'm guessing
<lifeless> nope
<Peng_> Oh, you rebased the 'repository' branch?
<lifeless> Peng_: huh?
<lifeless> Peng_: don't think so, previous work was merged
<Peng_> Eh. I just pulled it (for the first time in like a year), and there are removed revisions.
<lifeless> Peng_: do you mean the revno has dropped ?
<lifeless> Peng_: if so thats just because it had run way ahead of bzr.dev's revno, and when bzr.dev merged it, and I pulled back, we're back along with bzr.dev's revnos.
<Peng_> Oh. If you pulled back from bzr.dev to it, that messes with what's on the left-hand side of the graph or whatever the term is, right?
 * Peng_ shrugs.
<lifeless> Peng_: if I had rebased you would have had a diverged-branches message
<Peng_> Oh. Right. Sorry, my mistake in using the wrong term.
<jonoxer> spiv: I've done more testing to figure out the permissions problem, and I'm stumped. Unless the repo is owned by the user doing the push it just won't work. Even with the user in the correct group and "chmod -R 775 repo" done. It's like bzr+ssh and sftp methods are ignoring group membership.
<jonoxer> I'll see if I can get any more clues
<Peng_> Isn't there an OpenSSH bug about ignoring group ownership or permissions or something?
<lifeless> jonoxer: openssh's sftp-server ignores the sticky bit
<Peng_> ...What he said.
<jonoxer> Aha, that sounds exactly like the problem
<lifeless> more specifically
<lifeless> it masks it out on chmod() calls made over the wire
<jonoxer> Any good / bad experiences with vsftpd? Any particular suggestions for an sftpd to use for a bzr repo?
<lifeless> jonoxer: bzr+ssh should work though, because sftpd isn't involved
<jonoxer> lifeless: that seems to exhibit the same problem, but I'll try again with a clean setup in case I've broken things with all my mucking around
<jonoxer> Success: starting from scratch with a clean repo and setting group write perms and the sticky bit makes bzr+ssh work for me   :-)
<jonoxer> thanks lifeless
<bob2> for an ldap account?
<jonoxer> That test used local users, I'll test now with LDAP users...
<jonoxer> ...and it works
<lifeless> my bet: sftp borked the sticky bit, then you tested bzr+ssh after and it was already broken
<jonoxer> lifeless: certainly plausible
<jonoxer> This'll work nicely anyway, since all the devs are already in LDAP
<arjenAU> jonoxer: horay!
<spiv> jonoxer: excellent
<jonoxer> To ease the svn-bzr transition I'm thinking of doing something like the discussion above with a shared mainline and personal branches. That way devs can operate the mainline the same way we currently use svn, with their branches giving the added bzr flexibility
<poolie> hm, vila has no valid gpg key?
<spiv> jonoxer: sounds good
<jonoxer> I don't want to change their workflow too much in one go so if I can swap out svn for bzr and just tell them "instead of svn commit, from now on do bzr commit" etc that's step 1. Then getting them working in personal branches and merging to mainline is step 2, etc
<poolie> hm so apparently there is no way at all to persuade gpg to trust me just a bit
<poolie> short of patching it i suppose
<lifeless> poolie: how to do you mean?
<poolie> to encrypt to an expired key
<lifeless> poolie: is it your key?
<poolie> it's vila's key
<lifeless> yah no
<lifeless> he has to update the expiry date and resign it
<poolie> he'll just have to wait til he makes a new one
<poolie> can you renew it?
<lifeless> I'm pretty sure he has to do it
<poolie> heh, 'you'!=you
<poolie> i meant, i was wondering if it's possible for the owner to renew an expired key, not would you please do it for me :)
<poolie> and yes you can > http://www.gnupg.org/gph/en/manual/c235.html#AEN328
<lifeless> oh yes, owners can
<lifeless> thats why  I said he has too :>
<lifeless> to
<poolie> you should now be able to get to kerguelen btw
<poolie> except that i have two sessions open
<jonoxer> I've started writing a little "svn to bzr without pain" guide as I work through things. It's not really about the tech aspects of moving repos, more about the process of replacing one workflow with another. Rough beginning here: http://jon.oxer.com.au/svntobzr/
<jonoxer> I'll flesh it out / fix things as I go. Maybe eventually it'll be useful to someone
<lifeless> jonoxer: cool
<jonoxer> lifeless: It might sound backwards, but I actually find it good to write docs while I'm trying to figure things out rather than later when I'm an "expert" and have too many subconscious assumptions
<lifeless> jonoxer: you only learn something once
<poolie> jonoxer: that's a great idea
<teratorn> jonoxer: no I reckon that's pretty smart... I have a theory that the people most knowledgeable about a piece of software are often the least capable of understanding what new users need in terms of documentation
<poolie> overall what are you finding good or bad so far?
<jonoxer> poolie: I haven't found anything inherently bad so far, all the badness I've experienced has been related to migration. I'm coming to BZR with a lot of baggage (mental and infrastructure) to convert
<jonoxer> The good is definitely slick branching/merging. Other things like having full local history are nice, but I haven't felt the benefits yet
<lifeless> poolie: NEWS is a little odd at the moment
<lifeless> poolie: its missing all the normal sections
<poolie> because i added a main heading but no sections?
<lifeless> yah
<lifeless> I think its likely to promote merge conflicts; and it definitely won't work with my auto editing script
<lifeless> poolie: its also very confusiong
<lifeless> poolie: because - do I use API BREAKS
<lifeless> or CHANGES
<lifeless> or INTERNALS or what
<lifeless> I don't know what the current intended sections are anymore
<poolie> they're different things
<poolie> how would having the headers help if you don't know what they mean? :-)
<lifeless> I would have a menu
<lifeless> all the headings are approximations anyhow; there was a thread about reducing them recently
<lifeless> as it is I'm grovelling through the file to find what was used 'recently' and hoping its correct
<poolie> anyhow
<poolie> API breaks are things that will break plugins (etc) currently using the api
<lifeless> poolie: uhm, I do know what an API BREAK is
<poolie> INTERNALS similar but without implying the code will break - eg when it's deprecated
<lifeless> poolie: but as far as I can tell we now call them 'api changes'
<poolie> CHANGES are things that users need to know about - fe that there's a new format or a default has changed
 * lifeless thinks poolie has missed lifeless' point
<lifeless> I know what should be included under each header
<poolie> you asked "do i use ... or what"
<lifeless> poolie: there are N headers in used through NEWS
<lifeless> and M < N that we have decided to use
<lifeless> I need to determine which of the N headers are members of M to determine the menu that I have available to categorise my change.
<lifeless> poolie: but this whole conversation is moot; I've stabbed in the dark and review can catch it. What I'd like is for us to always include all the sections when a new version is opened.
<Peng_> That is usually done.
<Peng_> It didn't always used to be, but I think it has for the last few releases.
<lifeless> Peng_: define 'it' please
<Peng_> :P
<Peng_> Including all of the sections when adding a new version to NEWS.
<lifeless> ah yes
<poolie> i'll just do it now...
<lifeless> poolie: thank you, I'd really appreciate that
<Peng_> Oh, I don't think it has always been done recently.
<Peng_> Or maybe annotate is just confused.
<lifeless> Peng_: cat -r would be the easiest way to tell
<lifeless> Peng_: annotate will be confused, because the headers are not unique
<Peng_> I was gonna use annotate to see which -r to cat.
<poolie> lifeless: i see a thread where I suggested creating the headings at the start of the release ;-)
<poolie> i don't see any discussion of which headings should be there
<poolie> um
<lifeless> poolie: cool, consider this a + 1 :P
<poolie> i just didn't do it
<lifeless> poolie: I felt the previous conversation was angsty
<lifeless> poolie: and I didn't mean for that
<poolie> agree on both counts
<poolie> anyhow..
<poolie> i think the main point of them is so that people know how far through the file they ought to read - whether they're a user, a developer, etc
<lifeless> poolie: the script I am writing, to autoupdate NEWS, can be simpler if it doesn't need to understand 'dev area' vs 'rest of file'
<lifeless> poolie: that is, if it can just look for the first matching header
<poolie> i'm saying that i do consider the ordering of headers to matter
<poolie> they shouldn't just be alphabeticalized
<lifeless> poolie: agreed, I don't think they should be either. I think the items should be alpha though
<poolie> unless of course we add numeric prefixes or something to let that work
<poolie> the items within each category, sure
<lifeless> poolie: so my intent with the script is to never create headers
<lifeless> poolie: which avoids the ordering of headers question
<poolie> would it help if i made them more verbose, like "user-visible changes"?
<lifeless> poolie: it might help readers
<poolie> will there be no headers, or will they come from somewhere else?
<lifeless> poolie: I want the headers to be seeded by the RM
<poolie> i was also thinking of helping developers know where to put their news
<poolie> ok
<lifeless> poolie: then the script just inserts items under a header
<poolie> how does the script know where to file them?
<lifeless> the items will be (section, content) tuples
<lifeless> so it just has to scan for the header matching section
<lifeless> then scan for an item that comes after content, or the end of the section
<lifeless> and insert there
<poolie> lifeless, http://paste.ubuntu.com/56894/
<lifeless> poolie: the remote change seems unrelated
<poolie> it is
<lifeless> poolie: the headers list is ok, I do feel we perhaps have too much granularity; but thats a separate discussion
<lifeless> spiv: I haven't seen your patch to usertest; is it my eyesight?
<poolie> meow
<mlh>  jonoxer: you want setgid not sticky to preserve group
<mlh> chmod g+s ...
<jonoxer> mlh: oops, yes, corrected in my local copy (along with some other things about repo creation)
<jonoxer> Thanks
<vila> hi all
<mlh> jonoxer: you may have this fxed too, but you'll need chmod -R g+wX MyRepo (note additional uppercase X meaning do x if x for user otherwise not)
<lifeless> wow
<lifeless> thats quite a difference
<lifeless> real    0m5.555s
<lifeless> real    0m3.006s
<jonoxer> mlh: that sounds reasonable. I didn't need it (AFAIK only write privs matter in the repo, other than execute on dirs of course)
<lifeless> poolie: I'm done for the day
<Peng_> What's the 5.5 -> 3.0 second difference?
<lifeless> see the list
<Peng_> Oh! Cool. Thanks.
<sabdfl> lifeless: is that split inventory work trunked?
<mwhudson> sabdfl: no
<lifeless> sabdfl: most of it isn't, its not suitable for trunk yet - still developing good answers and designs; every bit that is solid is in trunk or in review for trunk
<poolie> hey vila, sabdfl
<sabdfl> howdy
<Kamping_Kaiser> hi all. i'm using bzr 1.5 on debian lenny, and its crashing trying to branch from launchpad. coudl someone look at this ( http://paste.debian.net/19120/ )and let me know if i should be filing a bug. (i see dbus/x11 errors, so itsprobably relevent that i'm trying to use it via ssh)
<luks> Kamping_Kaiser: looks like the dbus plugin is broken, try to uninstall it
<Kamping_Kaiser> luks: i'm trying it out, i'll let you know if it works
<Kamping_Kaiser> i'll also try removing the gtk plugin
<luks> that shouldn't be necessary
<luks> just the dbus one
<Kamping_Kaiser> luks: removing the dbus plugin makes the checkout work, thanks. i'll check debians bts
<Kinnison> Anyone here use/work-on the loom plugin?
<Kamping_Kaiser> luks: thanks for the help, i'll file a bug with debian - should i also file one in launchpad?
<luks> Kamping_Kaiser: I don't know, it's likely it's already fixed in the latest version
<Kamping_Kaiser> luks: roger.
<gorgapor> although it's a know problem, can anyone suggest a workaround to the permissions issues with bazaar+sftp? right now we have a cron job going in and fixing the permissions every minute, which seems to me like an ugly hack
<bob2> is using bzr+ssh an option?
<gorgapor> well, all of our developers have ssh access to the server, is the setup on the client end any different?
<james_w> jelmer: hey, there are a few duplicates of bug 271636 coming in from apport, do you know what the issue is going to be?
<ubottu> Launchpad bug 271636 in bzr-gtk "bzr-notify crashed with TypeError in load_credits()" [Medium,Confirmed] https://launchpad.net/bugs/271636
<gour> hi, short question...how is bzr good in keeping binary files? (i'm thinking to put my wammu's with phonebook entries under vcs)
<Peng_> gour: Sure, why not?
<Peng_> gour: Remember that compressed formats like JPEG won't compress well and may delta badly, so you might waste some disk space, but it's not like anything will explode.
<arjenAU> hmm
<arjenAU> adding a tag on its own is not regarded as a change?
<arjenAU> had to to commit --unchanged to get it pushed
<jam> arjenAU: I think doing "bzr push" will push it anyway, even though it says "nothing to push"
<arjenAU> jam: look that's not shiny ;-)
<arjenAU> so I just made an empty commit for it. but that's not pretty either
<Peng_> Yeah, new tags will be pushed even if it says "Nothing to push".
<Peng_> Tags are unversioned, and pushing/pulling them is a bit messy.
<Peng_> IMO, they feel rather tacked on.
<lifeless> jam: ping
<lifeless> jam: I wonder if you saw my repository stats mail; I know you have been doing repo size analysis ..
<arjenAU> Peng_: well here's the thing. while launchpad recommends branching for a release, it's actually just as sane to tag it. thats actually how mysql used to do it with bitkeeper and it works very well. easy to find, easy to use.
<lifeless> poolie: I've stopped the usertest run that was going... 7.5G    work_root_for-bzr.inv-branchAndFix
<lifeless> I'll either have a faster fetch up today, or remove the 'inv' flavoured tool for now
<poolie> hey lifeless
<poolie> do you want to reenable the cronjob?  i put in a mutex
<lifeless> great, doing so
<lifeless> will they backlog or just exit early?
<lifeless> [crontab reenabled]
<jam> lifeless: my analysis was done by looking at the output of -Dhpss and determining how many bytes were transferred after .iix, not exactly what you are looking for
<lifeless> jam: oh! ok
<mlh> what's a PPA?
<beuno> personal package archive
<beuno> archive for .deb files
<beuno> which Launchpad provides
<mlh> thanks beuno
<beuno> :)
#bzr 2008-10-14
<lifeless> fuding
<Pieter> *funding
<lifeless> abentley: ping
<lifeless> Pieter: it was a reference to a cartoon, wherein a dog has written 'Cat fud' on the door of a tumble dryer
<jonoxer> Another noob question: how do I get a list of files changed in a commit? With svn it's something like "svnlook changed MyRepo -r 123"
<lifeless> bzr st -c revno
<lifeless> or bzr st -r x..y for arbitrary ranges
<jonoxer> lifeless: perfect, thanks!
<Pieter> how does bazaar show a diff with conflicts?
<lifeless> Pieter: I don't know what you mean by that
<Pieter> well, what does it look like?
<Pieter> (can I get an example somewhere)
<lifeless> do you mean 'if I run "bzr diff" when I have conflicts, what do I see?' ?
<james_w> Pieter: you can only get them in your working tree, but it will just show the addition of the conflict markers and the "OTHER" block
<Pieter> lifeless: yes
<Pieter> james_w: ok, so no double +'s like git does?
<lifeless> Pieter: bzr diff doesn't report on conflicts at all, so as james_w says you just see the herringbone markers
<james_w> Pieter: you mean with diff --c etc?
<Pieter> james_w: I guess.. git does it with --cc, which is a compacted version
<Pieter> james_w: like in http://pastie.org/291669
<Pieter> I was wondering if bazaar did the same thing with triple @'s
<james_w> there's --c and --cc I think
<james_w> it doesn't currently
<james_w> I played with adding it once
<Pieter> ok.. I want to use that to detect conflicting diffs in my app
<lifeless> so, it marks the whole region, not just one side?
<Pieter> So I thought I'd check other VCS's do that too
<lifeless> james_w: file a bug please :P
<james_w> Pieter already did: bug 250783
<ubottu> Launchpad bug 250783 in bzr "Add a combined diff view" [Wishlist,Confirmed] https://launchpad.net/bugs/250783
<Pieter> Ah right, I thought bzr did the --c, but not the --cc
<lifeless> we have the code internally to do it
<lifeless> multiparent diffs
<lifeless> but we don't have a UI
<james_w> ah, didn't think of that, I was trying to do it around SequenceMatcher
<akahn_> Does bazaar make it easy to collaborate with a co-worker on a lan the way git does?
<arjenAU> akahn_: evenif they're 10k high and offline, yes
<akahn_> i'm thinking bazaar might be easier for the two of us to manage our work (web development) and put it online
<arjenAU> bzr rocks. and i'm not just saying that because it's the #bzr chan
<lifeless> akahn_: yes; we have avahi integration, a built in server and other such things
<akahn_> avahi?
<lifeless> zeroconf
<akahn_> not familiar with that
<lifeless> its for completely adhoc networking
<lifeless> no servers at all sort of thing
<akahn_> i see
<akahn_> ah, what apple calls bonjour
<akahn_> thanks people
<abentley> lifeless: pong
<lifeless> abentley: I had a weird revert failure
<lifeless> abentley: I suspect I did something to find a new corner case; so I filed a bug with the dirstate that caused it
<abentley> lifeless: Okay.
<abentley> lifeless: Is it possible reverting would have changed the root-id?
<lifeless> abentley: non-rich-root trees *as far as I know*
<lifeless> abentley: what I did was a parallel import of mysql, the pulled rev 1 of the import john did over that
<lifeless> abentley: (which conflicted on everything, moving them 'to the root'). Then a 'bzr revert' and boom.
<abentley> lifeless: I don't know whether that importer would create unique root-ids.  Can't say it wouldn't.
<lifeless> abentley: indeed. I know the parallel import didn't.
<lifeless> abentley: I can check one sec
<poolie> lifeless: re your earlier question, if the previous job is still running the new one will just exit
<lifeless> abentley: the mysql import has a unique root id, even though its not a rich roots repo:
<lifeless> >>> r = b.last_revision()
<lifeless> >>> t = b.repository.revision_tree(r)
<lifeless> >>> t.path2id('')
<lifeless> 'sp1f-changeset-20000731191004-fzqw7vgyzfnpbmw6f5gziiclvgyq4nc4'
<abentley> lifeless: Sounds like we have a corner case with root ids changing.  I thought I had a test for that, but..
<lifeless> abentley: yah
<abentley> vila: ping
<abentley> lifeless: Could you review http://bundlebuggy.aaronbentley.com/project/bzr/request/<48EFE285.7090402%40aaronbentley.com> please?
<lifeless> abentley: I think it needs a default on the if
<lifeless> in create_from_tree
<lifeless> else:
<lifeless>     raise AssertionError("unknown kind %r" % kind)
<lifeless> all the rest has been reviewed by folk already
<lifeless> so I don't think you need a review of the other parts of the patch
<abentley> lifeless: I'm not sure the rest has been reviewed by others.
<lifeless> abentley: poolie did the initial review saying that the iter_entries_by_dir hack was funky
<abentley> lifeless: That was on another patch.
<lifeless> abentley: which lead through the iterations to where we are today; I'm happy with the rest of the branch anyhow
<poolie> (well, i was just noticing that fairly long repeated expression)
<abentley> lifeless: Thanks.  I'll fix and submit.
<lifeless> poolie: ping
<vila> hi all
<vila> abentley: pong
<nubbun> Can one use the Intrepid APT repository for Debian Lenny systems?  or is there a more suitable repository?
<jml> bazaar really can chew up memory when it wants too.
<jml> s/too/to/
<jml> oh wow, it's greying out my terminal :)
<lifeless> poolie: ping
<haoyu> is TortoiseBZR  included in bzr installer?
<lifeless> for windows, yes I believe so
<lifeless> poolie: on the off chance that you look at this tonight; usertest's in progress log has stopped at the set stage, the actual test run is progressing but not visible anywhere
<haoyu> I have download bzr-setup-1.8rc1.exe
<haoyu> but seems tortoisebzr not included..
<haoyu> should I restart after install?
<speakman> yo folks :)
<speakman> (I was thinking of asking about PQM, but now I found the linuxfoundation.org article)
<Odd_Bloke> poolie: What's "Kerguelen"?
<poolie> kerguelen is (a) an island in the southern ocean, and (b) a windows virtual server for testing and building packages
<speakman> how is bzrbashprompt.sh supposed to work?
<Odd_Bloke> poolie: Ah, right.
<poolie> speakman: do you mean what's it meant to do or how does it do it?
<Odd_Bloke> Google told me the former, but not the latter. :D
<speakman> oh, I loaded it wrong, now it works :)
<speakman> (god it makes bash slow though...)
<speakman> are there any generic ways to speed up bzr?
<poolie> first you should make sure you're using the compiled extensions
<poolie> (ie are running from a package or have run make)
<poolie> then there is 'bzr shell' (in bzrtools) and bzr-client (a plugin)
<lifeless> poolie: any thoughts on usertest ?
<speakman> I'm running from ppa apt repo
<speakman> bzr shell doesn't load my .bashrc or .bash_profile, and seems to lack tab completion :/
<lifeless> speakman: in the last round of discussions folk were saying bzr is plenty fast for them; modulo really-big-trees
<lifeless> speakman: are you talking basic response time
<lifeless> speakman: or time to clone/do network stuff/etc ?
<speakman> basic response time mostly, but the thought was more to make the bzrbashprompt.sh works a bit faster (it's a cool thing though!)
<speakman> I do not have a problem with bzr in general (doing bzr commit and stuff), else I wouldn't promote it the way I do ;)
<lifeless> l
<guilhembi> abentley: hello! I am reading
<guilhembi> http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html#bzr-1-8rc1-2008-10-07
<guilhembi> and wondering: does 1.8rc1 include all of 1.7.1?
<guilhembi> and is there a way to tell (for next time I wonder :) ?
<guilhembi> To rephrase: 1.7.1 contained fixes to --weave, are they in 1.8rc1 too?
<abentley> guilhembi: Yes, 1.8rc1 includes everything in 1.7.1.  They always do.
<guilhembi> abentley: thanks!
<abentley> guilhembi: Anything in the NEWS file for a given release will pertain to that release.  If 1.7.1 wasn't listed in the NEWS, you might wonder.
<guilhembi> abentley: the NEWS file, you mean I should download the tar.gz of the release and read NEWS?
<abentley> guilhembi: No, you can look at http://doc.bazaar-vcs.org/bzr.1.8/en/release-notes/NEWS.html#bzr-1-8rc1-2008-10-07
<guilhembi> abentley: how did you arrive to the link above? I was able to find http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html#bzr-1-8rc1-2008-10-07 .
<abentley> guilhembi: I went to http://doc.bazaar-vcs.org/
<guilhembi> abentley: thanks!
<ngnp> can I push/pull between server/debian bzr (0.11.0) together with laptop/ubuntu bzr (1.3.1) ... I guess not but how to solve this?
<pysquared> Help please: I emailed someone a bzr branch.  They made changes and emailed me a merge-directive (MD). I merged the MD, made more changes, and I want to send back to them another MD.
<beuno> oleavr, what's the problem?
<pysquared> If I create a copy of the branch I originally emailed them and "bzr pull" their MD, I can then do "bzr send ../original_plus_pulled_md"
<pysquared> But can I do this without creating a copy of what their branch looks like?
<oleavr> beuno: ?
<pysquared> e.g. something like "bzr send -r-2.. ." (which does not work by the way)
<beuno> oleavr, misstyped, meant pysquared   :)
<oleavr> beuno: ah :)
<beuno> pysquared, so, you want to create a merge directive, without creating a branch?
<beuno> I don't think you can do that, because you need to have his revisions in the ancestry
<beuno> so you do actually have to create the branch
<beuno> but abentley is the expert on the subject
<abentley> pysquared: The only way to calculate which revisions need to be sent is using a branch that lacks the revisions they lack.
<pysquared> Or specifying which is the last revision of the current branch they have??
<pysquared> (Or am I being dumb?)
<abentley> pysquared: No, that's a way of specifying what merge you want them to perform, not which revisions need to be sent.
<pysquared> Sorry, please could you elaborate on "what merge" means.
<abentley> Merge is a bzr command.  It combines two lines of development.  It can merge either from a branch or from a merge directive.  When it uses a merge directive, it performs the merge that was specified in the merge directive.
<abentley> So when you specify bzr send -r 53..54, you're saying "merge just the changes from 53..54, even if you haven't merged 52"
<pysquared> I have used merge before (just a beginner though).  I'm just testing some merges now...
<pysquared> Is this correct: If I specify bzr send -r 10-30, and they are already at revision 20, then part of the merge directive is ignored, and they get the latest 10 revs?
<abentley> That is true.
<pysquared> Good, so it seems like I can do what I want: generate a merge-directive without having access to their branch, as long as I know what is a common ancestor revid?
<abentley> pysquared: Do they already have copies of your revisions?
<pysquared> Hmmm?  I think that is what I am trying to send them in the merge directive no?
<abentley> pysquared: No, you're telling them *what* to merge.
<pysquared> I basically want to find the most efficient way to generate the smallest merge directive which contains the work I have done since merging the work they did.
<abentley> pysquared: In your example, if they already have revision 20, bzr only needs to send revisions 21..30.
<pysquared> Cool.  What is the incantation?
<abentley> pysquared: In my example, if they don't have 52, it needs to be sent, because it will be used indirectly.
<abentley> pysquared: bzr send path/to/mirror/of/their/branch
<pysquared> I cannot find a way to produce a merge directive using a standalone branch which matches the one generated using a copy of their branch.
<pysquared> I think using path/to/mirror/of/their/branch should be unnecessary, but perhaps I am missing something important.
<abentley> pysquared: If you use your own branch as the submit location, you will always get an empty bundle, and that will never be what you want.
<abentley> pysquared: It is used to calculate which revisions need to be sent.
<pysquared> *Yes* that was what I was getting - empty bundles
<abentley> pysquared: By default, it is also used to calculate the merge to be performed, though you can override this with -r.
<pysquared> Can I tell "bzr send" which revisions need to be sent and the merge to be performed, and therefore lose the dependency on path/to/mirror/of/their/branch?
<abentley> pysquared: No.
<pysquared> Oh :-(
<pysquared> That felt strangely like chasing my own tail :-)
<abentley> pysquared: I said that at the start.  You need to use a branch that lacks the revisions they lack.
<ahasenack> bzr is giving me a weird url to break a lock, does this look right?
<ahasenack> bzr break-lock chroot--1217453396:///some/path/trunk/.bzr/branch/lock
<abentley> ahasenack: No.  Just use the normal URL for that branch.
<pysquared> abentley: Is it possible do you think to add this feature?
<ahasenack> abadger1999: thanks
<ahasenack> er
<ahasenack> abentley: thanks. Known bug? Should I open one?
<abadger1999> heh.  I need to change the first two letters of my nick.
<abentley> pysquared: It is possible, but pretty pointless.  Branches are ~44k
<abentley> pysquared: And the overhead of keeping track of their branch manually instead of letting bzr do it seems not worth it.
<pysquared> abentley: thanks for your patience and help.
<abentley> vila: I'd like lp-login to set the username that is used whenever bzr+ssh://bazaar.launchpad.net is specified.  It seems like the best way to achieve this is to use AuthenticationConfig.  Does that make sense to you?
<vila> abentley: yes
<abentley> vila: Where would be the best place for this?  In the SSHVendor code, or the individual transports?
<vila> I didn't address it at times because... can't remember exactly, lack of test infra or shyness to touch the launchpad plugin code
<vila> Well, if you do declare bazaar.launchpad.net in the file, it should already work
<vila> That is the intent at least :)
<abentley> vila: Really?  I see that for paramiko, but I thought the rest didn't use it.
<vila> hmm, let me refresh my memory
<vila> Ha yes, only paramiko implement access to auth
<vila> The sub process ones are alien to me (I use only paramiko), but I guess the right place is in connect_[ssh_sftp] for SubprocessVendor, LoopbackVendor doesn't care
<abentley> vila: Any suggestions how to test that?
<vila> Tricky :)
<vila> I think we lack the infrastructure for authenticating test servers
<vila> So... the closest existing code will be in test_http/http_utils/http_server I guess
<vila> I tested the AuthConfig in test_config.py and then there are some full stack tests in test_http (test_prompt_for_password, test_no_prompt_for_password_when_using_auth_config)
<jam> vila: do we actually use AuthenticationConfig for ssh ?
<vila> Only for paramiko apparently
<vila> scratch apparently
<jam> well, we would like it there
<jam> I'm not sure if we should be more consistent
<jam> but as paramiko doesn't have another way to configure it
<abentley> jam: My motivating example is Launchpad.
<jam> that is at least a start
<jam> abentley: I understand what you are after, and I've read the bugs as well
<vila> jam: more consistent ?
<jam> I think that having a way to configure the username for paramiko is a good thing
<jam> and perhaps "launchpad-login" is good enough
<jam> vila: If we are going to use AuthConfig for paramiko, shouldn't we also use it for ssh and plink?
<jam> arguable either way
<abentley> jam: launchpad-login doesn't do enough.  It doesn't allow users to use "bzr+ssh://bazaar.launchpad.net" URLs that have no username.
<abentley> jam: If we are going to insist that people specify their username via launchpad-login, not .ssh/config, we should ensure that it works all the time.
<vila> abentley: well, I'd argue that either you use lp: or you use bzr+ssh://user@bazaar.launchpad.net... No ?
<abentley> vila: That's not a shareable URL, so it can't function as a public URL.
 * vila should stop editing branch.conf and put lp: urls there ? :-)
<abentley> vila: I think that forcing a username into bzr+ssh urls is a bad choice because the resulting URLs can't be shared with other users.
<vila> Haaa, misunderstood
<vila> but then use lp: !
<abentley> vila: That's not usable by people who don't have the launchpad plugin.
<vila> and propagate it to .conf files so I can stop editing them :)
<abentley> And it's not a real URL.
<vila> there are people who don't have the lp plugin and want to use lp, oook. Fair enough :)
<vila> abentley: shaking the tree, don't take it personally :)
<abentley> I've implemented lp as a directory service.  This makes much more sense than implementing it as a transport.  But it means that the canonical url is whatever lp resolves to.
<jam> abentley: the number of users that are going to be using launchpad with bzr but not have the launchpad plugin is roughly -10% at the moment
<jam> (yes negative)
<jam> :)
<abentley> jam: Are you proposing to make it part of the core, not a plugin?
<vila> on the subject of AuthConfig with ssh, we decided to refuse to handle passwords, pointing people to agents instead (just a reminder)
<jam> abentley, vila: care to comment on bug #283123, I don't really want it to be just me versus bialix
<ubottu> Launchpad bug 283123 in bzr "Wrong result of cherrypicking merge" [Undecided,Won't fix] https://launchpad.net/bugs/283123
<jam> abentley: well, how many installs *right now* don't have the plugin... 0
<jam> how many installs in the future to we expect to not have it
<jam> roughly 0
<jam> unless something changes dramatically
<abentley> jam: If we're going to require it, it shouldn't be a plugin.  If it's a plugin, we shouldn't require it.
<jam> abentley: I think requiring it for people using lp: urls is just fine
<jam> as private urls won't resolve for everyone anyway
<jam> some people won't be able to reach your server, etc.
<jam> and branches move from time to time, servers disappear
<jam> I think we can make a "reasonable effort" without having to turn the world around
<jam> Obviously you feel stronger about it, and you're welcome to feel that way
<jam> I think using "lp:" urls is a nice pretty way to do things
<jam> that actually helps more than hurts
<jam> that said, I agree that I'd rather not have "bzr+ssh://myuser@"
<abentley> I really dislike lp urls, because they mask what's really happening.
<abentley> Having a way to look up URLs is great.
<abentley> Pretending it's the actual url... gross.
<jam> anyway bbiab, taking my son to day-care
<Verterok> mornin' all
<abentley> jam: I think that if a user specifies a username in authentication.conf, Bazaar should respect that.  I think it simplifies documentation and knowledge transfer to have this work for all SSH vendors.  However, if they haven't specified something in authentication.conf and the SSH vendor has its own configuration mechanism, that should be respected.  Do you disagree?
<jam> abentley: so I think it should be "URL username", "auth.conf", "ssh/config", in that order
<jam> I'm a bit concerned about "accidental" entries in authentication.conf
<jam> because we put them there, rather than just users
<jam> however, if we are careful, it should be finee
<jam> oh, and I wanted to point out an advantage of using lp:...
<jam> users who *don't* have an lp account or haven't issued 'lp-login' can still get the public branch
<abentley> jam: I agree with your order.
<jam> (the only bug I know of is problems behind an http_proxy, because xmlrpc doesn't support it)
<abentley> jam: We currently do add entries to auth.conf, or we would?
<jam> abentley: probably "we would", though I thought vila had some specs about adding things automatically when we connect to a server for the first time and prompt the user
<jam> I'm not sure what has been implemented
<abentley> jam: Okay.
<vila> abentley: we currently don't add entries to auth.conf, but we would
<abentley> jam: Certainly it would be possible supply credentials via AuthenticationConfig without touching auth.conf if we decided we wanted to.
<abentley> Something like that would happen if we supported native keychains/seahorses anyway.  But I doubt it's the right choice here.
<vila> jfroy is working on supporting OS X keychain
<vila> I made an attempt to accept pluggable credential stores at: lp:~bzr/bzr/pluggable-credential-stores
<vila> but that doesn't address your need which is to provide a *user* name (not a password)
<vila> And if we want to provide more public URLs, that may be needed
<abentley> vila: I took a look at lp:~bzr/bzr/pluggable-credential-stores.  I'm confused because it says "We don't use the netrc ability to provide a user since this is not handled by authentication.conf".  AIUI, authentication.conf can provide users.
<abentley> vila: Do you mean that only authentication.conf should provide users, not .netrc?
<vila> abentley: netrc can provide a default user, but we don't get it
<vila> abentley: yes
<vila> badly phrased, AuthConfig can't handle it, of course authentication.conf can
<vila> May be we should rename 'password_encoding' to 'credential_store' and allows the user to be provided :)
<vila> may be that 'we' is really an 'I' :)
<abentley> I'm confused.  AuthConfig has a get_username method.
 * jfroy|work listens to the conversation
<abentley> Maybe I don't understand the intended layering.
<vila> but it doesn't delegate to the credential stores so it can't get the user provided by netrc in that case
<vila> it just get the ones that are declared in authentication.conf
<vila> as described in the spec, only the password was intended to stored outside of authentication.conf
<vila> s/to/to be/
<abentley> vila: So I think you want authentication.conf to specify the user, and then to allow credential stores to provide credentials for that user.
<vila> Well, either the user is specified in authentication.conf or provided by the credential store, otherwise users would get confused
<vila> credentials are for user at a host, optionally at a path and so far is only a password
<vila> at a path or at a realm even
<vila> rephrasing: now, the user in authentication.conf only and credential stores can provides passwords
<vila> We can change that so that credential stores can provide user and password. But in that case the user shouldn't appear in authentication.conf (IMHO)
<vila> abentley: is the following clearer :
<vila>                 # We don't use the netrc ability to provide a user since there
<vila>                 # is no way to give it back to AuthConfig. So if the user
<vila>                 # doesn't match, we don't return a password.
<abentley> vila: That's better.  But it implies a flaw in AuthConfig, rather than a design decision.
<vila> abentley: agreed, especially with your new use case
<abentley> vila: Oh.  I thought you believed that AuthConfig should not allow a user to be specified.  So I thought you should say something like "To reduce confusion, users are specified only on AuthConfig.  So we don't use netrc to choose a default user."
<abentley> vila: But if you now think it makes sense for credential providers to specify a user, then your revised comment is good.
<vila> It makes sense for credential stores to be able to provide user, in which case the user shouldn't be specified in authentication.conf. If the credential store doesn't provide user then it should be specified in .conf.
<vila> So I will work in that direction in that branch which is  work-in-progress with a nick that perfectly fits :)
<vila> abentley: Thanks for the feedback
<abentley> vila: No problem.
<woutc__> hello
<woutc__> i am trying to use the bzrlib in my application
<LarstiQ> evening woutc__
<woutc__> but now i want to know the best function to check if a branch was changed by other people (somebody pushed the branch to a new rev)
<woutc__> so i would like the log and the new rev number
<woutc__> without pulling the branch
<LarstiQ> woutc__: are the two branches the same (same url), or do you have one local branch you want to check against a remote one?
<LarstiQ> woutc__: ala `bzr missing`
<woutc__> i want to check a local branch to a remote one
<LarstiQ> ok
<rocky> jelmer: bzr-svn 0.4.13 is for bzr 1.7.x right?
<jelmer> rocky, also for 1.8
<rocky> ah cool
<woutc__> bzr missing does what i need?
<jelmer> rocky, I'll probably release a 0.4.14 that silences the compatibility warning at some point
<rocky> jelmer: am i better off playing with bzr-svn 0.4.x branch (bzr 1.7.1 here) or bzr-svn 0.4.13 ?
<LarstiQ> woutc__: yes. Looking at that code, it seems to be find_unmerged(local_branch, remote_branch, ...)
<jelmer> the 0.4 branch is for bzr 1.9.x
<LarstiQ> woutc__: see bzrlib/builtins.py, search for cmd_missing
<woutc__> thank you so much! :)
<LarstiQ> woutc__: let me have a look at the IDE integration page btw
<LarstiQ> woutc__: if it isn't on there, it should be
<rocky> jelmer: huh? so no more releases for bzr 1.7.x or 1.8.x ?
<jelmer> rocky, not for 1.7, maybe one for 1.8 that is 0.4.13 + silences the compatibility warning
<woutc__> LarstiQ: it seems that it isn't listed on the integration page
<rocky> jelmer: i take that to mean bzr 1.8 is right around the corner?
<LarstiQ> woutc__: right. When you figure out exactly what to do, could you add it to http://bazaar-vcs.org/Integrating_with_Bazaar?
<LarstiQ> woutc__: I'm happy to review or help otherwise
<woutc__> ok, i am the developer from specto (http://specto.sf.net) and i am trying to create a watch that notifies you when somebody committed to a branch :)
<LarstiQ> woutc__: do you also support events instead of polling? Would need the help of the remote branch to work though, but would be less intensive.
<woutc__> the current specto design works only with polling
<woutc__> so if the refresh (or poll) time is not set too low, it is not really a problem
<LarstiQ> k
<rocky> jelmer: looks like that ghost revision bug thing i talked to you about before is back (it went away there for a bit) .... http://cluebin.appspot.com/pasted/2401
<woutc__> i found the function but i get an error
<woutc__> >>> local_branch = Branch.open_containing(u".")[0]
<woutc__> >>> parent = local_branch.get_parent()
<woutc__> >>> local_extra, remote_extra = find_unmerged(local_branch,parent)
<woutc__> Traceback (most recent call last):
<woutc__>   File "<stdin>", line 1, in <module>
<woutc__>   File "/usr/lib/python2.5/site-packages/bzrlib/missing.py", line 62, in find_unmerged
<woutc__>     remote_branch.lock_read()
<woutc__> AttributeError: 'unicode' object has no attribute 'lock_read'
<abentley> woutc__: You have the location of a branch as a unicode string, and you're treating it like a Branch object.
<woutc__> but the variable local_branch is a Branch object, no?
<woutc__> >>> type(local_branch)
<woutc__> <class 'bzrlib.branch.BzrBranch6'>
<LarstiQ> woutc__: but 'parent' is not
<the-geek-inside> Programming Python, O'Reilly, Mark Lutz, ISBN-10: 0-596-51398-4
<LarstiQ> woutc__: the two first arguments to find_unmerged are the two branches you want to compare
<LarstiQ> woutc__: and branch.get_parent() returns a url, not a branch
<woutc__> haha so i have to create a branch object with the url :)
<woutc__> ok that did the trick
<the-geek-inside> OSamaK: Learning Python is good when you don't know about the language, so I guess thath you find some a little more advanced
<jelmer> rocky, yeah, afaik 1.8 should be released soon
 * rocky finds it odd that he's the only person in the world to have such a glaring problem
<jelmer> rocky, ?
<rocky> jelmer: well this is preventing me from using bzr-svn (whether it's bzr's fault or not) ... just seems strange that this "showstopper" isn't severe enough to have fixed for bzr 1.7.1
<jelmer> rocky, which showstopper?
<LarstiQ> jelmer: http://cluebin.appspot.com/pasted/2401
<rocky> jelmer: you didn't see my paste above?  http://cluebin.appspot.com/pasted/2401
 * LarstiQ does drive by pasting and leaves the house
<rocky> lol
<jelmer> LarstiQ, :-)
<jelmer> rocky, :-(
<jelmer> rocky, That's a bzr-svn bug primarily, unfortunately (IIRC caused by older versions of bzr-svn that wrote incorrect data)
<rocky> jelmer: old data shouldn't be an issue... how do i get rid of old data?
<jelmer> rocky, the old data in the svn repository, if you do a fresh checkout (remove ~/.bazaar/svn-cache) outside of your existing shared repo it should work
<jelmer> james_w, ping
<james_w> hey jearl
<james_w> er, jelmer
<james_w> how are you?
<jelmer> Very good, thanks (-:
<jelmer> james_w, You asked about bzr-notify crashes earlier
<james_w> cool
<jelmer> I've uploaded a new snapshot of bzr-gtk that should fix those issues
<james_w> yeah, apport has shown that it affects a few people
<james_w> ah, great
<james_w> to experimental?
<james_w> bug 283294 arrived today, but I'm not sure why that only seems to affect Ted
<ubottu> Launchpad bug 283294 in bzr-gtk "bzr-notify crashed with RuntimeError in add_signal_receiver()" [Undecided,New] https://launchpad.net/bugs/283294
<jelmer> yep, I uploaded to experimental
<jelmer> I'm not sure what Ted's bug is about either
<james_w> I mean no mainloop is defined as far as I can see, so it's right
<james_w> but why isn't that always a crash?
<jelmer> I think it (used to ?) creates a mainloop implicitly
<james_w> jelmer: I'd like to just cherry-pick the fixes out, as we're two days from RC freeze, and it will avoid a freeze exception request
<jelmer> james_w, One sec, I'll look up the relevant revnums
<james_w> jelmer: there are a couple of fixes missing that I put in to the Ubuntu package, I'm sure I checked they were fixed in trunk though
<james_w> http://paste.ubuntu.com/57563/ for a start
<james_w> thanks for the heads up, I'm going to eat now, I'll work on it after that
<jelmer> james_w: http://people.samba.org/bzr/jelmer/bzr-gtk/trunk, revisions 607-611
<james_w> thanks
<jelmer> james_w, bon appetit
<jelmer> james_w, I think we may not have those changes, will check
<rocky> jelmer: i'll take a crack at that as soon as i finish preparing supper for the kids )
<rocky> :)
<ryanakca> could somebody help me figure out the mess I got myself into please? bzr is telling me to resolve a file that isn't conflicted: http://paste.ubuntu.com/57581/
<poolie> hello all
<poolie> ryanakca: maybe you're not in the base directory of the tree?
<poolie> like you're already in ./debian/?
<poolie> in which case you just want 'resolve changelog'
<poolie> jam, ping?
<jam> poolie: pong
<ryanakca> poolie: nope
<poolie> hey, Shang was just checking about bug 242510
<ubottu> Launchpad bug 242510 in bzr "Pack already exists when pushing/autopacking" [High,Fix released] https://launchpad.net/bugs/242510
<poolie> that is definitely fixed in 1.8 right?
<poolie> well, news says so
<poolie> lp is unreachable atm
<jam> poolie: that one should indeed be fixed in 1.8
<jam> bug 153786 is not, though
<ubottu> Launchpad bug 153786 in bzr "pack repositories do not retry when concurrent operations pack" [High,Triaged] https://launchpad.net/bugs/153786
<poolie> ryanakca: what does 'bzr st' show
<ryanakca> poolie: http://paste.ubuntu.com/57588/
<poolie> oh, i see
<poolie> so someone has actually committed three files called changelog.BASE .OTHER and .THIS
<poolie> maybe you :)
<poolie> that might not really be what you want?
<ryanakca> poolie: bzr ls debian/ doesn't show those files?
<poolie> what about plain ls?
<ryanakca> poolie: same
<poolie> how about just 'bzr resolve' then
<ryanakca> poolie: it tells me it auto-resolved nothing and then it spewed out the same as the conflicts part of bzr status
<GhostFreeman> Is there a channel for tortoisebzr?
<poolie> no, just ask here
<GhostFreeman> Ok. Well I installed Bazaar on my windows vista machine (1.8rc1) and while bzr works, I can't get TortoiseBzr to show up in Windows Explorer
<poolie> GhostFreeman: using the python-based 1.8rc1 installer?
<poolie> GhostFreeman: i think that only includes bzr, not any plugins
<poolie> the person who normally makes windows builds, mhammond, is on holidays
<poolie> i'm getting set up to build 1.8 myself
<GhostFreeman> I did install using win32-py2.5
<poolie> in the meantime you could try 1.7-setup.exe, which does have it
<poolie> s/it/tbzr
<GhostFreeman> Alright. Should I remove 1.8 before I revert to 1.7?
<poolie>  probably a good idea
<poolie> jam, yeah it'd be good to fix 153786
<mwhudson> is it expected that you can call branch.set_stacked_on_url() on a branch that is write-locked by another process?
<lifeless> mwhudson: no, bugger a file please
<mwhudson> lifeless: okidoke
<jam> poolie: when it comes time for the standup, ping me. If I don't respond, call my cell phone
<poolie> ok
<poolie> that sounds painful
<lifeless> poolie: did you see my query re usertest log ?
<poolie> mm, i did
<lifeless> http://benchmark.bazaar-vcs.org/usertest/log/usertest.log.inprogress <- shows only the pull phase
<poolie> and then i fell asleep :)
<lifeless> fair enuff
 * poolie looks
<mwhudson> lifeless: https://bugs.edge.launchpad.net/bzr/+bug/283457
<ubottu> Launchpad bug 283457 in bzr "set_stacked_on_location doesn't take a write lock" [Undecided,New]
<lifeless> mwhudson: I suspect its really 'config objects don't honour lock status of their branch'
<mwhudson> mm, that would make sense
<jfroy|work> jelmer: ping
<jfroy|work> (and hi!)
<jelmer> jfroy|work, pong!
<jfroy|work> So, I have mostly addressed the issues I've (suddently) been having with bzr-svn, at the cost of a rather large performance problem.
<jfroy|work> What showed up as corrupted knit exceptions in bzr 1.7.1 and bzr-svn 0.4.3 became not-a-branch exceptions or problems in top of tree (both for bzr and bzr-svn).
<jfroy|work> The svn repository I'm working with has ... a tortured history of projects being moved around several times, not always following svn conventions.
<jfroy|work> And it was clearly tripping bzr-svn up.
<jfroy|work> So I managed to write up a list of branch paths in subversion.conf that made it mostly work (some branches in certain projects no longer can be checked out, the entire project (e.g. the root containing trunk, branches, tags) has to be checked out).
<jfroy|work> However, now, sending a changeset takes upward of 15 seconds to complete, pegging Python to 100% of the core it's running on.
<jfroy|work> Any ideas why that might be?
<jfroy|work> Also, how reasonable would it be to have an option to force a specific svn revno to be considered the "baseline", from bzr-svn's POV. E.g. it wouldn't look in the Subversion history earlier than that revno, to help deal with old svn repositories that have had a less than ideal history.
<jonoxer> jfroy|work: you could dump from a specific revision using svnadmin, populate a new repo with just that history, then convert that
<jfroy|work> Not viable in this case, I do not control or own the subversion repository in question.
<jonoxer> Ah, right
<jonoxer> It's kinda brute-force, but I did something nasty once where I scripted a sequence of "svn up -r $i" updates to let me pull a sequence of commits from a remote repo and run analysis on them. Maybe something similar?
<jfroy|work> Well my understanding is bzr-svn has to map svn paths to branches (since svn has no formal notion of branches), and when a svn repository is really messed up, bzr-svn blows up :p
<jfroy|work> You can grab its hand by specifying a custom list of branches, but that has limits, and apparently bad performance implications for commit operations.
<jelmer> re
<jelmer> jfroy|work, 0.5 will be a lot of better in that regard
<jfroy|work> jelmer: 0.5 is "working" for the most part, commits are exceedingly slow though
<jfroy|work> And for one project the branches trick didn't quite work because of a svn mv operation (IIRC my analysis of the bzr log)
<jfroy|work> if log files can help, I'd be happy to provide them to you, just let me know the debug flags you need
<jelmer> jfroy|work, s/0.5/0.4 ?
<jfroy|work> I'm using bzr and bzr-svn mainline
<jfroy|work> I'm bleeding-edge :p
<jelmer> jfroy|work, trunk or 0.4 ?
<jfroy|work> 0.4 just explodes, and 0.5 needs what appear to be 1.9 API
<jfroy|work> trunk
<jelmer> jfroy|work, Please be careful with that, you wouldn't want to use it with production-type stuff
<jelmer> jfroy|work, how does 0.4 blow up?
<jfroy|work> I am using it on production stuff, I trust it to not delete every file :p
<jfroy|work> 0.4 throws corrupted knit errors
<jfroy|work> I haven't, though, tried 0.4 with the custom branches option
<jfroy|work> I never would have found out what the problem even was without 0.5's much more helpful errors.
<jfroy|work> So yeah, if there's anything useful I can do, let me know.
<jfroy|work> I have, incidentally, a small change to trunk that addresses assertions (usually on branch names) that checked if certain parameters were str objects, also allowing unicode objects
<jam> lifeless: for bzr.dev, 'time bzr pack' w/ normal compression: 39.5s & 5.7MB, w/ max compression: 42.7s and 4.5MB
<jam> I'm off for now
<lifeless> jam: ciao
<lifeless> jam: I do wonder about just turning it on; indices are never done in isolation
<lifeless> jam: and the proportion to data written should be roughly constant
<lifeless> jam: (we'd want spill indices to have it off)
<awilkins> jelmer: The trunk of bzr-svn is the not-tied-to-a-fixed-concept-of-branch-mapping branch, yes?
<jelmer> awilkins, yes
<awilkins> jelmer: E.g. - if you have a wacky repo layout it's ok
<jelmer> jfroy|work, any chance you can send me those patches?
<jam> lifeless: so for 'bzr pack' it is 10% more time for 25% less space. I was tuning it to be minimal by request for 'bzr commit' time.
<jam> Which seemed reasonable
<awilkins> jelmer: How stable is that now?
<jelmer> awilkins, not recommended for use with production code
<awilkins> jelmer: I have some really horrible repos I can run it on :-)
<awilkins> jelmer: I don't mind it not being OK for production at the moment but I'm happy to devote a few CPU cycles to trying it out
<awilkins> jelmer: We are moving to another office that may have limited bandwidth and I think people might appreciate something that can buffer the gap to the server a bit
<awilkins> jelmer: 0.4 struggled with the repo layout of our main repo the last time I tried it (large revisions where there should have been tiny ones for branches)
<awilkins> jelmer: And of course, there's that KeyError thing (is that fixed?)
<jfroy|work> jelmer: can I bzr send that to some email address?
<jfroy|work> awilkins: I saw those key errors a bunch of times too
<jfroy|work> I had to experiment a few times on my branches setting to get bzr-svn to checkout.
<jelmer> jfroy|work, just "bzr send" against the main branch should do the right thing
<jfroy|work> commits are also exceedingly slow
<jelmer> awilkins, use of trunk may silently break the ability to use bzr-svn in the future on those branches
<jfroy|work> jelmer: bzr send complains it wants a mail-to address
<jfroy|work> whoa, really?
<jelmer> jfroy|work, are you using http://people.samba.org/bzr/jelmer/bzr-svn/trunk ?
<jfroy|work> jelmer: ah no, that was against the launchpad mirror
<jfroy|work> Complained against that branch too :/
<jelmer> Ah, looks like I've only got it set on 0.4
<jelmer> one sec
<jfroy|work> I didn't know a branch could specify a mail-to address, that's kind of very cool :)
<jelmer> jfroy|work, please try again
<jelmer> jfroy|work, you can set "child_submit_to = email@address" in .bzr/branch/branch.conf
<mwhudson_> something doesn't seem right here: http://pastebin.ubuntu.com/57627/
<mwhudson_> lifeless: more set_stacked_on_url/write lock interaction nasties :(
<mwhudson_> ^
<awilkins> jelmer: Do you mean the ability to use bzr-svn on the actual SVN branches?
<awilkins> jelmer: Or just the bzr branches?
<jelmer> awilkins, the ability to use bzr-svn on the actual SVN branches
<awilkins> jelmer: That down to the bzr: properties?
<jelmer> awilkins, yep
<awilkins> jelmer: Is this because experimental progression is neglecting to put migration steps for the properties in?
<jelmer> awilkins, that, and the fact that several corner cases are not well tested yet for trunk
<jelmer> and so may set invalid values for the properties
<awilkins> jelmer: Is this only a problem if you push?
<jelmer> awilkins, generally, yes
<jelmer> awilkins, however, if you use trunk for pulling you may also corrupt your local bzr branch
<jelmer> awilkins, since trunk may sometimes be broken (it warns you every time you use it for a reason)
<awilkins> jelmer: Fair enough - less of a risk if you are just pulling branches on a particular trunk revision for experimental purposes?
<awilkins> jelmer: Since 0.4 can't pull the trunk of my "big nasty" repo, it's not too much of a loss
<jfroy|work> ack, this is kind of scary -- to never be able to use bzr-svn again on a repository.
<awilkins> jelmer: If you dropped the bzr: properties, and re-pulled your branches, you'd lose some metadata but the compatibility problem would be fixed, yes?
<jelmer> awilkins, you can'y drop them without taking the repository down
<awilkins> jelmer: Are they all revprops or are there fileprops there too?
<jelmer> all fileprops at this point
<awilkins> jelmer: So you'd need a dump | filter | load ?
<jelmer> awilkins, yep
<jfroy|work> jelmer: do you think a "baseline" revno option would be a suitable workaround for the extreme case of a broken subversion repository that is not under your control?
<awilkins> Happily, I am the server admin :-)
<jelmer> jfroy|work, that means you can't allow dir push to svn
<jelmer> s/dir/direct/
<jfroy|work> I don't know enough about how this stuff is working to understand why that is, but I'll trust you on that
<jfroy|work> Urg, I might have owned myself for all time :|
<jfroy|work> (patch sent, btw)
 * mwhudson_ bounces
<mwhudson_> lifeless, poolie: could one of you look at http://pastebin.ubuntu.com/57627/ for me?
<poolie> mwhudson: really
<poolie> mwhudson: and where is the repository for them?
<poolie> i presume they're in the same repository?
<poolie> that's probably the bug, can you file it?
<mwhudson> poolie: i don't think that matters, actually, it seems you get this when the branches are both standalone
<mwhudson> poolie: i can check though
#bzr 2008-10-15
<mwhudson> poolie: yes, i can reproduce with standalone trees
<poolie> wow
 * mwhudson biles another fiug
<poolie> this is kind of surprising
<mwhudson> yes
<poolie> it's probably shallow but i'm surprised it has not been hit before
<mwhudson> https://bugs.edge.launchpad.net/bzr/+bug/283479
<ubottu> Launchpad bug 283479 in bzr "set_stacked_on_location unconditionally(?) unlocks the repository" [Undecided,New]
<mwhudson> poolie: oh, i know what's going on
<mwhudson> poolie: unlock is trying to unlock all of the repositories
<poolie> yes, i know :)
<mwhudson>             for repo in self._fallback_repositories:
<mwhudson>                 repo.unlock()
<mwhudson> ok, i hadn't figured this out yet :)
<poolie> the question is, why was the fallback repository not locked
<poolie> or actually, why does it ever work
<mwhudson> well, nothing locks it
<poolie> i guess because we normally change it without locking the branch
<poolie> which i think is actually a bug
<mwhudson> see the other bug i filed today :)
<mwhudson> poolie: i changed the description of the bug to be more honest :)
<mwhudson> poolie: i guess the fix is to make set_stacked_on_location @need_write_lock and then lock the added repository somehow or other
<mwhudson> but still leave the fallback repo unlocked when you open a branch
<mwhudson> (unless now is the time to make "open and write lock a branch" a more primitive concept ...)
<poolie> i agree up to <mwhudson> but still leave the fallback repo unlocked when you open a branch
<lifeless> abentley: hey, do you know of code to go from iter_changes <-> inventory_delta ?
<lifeless> (that is, to transform an inventory delta into a valid iter_changes output (without include_unchanged or want_unversioned); and/or vice vera to generate an inventory delta when given a iter_changes iterator
<abentley> lifeless: Can't think of anything off the top of my head.  Though TreeTransform can emit both iter_changes and inventory_delta.
<lifeless> abentley: I'm looking at making faster deltas between inventories given the capabilities of CHKInventory
<lifeless> abentley: but I don't want to expose inventory centric API's :)
<pdf23ds> It would be nice if the commit command exposed the timestamp parameter of the commit object, as that way I could write my importer program using the bzr commandline.
<abentley> lifeless: I always figured inventory_delta -> iter_changes was a lossy conversion, so I don't know about going backward.
<pdf23ds> I think I have a patch that should do it to builtins.py. Is there a way I can apply that to a binary windows download?
<lifeless> pdf23ds: if you're writing an importer I really encourage you to use the bzrlib api and python
<lifeless> pdf23ds: as for changing the windows binary, I think you can edit the zip contents
<pdf23ds> My converter is for svn and extremely hacky. I doubt anyone else would be interested.
<lifeless> abentley: so, add_inventory_delta is 20 times faster than add_inventory, currently
<pdf23ds> Would I need to compile to a .pyo?
<lifeless> pdf23ds: have you tried bzr-svn ?
<pdf23ds> I have a multiple repository setup with many weird renames and only a few revisions. I don't want to even bother.
<pdf23ds> Multiple project repository, that is.
<lifeless> ok, well up to you
<lifeless> anyhow, I'd  remove the pyo and  pyc for the file you edit in the zip
<pdf23ds> Cool, it works.
<pdf23ds> Thanks.
<pdf23ds> Mercurial has that option, but I'm not going to go with mercurial because I don't like the branching as much.
<pdf23ds> Where would I request that this feature be added?
<lifeless> pdf23ds: file a bug in launchpad.net/bzr
<lifeless> however, we want the CLI to be good for humans, for scripting we encourage the use of python directly, it helps keep the UI cleaner
<pdf23ds> Well, I program mainly in C# and don't really enjoy python. I wouldn't want to do much work in python.
<lifeless> I believe there are C# bindings floating around
<lifeless> anyhow, please file the bug
<lifeless> with your patch
<lifeless> and you've gotten your conversion done now right? which is a one-time thing
<pdf23ds> Well, it's an interactive and painstaking conversion, but it's now on its way.
<pdf23ds> I won't really need the patch after that.
<pdf23ds> Or probably need to do any other hacking on bzr. :)
<pdf23ds> But I'm glad it's python and not C or Haskell. :)
<pdf23ds> Ugh. stupid registration.
<pdf23ds> I'll do it for the sake of open source.
<pdf23ds> BTW, the view/annotate thing gives an error clicking on builtin.py from launchpad web source browser, but I can download the file. Should I report a bug on that one too?
<pdf23ds> IRC sure is useful.
<lifeless> abentley: if you're around
<lifeless> abentley: I'd love feedback on the RFC I just sent about install_deltas
<abentley> lifeless: You weren't very clear on whether this was deltas for everything or just for inventories.  It definitely seems reasonable if just for deltas.
<abentley> if just for *inventories*.
<lifeless> abentley: good point; I was thinking of deltas of the inventory, and asking the tree for iter_file_bytes when new texts are needed
<abentley> lifeless: And Revisions and Signatures would be fulltexts?
<lifeless> revision would be an object
<lifeless> signatures are the bytes of the signature as in install_revisions
<abentley> lifeless: So is the "deltas" parameter really an iterable of tuples?
<lifeless> yah
<lifeless> each tuple contains all the data for an individual revision - revision, signature, tree, basis_rev, inventory_delta
<lifeless> an alternative signature Iw as thinking off
<lifeless> *of*
<lifeless> was to pass in the source repo
<abentley> lifeless: It seems like you could calculate the delta from the tree itself, no?
<lifeless> and not pass the tree object in
<lifeless> abentley: you can, and I have an install_revisions version that does this, but its not as efficient, because as its currently structured we check everything in the tree, and do the delta against the target repo not the source
<lifeless> abentley: I'm wary of changing the behaviour of install_revisions, I'd rather add a new method that is explicitly delta based than find someone depends on a corner case of install revisions
<abentley> lifeless: There's no Tree method that can calculate a delta efficiently (at least under ideal conditions)?
<lifeless> abentley: there are two issues; one is that the ideal tree to calculate the delta against may not be present in the set being copied
<lifeless> abentley: secondly is that the idea tree to calculate against may be representation dependent - that is:
<lifeless> time(make_delta(Tree-rev1-repoA, Tree-rev2-repoA)) may be much smaller than
<lifeless> time(make_delta(Tree-rev1-repoB, Tree-rev2-repoA))
<lifeless> less abstractly
<lifeless> for xml inventories, doing a iteritems on the _byid attribute is very fast; for CHK inventories, doing that is very slow (because you page in all the pages of the two inventories)
<lifeless> for chk inventories, walking to common pointers is very fast
<abentley> lifeless: If you take a source repository, it seems a lot like Repository.fetch
<lifeless> for xml_inventory <-> chk_inventory its worst case of all - you have to load the entirety of both inventories, and chk inventories require more IO to load a full single inventory (because its fragmented)
<lifeless> abentley: (optionally taking a source repo) it does start to look a lot like fetch; thats why I decided against doing that
<lifeless> abentley: on the other hand, perhaps I should just doing fetch-cleanups so that this can happen more totally within the normal fetch structure. (I'm looking at this for fetch from pack-0.92->chkinventory)
<abentley> lifeless: I think that might be better.  Interfaces with iterables of tuples make me nervous, for some reason.
<lifeless> abentley: well, install_revisions() takes a iterable of tuples
<lifeless> abentley: I was patterning off that in that respect
<abentley> That's true.  I was actually thinking of iter_changes.
<abentley> lifeless: The fetch API doesn't care what two consenting repositories do behind closed doors, so I think it's a good way to achieve flexibility.
<lifeless> abentley: right; note that fetch() is already involved here
<lifeless> abentley: fetch -> InterDifferingSerializer -> install_revisions
<lifeless> abentley: what was in my head was to change that to fetch -> InterDifferingSerializer -> install_revision_deltas
<lifeless> abentley: the main thing being to move away from size_tree being embedded in the API
<abentley> lifeless: But you could replace InterDifferingSerializer with InterDeltaLovingRepositories.
<lifeless> abentley: sure, it still will either have, or want to use, a function/method that operates on deltas
<lifeless> abentley: and there is no reason for it to only match delta loving repositories IMO
<abentley> lifeless: Sure, but it has the option of doing *all* the file texts, then *all* the inventories, etc.
<lifeless> abentley: well, InterDifferingSerializer has that option too doesn't it ?
<abentley> lifeless: Yes, and it would look much cleaner if install_revisions wasn't involved.
<lifeless> abentley: right; so thats what I'm proposing to do: to change IDS to not use install_revisions; and to use a new method that focuses on deltas instead
<lifeless> abentley: another approach is to start working on the repository level streaming stuff again
<abentley> I don't understand why you want to do it that way, instead of implementing it directly on IDS.
<lifeless> abentley: I think I'm assuming that there may be some repo centric code involved to get best performance
<lifeless> abentley: so putting that on repo lets it be interface tested easilly
<lifeless> I may be drawing the lines early/wrng
<lifeless> abentley: also for reuse
<lifeless> something embedded in the inter-object is harder for e.g. importers, bundles, etc to use
<abentley> lifeless: If Repo is an input, it's similarly difficult for importers, bundles, etc.
<lifeless> abentley: right; note that I didn't include Repo as an input
<lifeless> abentley: I *considered* it
<abentley> lifeless: Yeah, and we were discussing that option, weren't we?
<lifeless> abentley: oh, I didn't click that it was a sub-discussion :P
<lifeless> abentley: anyhow, the discussion has been great
<abentley> I guess, you know, a 5-tuple makes me uneasy.
<lifeless> yah
<lifeless> its close to an object is definitely better
<abentley> Yup.
<lifeless> its one-per-rev, so object creation count is bounded by history
<lifeless> I'm comfortable making this objects
<abentley> Or perhaps a dict with namespaces?
<lifeless> a dict would be faster than an object
<abentley> lifeless: Yeah, object creation isn't that expensive here.
<lifeless> lets say a dict for now, and a private-but-tested method
<lifeless> once it stabilises a bit, we can go for an object if we want to
<abentley> lifeless: You'll lose ordering, and lose the ability to take a generator as input.  Is that okay?
<lifeless> abentley: oh uhm clarity: I was proposing an iterator of dicts
<lifeless> each dict has the data for a single revision
<lifeless> the transform being (5-tuple -> dict)
<abentley> lifeless: I mean that the dict would hold the entire input.
<lifeless> abentley: oh
<abentley> That's why I said "namespaced".
<lifeless> abentley: I think that will not work due to memory
<abentley> But your approach sounds fine.
<lifeless> abentley: ok cool; yay compromise
<lifeless> thanks
<abentley> lifeless: np
<poolie_> lifeless, spiv, i'm going to read https://code.edge.launchpad.net/~spiv/bzr-usertest/exit_codes/+merge/1309 unless you're already on it
<lifeless> poolie_: thanks, that would be useful
<lifeless> poolie_: if you're in a reviewing mood
<lifeless> I have a commit-uses-delta patch needs review too
<poolie_> lp reviews have more reasonable urls than BB
<poolie_> spiv, are you around?
<spiv> I am.
<poolie_> nm, i'm replying in launchpad
<poolie_> spiv, it's approved with mumblings
<poolie_> lifeless, orcadas may be better now; i'd changed the script to separate out stderr and i think it was not getting into the right file
<poolie_> let me know
<poolie_> the pulls are still pretty slow
<lifeless> poolie_: yes, thts why I'm working on pull :P
<poolie_> :)
<spiv> poolie_: could you merge http://people.ubuntu.com/~andrew/bzr/push-unlock-1.8 to 1.8 for 1.8 final?  I sent a mail to the list a while back asking for someone with permission to merge it, and I just realised it hasn't happened yet.
<poolie_> sure
<spiv> poolie_: thanks
<vila> hi all
<poolie_> hi vila
<vila> poolie_: ping
<lifeless> gnight all
<gour> night
<poolie_> hi
<poolie_> lifeless, nice explanation of formats
<lifeless> poolie_: thanks; felt compelled to reply to s turnbull
<vila> poolie_: ping
<poolie_> hi vila
<vila> lifeless: One thing worth mentioning on the subject is that everything changes
<vila> Being able to handle these changes is what matters
<vila> but overall, very nice summary, thanks for that :)
<jml> lifeless: hi
<poolie_> that's a good way to put it vila
<jml> lifeless: would now be a good time to get subunit and testresources into pyunit-friends?
<poolie_> i think the experience of upgrades and ui could be better
<poolie_> i think the bug about it is 90302
<poolie_> not sure when we'll get to it though
<poolie_> btw http://benchmark.bazaar-vcs.org/ now shows the machine load
<vila> poolie_: You couldn't even dream of making such a comment if bzr haven't already experienceS in upgrades... and really, *by default* nobody *has* to care about our formats most of the time
<jml> vila: I have to care about formats most of the time.
<vila> jml: You're not the average bzr user :-)
<jml> :)
<vila> jml: Of course *you* have to care, but aren't you happy that 'bzr upgrade' exists ?
<jml> vila: very happy, actually.
<vila> Man, when bzr-1.6 begun to warn me about all my old branches still using old formats, I was just surprised there was so many, but none of the upgrades (like in None) has a single problem
<a_c_m> is it possable to commit a "nothing changed" revision? We have several repro's and we want their revision id's to stay in sync
<jml> a_c_m: it is possible (bzr commit --unchanged) but that sounds like a strange thing to want.
<jml> a_c_m: why do you want the revnos to be the same?
<vila> ubottu: bug #90302
<ubottu> Launchpad bug 90302 in bzr "Improve help-formats" [Medium,Confirmed] https://launchpad.net/bugs/90302
<a_c_m> jml: we have 3 repro's for each project, /code /files and /database
<a_c_m> jml: dev's only have commit access to /code, but the dev server pushes out to /files /code /database
<a_c_m> jml: were still trying to work out the best process for what we need to do...
<jml> a_c_m: *nod*
<jml> a_c_m: what do you hope to gain from synchronizing revnos?
<a_c_m> jml: being able to pull a full site (code, files and db) by knowing the revision number
<a_c_m> jml: else they will get out of sync, and it will be harder to get a stapshot
<a_c_m> no?
<poolie_> a_c_m, hm, interesnting
<poolie_> there is commit --unchanged which will do this
<poolie_> you should probably also set append_revisions_only=True in the branch conf to stop people pushing over the branches and getting them out of sync
<a_c_m> wow, i've just tested... i didnt think bzr could do partial commits ie from sub folders. That might solve the problem no?
<a_c_m> if we just dont give write access to the /database and /files folders...
<a_c_m> if they try to commit, from / it will just fail. but if they commit from /code - all will be well ?
<poolie_> a_c_m, you can do this in the working copy
<poolie_> the server can't enforce those permissions
<a_c_m> ahh
<poolie_> though it would be feasible to write a server side hook that does check it
<poolie_> not so hard but you would need to learn a little bit about the bzrlib api
<a_c_m> poolie_: it think its going to be simpler to use multi-repositories.
<a_c_m> poolie_: ugg...
<poolie_> hm
<poolie_> how strong do you need the security to be? how about a shell hook in the non-developer checkouts that just makes sure they've only changed the files they're meant to?
<a_c_m> poolie_: humm, could be but it needs to be really simple and cross system (mac, linux and windowS)
<poolie_> so just to back up a bit
<poolie_> if people are committing to these things independently, how do you know which version of the code goes with which version of the db?
<a_c_m> let me back up and explain the situation
<a_c_m> ugg its quite intricate... bear with me
<a_c_m> 3 repro's - code, database and files. Developers need to check out all 3, but only every update code, the dev server can be triggered to sync, which means, pulling in code and committing database and files. Developers should never be able to commit to files and database, except to keep the revision numbers in sync.
<a_c_m> looking at it, your solution of a single repro with a server side hook is probably my favorite, how long might that take someone who knows what they are doing?
<matkor> hmmm how long bzr reconciel may work ? It's 10min already at and of bar ....
<AfC> matkor: (is the CPU still being used, or is it idle?)
<poolie_> a_c_m, so what does the server do when it commits to the database and files?
<poolie_> i guess i'm wondering: if there's no strict dependency between them
<poolie_> why not just have say a 'deployment' branch of all three, and push to that when it's ready to go out
<poolie_> similarly for 'staging' and whatever
<matkor> AfC: CPU still used
<a_c_m> so after a quick chat with poolie_ (many thanks) i'm going to try to clarify my problem again
<poolie_> a_c_m, so the content in the database that's committed by the server - where does that come from?
<poolie_> do people also log in to the server running the master db and make changes there?
<a_c_m> yes
<a_c_m> via drupal's main interface
<a_c_m> then we hope to have a sync.php script which dumps the db and performs the sync with the various repro's/folders
<a_c_m> ok, apologies for re-iterating what i'm trying to achieve, but i think i have it in a understandable format now :)
<a_c_m> Were building out the development process for a new Drupal site. We want the DEV server to only ever be updated by a script which pulls from BZR, so no manual editing ever happens.
<a_c_m> Drupal is brilliant but has a challenges, it stores a lot of config information in its database, so this needs to be backed up as well. For this reason we are thinking we need 3 repros (or folders), CODE, DATABSE and FILES.
<a_c_m> The developers should be able to check out all 3, but only every COMMIT to CODE. The DEV server will have a script on it which will dump the database and then COMMIT the user generate files to FILES and the database dump to DATABASE, after that it pulls in the CODE from bzr.
<a_c_m> With their code now on the DEV server, they log onto it and perform any of the db changes they need via the main drupal interface, once done, they commit thier chagnes again by re-running the sync script.
<a_c_m> Question is, how can i best achive this with BZR?
<poolie_> i think you should start by just having 3 branches, and committing to each of them either when you change the master db or whatever
<poolie_> it's possible that the code will get out of sync with the drupal config, but i don't think that problem is actually technically soluble
<a_c_m> yeah, i'm starting to see that...
<a_c_m> oh, how about a post commit hook on the CODE repro ? which fires off a ï»¿--unchanged commit on the other 2?
<a_c_m> (to keep the revisions in sync)
<a_c_m> i think, it might be ok to just have CODE and FILES (and store the db in FILES)
<a_c_m> so there would need to be the corresponding hook on FILES to trigger a ï»¿--unchanged on CODE...
<a_c_m> but that might do it ?
<vila> matkor: repository size is the main factor (overly simplifying), what is yours ?
<matkor> vila: 121 [MB] .. it's now 1h of cpu time but progressbar is back in middle after "Inventory regenerated." message ...
<vila> matkor: it can take far longer than 1 hour, feel free to kill it and run it at night
<vila> guilhembi_: ping
<guilhembi_> vila: pong
<uws> jelmer: pulling from webkit svn into my bzr branch using bzr-svn 0.4.13 icw bzr 1.8rc1 is very slow
<uws> jelmer: I remember to have had performance issues before.
<jelmer> uws, can you run with -Dtransport and see which steps are slow (by looking at ~/.bzr.log) ?
<jelmer> or perhaps, just pastebin ~/.bzr.log somewhere?
<uws> jelmer: running with -Dtransport now
<uws> determining changes 23541/37602
<uws> ^^ takes as while as well...
<uws> jelmer: each "svn update" takes time, and it's mostly cpu bound
<uws> 260.253  svn update -r36507:36508
<uws> 267.228  svn update -r36508:36509
<uws> jelmer: Aii... if I cancel and retry (as I did with -Dtransport) previously pulled revisions from the interrupted "bzr pull" are lost it seems... :S
<jelmer> uws, yes, that's right because of the way bzr works
<jelmer> uws, bzr-svn stores revisions in groups of 100 I think
<uws> jelmer: Ok, I'll just leave it running for a while then :)
<uws> jelmer: I'm running   "bzr -Dtransport pull"  right now, but there's not much debug info in .bzr.log, just the "svn update" lines and a few "XYZ copied from ABC" messages.
<jelmer> uws, and that's the step that's slow?
<glade88> hello.. If I have pushed a code once to a branch and I add a component to one of the subfolders of the code on my hard drive, how do I make the new change?
<glade88> I have done: bzr commit -m "Added plugin"
<uws> jelmer: between 5 and 15 seconds in between each svn update line
<glade88> and the bzr push <branch>
<jelmer> uws, could it be that the server is just slow?
<uws> jelmer: sometimes even a lot more, ~30s
<uws> jelmer: could as well be... it has been faster before ;)
<uws> jelmer: But if it's the SVN server being slow, why is bzr eating all my cpu :)
<jelmer> uws, ah, hmm
<jelmer> uws, I guess you'd better wait for 0.5 in that case, that should be a lot faster
<abentley> vila: Is there an SSH smart server we can use for testing?
<vila> I don't think so
<abentley> vila: Drat.  Makes it hard to test what user bzr+ssh is using...
<vila> abentley: I know the feeling :-/
<a_c_m> hey all
<vila> I ahve vague plans to add some in the lp:~vila/bzr/local_test_server plugin but didn't find the time so far
<a_c_m> anyone know why 'bzr ci -m "test" ' wouldnt work in a php exec() statment, but 'bzr status' does?
<vila> jam: ping
<abentley> vila: OTOH, maybe I don't need a successful bzr+ssh operation...
<vila> as in whitebox testing that will attempt to connect with the right user ?
<vila> s/that/& you/
<abentley> vila: right.
<vila> abentley: ha ! I just re-read the FIXME at the end of test_config.py :-/
<jelmer> james_w, I can reproduce Ted's problem now as well
<abentley> vila: Agreed :-/
<james_w> jelmer: do you know what the cause is?
<james_w> jelmer: did you also see the bug about the notification icon not being a notification?
<jelmer> it's only started appearing recently so I suspect it's indeed some upstream change
<vila> abentley: I suppose your need is urgent ? Because I have less vague plans to implement http auth servers in lp:~vila/bzr/local-test-server and bzr+http, I never thought about ssh but that may be possible (but beware of the caveats I encoutered when trying to do ftp servers)
<jelmer> james_w, Yes, I saw it but I'm not sure I agree with the submitter
<james_w> I kind of do
<james_w> I think there will be more complaints about it
<vila> abentley: May be you can just plug an *existing*, running bzr+ssh server like I do in this plugin
<abentley> vila: not deadly urgent, but Launchpad developers have been barking their shins on it.
 * vila search for barking their shins...
<abentley> barking-their-shins~=banging-their-shins
<vila> Hu hu, should be the rough equivalent of the french "pleurer leur mere" :)
<abentley> Raining their mother?
<vila> crying :)
<jelmer> (-:
<jelmer> james_w: it's not just there for notification, also to allow you to e.g. enable gateway to LAN
<vila> raining is pleuvoir
<jelmer> james_w, perhaps it should just be disabled by default
<abentley> vila: Right.
<james_w> jelmer: yeah, I think that would be better.
<vila> Woohoo ! Fixing bug #277537 with bzr reconcile requires 20 h, I was down to 2h10 last night with a dedicated plugin, and now I'm down to 312 *seconds*
<ubottu> Launchpad bug 277537 in bzr "annotate says revision modified file, "bzr diff -c" widly contradicts" [High,Triaged] https://launchpad.net/bugs/277537
 * vila had to share :)
<vila> jam: ping ping ^
<LarstiQ> woh
<LarstiQ> vila: it's fair to say it wasn't entirely optimized? :)
<vila> LarstiQ: Hold on ! I didn't optimize reconcile, I did a specific reconciliation
<vila> for a specific bug applicable only on specific repos based on results acquired with a bzr check that needded 32 hours
<vila> but yet... :)
<LarstiQ> vila: seeing as I have repositories with the exact same problem, I'm still interested :)
<a_c_m> anyone know what the return status of 3 means (or ideally where i can find a list of what the return status numbers mean?)
<LarstiQ> a_c_m: the same as diff(1), iirc 3 is modified
<LarstiQ> hmm, maybe not
<LarstiQ> a_c_m: right, 1 is modifications present in `bzr diff`, and 3 in general for bzr is an error occurred
<a_c_m> LarstiQ: i'm trying to call bzr from php via exec... and getting that...
<a_c_m> any ideas?
<LarstiQ> a_c_m: I'd look at the output of bzr
<vila> if bzr returns 3 you should find something in stderr (or the php equivalent)
<a_c_m> vila: LarstiQ: bzr --version works... bzr status ... returns nothing, but when i run the same command in a shell, it works fine
<LarstiQ> a_c_m: bzrlib/errors.py, EXIT_OK=0, EXIT_ERROR=3, EXIT_INTERNAL_ERROR=4
<a_c_m> LarstiQ: humm ok.
<LarstiQ> a_c_m: common causes, running `bzr st` while not in a branch
<vila> a_c_m: I don't know php but you need to get back the output from stderr and stdout, that's where bzr will explain why it fails
<a_c_m> LarstiQ: humm ok will do some exsautive testing... thanks
<a_c_m> vila: thanks too
<LarstiQ> a_c_m: which makes sense in an exec context. Are you sure the cwd is what it is supposed to be? (In other cases, the environment might not be what you think it is)
<a_c_m> LarstiQ: thats the thing i've tried full urls e.g. /usr/bin/bzr st /home/me/foo/dir/
<a_c_m> LarstiQ: still exists with 3
<LarstiQ> a_c_m: and /home/me/foo/dir/ is actually a branch?
<LarstiQ> a_c_m: if that works in the shell, I'm not sure what is different with php
<a_c_m> LarstiQ: yeah works in shell
<a_c_m> :(
<LarstiQ> a_c_m: you could also check ~/.bzr.log
<a_c_m> LarstiQ: aaah looking
<a_c_m> LarstiQ: the plot thickens! bzr info work...
<a_c_m> LarstiQ: worked it out
<LarstiQ> a_c_m: what was it?
<a_c_m> LarstiQ: it was due to the www-data user (who was doing the exec())
<a_c_m> thier home dir was /var/www
<a_c_m> which www-data doesnt have write access to, so couldnt make the .bazzar folder
<LarstiQ> ~/.bazaar/ you mean?
<a_c_m> yeah
<LarstiQ> ah yes
<a_c_m> as www-data is homed to /var/www
<LarstiQ> a_c_m: how did you figure this out?
<a_c_m> exec('whoami')
<a_c_m> then su www-data
<a_c_m> and then tried doing the same commands
<a_c_m> i also get "No handlers could be found for logger "bzr"" message
<a_c_m> but it doesnt seems to matter
<jelmer> w00t
<jelmer> "bzr svn-serve" can now natively provide svn checkouts from bzr branches
<jelmer> and it's *fast*
<jelmer> not as fast as svn itself obviously, but < 15 seconds locally for bzr.dev
<Odd_Bloke> jelmer: So I do 'bzr svn-serve my_branch' and then can 'svn checkout' that branch?
<jelmer> Odd_Bloke, yes
<jelmer> e.g.  svn co svn://145.97.197.14/trunk bzr.dev-trunk
<jelmer> (that's running with bzr.dev now)
<jelmer> It's not as quick as locally as I haven't added zlib support yet
<Odd_Bloke> 21:41:58 < lamby> Has it been tested with git-svn? *g*
<jelmer> It provides only a subset of the svn smart server commands, but there's no reason why that shouldn't work :-)
<jelmer> in particular, it can't do incremental updates yet, only full checkouts
<jelmer> which would be a bit of an obstacle for git-svn ;-)
<thumper> jelmer: why is this good?
<thumper> jelmer: I'm just wondering who is going to use this functionality
<jelmer> thumper: It means being able to provide svn access to users while migrating to bzr
<thumper> does git offer this?
<jelmer> thumper: E.g. you can use the netbeans svn plugin with a bzr repository
<thumper> ah, that's kinda nice
<LarstiQ> thumper: ie, leverage all of the 3rd party svn tools (but I guess you already got that)
 * thumper nods
<jelmer> thumper, also, it allows users who are already familiar with svn a way to check out the source code of a project in bzr without having to install or learn bzr
<thumper> and we all know there are lots of svn users out there
<jelmer> this last bit was one of the concerns within the Samba team while we were considering various DVCSes
<jelmer> thumper, Git doesn't have anything like this as far as I know
<Verterok> jelmer: WOW! that's awesome!
<jelmer> it's also a bit faster than "bzr co --lightweight", 1m11 vs 3m07 here
<LarstiQ> jelmer: have you analysed what makes the difference?
<jelmer> no, but I suspect it's because bzr co --lightweight hasn't been optimised yet
<jelmer> LarstiQ, svn co basically means sending all the tree contents without requiring acks from the client until everything is received
<LarstiQ> jelmer: right, so I was wondering if it's over the wire roundtrips/fileformat, or perhaps that svn_serve does less work client side, or what
<jelmer> LarstiQ, both
<jelmer> the number of round trips is far less with svnserve (4)
<jelmer> and there's no dedicated verb for Repository.revision_tree() in the bzr smart server
<mwhudson> jelmer: wow, cool
<wingo-tp> good day bzr hackers!
<wingo-tp> lifeless.
<wingo-tp> can i interest you in a bug
<wingo-tp> bugs are a good source of protein
<wingo-tp> https://bugs.launchpad.net/bzr/+bug/239499
<ubottu> Launchpad bug 239499 in bzr "corrupt knit index on an old arch-imported bzr repo" [Medium,Confirmed]
<LeoNerd> Hrm... bzr doesn't seem to like ControlMaster shared ssh
<LeoNerd> Control socket connect(/home/leo/var/run/ssh-master-leo@cel.leo:22.sock): Connection refused
<LeoNerd> srw------- 1 leo leo 0 2008-10-13 00:42 ssh-master-leo@cel.leo:22.sock
<LarstiQ> LeoNerd: I did use the combination in the past
<LeoNerd> Ya.. I'm sure it has worked
<LeoNerd> 28109 connect(3, {sa_family=AF_FILE, path="/home/leo/var/run/ssh-master-leo@cel.leo:22.sock"...}, 51) = -1 ECONNREFUSED (Connection refused)
<jam> LarstiQ: 'bzr co --lightweight' still does all the work locally (so it has to read the indexes, request the deltas, etc.)
<jam> I believe spiv was going to implement a smart verb for "get_record_stream()" which would allow us to stream the texts directly to the client
<jam> along with other benefits
<LarstiQ> jam: yet it doesn't store any of those?
<LarstiQ> that's ... suboptimal
<jam> "store any of those" ?
<jam> the deltas, yeah
<LarstiQ> sorry, too broad
<LarstiQ> jam: in delta form, or just deflated?
<jam> LarstiQ: I think it can depend on the parameters for 'get_record_stream()'
<jam> but for building a working tree, it would set the "give me fulltexts".
<jam> As yet, we don't have a habit of having the bzr:// protocol do deflate
<jam> it *could*, but if you are tunneling over ssh, it typically does it for you
<james_w> jelmer: hey, only just got round to looking at the bzr-gtk changes, sorry.
<james_w> jelmer: does the change require that bzr-stats be installed during the build?
<james_w> jelmer: or is that the "is_versioned" thing?
<jelmer> james_w, It's required while creating the .orig.tar.gz
<james_w> ok
<james_w> I was going to re-use the 0.95 .orig.tar.gz
<jelmer> you should be able to just add a patch that adds the pickle file
<james_w> is the pickle file binary?
<jelmer> nope
<james_w> there is a credits.pickle file already
<james_w> does it just need installing?
<jelmer> yeah
<jelmer> the changes I mentioned yesterday should take care of that
<james_w> http://paste.ubuntu.com/58061/
<james_w> that'd the diff I extracted from what you said
<james_w> sorry for being slow
<jelmer> did I include r607 ?
<james_w> ah, just got the range wrong, I'm sure
<james_w> ah, much better, thanks
<poolie_> hi
<james_w> thanks jelmer, I've just uploaded the change to install what's there, I'll sync up after release
<james_w> hi poolie_
<wingo-tp> going to sleep -- but lifeless, i really would appreciate a look at that repo corruption bug -- I've had it for months at this point
<Peng_> jelmer: ping?
<jelmer> Peng_, pong
<Peng_> jelmer: Hi. I have a bzr-svn 0.4 issue: if I 'bzr branch' from an svn checkout, it builds the branch, but tracebacks when building the working tree with "AttributeError: 'SvnWorkingTree' object has no attribute '_transport'".
<awilkins> jelmer: bzr svn-serve ooh
<Peng_> I should file a bug, right? :P
<jelmer> Peng_: There's already a bug open about it - it's fixed in trunk
<Peng_> jelmer: Ah, OK. :)
<jelmer> 'morning poolie_
<Peng_> jelmer: Should I use the trunk with bzr.dev? Is it fairly stable?
<poolie_> hi jelmer
<jelmer> Peng_, no, trunk is still unstable at this point. it will eat your cat, etc
<Peng_> OK. I like my cat.
<Peng_> I totally didn't think to search the bug database. Whoops.
 * awilkins thinks your cat is nice. With ketchup and fries.
<fullermd> You're crazy.  Ketchup is all wrong for cat.  Need something mayo-based.
<woeye> hi all
<awilkins> Step 1: Gut, clean, and defur cat  2) Rub skin with salt, cumin, and oil  3) Spitroast on fire.
<fullermd> There's certainly room for a variety of opinions.  There is, after all, more than one way to skin a cat.
<fullermd> Way #28: Krazy Glue and an electric toothbrush.
<awilkins> Way #79: Tie a pot magnet to it's tail and throw it into the Large Hadron Collider
<davidstrauss> Is it possible/sane to checkout from another checkout?
<fullermd> I doubt it would be sane, whatever else it may be.
<davidstrauss> fullermd: What would you recommend for running a dev -> staging -> production flow?
<fullermd> Way too broad   :)
<davidstrauss> make dex and production both checkout of staging?
<davidstrauss> dev*
<fullermd> In MY flows, dev is local thing to the developer in whatever fashion, staging (well, doesn't exist, but the closest analog) and production are just different places that the files are copied by a developer.
<fullermd> But I don't have any of the three being branches or anything.  Version control doesn't touch deployment.
<fullermd> If they were, presumably they'd be different branches, and changes were moved up the tree as they were considered to advance.
<fullermd> e.g., devs would have whatever dev stuff they were dev'ing, staging would be a branch presumed-cooked dev bits were merged into, and production would be periodically pull'd staging.
<fullermd> But the best (or even 5th-best) answer depends pretty directly on exactly what and how you're dev'ing, what your deployment mechanism and schedule look like, yada yada.
<davidstrauss> fullermd: thanks anyway :-)
<lifeless> davidstrauss: if you want a waterfall of sucessively more tested locations
<lifeless> davidstrauss: I would use pull and branches
<davidstrauss> thanks
<lifeless> because you may wish temporary divergence, for cherrypicking/emergency bugfixes in e.g. prod
<davidstrauss> Easier question: how can I get a listing of the pending updates? In svn, I use svn status --show-updates.
<bob2> bzr missing
<bob2> oh, for a checkout?
<davidstrauss> bob2: yes, for a checkout
<awilkins> davidstrauss: bzr missing --theirs
<awilkins> davidstrauss: THat's just reviiosn logs though
<spiv> Hmm, bzr missing probably should work in checkouts.
<awilkins> you can do status netween 2 branches, that should work
<davidstrauss> spiv: when i run it in a checkout, i get "bzr: ERROR: No peer location known or specified."
<spiv> awilkins: that doesn't appear to report revisions in the branch that aren't yet in the checkout
<spiv> davidstrauss: sorry, I meant "it ought to be fixed to work", not that "it should already work for you" :)
<spiv> davidstrauss: you can do "bzr missing --theirs BRANCH", where BRANCH is the path or url of the branch the checkout is of.
<spiv> I thought there was an easier way, but I can't remember what it is.
#bzr 2008-10-16
<spiv> Ah, "bzr missing --theirs :bound" is slightly simpler.
<fullermd> Oh look, another layer violation...
<davidstrauss> fullermd: layer violation?
<fullermd> Oh, it's another log on a long-standing gripe of mine.
<nbjayme> hello folks.  my repository has grown. is there a way to have bzr flush the rest of the revisions?  from revision 1 to 68 and i want to flush revisions 1 to 30... that'll end my repository to have only from revisions 31 to 68.   ?
<ferringb> nbjayme: why do you want this?
<ferringb> kind of defeats the purpose of a vcs if you're chucking out history
<nbjayme> okay okay....  probably i worry too much of diskspace.  :) he-he
<ferringb> nbjayme: if you're talking thousands of revs, sure
<ferringb> although personally that's still pretty small, at least for the repos I deal w/.  either way, look into the pack command
<lifeless> poolie - split inv fetching mysql down to under 1sec/rev
<lifeless> nbjayme: how big is your tree?
<jml> lifeless: can you please give me permission to set priorities on testresources bugs?
<lifeless> nbjayme: I'd be bothering with that at the 100's of thousands of files & revisions
<lifeless> jml: whats the metaproject called?
<jml> lifeless: pyunit-friends
<nbjayme> @ferringb... no not really that large.... i just want to make it minimal to lessen some bandwidth transfer.  @lifeless, pretty small i would say....
<lifeless> nbjayme: deleting history like that is *possible* but it will not result in a significant bandwidth reduction because texts are delta compressed
<nbjayme> lifeless... okay.... i'm still around 8mb though..  :)
<lifeless> jml: I've put it in pyunit-friends, that may have done it?
<lifeless> nbjayme: how are you measuring that?
<nbjayme> i go to nautilus and righ-click on the .bzr directory....
<lifeless> nbjayme: that figure doesn't represent what is transferred
<bob2> nbjayme: are you often copying the whole repository, or just updates?
<lifeless> nbjayme: there are transactional details that are not copied, and incremental pulls only copy new content anyway
<jml> lifeless: thanks, let's see.
<nbjayme> the project is small, i'm still going to upload it in launchpad... :-)  just wanna be a good netizen... he-he. yes, transfers to repo are faster after the initial commit or push. :)
<jml> lifeless: nope. There's no such thing as a driver or bugs supervisor for super-projects.
<jml> lifeless: the thing to do is make a team with you and I in it and set it as the bugs supervisor (or appoint me project maintainer, whichever works)
<lifeless> garh
<lifeless> so complex
<lifeless> jml: I think I'd like to stay as maintainer :P
<jml> lifeless: de jure at least
<lifeless> jml: of the day?
<jml> lifeless: "by law". often contrasted with "de facto"
<jml> :P
<lifeless> oh right
<lifeless> architecture astronauts R us
<lifeless> just filed my LP bug for the day
<jml> heh heh
<lifeless> (bug supervisor field requires a precreated team)
<lifeless> jml: https://edge.launchpad.net/~testresources
<jml> lifeless: I've joined, moderate me please.
<lifeless> done, you are now moderate
<jml> lifeless: thanks.
 * jml is born to be mild
<jml> lifeless: we're saying that a commit to trunk is a release, right?
<lifeless> jml: yes
<lifeless> jml: 'early and often'
<lifeless> jml: can't get more early than every commit :P
 * jml spams lifeless with bug mail.
<lifeless> too late
<lifeless> you already did
<ferringb> curious; fixing tracbzr, one thing I did was yoink out the revno in favor of revision_ids (will add revno at some point, but it complicates it); problem being, that's chunks of an email address most of the time.  how are others handling the scraping potential there?
<ferringb> ...aside from just using revnos instead
<jml> lifeless: this is round #2 :)
<lifeless> ferringb: not sure
<lifeless> poolie_: I've put the usertest order back - because the numbers are a *lot* easier to read in the order I put together last week
<poolie_> ok
<poolie_> did you kill it too?
<lifeless> poolie_: eys
<lifeless> poolie_: fingers crossed .inv will be 'fast enough' now
<lifeless> its about 0.8sec/rev for me now
<poolie_> did you kill it twice or more?
<lifeless> on my laptop
<lifeless> yes
<poolie_> it looked like it disappeared a while ago i was just trying to work out why :/
<lifeless> twice, once when I pushed my branch, and then again when I saw it skip .inv
<lifeless> sorry for any panic :)
<lifeless> bbiab
<poolie_> woo, python compiled the extensions on kerguelen
<poolie_> and selftest is running
<lifeless> poolie_: its pulling much faster; 1.7G used so far :P
<lifeless> poolie_: previously that took a day or so
<poolie_> great
<jml> spiv: hi
<jml> spiv: tell me where the smart server does error translation.
<jml> I have a bug that needs a-filing.
 * jml finds it manually
<spiv> jml: look at the bottom of bzrlib/remote.py
<spiv> jml: that's where is mostly happens on the client side (although there's also some in bzrlib/transport/remote.py).
<jml> spiv: I get this when I push to a non-existent product on Launchpad: bzr: ERROR: Generic bzr smart protocol error: Permission denied: "Project 'no-such-product-xxx-flibble-ai-po' does not exist."
<jml> spiv: I have 99% confidence that we are raising an honest-to-goodness PermissionError from the bzr running on the server.
<spiv> jml: which verb does -Dhpss reveal that to be in reply to?
<spiv> Hmm, maybe BzrDir.open?  There's a bug open about that one, I think.
<jml> 5.217  hpss call:   'mkdir', '/~jml/no-such-product-xxx-flibble-ai-po/branch', ''
<jml> 5.217               (to bzr+ssh://bazaar.staging.launchpad.net/%7Ejml/no-such-product-xxx-flibble-ai-po/branch/)
<jml> 5.569     result:   ('error', 'Permission denied: "Project \'no-such-product-xxx-flibble-ai-po\' does not exist."')
<spiv> jml: (https://bugs.launchpad.net/bzr/+bug/278673 is the bug I was thinking of)
<ubottu> Launchpad bug 278673 in bzr "Traceback when uploading to an invalid location" [High,Confirmed]
<mwhudson_> note that launchpad doesn't need to be involved
<mwhudson_> $ bzr push bzr+ssh://localhost/bob
<mwhudson_> bzr: ERROR: Generic bzr smart protocol error: Permission denied: "/bob": [Errno 13] Permission denied: '/bob'
<spiv> jml: that's not a PermissionDenied error on the wire, that's a generic 'error'.
<jml> spiv: interesting
<spiv> jml: so the problem is server-side.
<jml> mwhudson_: also interesting.
<spiv> (and quite possibly still in bzrlib)
<spiv> jml: bzrlib.smart.request.SmartServerRequest._call_converting_errors is probably the culprit
<jml> spiv: looks plausible.
<spiv> jml: in fact, it appears that currently the only place that encodes a PermissionDenied error is an explicit except in bzrlib.smart.vfs.GetRequest
<jml> spiv: how many places does one need to list an error before it gets translated properly?
 * jml finds https://bugs.edge.launchpad.net/bzr/+bug/246792
<ubottu> Launchpad bug 246792 in bzr "permissiondenied not translated on creating branch over bzr+ssh" [Undecided,Confirmed]
<spiv> jml: Ignoring tests, typically three.
<jml> spiv: that seems like at least one place too many
<spiv> jml: server side, client-side vfs, client-side non-vfs.
<spiv> The latter two can probably be unified somewhat sanely now.
<Linuturk> I've kinda followed the mini tutorial, but I've got a question. I created a branch on my laptop, and then pushed that to my personal sftp server
<Linuturk> but, none of the files are showing up on the server
<Linuturk> ideas?
<Linuturk> there is a .bzr directory on the server though
<Linuturk> just, no files in the project folder
<mwhudson> Linuturk: pushes to a remote location don't push a working tree too
<mwhudson> Linuturk: the push-and-update or 'upload' plugins might be what you want
<mwhudson> (or maybe you shouldn't care, the .bzr directory contains enough to share the branch)
<Linuturk> hmmm, so, if my laptop died, would the files be safe?
<Linuturk> or, is my laptop considered the primary repo
<Linuturk> and, the other links just point to it?
<mwhudson> no
<mwhudson> the .bzr folder contains the complete history of the branch
<mwhudson> if you go to the server and run 'bzr co'
<spiv> Linuturk: the files would be safe.  The .bzr directory contains all the data.
 * Linuturk quietly installs bzr on the server first
<Linuturk> lol
<spiv> Linuturk: you can do "bzr log" or "bzr branch" or "bzr checkout" etc from that remote location.
<Linuturk> ooo, what's the bzr co ?
<Linuturk> checkout?
<Linuturk> o sweet
<Linuturk> and, that pulled from the local .bzr
<Linuturk> not my laptop
<Linuturk> I'm looking to use bzr to control system configs on my servers
<Linuturk> and, it seems like this will work great
<Linuturk> that sound good?
<poolie_> it does
<vila> hi all !
<jml> hello.
<spiv> Sometimes I think it'd be nice to be able to make a loom post hoc from a series of commits.  So I could just start hacking on a non-loom branch, then go e.g. "loomify --base-from ancestor::submit", and get a loom with a thread per commit.
<spiv> Well, by "sometimes" I mean "just now" :)
<vila> A *thread* by commit ? Wow, care to give a bit more context ?
<spiv> vila: the use case I have in mind is where I've just started hacking without being sure in advance what shape it'll take, or how far I'll want to go.
<spiv> vila: so I do something interesting, commit it, do some more, commit, etc.
<spiv> vila: and then I start thinking "this would make a nice series of changes to submit for merging, but I'd like to tweak some of the earlier steps"
<spiv> If those steps were already in a loom, then I'd be set, but in this case I didn't have that foresight.
<vila> So certainly you want somme commitS in the same thread no ?
<spiv> But if I could trivially make a loom pre-populated with threads based on my commits, then I wouldn't need the foresight.
<spiv> Sure, probably.  But it's easy to collapse threads.
<spiv> It's harder (not impossible, just not as easy) to split a thread.
<vila> I learn recently and with a bit of pain that combine-thread is more detructive than I thought
<spiv> That's true, but that's a separate problem :)
<vila> So how do you collapse threads then ?
<spiv> vila: "bzr combine-thread"
<spiv> vila: e.g. if I have commits r1, r2 and r3, and corresponding threads t1, t2, t3, then from inside t2 "bzr combine-thread" will leave me with t1, t3.
<vila> I'd like at least a warning there when I'm about to shoot in my foot :)
<Mez> spiv, sorry, havent been able to get round to the whole bzrssh thing yet... it is on my todo list though
<spiv> vila: sure, or at least an easy way to unshoot the foot
<AfC> Mmmm. Self-inflicted wounds.
<vila> I think my use case was: r1, r2, r3 in threads t1, t2, t3, then in t2, add r4, combine-threads, boom, r4 is gone
<lifeless> vila: spiv: patches, appreciated, kthx
<spiv> vila: right.  I think it ought to require a --force when a combine-thread will lose a revision not merged in later threads.
<vila> lifeless: things would more easier if the loom test suite was passing :-/
<lifeless> spiv: bzr create-thread; bzr pull . -r thread:<dead-head>
<vila> be even
<lifeless> vila: abentley has fixed that
<spiv> lifeless: I know, just thinking out loud before I start hacking on a new idea.
<vila> lifeless: huh ? bzr missing lp:~bzr-loom-devs/bzr-loom/trunk : Branches are up to date.
<vila> damn lp:~abentley/bzr-loom/stuff
<vila> why isn't that merged in trunk ?
<poolie_> hi vila
<abentley> vila: wait, you're cursing me for fixing stuff?
<vila> abentley: Surely not !!! I didn't think you were online ! THANKS A TON :_
<vila> :)
<abentley> vila: of course, I *shouldn't* be online.
<abentley> But you used my nick, so I'd have seen it in the morning.
<vila> hehe, I didn't realized there was 'damn' and 'abentley' so close :)
<vila> abentley: I was willing to review your user stuff but jam beat me to it :) (let's bring him into this too ;p)
<abentley> lol
<vila> spiv: just notice your --force remark, agreed
<vila> abentley, lifeless, spiv: so what's the policy to bring remarkable abentley work merged into trunk ?
<vila> :-)
<abentley> spiv: I kinda want that thread-per-commit thing every now and then.  But usually I just want to split a thread at a given revision.
<abentley> spiv: So given r1, r2, r3 in a thread, I want to create a new thread with r3 and change the existing thread to have r2 as its head.
<abentley> spiv: Which is doable, if a bit annoying.
<spiv> abentley: yeah, that would be good.
<poolie_> hi spiv
<a_c_m> i need a nudge in the right direction... i have checkouts via bzr:/localhost working, but want to only be accessible over ssh - any tips / links?
<vila> abentley: ping
<vila> I'm just pushing a trivial branch at lp:~vila/bzr/2843443-docfix
<vila> sudden;y bzr says: Using default stacking branch /~bzr/bzr/trunk at bzr+ssh://vila@bazaar.launchpad.net/%7Evila/bzr/
<abentley> vila: pong
<vila> Hurrah, did I think, automatic stacking !
<vila> But then the push seems to take as long as usual...
<vila> Should I file a bug ?
<vila> Or did I misunderstood something ?
<abentley> vila: Are both the branch and repo in 1.6 format?
<abentley> scratch that.  Yes, it should be giving you auto stacking, and shouldn't take as long as before.
<vila> bran/format: Bazaar Branch Format 6 (bzr 0.15)
<vila> and the message is strange, what is '/~bzr/bzr/trunk' ?
<vila> *I* suspect it's on launchpad, but yet
<abentley> vila: it's a host-relative path.
<vila> what host ? mine ? launchpad ? the target branch's  ?
<vila> ohhh, you mean an hpss one and it doesn't know its name ?
<abentley> vila: We stack on /~bzr/bzr/trunk rather than bzr+ssh://vila@bazaar.launchpad.net/~bzr/bzr/trunk so that it works over all protocols.
<abentley> It is relative to the target branch.
<vila> Ha, some problem than yesterday, or related at least
<vila> for clarity it would be nicer if the host was specified or even the url used internally no ?
<abentley> vila: It's basically a question of precision vs accuracy.
<abentley> The value we are writing to branch.conf is literally /~bzr/bzr/trunk
<abentley> If we change it the way you're suggesting, then we can't tell from that message whether it will work over multiple protocols.
<vila> I see
<vila> How about "Using stacking branch /~bzr/bzr/trunk from branch.conf" or something ?
<vila> and I stop there :)
<abentley> vila: You mean "Writing stacking branch /~bzr/bzr/trunk to branch.conf"?
<vila> wow, you mean this message is emitted when writing branch.conf ?
<vila> if that the case, yes
<vila> I will be happy with that, more even as it make it clear that lp is doing it
<james_w> it's doing that on the host? If so, I think stating that might be good.
<abentley> james_w: No, it's not.
<james_w> oh, ok
<abentley> vila: lp is not doing it.  bzr is doing it.  lp is just providing a file that suggests a location.
<abentley> vila: the choice to follow lp's suggestion is made by bzr.
<vila> what is the file name you're referring to ?
<abentley> vila: bzr+ssh://abentley@bazaar.launchpad.net/%7Ebzr/bzr/.bzr/control.conf
<abentley> or for the branch you're pushing,  bzr+ssh://bazaar.launchpad.net/%7Evila/bzr/.bzr/control.conf
<Odd_Bloke> Is there a way to set the parent of a branch from the UI, without having to do a ``bzr foo --remember``?
<james_w> Odd_Bloke: if you count vim as a UI
<Odd_Bloke> It seems like there should be a way to do it, but I'm not sure to what extent we want to avoid people editing the config files under .bzr...
<vila> It would help if you tell us *why* you feel that need just now
<vila> Because ISTM that you need to do that *before* issuing a bzr command which may be laking the --remember option :)
<abentley> vila: You say about AuthenticationConfig._save: "Save the config file, only tests should use it for now."
<abentley> vila: Is that because it's not atomic?
<vila> Not more nor less than other config, but the true reason was because bzr never modifies it
<vila> Are you working on that right now ?
<Odd_Bloke> vila: The upstream location has moved, and the user wants to do this while they're doing the move, rather than next time they actually want to perform an operation.
<Odd_Bloke> s/upstream/parent/
<vila> Odd_Bloke: I see
<abentley> vila: Yes.
<vila> abentley: ok, I'll work on something else then, I'm looking at your previous patch anyway
<abentley> vila: As I mentioned to jam, we might want to support different authentications for sftp and bzr+ssh eventually.
<vila> I didn't see that, can you explain why, it sounds strange
<abentley> vila: Well, we support different authentications for other protocols.
<vila> you can already differentiate on port or on path
<abentley> vila: http and ftp can also be differentiated on port.
<vila> sure, all schemes are handled the same
<vila> but sftp and bzr+ssh really use ssh
<vila> and the remote host will handle them with the same authentication
<abentley> vila: But is that an implementation detail?  Is "sftp" not a more obvious scheme for controlling sftp?
<vila> hmmm
<abentley> I know that for launchpad, it will be convenient to specify 'ssh'.
<vila> I don't want users to define the same settings for sftp/bzr+shh or http/bzr+http
<abentley> I'm not proposing replacing 'ssh'.
 * vila hopes jam is not around and catch bzr+ssh typo...
<vila> What are you proposing ?
<vila> that sftp and bzr+ssh are handled as ssh aliases ?
<abentley> I'm saying that one day, we may want to support "sftp" and "bzr+ssh" as additional schemes in authentication.conf
<vila> I don't understand what that means
<vila> Currently we use auth.get_user('ssh',  will that change ?
<abentley> vila: Yes, it would change to if auth.get_user('sftp...) is None: auth.get_user('ssh'...)
<vila> Do you have a need to specify, for the same host, different credentials or do you just want to be able to use sftp/ssh/bzr+ssh in the authentication.conf file interchangeably ?
<abentley> vila: Neither.
<vila> So what ? >-<
<abentley> It would not make sense for bzr+ssh to affect sftp.  It would not make sense for sftp to affect bzr+ssh.
<vila> It makes sense to specify only once the credentials that can be used for both
<abentley> And you would not *need* to specify different credentials for the same host.  You could specify 'ssh' instead.
<vila> And it may even be mandatory to store them in things like OS X keychain or gnome keyring, i.e. sticking to known schemes
<vila> but if I use sftp and connect to bzr+ssh the credentials will not be found ?
<vila> but if I define sftp  credentials and connect to bzr+ssh the credentials will not be found ?
<abentley> vila: Right.
<vila> Eerk, what's the point then ?
<vila> While writing the spec I *did* use sftp until I realized that it will be a trap for the user because all the remote host knows is users or keys for ssh, users for ftp, users for http, etc
<pysquared> Hello.  I am migrating from CVS.  Is there a way to get Bazaar to either preserve mtime, or set the mtime of checked out files to the date of the last file change?
<abentley> vila: There are certainly cases where users have multiple accounts on one machine, one for shell access, one for Bazaar.
<abentley> vila: I haven't come up with a plausible reason for having two accounts, both used for Bazaar.
<vila> You also need to come up with a way to handle that on the remote host
<vila> but it may be possible with different ports
<lifeless> abentley: on the way to bed... but you might like to know that the losa's run two accounts on launchpad's code hosting service from one unix account, on a pqm machine
<abentley> vila: I don't see what the problem is.  It's easy to have multiple ssh accounts.  You just specify username.
<lifeless> abentley: (both accounts are for separate unrelated private branches)
<lifeless> anyhow, dunno if that matters; gnight everyone
<beuno> night lifeless
<nbjayme> vila: does that mean bzr+ssh is the most preferred way. i use bzr sftp. :(
<nbjayme> ?
<nbjayme> gnight lifeless.
<vila> nbjayme: that's totally unrelated but bzr+ssh should gives you better performances :)
<nbjayme> okay... thanks. :)
<vila> nbjayme: we are discussing how to describe credentials in authentication.conf
<vila> abentley: the only problem I have is that declaring sftp credentials leads to bzr+ssh credentials being not found except if use ssh, go explain that to the average user :-)
<abentley> vila: Anyhow, as I said, I'm not interested it doing it now.
<vila> ok
<vila> abentley: what is the scope of you modification then ? Writing an authentication.conf file when launchpad-loging is used ? Or more ?
<vila> LOSA: ping, pqm blocked
<abentley> vila: Also, writing an authentication.conf entry when it discovers that there is a configured login, but no corresponding authentication.conf entry.
<abentley> vila: But I think that's all.
<vila> ok, great, I can work on other parts then
<pysquared> Bazaar does not set mtime of checkout out files (which I would like), but when doing "bzr diff --using=...", the old/* files it creates have the mtime set (so it is possible).
<pysquared> Should I submit a patch?
<pysquared> Any bzr wizards around right now?
<abentley> pysquared: Setting the mtime to the stored date messes up build systems.  We do not want that.
<pysquared> I did not realise until I started using bzr how much I used mtime as a visual clue.  i want that.
<pysquared> Perhaps a checkout --restore-mtime option?
<pysquared> I hate coming back to work on a tree, doing a checkout and all the mtimes are the same.  Anyone else find this?
<abentley> pysquared: This has been discussed on the mailing list in the past.  You should probably read up on it before trying to land such a patch.
<pysquared> abentley: thanks, I did search a bit but found nothing, so I asked here, you guys are always helpful.  I will look again.
<abentley> pysquared: http://search.gmane.org/search.php?group=gmane.comp.version-control.bazaar-ng.general&query=mtime
<abentley> pysquared: The ones about "revert" would also apply to checkout.
<pysquared> abentley: fantastic
<qebab> Hi. I have a bzr repository that I'm trying to make a svn repo from, for a couple of friends to use. I'm having problems getting things working here. Could anyone tell me how I should do this? I'm probably just doing it wrong, but I'm getting a lot of weird errors (Everything from segfaults to AttributeErrors). I'm using bzr-1.3.1ubuntu0 and bzr-svn 0.4.9-1.
<jelmer> qebab, please try a more recent version of bzr-svn
<qebab> jelmer: okay. As to how to do this, I svnadmin create a repo, svn co it somewhere, and then I bzr push to it?
<qebab> or is there further magic I need to work
<jelmer> qebab, there's no need to svn co it
<jelmer> just "bzr svn-push <svn-repository-location>/trunk"
<qebab> cool :)
<nbjayme> i recently read in the launchpad news about stacked format.  and, it's blazingly fast in uploading my large repo but under +junk.  now I have a repo associated with a project... i tried --overwrite but it did not update the remote repo's format.  must i really delete the project's branch and reupload / push?
<nbjayme> i meant *delete the focus branch in launchpad* and push my local branch?
<jelmer> nbjayme, yes, I think so
<nbjayme> okay thanks!.... by the way, congrats to the devs for the great feature. :)
<qebab> jelmer: when running make for bzr-svn, it gives me this: /bin/sh: rst2html: not found
<qebab> jelmer: is that going to be a problem?
<Odd_Bloke> qebab: That's presumably just for docs, but you could just install it?
<qebab> Odd_Bloke: the apt package was apparently not recent enough :)
<abentley> jelmer, qebab I don't think there's a requirement for the target branch to be in format 1.6.
<jelmer> abentley: Sorry, I think I'm missing some context
<abentley> jelmer: Sorry, I meant nbjayme
<abentley> jelmer: I don't think there's a requirement to update the format of focus branches in Launchpad.
<jelmer> abentley, ah, indeed
<jelmer> abentley, related to that, it would still be nice to have a 'upgrade' button or "bzr upgrade" on a HPSS connection work a bit better ;-)
<abentley> jelmer: Yes, it does, but upgrading is async, and would have to run on a non-web machine.  Therefore a job handling framework is required.  I have been working on one.
<abentley> jelmer: I thought bzr upgrade on hpss was decent now, though.
<jelmer> abentley, it works, but still does the actual conversion locally, thus it's very slow
<sohmestra> Given a bazaar branch, and and a branch that is based on that branch, yet lacks any common history...is there any way to "graft" the 2nd branch back onto the first?
<sohmestra> "lacks any common history" meaning: an export of the original branch was placed under revision control and development continued from there.
<beuno> sohmestra, both versioned with bazaar, only that the second one wasn't branched from the first one?
<abentley> sohmestra: You could perhaps regenerate the second one with the "rebase" plugin.  jelmer would know more about that.
<sohmestra> beuno: correct
<beuno> sohmestra, what abentley said  :)
<sohmestra> abentley: I was fiddling with that...but it complained about having no common ancestery, so I figured that I didn't understand what it was supposed to be doing
<sohmestra> anyway, I'll fiddle some more
<jelmer> rebase doesn't handle the case where there is no common history yet (bug 231674)
<ubottu> Launchpad bug 231674 in bzr-rebase "can't replay, need maptree support in rebase" [Wishlist,Triaged] https://launchpad.net/bugs/231674
<abentley> jelmer: what's maptree?  Remapping file-ids?
<jelmer> abentley, yes
<abentley> jelmer: I think a PreviewTree would also work for that.
<jelmer> abentley: MapTree does exist, it's just not hooked up in the bzr-rebase commands
<jelmer> bzr-svn's upgrade command makes use of it though
<abentley> jelmer: Yeah, I see it.
<jelmer> abentley: I guess it wouldn't be a bad thing to get rid of it in favor of PreviewTree though
<abentley> jelmer: All other things being equal, of course :-)
<abentley> jelmer: maptree looks like it reimplements the Tree API.  Can you use it as a merge source?
<jelmer> abentley, yes, that's the idea
<abentley> Wow, I'd have thought you needed a bigger implementation to support that.  Good stuff.
<jelmer> hmm, it doesn't appear we're doing that yet so it may not be complete anymore
<mtaylor> hey all... if I made a stacked branch and want to replace it with a normal branch ... what's the best way?
<beuno> mtaylor, maybe push --overwrite?  I'm not sure if that will work
<beuno> you can, alternitavely, delete it and push again, of course
<mtaylor> beuno: but locally... if I branch from it, will I get another stacked branch, or one with everything?
<beuno> if you branch from a stacked branch, I don't think it defaults to stacked, you would get the full branch, unless you specify otherwise
<LarstiQ> beuno: hmm, that would surprise me
<beuno> LarstiQ, me too, but, I've been suprised before  :)
<LarstiQ> :)
<ktenney> Howdy, seeking help creating an alias from a script. Looks like bzrlib.builtins.cmd_alias.set_alias, but I've not had success using this
<ktenney> I don't understand the cmd_xxxx stuff in general, is there doc?
<LarstiQ> ktenney: the cmd_ stuff is not really meant to be invoked from other python code
<ktenney> ah, what is recommended for defining an alias?
<LarstiQ> ktenney: cmd_ should use other functions, those would be more fit for bzrlib consumers
 * LarstiQ looks at alias
<LarstiQ> ktenney: config.GlobalConfig().set_alias(alias_name, alias_command) it looks like
<LarstiQ> ktenney: where config is bzrlib.config
<ktenney> LarstiQ: thx, I'll try that ...
<ktenney> LarstiQ: works, thanks, bye.
<LarstiQ> ok :)
<mwhudson_> jam: did you see that if your bzr branches are in a stackable format they should be stacked on lp:bzr now?
<mwhudson_> jam: might save your dsl line some stress :)
<jam> mwhudson_: not entirely, I'd have to upgrade all my branches, which would cause LP to re-mirror everything
<jam> so potentially in the future it will help
<jam> but it wouldn't help for me to go do it right now
<jam> :)
<mwhudson_> well, if the branch had been merged into lp:bzr it would be a pretty light mirror...
<mwhudson_> so i'm not sure i really see that
<abentley> jam: Thanks for all the reviewage
<jam> abentley: I'm happy to try and get our queue unstuck from time to time :)
<jam> your's just happen to be at the bottom of my email and thus easiest to find
<pickscrape> Anyone know off the top of their head what bundle buggy matches against when deciding if someone is a voter or not?
<beuno> email address
<beuno> or, you log in through the webui
<pickscrape> Just the email address, and not the name part?
<beuno> yeap, just the email address
<beuno> of course, abentley would know 100% for sure
<pickscrape> beuno: thanks. Just trying to debug why it's not working for me. That helps :)
<beuno> but I'm 95% sure  :)
<abentley> pickscrape: The email address and the name part.
<pickscrape> abentley: ah, so if you have two mail clients that have slightly different names set up (though using the same email address), you have to be registered independently for each name?
<abentley> pickscrape: Well, each email-id needs to be associated with your account.
<pickscrape> Ah, you mean in submitter.id?
<beuno> phew, good thing I stuck with 95%
<beuno> abentley, just curious, why do you check the name as well?
<abentley> beuno: mostly because it was the fastest thing at the time.
<beuno> abentley, heh, ok, makes sense   :)
<abentley> lifeless: ping
<lifeless> abentley: hi
<abentley> lifeless: nm.  PQM was stuck.  Isn't now.
<lifeless> abentley: did a losa intervene, or did it just come good?
<abentley> lifeless: herb intervened.
<lifeless> k; do we know the cause?
<pickscrape> What is the meaning/purpose of the "My Pending" and "Mine" tabs in BB?
<jelmer> pickscrape, one is stuff you haven't reviewed (including stuff from others)
<jelmer> pickscrape, the other are your own submissions
<jam> pickscrape:  things you have submitted which may be marked 'resubmit'
<jam> versus things which you might have reviewed
<jam> and may be responsible for merging
<pickscrape> Right. I've submitted one thing myself (the only thing so far) and it not appearing under either.
<pickscrape> It does appear under "My Todo" and "Pending" though.
<a_c_m> i'm trying to get bzr working on my local host , using ssh+bzr but cant seem to get it to work
<a_c_m> (testing it ready for a deployment on a server)
<bob2> is bzr in your PATH?
<a_c_m> its in /usr/bin which is in my path yes
<a_c_m> i get 2 errors when i try it
<a_c_m> TERM environment variable not set.
<a_c_m> bzr: ERROR: Generic bzr smart protocol error: bad response ('',)
<a_c_m> i did quite a bit of google searching, i was quite supprised how little documentation there is on setting up a bzr server (plenty on using bzr though)
<fullermd> That sounds like your shell rc files spitting output, confusing bzr.
<a_c_m> ahhhh
<a_c_m> that would be true!
<a_c_m> let me try 2 ticks
<a_c_m> well that gets me closer for sure!
<a_c_m> Oh my... it worked
<a_c_m> thank you VERY much fullermd !
<a_c_m> i never would have worked that out
<fullermd> Oh.  Well, it's surely a sign of my genius, and TOTALLY not the fruits of having screwed myself so indenumerable times in the past.
 * fullermd nods at himself.
<a_c_m> lol
<a_c_m> needs to go on a wiki page or somthing somewhere
<a_c_m> as when i searched for those errors i got bugger all
<fullermd> Well, there wouldn't really be any constant error.
<a_c_m> no?
<lifeless> a_c_m: probably sftp wasn't working for you either
<lifeless> a_c_m: and there are hits for that :)
<fullermd> "TERM environment variable not set." is the tipoff in this case, but that's nothing to do with bzr; that's output right from your shell.
<lifeless> that said
<lifeless> there is a test
<fullermd> It would depend on exactly what output was being generated   :)
<a_c_m> ahh wasnt even trying sftp
<lifeless> fullermd: we can write up a 'check your server config' checklist
<lifeless> fullermd: with 'ssh -T host echo' as a test line
<a_c_m> fullermd: mine was a combo of lifehackers handy bashrc + some simple customizations ;)
<fullermd> Oh, I was thinking jump right to "ssh -T host bzr version" to check as much of the path as possible.
<lifeless> fullermd: right - but when it fails, we can test that one step in isolation
<lifeless> fullermd: which is clearer than we do today
<lifeless> in other news
<lifeless> Every 2.0s: du -s work_root_for-bzr.inv work_root_for-bzr.inv-branchAndFix                                                                                                                  Thu Oct 16 23:53:58 2008
<lifeless> 648036  work_root_for-bzr.inv
<lifeless> 12446008        work_root_for-bzr.inv-branchAndFix
<lifeless> thats right, split inventory is at 12G and climbing
<lifeless> "epic"
<fullermd> It's a feature.  bzr comes with built-in I/O benchmarks.  Email reading is expected for 2.0.
<elmo> even gnu hello has email reading
<lifeless> poolie: was debugging an lp issue @ 9. anything particularly interesting from the standup
<lifeless> ?
#bzr 2008-10-17
<abentley> jam: turns out there's a downside of lp: URLs, too.  They can't address private branches.
<abentley> jam: actually, that's wrong.
<august> is there an easy way to copy somebody's branch into a new branch under me on launchpad?
<thumper> august: only to get a copy yourself and push it
<august> hmm
<august> ok
<poolie> august: or bzr branch lp:~him/thin/1 lp:~me/thing/2
<august> that's simpler
<poolie> lifeless: interesting but nothing earthshattering; the review queue is growing again and needs love
 * a_c_m is FINALLY understanding branches vs checkouts... god bzr rocks
<lifeless> 13G
<jml> a_c_m: :)
<cafuego> Hi all, I have a question about merging unrelated trees into one, whilst keeping all history. is that possible?
<cafuego> And if so, how? :-)
<jonoxer> cafuego: Interesting question, I'm going to put it to the test right now
<thumper> cafuego: yes it is possible
<thumper> cafuego: but I can't remember the special magic words
<thumper> spiv: can you help?
<cafuego> jonoxer: Oh, hi there!
<jonoxer> cafuego: hi!
<jonoxer> I'm just a bzr noob here to figure out how things work
<jonoxer> So questions like that are interesting
 * cafuego is also a bzr noob, so asks questions like that ;-)
<cafuego> I had  aperv at bzr merge, and then mentions a mergebase, but then doesn't say how to specify it or what it is
<jonoxer> cafuego: merge has an "--lca" flag! And the help text says "LCA-newness merge"!
<jonoxer> Not that it helps you, it's just funny
<cafuego> Yeah, I saw that <heh>
<cafuego> I think it means "merge now and worry later" ;-)
<thumper> I think adding --force to the merge command gets it to work
<jonoxer> thumper: nope, still says "branches have no common ancestor"
<thumper> hmm..
<spiv> -r 0..-1
<thumper> spiv: I was just thinking about something like that
<spiv> cafuego: bzr merge -r0..-1 unrelated_tree
<jonoxer> spiv: interesting, that worked in my test
<jonoxer> Neat trick
<spiv> Yeah, it's handy.  It's a bit of a special case.
<cafuego> spiv: Ta, and hi also
<spiv> cafuego: hi :)
 * cafuego goes back to his clean tree and runs it in a subdir this time
<jonoxer> spiv: Makes for a cool-looking vis graph, too! I've never seen a convergence like that before
<jonoxer> Or a rev "0.1.1"
<spiv> Heh :)
 * fullermd has plenty of branches with rev 0.4.1   :p
<jonoxer> spiv: by the way, thanks to you (and others on #bzr as well): http://jon.oxer.com.au/blog/id/290
<lifeless> 13.6GB
<spiv> jonoxer: awesome.  Thanks :)
<cafuego> Whee, all done.
<emmajane> I'm just setting up JungleDisk+Amazon S3 as a backup network. I know I can rsync files to it as well. If I wanted to have my "personal" bzr repositories somewhere other than my office network, could I push commits to S3 as well? And does that even make sense as a question? :)
<jonoxer> emmajane: if you can rsync to it then yes, you should be able to push the repo to it. However, see here: http://research.operationaldynamics.com/blogs/andrew/software/version-control/bzr-repository-rsync.html
 * emmajane reads
<jonoxer> That's from a couple of years ago, I don't know if things have changed since
<jonoxer> AfC was just on the channel but left 10 mins ago, we could have asked him
<emmajane> I don't usually branch... just tag. So I think I'll be ok.
<emmajane> jonoxer: i'm backing up the directories that contain the bzr repos, so I'm not sure I also need to push them as well...
<jonoxer> emmajane: It sounds like all you're wanting is somewhere to put them for disaster-recovery purposes, in which case you don't need to "push" in the bzr sense. Just update your backup with rsync from time to time
 * emmajane nods
<emmajane> yes. :)
<jonoxer> Cool. Just treat your S3 storage like an extra disk then and dupe your directory onto it
<emmajane> excellent. :)
<emmajane> I love it when life is easier than originally expected. :)
<lifeless> the only caveat is don't commit or pull while rsyncing
<lifeless> there is a database in the repo that rsync can copy in an inconsistent state - unless you use a file system snapshot
<emmajane> lifeless: good call re. commit and pull. I don't use a file system snapshot for this backup (although I have used it in the past for other things)
<jonoxer> lifeless: good point. I'd assumed it would be done as a manual process so emmajane wouldn't be likely to be doing both at the same time, but if you cron-jobbed it you could have a problem
<jonoxer> lifeless: are you going to OSDC or LCA?
<lifeless> http://paste.ubuntu.com/58644/
<lifeless> jonoxer: well the LCA miniconf invite actually put me off
<lifeless> I might swing by LCA for a day
<lifeless> jonoxer: more details in a bit, phone call right now
<jonoxer> lifeless: I'm very curious now
<poolie> the problem with S3 is it does not, in itself, provide ordering between different writers
<emmajane> writers?
<poolie> ah, i was talking about treating S3 as an actual repository
<poolie> ratherthan just backing up to it
<emmajane> ah :)
<emmajane> would there be an advantage to using S3 instead of launchpad?
<poolie> well, no, because it won't actually work :)
<emmajane> hehe
<emmajane> Although the PPA option on launchpad is always free + open and cannot be private/restricted, IIRC?
<bob2> are sure you can rsync to s3?
<emmajane> bob2: via jungledisk
<emmajane> bob2: not directly though, no.
<emmajane> bob2: www.jungledisk.com
<thumper> poolie: are there any blockers to making format 1.6 the default for bzr 1.9?
<bob2> emmajane: ah, interesting
<emmajane> bob2: I'm just setting it up now. I'm quite impressed so far.
<emmajane> bob2: I like that it's scalable. Dropbox was also nice but it was either 2G free, or 50G paid at $10/month.
<jml> lifeless: wanna make subunit part of pyunit-friends too?
<jdm> Has anyone had success using bzr-svn with Sourceforge?
<jdm> specifically, committing using your account?
<jdm> I've created a checkout for https://account@project.svn.sourceforge.net/svnroot/project
<jdm> And it took my password just fine checking out
<jdm> But committing doesn't seem to work
<jdm> It just gives me a permission denied error
<lifeless> thumper: yes, its too new
<thumper> lifeless: given that it changes very little in the way of actual disk format, I find that surprising
<lifeless> thumper: its nothing to do with what it changes
<lifeless> thumper: I didn't say unstable :P
<thumper> lifeless: this is somewhat screwing up the wonders of stacking with LP
<thumper> lifeless: until it becomes the default, it looses a lot of its appeal
<lifeless> thumper: changing the default tends to be disruptive because availability of the minimum version to use that bzr hasn't propogated out far into the ecosystem
<lifeless> thumper: we cop a lot of flack about formats already; doing churn on the default will only make that worse
<lifeless> thumper: branch --stacked and push --stacked will convert automatically, so I'm not sure why its screwing up LP
<lifeless> I need food, lightheaded - back soon
<jonoxer> lifeless: while you're eating, think about the miniconf story you're going to tell  :P
<lifeless> jonoxer: back
<lifeless> so miniconfs - did you see the generic RFP a few days back ?
<jonoxer> Yes, linking to a number of miniconf sites IIIRC
<lifeless> this sentence really bugged me: "Each miniconf is looking for a select range of talks from industry leaders and professionals alike."
<jonoxer> Sounds like marketing-speak
<lifeless> what happened to the grass roots community amateurs-are-as-good-or-better conference I knew and loved
<lifeless> anyhow, I read that, and thought "I don't want to see a conference organised by people with that attitude"
<jonoxer> Hopefully it hasn't been lost in translation and the conf itself will still have the same character
<jonoxer> Rather, *has* been lost in translation
<lifeless> jonoxer: hopefully; at this point I'm not interested enough to gamble time, leave and money in finding out
<lifeless> I may blog about it once its had a full week to ruminate
<jonoxer> I've been totally de-looped re LCA this time around, it's quite a weird feeling after being so much a part of it the last few years
<lifeless> heh
<lifeless> I got delooped after sydney
<jonoxer> You're a Sydneysider, right? OSDC is in Sydney, but it may not be hard-core enough for you
<lifeless> yah
<lifeless> as I said re OSDC, I may drop by
<lifeless> its right on the border of conflicting with other stuff IIRC
<jonoxer> OSDC's content seems to converge closer toward LCA's each year. The first year it was very webby, very "let's do FOSS on Windows and MacOS". By last year it had Rusty doing rants on threading models
<fullermd> I remember 10 years ago or so when I used to think once in a while, "Hm, I should try to hit a conference once in a while"...   eventually I saw the light   :p
<lifeless> jonoxer: neat; sounds like LCA is a moving target though; question is if OSDC are smart enough to stop at peak :>
<jonoxer> fullermd: Saw the light and realised you should go, or saw the light and realised you shouldn't?
<fullermd> Well, realized it was never going to happen, and I probably wouldn't care for it if it did anyway   :p
<lifeless> jam: btw - http://code.google.com/p/hypertable/wiki/ArchitecturalOverview - uses bloom filters
<lifeless> poolie: 18.4GB
<cafuego> you should see the number of webby talks we rejected for lca
<jonoxer> cafuego: you mean for Melb, or are you on the papers ctte for Hobart?
<cafuego> hobart
<jonoxer> Glad I didn't submit any then!
<cafuego> i cna't rember the submisisons for '08 - all repressed now ;-)
<lifeless> cafuego: so if you're reading backlog, whats with the commercialoid nonsense in the RFP ?
<cafuego> lifeless: I think it's just that - and won't affect the conference itself.
<cafuego> At the end of the day the conf is made by the speakers and attendees, but by the press releases
<cafuego> s/but/not/
<cafuego> Keep in mind that Ben works for gov't
<lifeless> cafuego: that press release implied no hobbyist or amateur talks
<cafuego> lifeless: Oh, but there will be
<jonoxer> Well, my talk about hotted up cars got in, so it's bound to be an "interesting" LCA!
<lifeless> cafuego: then that press release needs reissuing asap; though perhaps I'm the only one reading it this way
<lifeless> cafuego: cause I can't emphasise how big a turn off it is
<cafuego> lifeless: I'll ping ben and let him know
<lifeless> thanks
<cafuego> but don't let it turn you off submitting or attending
<lifeless> (unless of course it really means professional and industry leaders only, in which a blog post or something explaining is something I would read with interest)
<emmajane> Heh. Ignore the public call for papers and submit regardless of what we've said. ;)
<lifeless> cafuego: it's already turned me off; the work now is to get excited again
<cafuego> lifeless: I'
<cafuego> lifeless: I've tested the Daquiri machines at the casino .. they rock ;-)
<lifeless> cafuego: they have a machine to make daquiri's!
<cafuego> Yup. green and red.
<cafuego> red sucks, green rocks.
<lifeless> lol
<bob2> commendable thoroughness!
<fullermd> Bad time to be R/G colorblind   :p
<cafuego> fullermd: I am actually.
<cafuego> though not completely, which is a blessing ;-)
<fullermd> Well, so much for trusting your advice on the matter now...
<cafuego> you mean you're going to have to attend LCA and find out for yourself?
 * jonoxer things lifeless may have just found the motivation he needs
<jonoxer> s/things/thinks
 * fullermd doesn't actually even know what LCA is, so....
<lifeless> fullermd: linux.conf.au
 * cafuego should decide whether he'll go to osdc
<fullermd> Oh, heck.  I can't stand on my head long enough to be on the upside-down side of the world...
<cafuego> fullermd: that's where the daquiri comes in
<fullermd> I'm not sure I'd call that "helping".
<lifeless> so, 41K revisions copied
<jdm> hooray, apparently I was just giving bzr-svn the wrong password for sourceforge
<jdm> the world is right again
<lifeless> poolie: the usertest run is 4/5ths complete
<lifeless> poolie: more than 41K out of 54K revisions copied
<vila> hi all
<vila> lifeless: what are those GB you keep announcing, I don't know if I should be rejoiced or frighten...
<lifeless> http://benchmark.bazaar-vcs.org/usertest/log/usertest.log.inprogress
<lifeless> its the CHK based inventory
<lifeless> vila: pulling mysql-server into it
<gour> hi, it's not very high priority but would be nice if bzr-svn could serve svn-externals. what is missing in bzr?
<gour> http://bazaar-vcs.org/BzrForeignBranches/Subversion mentions need for 'nested branch' and the other issue which i'm not clear about
<vila> lifeless: what do those GB represent ? The repo is around 620MB with packs...
<lifeless> vila: well its not really
<lifeless> vila: grab the plugin I just posted and the repository branch, and then analyse an existing repo
<lifeless> vila: the raw data is _much_ bigger than 620MB; the CHK inventory is smaller in raw data
<lifeless> vila: its just not being delta compressed at all at the moment
<vila> lifeless: haaa, good, so you're *creating* a complete repo, uncompressed, with CHK invs ?
<lifeless> vila: read the code
<lifeless> vila: it will accomplish many things
<lifeless> vila: you will know exactly what I'm doing; and you'll get a handle on the CHK inv work, and it will answer that question
<vila> lifeless: hehe, touche, I must do that :)
<lifeless> vila: I believe you will find it interesting
<vila> I already know that and hope I can come in the game before it's too late :)
<fullermd> Hm.  So, is 1.8 officially released?
<fullermd> I see the tarball, and the wiki says so...   but the /topic and launchpad both still say 1.7.1, and I haven't seen an email about it.
<lifeless> vila: is something making it difficult for you to get involved?
<vila> shyness ? not knowing enough about the internals ? doubts about how to prioritize between the other areas I'm involved in ?
<vila> Maybe
<vila> Lack of brain power due to that damn wisdom teeth still hurting ?
<vila> Surely
<lifeless> wisdom teeth are a pain
<lifeless> very distracting
<lifeless> the first is in your court; the second is la poulet et la <egg>
<spiv> ouef, IIRC?
<lifeless> for the third, I'm happy to let you bounce this-or-that questions of me anytime
<lifeless> spiv: oui
<spiv> (as usual, I have no idea why I know that)
 * vila goes to dentist for a control and hope for an explanation about why he can't open his mouth more than 1,5 cm wide
<lifeless> vila: perhaps the rubber bands are too tight
<vila> egg =oeuf (very close spiv but no cigar)
<vila> lifeless: no user serviceable  parts :)
<spiv> vila: ah, I feel better now :)
<vila> lifeless: in retrospect I may change my first one (shyness) with can't open  my mouth these days :)
 * vila realizes laughing is painful too o_O
<lifeless> >
<lifeless> :
<vila> { ?
<poolie> hey vila, lifeless
<vila> hey poolie
<fullermd> poolie: ^^ re 1.8
<poolie> fullermd: hi?
<fullermd> Hm.  So, is 1.8 officially released?
<fullermd> I see the tarball, and the wiki says so...   but the /topic and launchpad both still say 1.7.1, and I haven't seen an email about it.
 * awilkins knows the pain of wisdom teeth
<awilkins> I had all four done surgically ; the lower set were growing downward and forward
<awilkins> My days were becoming a haze of internal skull pressure
 * fullermd has all 4 wisdom teeth.
<lifeless> 43000 done, 11K to go
<lifeless> hi poolie
<poolie> fullermd: i've been taking it a bit slower and automating things or updating them as i go
<poolie> mail will be sent soon
<awilkins> My jawbone is still remodelling some years later - I have days where the lymph nodes in my tongue really swell and ache. I still keep a little dextropropoxyphene in reserve just in case.
<awilkins> My teeth are nearly back where they started now...
<fullermd> Ah, OK.  I had the port all updated and was getting ready to send it in, then I realized, "Hey...   I haven't even heard that this thing is really there yet".
<awilkins> Which branch of bzr-svn are you using to convert MySQL?
<lifeless> awilkins: ?
<awilkins> Sorry, are you not doing that?
<lifeless> awilkins: its in bzr already, this is converting to my testin format
<lifeless> awilkins: mysql's master is in bzr :>
<awilkins> Groovy!
<lifeless> awilkins: you didn't know ?
<poolie> lifeless: woo, it looks like your run finished
<awilkins> lifeless: I dont do a lot of mysql hacking....
<lifeless> poolie: no...
<lifeless> poolie: its still running, 11K to go
<poolie> oh, strange
<poolie> why did the load jump up to 2.0 there?
<lifeless> poolie: I'm running analysis on the partial data
<poolie> ok
<lifeless> I'm also prepping to copy the result out
<lifeless> oh foo, just ctrl-c'd it
<poolie> mail sent
* poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | bzr-1.8 released 17 Oct | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<poolie> lifeless: are you serious, you killed the main run? :P
<lifeless> poolie: yah, meant to stop a tail -f
<lifeless> poolie: i've backed up the data and am finishing by hand :(
<jonoxer> Noob question #47: does bzr support something analogous to svn's "externals"?
<ronny> hi
<jonoxer> :)
<ronny> is there a way to set up aliases for push/pull locations of branches?
<bob2> try the bzr-bookmarks plugin
<lifeless> jonoxer: not stably; its intended to arrive, but EDEFERRED
<lifeless> jonoxer: there is config-manager, which is somewhat similar
<jonoxer> lifeless: thanks for the pointers. I'd prefer to avoid it entirely if I can, so I may just restructure our tree a bit anyway
<jonoxer> A useful thing to know though
<ronny> hmk
<ronny> bob2: just needed to figure if it makes sense to have it as part of the generic vcs api in the pida ide (we are about to get a good bzr integration by the gedit-bzr author)
<vila> awilkins: trying to scare me ? YOU WON'T ! The reason my wisdom teeth are coming back to haunt me is because I became younger by around 20 years working on bzr, two painful weeks are a drop in the ocean of my felicity :-) fullermd: I'm perfectly happy to *not* have them anymore if that's the price for becoming that young again :)
<fullermd> Well, I'd be happier not having them too   :p
<Odd_Bloke> poolie: Good job on the release. :)
<Odd_Bloke> Where is .bzr.log kept on Windows machines?
<james_w> Odd_Bloke: ask "bzr --version"
<AnMaster> hm
<AnMaster> website for says "Bazaar 1.8 was released on the 16th of October, 2008.
<AnMaster> topic says "bzr-1.8 released 17 Oct"
<AnMaster> so which one is it?
<lifeless> AnMaster: both
<lifeless> AnMaster: the world is wide
<AnMaster> lifeless, which timezones?
 * AnMaster consider it from UTC
<jonoxer> spiv, poolie, lifeless: thanks to all your assistance I now have 1.1M lines of code migrated from svn to bzr   :-)
<lifeless> AnMaster: yeah I think different folk looked at the clock ~ the same time
<lifeless> jonoxer: sweet
<poolie> jonoxer: sweet
<poolie> goodnight!
<jonoxer> night!
<AnMaster> lifeless, so what day was it in UTC?
<lifeless> AnMaster: I don't know, I'd have to think
<AnMaster> lifeless, well what time was it in second since epoch then? ;P
<lifeless> AnMaster: right now, its the 17th where I am
<AnMaster> so it is here
<AnMaster> 12:18
<AnMaster> and that is UTC+2 currently
<AfC> "It was the dawn of the 3rd Age..."
<AnMaster> heheh
<ronny> hmm, does the threadlocal chdir issue of bzr 1.8 affect linux?
 * lamont wonders how soon 1.8 will land ar launchpad.net/~bzr/+archive
<lamont> at, even
<Odd_Bloke> poolie is most likely to know (IMPLICIT PING).
<lamont> Odd_Bloke: OTOH, he called g'night almost 2 hours ago
<Odd_Bloke> Then I'd expect it tomorrow sometime. :)
<lamont> which means I'll probably worry about it on monday or so
<lamont> though it's only 2355 in Sydney right now..
<Odd_Bloke> Yeah, I probably meant Monday by 'tomorrow', now that I recall that it's Friday.
<lamont> and fwiw, the topic change occurred at 0812 UTC, so there wasn't much of the world left where it was Oct 16
<vila> jam: ping, regarding bug #277537 I can't understand if we agree or not, chatting seems easier to sort that out, pong me back when you're available
<ubottu> Launchpad bug 277537 in bzr "annotate says revision modified file, "bzr diff -c" widly contradicts" [High,Fix committed] https://launchpad.net/bugs/277537
<jam> vila: sure let's chat about it for  bit. I'll need to go in about 30min, but then I'll be back later
<jam> I think what you've done is probably fine (and probably what 'reconcile' would have done anyway)
<vila> ok
<jam> my concern is that code like 'annotate' isn't ready for it
<jam> but we want to make the code handle it anyway
<vila> My understanding is that you're right but time shifted
<vila> the bug already shows that annotate isn't ready for it
<vila> fixing the repo seems to please annotate very much
<vila> Does that make sense ?
<jam> vila: I think you are misunderstanding my concerns with annotate. And if *I'm* wrong then it seems something much more serious is going on
<vila> That's I wanted to chat, there are surely grey areas for me
<jam> Looking at the annotate code, I'm 95% sure that it assumes that the compression_parent == parent_ids[0]
<jam> (left-hand parent)
<vila> Did you read my replies ?
<jam> I haven't got to that yet, I'll look
<vila> I agree with you on that part but I wonder if annotate is not getting these parents but some others and then assuming they are the same. In that case your diagnosis *is* already correct about the matching blocks use
<vila> I also agree that if my fix (modulo the tweak for more than 2 refs) is correct but incomplete then we have a bigger problem because reconcile use that same way to fix inconsistent parents
<jam> vila: well the patch to annotate should be merged regardless
<jam> When I look at my local graph, I didn't see a single case where 'compression_parent' wasn't parent_ids[0]
<jam> which is why it seems weird that swapping it, which *should* break annotate actually ends up "fixing" annotate
<jam> vila: I'm also rather positive that the converter isn't actually to blame, but the version of bzr that was used during conversion
<jam> this was a known bug in bzr
<vila> which is why I suggest that annotate is not using the compression_parent
<jam> which is why reconcile already tries to fix it
<jam> and the reason to make _generate_text_key_index faster is just to make 'reconcile' *usable*
<jam> 30+hrs isn't in the very usable category
<vila> 1) we should clearly identify the oldest bzr version that fixes that
<vila> 2) check is 32 hours, reconcile is 20 hours, as I said I think we should keep them that way and focus elsewhere
<vila> and make sure they are never needed
<vila> I don't have a problem with a verification tool that take days if it save *me* days
<vila> but anyway, I think this bug should be fixed without requiring users to update bzr so even if we optimize check/reconcile they won't be able to use them
<jam> so, #1 I think your plugin is probably fine
<jam> #2 I think we need a better understanding of what is going on in annotate
<vila> ha, ok, I was unsure about that
<jam> because it doesn't fit *my* mental model
<jam> and I've been neck deep in it for a long time
<vila> I respect that and share the concern
<jam> looking at bzrlib/knit.py line 955, we pull 'compression_parent' directly from '_index.get_build_details()'
<jam> so I'm quite sure it is getting the info from the file graph
<jam> sorry, the line in question is 2587
<jam> but it is doing the same thing
<vila> compression_parent is not changed by my fix
<jam> vila: yeah I know, which is why it is getting weird
<vila> where are the parents coming from ?
<jam> I'd like to try just always setting "left_matching_blocks = None" and see what that does
<jam> so... _KnitAnnotator should be completely focused within the per-file graph
<jam> and not know anything about the whole tree graph
<vila> tell me where, I have buggy and fixed repos at hand
<jam> bzrlib/knit.py has the _KnitAnnotator code
<jam> alternatively, you can go to bzrlib/annotate.py
<jam> and in the "reannotate()" function
<jam> just set the 'left_matching_blocks = None'
<jam> right at the beginning
<vila> I fired 4 gblames, setting left_matching_blocks to None has no effect
<jam> vila: did you try "_left_matching_blocks" I was missing the underscore
<vila> yes
<vila> I just checked I used the right bzr by adding a print '_left_matching_blocks set to None'
<jam> so, I probably need to swap back some state in my head to test it here.
<jam> can you link the rev-ids that are 'correct'?
<jam> I think: sp1r-anozdrin/alik@quad.opbmk-20080322080224-35901
<jam> is  correct revision
<jam> and merging it with sp1r-anozdrin/alik@quad.opbmk-20080322083224-09299
<jam> broke it in the ancestry
<jam> but doing it manually gives the "right" answer
<jam> vila: does that sound right to you?
<vila> yes
<vila> err no wait, let me check
<vila> jam: checked, yes
<jam> k, I'm working on reproducing here, give me  a sec
<vila> But I mentioned that the "right" answer is not as right as I thought, my fix reveals different annotations (because that file has 71 inconsistent parents in its ancestry, the manual merge fix only one pair out of the 71)
<jam> vila: sure, I just want *a* test case :)
<jam> Even if it is only this one hunk
<jam> What I'm seeing is:
<jam> _left_matching_blocks was already None
<vila> ok, so the manual merge gives the right one
<jam> And no case where _left_matching_blocks was not None
<jam> which is really weird
<vila> Haaa, at least it explains your misunderstanding ! We're making progress :)
<jam> anyway, I have to go right now, but I'll be back later
<jam> I'll also mention that there are no cases of: print "compression parent is not left-parent: %s, %s" % ("
<vila> ok, don't forget  that you're using a *weird* repo, that could explain the weirdness
<maestrolinux> http://s2.ar.bitefight.org/c.php?uid=19732
<jam> vila: so the reason _left_matching_blocks is None is because of the code to check about using "_fallback_vfs"
<jam> and that is because someone hijacked it in bzr.dev:
<jam> if True or len(self._knit._fallback_vfs) > 0:
<jam>     # stacked knits can't use the fast path at present.
<jam>     return self._simple_annotate(key)
<jam> Note the "if True" portion
<jam> ugh
<vila> I remember reading that but thought it was intended :-/
<jam> vila: no, we found that annotate was a lot slower, so poolie brought in the "if len() > 0"
<jam> I think he forgot to take out the "if True" block
<jam> Merge unoptimized annotate code for stacking, and only use it when needed
<jam> is the comment for that line
<jam> poolie: shame on you. I trusted you :)
<jam> vila: so it could be a bug in the '_simple_annotate' code
<jam> which is why they aren't getting the right ordering
<vila> Didn't you tell me one day that you used to check what code was checked in ? :-P
<jam> vila: before we had 30 patches a week, yeah. I would read the diff everytime I did 'bzr up'
<vila> yes, it's on the path, I have some commented out import pdb; pdb.set_trace() there
<vila> jam: you should know better than quitting good habits
<vila> So, does that path get different parents than the pack index ones ?
<jam> vila: I'll have to look
<jam> it doesn't *look* like it does, but lifeless wrote that code
<jam> vila: try takeing out the "if True" and see if we get different results
 * vila taking out the 'True or' instead :)
<jam> I seem to get the same results
<jam> I just get them a bit faster :)
<vila> no difference for broken repo, tracenack for fixed repo :-/
<vila> AssertionError: mismatched new_lines and annotated_lines
<jam> vila: I'm glad we at least caught the bug
<vila> can't reproduce o_O
<jam> vila: can't reproduce?
<jam> (it is still giving bad results, but it gives them in 1.3s instead of 2+)
<vila> I traceback once but not twice...
<jam> vila: different files?
<jam> vila: the check is: if len(new_lines) != len(annotated_lines):
<vila> nope, same exact command
<jam> So there has to be a line length mismatch or we won't catch it
<jam> Though I don't see any reason it would be a heisenbug
<vila> I know after the traceback I changed the format to display the lens and since then the traceback vanished...
 * vila check ghosts
<jam> vila: I would check your modification to make sure you aren't overwriting a variable, etc.
<vila> I reverted it !
<vila> Ok, wrong shell, got it back:
<vila> AssertionError: mismatched new_lines (732) and annotated_lines (721)
<jam> vila: I'm sending a patch to the list which fixes these 2 things with the annotate code.
<jam> And then I'll try to debug why we are getting the wrong annotations regardless
<jam> as 'reannotate' shouldn't really care whether a text is the left or right parent.
<vila> hold on
<vila> If my fix is wrong it means reconcile is wrong too, you understood something I don't here :)
<vila> jam: and I fixed only one thing: 'deleting the True or' what is the second one you're referring to ?
<jam> vila: the first fix is "True or" the second fix is changing the 'fast path' code to not re-use a matching block if compression_parent isn't the left-parent
<jam> so it should not trigger the AssertionError
<jam> vila: can you apply the patch and make sure 'bzr annotate' works properly after your reconcile
<vila> jam: ok, it fixes the traceback (pfew)
<vila> I suppose your fix will have an impact on the 80s slow annotate case, no ?
<jam> vila: right, it drops from 60s => 16s on my machine
<vila> yeah, two birds with one stone ;)
<jam> vila: well, it still doesn't give the correct result for their "broken" repo
<vila> true, but my fix address that
<vila> Are you sure annotate doesn't recalculate the parents with another source ?
<vila> I never looked at the code path that is active now so my prior experiments are useless now
<jam> vila: they both go through "reannotate()"
<jam> it is just that one does a lot of work to pass in 'left_matching_blocks" when it can
<jam> as well of other work to be memory friendly
<vila> My tooth (or rather its lack now) is waking up again. 6 hours is definitely the time it takes for Advil to become ineffective :-(
<jam> and go in pack read order
<jam> vila: feel better with more drugs :)
<vila> I hate that but has done it for the last two weeks ;(
<vila> Hmmm, your patch may not be active after my fix (except the blocks = None) , let me check
<vila> rats, I need a more sophisticated breakpoint
<jam> so.. I'm trying to look more closely at the parent ordering thing. The first thing that I see is that it seems this particular code block is *repeated* inside one of the parents
<vila> Indeed, when annotating in a broken repo I stop after compression_parent == parent_ids[0], but not with a fixed repo
<vila> Indeed, when annotating in a broken repo I stop after compression_parent == parent_ids[0], but I don't with a fixed repo
<jam> vila: so *with* my patch and the old repo it is breaking?
<vila> jam: yes
<jam> hmm... it gives the 'bad' results but it works here
<jam> so... I think we have a case of a code block being moved, and that confusing the annotation code
<jam> if it gets one parent first, it lines up this particular portion
<jam> if it gets the other parent it gets a different alignment
<jam> and then can't match this portion because it considers it moved
<jam> still investigating
<jam> vila: but I'm thinking... fixing the per-file graph will make "bzr diff" use the same texts as "bzr annotate". but both annotations are legally correct
<jam> because there is an ambiguity in the system
<vila> The bug report was about annotate giving a different result than diff and *that* was the problem
<jam> vila: though if you did "bzr diff" versus the other parent you would agree with annotate
<jam> I'm fine fixing the graph, I just wish our diff an annotate could handle moved blocks a bit better
<vila> Be aware of the conclusions you draw from the "manual" merge, the annotations it gives are far from the one I can see with a fixed repo, may be you try to get one  (it's only 312 seconds away ;-)
<vila> Be aware of the conclusions you draw from the "manual" merge, the annotations it gives are far from the one I can see with a fixed repo, may be you should try to get one  (it's only 312 seconds away ;-)
<vila> I leave now, I'll check later or even pass a bit if I'm in better shape
<jam> vila: rest well
<jfroy|work> jelmer: you do use launchpad for bug reports, right?.
<jfroy|work> jelmer: new failures this morning since I updated bzr and bzr-svn to the latest trunk revision
<jfroy|work> AttributeError: 'CachingRevisionMetadata' object has no attribute 'generate_revision_id'
<fynn> how do I get a list of all monitored files in a repo?
<fynn> "bz ls" seems to show non-monitored files and directories as well, at least at the top-level.
<fynn> OK, "bz ls --versioned" seemed to do the trick...
<jfroy|work> I am getting a "bzr: ERROR: A nested progress bar was not 'finished' correctly." exception when running a merge command...
<jfroy|work> Any ideas?
<lifeless> jfroy|work: file a bug, and you could try running with PDB=1 if you want to analyse the cause yourself
<jfroy|work> I tend to ask in IRC before filing bugs, in case it's a "duh don't do that" :p
<lifeless> jfroy|work: sure; I didn't criticise your asking :>
<jfroy|work> I didn't mean it as a rebuttal, sorry if it sounded that way. Your advice is, of course, well founded and appreciated :)
<lifeless> :)
<lifeless> anyhow it smells like a bug
<lifeless> probably a rare code path not cleaning up well
<lifeless> win 40
#bzr 2008-10-18
<maelcum> hi. i heard that you bazaar guys fixed some issues in python-subversion. what do such issues look like?
<maelcum> there are some more waiting to be fixed
<Peng_> bzr-svn eventually gave up on python-subversion.
<maelcum> what did it switch to?
<Peng_> maelcum: jelmer wrote something new, https://launchpad.net/subvertpy
<maelcum> i've had a look at python-subversion and it's a huge amount of ugly code (which might be par for the course for bindings).
<maelcum> i wonder how such things are created, and how to mess them up because it's supposed to be pretty much automatic.
<Peng_> Isn't python-subversion generated by SWIG or something?
<maelcum> yes. somebody still has to write the swig definitions, and there are also comments in the C sourcecode.
 * Peng_ doesn't know how SWIG works.
<ronny> i kinda categorized it as broken mess from hell
<Peng_> Ah.
<maelcum> yeah, that is what the code looks like anyway
<ronny> svn and its libs
<maelcum> the parameter count of some svn methods cannot be counted on the fingers of one hand as i noticed in the bindings code, which qualifies as "bad".
<maelcum> s/one hand/two hands/
<maelcum> this one is also made of lose:
<maelcum> #define SWIG_fail                        goto fail
<ronny> oh, at least it cant kill kittens
<ronny> it trips over its own fail, then a lolcat makes a phun
<maelcum> goto for error-out is kinda useful but hiding it is **really** stupid
<ronny> its swig, it cant do any good
<maelcum> at least the macro name is well-chosen
<ronny> nah, it clearly lacks a "is_" in the middle
<ronny> hmm, is subvertpy usable?
<Peng_> ronny: Define "usable". bzr-svn uses it..
<ronny> stable api, works for getting workdir status indformation+ stuff like commit
<ronny> (in pida we use subprocess for calling to svn, but im not happy about that)
<Peng_> ronny: I dunno. You should talk to jelmer about it.
<GhostFreeman> I'm still having issues getting TortoiseBzr to work on my computer, and I think its because I'm running Windows Vista 64
<GhostFreeman> any possible workarounds
<Peng_> ronny: At this point, it probably just does whatever bzr-svn needs, and bzr-svn can do "status" and "commit" on svn checkouts.
<ronny> hmk
 * Peng_ doesn't atually know anything.
<Peng_> actually*
<ronny> i'll bookmark it and figure stuff out when i work on anyvc again
<lifeless> subvertpy ?
<lifeless> oh I see
<lifeless> pulled out to a new package
<GhostFreeman> Is there any way to get TortoiseBzr to work on 64-bit OS?
<lifeless> GhostFreeman: is there a bug open ?
<GhostFreeman> Don't know -- where's the link to the Launchpad page?
<GhostFreeman> nevermind, found it
<GhostFreeman> well the real problem is that TortoiseBzr still won't work for me, and I read in the documentation its an issue on only 64-bit systems
<lifeless> if its in the docs it sounds like the windows guys know about it
<lifeless> and don't have a fix [et]
<GhostFreeman> Well, the taskbar responds, but the context menus do not (as in they don't show up at all)
<GhostFreeman> I'll check on Launchpad and file a bug if I find anything. thanks.
<lifeless> all I can suggest is that you make sure there is a bug
<GhostFreeman> Alright
<gour> jelmer: hello, what is missing in order for bzr-svn to support svn:externals ?
<clemente> Hi, is this a good usage of set_parent_ids in a test?:
<clemente> tree=self.make_branch_and_tree('tree1'); rev1=tree.commit('first'); rev2=tree.commit('second'); tree.set_parent_ids([rev1],allow_leftmost_as_ghost=True);
<clemente> With that, I tried to uncommit the second revision
<james_w> clemente: I'm not sure why you need the allow_leftmost_as_ghost
<clemente> james_w: neither am I, but otherwise it fails: GhostRevisionUnusableHere
<james_w> weird
<james_w> not sure why rev1 would be a ghost
<clemente> It must be due to other things on the test I'm writing. I will continue with it set to False
<clemente> Weird; now it works
<Schalken> Is it possible to have a branch with neither a working tree nor a repository?
<bob2> yes
<bob2> (e.g. a branch a in a --no-trees repository)
<dstanek> is using bzr-svn similar in concept to using svk?
<dstanek> it seems like it is with the biggest difference being that it does not import the entire repository
<gour> dstanek: yeah, i like bzr-svn, but would like to have support for svn:externals
<jelmer> jfroy|work, yep, please file bugs in launchpad
<fynn> Hi. I was wondering: what kind of routine maintenance does a Bazaar repository require?
<LarstiQ> possibly backups, but nothing else I can think of
<LarstiQ> though with the distributed nature of Bazaar, even that isn't as important as for other systems
<fynn> LarstiQ: I'm thinking of stuff like "git gc" and "git repack" commands, that you should run every once in a while if you're hosting (particularly a busy) git repo.
<dstanek> gour: do you know of a good tutorial?
<fynn> is there anything similar with Bazaar?
<gour> dstanek: for bzr?
<LarstiQ> fynn: hmm, maybe remove the obsolete packs once in a while, although bzr will do that on its own if you do not
<fynn> LarstiQ: what's the command to do that in bzr?
<LarstiQ> fynn: rm -rf? :)
<dstanek> gour: bzr-svn
<fynn> LarstiQ: of what? :)
<fynn> delete the repo, start a fresh one?
<LarstiQ> fynn: .bzr/repository/obsolete_packs
<LarstiQ> fynn: nah
<fynn> OK, I see.
<LarstiQ> fynn: but I haven't needed to do that
<fynn> basically, I'm trying to determine whether a bzr repo requires more maintenance than a git one.
<LarstiQ> fynn: on 'git gc', what exactly does it do? And can you comment on wether needing to run that is related to the git culture of rebasing?
<LarstiQ> fynn: ime, there is zero maintenance
<gour> dstanek: well, you just use bzr commands...e.g. bzr checkout instead of svn...i'm not very familiar with svn, but use e.g. bzr branch on svn repo to fetch it etc.
<fynn> LarstiQ: I'm a git newbie. from what I understand, 'git gc' removes obsolete packages as well.
<fynn> I don't know about rebasing.
<gour> fynn: i do not think about any housekeeping tasks while using git...but i'm scared to even think of using git :-)
<gour> s/using git/using bzr
<LarstiQ> fynn: do you maintain a (busy) vcs host?
<fynn> gour: what I'm not sure about, is what the lack of stuff like 'git gc' and 'git repack' means.
<gour> dstanek: have you checked http://bazaar-vcs.org/BzrForeignBranches/Subversion
<fynn> LarstiQ: I'm considering a migration of a fairly busy SVN repo to a VCS.
<gour> fynn: you have to use git?
<LarstiQ> fynn: well as I said, in practice I don't need to do any maintenance.
<fynn> gour: I don't have to. I like BZR, and use it to manage my personal projects.
<LarstiQ> fynn: oh, maybe `bzr upgrade` once in a while
<gour> fynn: i switched from darcs to bzr and do not look back...bzr is quite robust, simple enough with a friendly community
<fynn> but now I need to know whether migrating a large, busy SVN repo should be done to bzr or to git.
<LarstiQ> fynn: what do you currently do for svn maintenance?
<fynn> nothing.
<gour> fynn: i like bzr's 'safety net' over git complex ui
<LarstiQ> ok, that I expect to remain the same then :)
<fynn> gour: what do you mean?
<gour> fynn: well, afaik, git allows one to shoot oneself in the foot too easy
<gour> fynn: have you tried bzr-svn ?
<fynn> sort of, a few months ago. didn't go very well.
<gour> newer release might be quite better...
<LarstiQ> fynn: for my svn repos, I keep backup dumps, and have to restore them once in a while.
<fynn> the goal is to migrate the repo, not work with the current svn repo using a different client.
<fynn> LarstiQ: I keep backups to, but why do you have to restore?
<LarstiQ> fynn: for bzr, that is more offloaded to the users, not the admin running the site.
<gour> fynn: well, i suggest you to take a test-drive  with both git and bzr...i'm more than satisfied with bzr
<LarstiQ> fynn: fuckups from users basically
<fynn> gour: (in fairness, that was with a relatively old bzr [the stable one on Ubunutu Feisty])
<gour> ahh
<gour> fynn: bzr improves rapidly with recent releases...check announcements and changelogs
<dstanek> gour: yeah - but that doesn't really tell you how
<fynn> gour: my greatest puzzlement is whether the availability of the repack command on git means that: 1) git just gives you an option to optimize and "defrag" your repo, that bzr doesn't provide,  OR 2) git repos actually require more care and nurturing than bzr repos.
<gour> dstanek: well, bzr-svn makes it transparent for you to use svn repo - just as you would work with bzr. however you must be familiar with bzr
<dstanek> gour: this one is better, but i was hoping for something more official - http://tinyurl.com/59j389
<fynn> I suspect it's the former.
<LarstiQ> fynn: bzr tends to do it automatically
<fynn> LarstiQ: yeah, git does that automatically too, at least the crucial parts.
<LarstiQ> fynn: bzr has `bzr pack` btw
<fynn> hm, interesting.
<fynn> what large, active code repositories are using bzr?
 * LarstiQ hasn't had use for it
<gour> dstanek: ahh...my bzr-svn needs are quite basic for now and i do not intend to fiddle with svn repos more than fetching and possibly doing some simple commits
<LarstiQ> fynn: mysql, launchpad
<gour> fynn: there is gnome repo as well (unofficial), emacs...
<LarstiQ> fynn: you're aware of the differences in branches/repositories between svn and bzr?
<fynn> LarstiQ: (yeah, `git repack` isn't mandatory as well. I've been told that manual repacking might only be deemed important for very large repos, e.g. the Linux kernel.
<LarstiQ> fynn: right, that makes sense
<fynn> and even then, completely failing to run it manually (thus relying on the automatic `git gc` that runs every once in a while, sort of like how bzr deletes obsolete packages I gather) would only result in:
<fynn> 1) the .git dir size being larger than it could be.
 * LarstiQ nods
<fynn> 2) performance being not as good as it could be.
<LarstiQ> same with bzr
<fynn> (very large *and active repos)
<LarstiQ> although obsolete_packs don't impact performance
<LarstiQ> but joining packs might, I guess that's similar to `git repack`
<fynn> yeah, probably. it would be nice to have commands in bzr for joining packs and deleting obsolete_packs.
<LarstiQ> fynn: the difference between bzr and svn results in more finely grained branches than svn repositories (where the branch concept doesn't exist as a domain object)
 * gour likes and prefers branch/repo concept
<LarstiQ> fynn: `bzr pack` and rm -rf .bzr/repository/obsolete_packs/ . I don't really think the latter warrants a bzr command on its own.
<fynn> LarstiQ: ah, so `bzr pack` joins packs?
<LarstiQ> fynn: let me figure that out for certain
<LarstiQ> fynn: btw, how big is your svn repo?
<fynn> LarstiQ: close to 100k commits
<LarstiQ> fynn: and it's all 1 project?
<fynn> yes.
<LarstiQ> ok, that makes it a lot easier at least
<fynn> why?
<LarstiQ> fynn: 100k on the mainline, or in total?
<gour> i'd say that bzr is made with more up-front design that some other VCSs and now is much easier to tweakk/improve performance..however, when the UI is broken...
<fynn> total, but that's mostly trunk.
<LarstiQ> fynn: since svn doesn't have the branch concept, it is possible that detangling different projects can be a bit of a pain
<fynn> there is some discussion about splitting the project, but that's mostly relevant once we move to a DVCS.
<fynn> because yes, the codebase is large.
 * LarstiQ was thinking unrelated projects
<fynn> nah, everything in the repo is definitely related.
<LarstiQ> fynn: ala the apache svn repo, although those are relatively well seperated
<fynn> although there's a possibility that the development team would split, and there'll be a sort of splitting into "sub project"
<LarstiQ> fynn: ah
<fynn> I'm sure both bzr and git can handle that very well - the question is about performance.
<fynn> especially long-term performance.
<LarstiQ> maintenance wise, or actually working with it?
<gour> fynn: you know about stacked branches?
<fynn> three areas: 1) required routine maintenance, 2) repo size, 3) usage speed
<fynn> gour: no, what are those?
<LarstiQ> gour: stacked branches solve a particular problem
<LarstiQ> gour: we don't know yet what fynn is interested in
<LarstiQ> fynn: your needs are a bit different than mine, 1 and 2 are no issue for me, so I'd recommend asking on the list/the people involved with mysql
<LarstiQ> like jam
<gour> fynn: see http://jam-bazaar.blogspot.com/2008/05/this-week-in-bazaar_29.html
<gour> LarstiQ: i was thinking about stacked branched due to possible long history of the project
<gour> something like emacs-project
<LarstiQ> fynn: on usage speed, git is faster on most operations, you will have to see if bzr is fast enough for you (it is for me) and which particular use cases are important to you.
<LarstiQ> gour: yes, that might help for the initial-branching-speed for users, but not so much for an admin
<fynn> LarstiQ: cool. I'm interested in 2 mainly because we have quite a few developers, some of them switching machines and pulling the trunk over poor and/or wireless connections.
<LarstiQ> fynn: ok, for those cases gour is right, stacked branches don't require to have the full history present
<fynn> so if bzr repos are almost 3 times larger than git repos (which some benchmarks suggest), that could have a significant impact on them.
<LarstiQ> fynn: with 100k commits, that can significantly cut down in download size.
<fynn> *nod*
<LarstiQ> (and disk space, but that's not the main problem here)
<fynn> usage speed is the least of my concerns (which is why I listed it last).
<LarstiQ> fynn: it really depends on what the benchmark is looking at and when, bzr and git have been bigger and smaller than each other through history
<fynn> it's mainly because now that we're moving to an advanced DVCS, some of the developers are thinking about new refactoring / code-mining practices that could be performance-intensive.
<LarstiQ> fynn: right
<fynn> usability-wise, bzr is the most convenient of all DVCSes that I used so far.
<gour> i know that e.g. for ghc evaluation someone didn't use shared repo, so it ended up comparing apples & oranges
<LarstiQ> gour: right
 * gour likes darcs as well, but stability...hmm
<LarstiQ> fynn: in bzr terms, a repository is a storage place for revisions. More than one branch can share the same repository, storing each common revision only once.
<fynn> it really allows me to do anything I need, I'm extremely pleased with it, and use it for all my personal projects. the only reason I brought up git is because it's not a personal project, and stuff like performance or maintenance overhead will affect others besides me.
<LarstiQ> fynn: this is obviously easier on disk space, but it also makes branching within the repo cheap, you don't have to copy all that data around
 * LarstiQ nods at fynn 
<LarstiQ> fynn: is the project public?
<fynn> gour: (didn't the GHC evaluation also talk about git flexibility features that hg/bzr lacked, for example history rewriting?
<fynn> LarstiQ: unfortunately, not ATM :)
<fynn> we may be able to release some of it (especially if we manage to split out some of the sub-projects, using git/bzr)
<LarstiQ> fynn: ok
<gour> fynn: if you check that wiki page on GHC tracker and ml, bzr was ruled out due to speed only based on dubios benchmarksmrks :-/
<LarstiQ> fynn: well, then I won't give it a quick peek with bzr-svn right now :)
<LarstiQ> fynn: I'm happy to assist you further with this though
<LarstiQ> but I need to get myself some dinner first
<gour> fynn: history rewriting and git's rebase is mostly not required with bzr
<fynn> LarstiQ: thanks. my next step is to import our massive SVN to both bzr and git, and run some benchmarks on the resulting branches.
<fynn> LarstiQ: bon appetite!
<fynn> gour: hmm, could you elaborate?
<gour> fynn: read http://andrew.puzzling.org/diary/2008/July/29/rebase-criticism
<LarstiQ> fynn: there is a bzr rebase, and it is useful in certain situations, but in general the bzr culture tends to frown at the level of history destructive operations common with git
<gour> ;)
 * gour is reading learning-python-3e in order to be able to hack on django/pinax/.../maybe bzr in the future
<fynn> heh, "The current stable version is 1.8, released November 17th, 2008."
<gour> where did you find it? site says: Bazaar 1.8 was released on the 16th of October, 2008.
<fynn> http://bazaar-vcs.org/Download
<gour> so, no need to worry about the future :-)
<fynn> the future is here.
<fynn> gour: btw, I'd just read the Python tutorial
<gour> ohh, you're also new ;)
<fynn> do you have any previous programming experience?
<fynn> no, actually :)
<fynn> I'm saying, if you have experience, reading the entire "Learning Python" is a waste of time imho.
<gour> yep...from fortran to C(++)...but didn't do any programming for many years and then became interested for haskell
<fynn> OK, see, the tutorial will get you up to speed with Python in the fastest way.
<gour> heh, learning python is really slow, but it covers 2.5 with insight into 2.6 & 3.0
<gour> i like books for 'offline reading' when i'm afk :-)
<gour> i'm at the last part - exceptions...
<LarstiQ> fynn: ah thanks, I fixed the release from the future.
<fynn> LarstiQ: cool.
<aidans> hi. i have a bzr 101 question. I messed up a bzr send and now it seems to think i'm rooted at /path/to/branch/address@mail.com. how do i fix that?
<beuno> aidans, what do you mean it thinks your rooted?
<aidans> bzr bundle complains with bzr: ERROR: not a branch "/path/to/branch/address@mail.com"
<Peng_> beuno: FWIW, there's a new version of MooTools out. You should update the copy in Loggerhead.
<beuno> aidans, you can do:  bzr send ../branch
<beuno> Peng_, I have a better idea for that
<beuno> I'm at the airport, waiting to get on a plane to London with all the rest of the lp devs
<aidans> ah. thanks. :) any idea how to fix the confusion it's suffering?
<beuno> and we're going to switch it over to YUI, rockstar is going to improve performance, and, hopefuly quite a lot of other improvements will get done in the next 2 weeks  :)
<Peng_> beuno: Heh, that works too. :)
<LarstiQ> 2 weeks of sprinting?
<beuno> aidans, take a peak in ~/.bazaar/locations.conf
<beuno> Peng_, :)
<beuno> LarstiQ, yes. "Epic Sprint"
<LarstiQ> beuno: okay :)
<beuno> lot's of new shiny things coming, we need to prepare!
<beuno> lots even
<aidans> beuno: i don't have that file, or anything similar under .bzr in the brnach
<beuno> aidans, right, it's in your home dir
<james_w> hey beuno
<james_w> hey LarstiQ
<Peng_> aidans: "bzr info" to check what's wrong, bzr pull/push/merge --remember the_right_path to fix it.
<james_w> how you doing?
<beuno> /home/username/.bazaar/locations.conf
<Peng_> aidans: Or edit .bzr/branch.conf or ~/.bazaar/locations.conf.
<beuno> hey hey james_w
<beuno> pretty good
<beuno> bored in an airport
<beuno> how are you?
<james_w> you always seem to be flying at the moment :-)
<aidans> beuno: i know, i only have bazaar.conf and ignore in ~/.bazaar
<james_w> good thanks
<beuno> aidans, ah, then what Peng_ said  :)
<beuno> james_w, heh, yeah. I kinda get that feeling as well  :)
<beuno> I'm off for a month now
<LarstiQ> woha
<james_w> are you holidaying post-epic?
<beuno> I wish
<beuno> more sprints
<beuno> Montreal
<james_w> heh :-)
<aidans> Peng: --remember sorted it. pull had the right place, but merge didn't and that seems to have fixed send. thanks!
<beuno> I'm just hanging out in madrid for the week in between, so I don't rack up so many miles  :)
<Peng_> ...Or actually "bzr send --remember".
<Peng_> aidans: :)
<aidans> editing the index files by hand was unappealing ;)
<Peng_> Err, I meant .bzr/branch/branch.conf.
<Peng_> Anyway..
<aidans> s'all fixed now :)
<beuno> aidans, the bug you reported
<beuno> it's because you aren't specifying the revid
<beuno> you're giving it a revno
<beuno> of course, it shouldn't traceback, so the bug still holds
<StyXman> hello. I wan to cnovert a svn repo to a bzr one. I found svn2bzr, and it seems fine... in the papers. the link to the code is dead. which is agood way to do it?
<LarstiQ> StyXman: I'd either use bzr-svn or something based on fast-export/import
<StyXman> I can't branch a shared repo, can I?
<beuno> not the whole repo, no
<beuno> you can branch branches
<beuno> or, just cp the whole repo
<StyXman> ajÃ¡, so I co a branch from the repo and then barnch it?
<beuno> you can branch the branch  :)
<StyXman> I meant, I chechout a branch  and then branch the branch, is that it?
<beuno> why don't you just branch the branch>
<beuno> ?
<StyXman> beuno: because I don't have one
<StyXman> I just used bzr-svn to convert a svn repo, and I think I got a bzr repo
<beuno> then what are you talking about doing a checkout from?
<beuno> OH
<beuno> SVN
<beuno> ignore me
 * beuno defers to LarstiQ 
<StyXman> i got a dir with a .bzr dir in it
<beuno> ok
<StyXman> if I run bzr info, it says it's a shared repo
<beuno> I can do that
<StyXman> and now?
<beuno> and you want to see the actual files?
<beuno> create a working tree?
<StyXman> hmm, create something in it so I can... ah
<StyXman> yes, in the end I would like the files
<beuno> try running 'bzr co' in there
<StyXman> ok, I think I'll re-read the concepts
 * LarstiQ blinks
<LarstiQ> StyXman: how did you get a shared repo from bzr-svn?
<StyXman> LarstiQ: dunno, I just found a conversion I did several months ago :|
<StyXman> but I think what I want is a bzr init
<LarstiQ> StyXman: what I would probably do, install bzr-svn, then 'bzr branch path/to/svn/repo' and get a bzr branch out of it
<StyXman> no, it's not that
<LarstiQ> ok
<LarstiQ> StyXman: then you'll need to fill me in on what the problem is :)
<StyXman> I mean, it's not bzr init
<LarstiQ> StyXman: what are you trying to do?
<StyXman> I want to completely convert the svn repo in a bzr one, and then get rid of the svn one
<StyXman> then take this bzr repo, put it in my server, branch away from it, and keep hacking
<LarstiQ> StyXman: right. I'd personally still try first branching with bzr-svn as I said.
<StyXman> I think i got the first step
<StyXman> hmm
<LarstiQ> StyXman: then, if you're happy with that, you could import all the branches from the svn repo with `bzr svn-import`
<StyXman> so branching from the (svn?) repo would give me a bzr brach (with its own repo)?
<LarstiQ> StyXman: yes
<StyXman> wow
<LarstiQ> StyXman: that is
<StyXman> that's some magic, not the one I spected
<LarstiQ> StyXman: the branching will work as normal bzr branching
<LarstiQ> StyXman: if the location you are branching to doesn't have a repository, it will create a standalone branch (which has its own repository)
<StyXman> hmm, I remember something about lightwieight branching not having repos...
<LarstiQ> StyXman: and if you are branching into a shared repository, it will use that instead.
<LarstiQ> StyXman: lightweight checkouts
<LarstiQ> StyXman: but you don't deal with those if you use `bzr branch`
<StyXman> into? do I branch *into* a shared repo?
<LarstiQ> StyXman: sure. My ~/src/bzr/ is a shared repo, with the branches bzr.dev, nested-trees, 1.5, 1.8 etc within
<StyXman> hmm
<beuno> nested trees!
<beuno> :)
<LarstiQ> StyXman: a shared repository is just a storage place for revisions, nothing more.
<LarstiQ> beuno: yes! indeed!
<StyXman> LarstiQ: yah, that one I got :-P
<LarstiQ> StyXman: ok :P
<beuno> LarstiQ, have you done more work on making the diff smaller?
<StyXman> so when you sya 'into', you mean 'in a directory "below" the one holding the shared repo'?
<StyXman> say*
<LarstiQ> StyXman: so, when I do 'cd ~/src/bzr; bzr branch lp:bzr' I get ~/src/bzr/bzr, a new branch, which uses ~/src/bzr as its repository. That action we call branching into a repository.
<LarstiQ> StyXman: correct.
<LarstiQ> beuno: no :(
<StyXman> lp:?
<LarstiQ> StyXman: lp: is a prefix that will look on launchpad for the branch
<StyXman> che, te jodo para hacerte unas preguntitas de los tracs que dan
<StyXman> oup, wrong paste
<StyXman> bzr: ERROR: Not a branch: "/home/mdione/src/projects/psync/bzr/.bzr/branch/".
<LarstiQ> StyXman: so lp:bzr expands to http://bazaar.launchpad.net/~bzr/bzr/trunk/
<LarstiQ> StyXman: this occurs when you're doing what exactly?
<LarstiQ> StyXman: something is not a branch :)
<StyXman> bzr branch . in the shared repo
<LarstiQ> `bzr branch .` ?
<StyXman> (and I thought I got it right...)
<LarstiQ> StyXman: branch requires an argument for where to branch _from_. And optionally takes an argument where to branch _to_
<LarstiQ> StyXman: did you tell it to branch from '.'? In that case, is '.' a branch, or is it not?
<StyXman> no, it's teh shared repo
<StyXman> let me read a little more, see if i can get it
<StyXman> ok, so what I got whas several barnches (trunk, branches/*, tags/*) with a repo shared between them
<StyXman> O i should move everythong to the server and branch from the trunk branch
<StyXman> so I*
<LarstiQ> StyXman: that's an option, yes
<StyXman> nice!
<StyXman> \o/
<mwhudson> i do find it a bit hard to read the thread on hudson on the list without wtfing a bit
<james_w> because you're not the brother of a Java application?
<mwhudson> yeah
<zachera> zachera@apollo:~$ bzr branch aristaeus/
<zachera> bzr: ERROR: Not a branch: "/home/zachera/aristaeus/".
<zachera> what'd i do wrong
<LarstiQ> zachera: aristaeus does not seem to be a branch. You think it should be?
<zachera> hm, i think i figured it out
<zachera> did bzr init
<zachera> then bzr add
<zachera> lol
 * LarstiQ blinks
<zachera> how do i delete the SVN repo for this aristaeus folder
<zachera> i want to start it over
<zachera> >_>
<LarstiQ> zachera: svn repo?
<zachera> repository
<zachera> how do i remove all the .svn folders out of aristaeus
<LarstiQ> zachera: do you mean bzr?
<LarstiQ> zachera: this is #bzr, not #svn
<zachera> .
<LarstiQ> zachera: maybe you can provide some more context so I actually get what is going on.
<zachera> okay
<zachera> do i do bzr init outside of aristaeus or within
<zachera> LarstiQ: ^
<matkor> Hi I am getting TypeError: object.__init__() takes no parameters after I upgraded to python 2.6 with bzr 1.6.1 .. is bzr 1.8 enough to work with python 2.6 ?
<LarstiQ> zachera: if aristaeus is a project you'd like to make a bzr branch out of, then within
<zachera> screw the whole branch thing
<zachera> aristaeus is the folder which contains the project
<zachera> i want to make the files within the aristaeus a part of the SVN repository
<LarstiQ> zachera: what do you mean with "SVN repository"? Specifically a Subversion repository, or are you using "SVN" as a general term for version control systems, and actually want to do something with Bazaar?
<zachera> ok
<zachera> i am setting up trac.
<zachera> and this whole svn/trac shit is pissing me off
<LarstiQ> matkor: there were some 2.6 problems that got fixed when encountered, without seeing the traceback I can't be sure it's the same as your problem
<zachera> i installed bazaar
<zachera> i installed trac
<zachera> but trac is saying
<zachera> "/home/zachera/aristaeus does not appear to have a Subversion repository"
<LarstiQ> right
<zachera> so i assume its because aristaeus wasnt setup properly
<zachera> what am i doing wrong here..
<zachera> i commited..
<zachera> i'm on revision 1
<zachera> >_>
<LarstiQ> zachera: That is because trac by default only works with Subversion. To get it to work with Bazaar you will need to install a trac-bzr plugin.
<zachera> smooth.
<zachera> same error, LarstiQ.
<LarstiQ> zachera: so, why are you trying to set up trac?
<zachera> what do you mean
<zachera> LarstiQ: ??????
<zachera> what do you mean
<LarstiQ> zachera: maybe if I understand better what your high-level goal is, I can help you get there, instead of trying to treat symptoms.
<zachera> Okay.
<zachera> Assembla.com has stopped allowing free, private spaces.
<zachera> Therefore I want to install SVN and Trac onto my webserver.
<zachera> Ubuntu server + lighttpd.
<zachera> Bazaar and Trac.
<zachera> My project is in /home/zachera/aristaeus
<zachera> My trac is located at /var/subs/trac
<zachera> I want to be able to maneuver to trac.zachera.com/aristaeus
<zachera> And be able to use Trac there.
<zachera> I have a feeling that I will be needing to start over again...
<LarstiQ> zachera: ok, dod assembla.com give you an svn dump you can import?
<zachera> Yes.
<LarstiQ> zachera: ok, then you probably want to install the subversion package and use that, not bazaar
<zachera> .. ok
<LarstiQ> zachera: Subversion and Bazaar are two different version control systems.
<zachera> I already have Subversion apparently.
<LarstiQ> zachera: ok, you can create a svn repo with `svnadmin create /path/to/repo`
<LarstiQ> zachera: and you can restore from the dump with `svnadmin load /path/to/repo < svn.dump`
<zachera> zachera@apollo:~/aristaeus$ svnadmin create /home/zachera/aristaeus
<zachera> svnadmin: Repository creation failed
<zachera> svnadmin: Could not create top-level directory
<zachera> svnadmin: '/home/zachera/aristaeus' exists and is non-empty
<LarstiQ> zachera: right, what the command said
<zachera> lol
#bzr 2008-10-19
<zachera> ok
<zachera> imported
<zachera> whats next
<zachera> :D
<zachera> create /aristaeus in /var/subs/trac ?
<LarstiQ> zachera: point trac at the svn repo you just created, yes
<zachera> sweet
<zachera> hang on
<LarstiQ> zachera: either use the trac-admin tool, or set 'repository_dir' under [trac] to the correct location
<zachera> it worked
<LarstiQ> good
<LarstiQ> zachera: so, solved now?
<zachera> not quite
<zachera> the website style isnt showing up
<zachera> lol
<LarstiQ> zachera: may I ask btw why you came here for help? Since this doesn't involve bzr at all.
<zachera> because i installed bazaar in the first place
<LarstiQ> how did you get the idea to do that? Assembla is svn only afaik?
<zachera> It's simple.
<zachera> I saw the words "Bazaar" and "Version Control" and installed it. :P
<LarstiQ> Aha :P
<zachera> IT WORKEDDDDDDD
<zachera> hahaha
<zachera> :D
<LarstiQ> good
<fynn> What's the canonic (pun not intended) way to perform a message-less commit?
 * fullermd watches launchpad ladle out a tarball at <3k/s...
<Odd_Bloke> jelmer: Are there any instructions on using the Debian bzr packaging team's branches available?
<Odd_Bloke> jelmer: I just hit http://paste.pocoo.org/show/88477/.  Any thoughts?
<bazaar> hi, is it possible to find out the revision a specific file was added?
<Jc2k> bazaar: you should be able to do bzr log filename to see all the revisions  that touched a given file, and hence you should be able to see the one that added it...
<Jc2k> (i think)
<bazaar> i'll try that.
<bazaar> worked. thanks.
<LarstiQ> yes, and in most cases it will be the first one, so --limit 1 will work too
<Jc2k> oh, i didnt realise it was oldest first or i would have suggested that ;)
<LarstiQ> Jc2k: switchable with --forward
<fynn> Hey. What's the canonical way to perform a message-less commit?
<fynn> (A commit with no commit message.)
<LarstiQ> fynn: that's normally guarded against
<LarstiQ> I don't think you can get around that without resorting to using bzrlib
<fynn> LarstiQ: yeah, I'm asking because some developers asked for this feature.
 * LarstiQ isn't in the position to check the code right now
<fynn> that's OK, I might do that myself. it's Python after all :)
<fynn> it's just that some people asked for it, and I didn't find any way to do it, so I asked to make sure I didn't miss anything.
<LarstiQ> fynn: hmkay, it seems like a very bad idea to me :) But yes, a custom plugin shouldn't be too hard.
 * LarstiQ nods
<LarstiQ> fynn: be aware that the commit message is a property of a revision, you can not change it afterwards.
<LarstiQ> fynn: so if they want to punt till later, they can't.
<fynn> it's just that some developers work on semi-private branches, and they make a lot of personal commits
 * LarstiQ just wildly guesses as to why they'd want that.
<LarstiQ> fynn: what happens with those personal commits later on?
<fynn> well, they get merged.
<fynn> but I'm thinking about that article someone gave here yesterday
<LarstiQ> ok, so they just want to describe the entire package of work during merge time?
<fynn> about Loom
<fynn> yeah, exactly.
<LarstiQ> right, I can see that.
<fynn> should I take a look at Loom?
<fynn> or is there a builtin way of doing that?
<LarstiQ> fynn: do what exactly? Merging is a core bzr capability.
<fynn> LarstiQ: hm, OK, I'll take a better looks at what _can't_ be done via vanilla merging, before I assume I need Loom :)
<fynn> although Loom does look very interesting: http://bazaar.launchpad.net/~bzr-loom-devs/bzr-loom/trunk/annotate/head:/HOWTO
<LarstiQ> yes, that it is :)
<LarstiQ> but I haven't gotten further than "cool!", haven't actually used it myself yet
<fynn> LarstiQ: is there a way to create an alias that would run a shell command?
<fynn> like the ! aliases in git?
<LarstiQ> fynn: bzr aliases are restricted to bzr afaik. Do you have an example of such a git alias?
<fynn> LarstiQ: sure:
<fynn>  git config --global alias.ci '!git commit -m "`date`"'
<fynn> this causes `git ci` to commit the current changes with a message equal to the output of DATE(1)
<LarstiQ> fynn: right, I see.
<fynn> as far as I can see, the easiest way of doing that on bzr would be to write a plugin that would provide that command.
<arj> hi, I tried upgrading remove sftp tree but it failed and now I have a backup.bzr dir
<arj> how do I remove that and try again?
<Flare183> When I try to push one of my infobot projects I get this error: bzr: ERROR: Invalid http response for http://bazaar.launchpad.net/%7Erichardson183/ubuntu-bots/flarebot/.bzr/branch-format: Unable to handle http code 502: Bad Gateway
<Flare183> Why do I get this error?
<Flare183> dres: Can you help me?
<LarstiQ> fynn: yes, though extending current alias support with ! shouldn't be too hard
<fynn> LarstiQ: yeah, probably :)
<muntyan_> hi guys. is it easy to have multiple branches inside one repository, and have those branches synchronized between multiple repositories?
<muntyan_> to achieve something like svn but without a real central server
<lifeless> muntyan_: yes
<muntyan_> lifeless: any docs about it? i was googling around, and just found that what i want is actually impossible
<muntyan_> some stuff about shared repositories and whatnot
<LeoNerd> Hi guys.. I have a slightly odd question. I'm looking at wrapping bzrlib in perl for some perl code.. I've found Inline::Python which basically seems to Just Work. Just with one problem.
<LeoNerd> Given an object reference to a python object, I can call methods on it, but not access bare attributes. Some of the bzrlib stuff needs these, in places. Anyone any ideas around it?
<lifeless> LeoNerd: teach Inline::Python about __getattr__
<LeoNerd> Oh.. is that a method on python objects anyway though?
<LeoNerd> Could I  $object->__getattr__("attrname")  ?
<lifeless> LeoNerd: (there is no such thing as bare attribute access - foo.bar is getattr(foo, "bar") under the hood
<lifeless> and getattr calls into foo.__getattr__("bar") - using getattr(foo, "bar") is the standard though
<LeoNerd> Yes.. but that form I can do for free
<LeoNerd> Wrapping getattr() as a plain perl function is More Work
<lifeless> well, up to you
<lifeless> probably just doing foo.__getattr__("bar") will work
<spiv> Actually, getattr calls __getattribute__.
<lifeless> ah
<lifeless> thanks :)
<LeoNerd> OK. But that's just a plain object method on the object, right?
<spiv> A pure-python translation of getattr (and type.__getattribute__) is surprisingly messy! :)
<LeoNerd> so e.g. at the perl level, I could   my $repository = $revision->__getattribute__("repository");  and it would work?
<lifeless> LeoNerd: its on the class I think
<spiv> LeoNerd: If you can make Inline::Python use the getattr builtin function, that would be best I think.
<LeoNerd> spiv: That requires Much Voodoo
<LeoNerd> Anyone who works on Inline::Python has to know a lot about both perl and python's C-level representations
<LeoNerd> There's not many who do
<spiv> LeoNerd: well, I mean, use its API to invoke getattr, rather than the (presumably hard) task of fixing Inline::Python.
<lifeless> LeoNerd: another thing you could do is write a small python helper module
<LeoNerd> lifeless: I've pondered that.
<LeoNerd> I also pondered just adding a 'get_repository' method to Revision
<LeoNerd> So I can call it :)
<LeoNerd> spiv: Yes, but that means I have to export getattr. It seems Inline::Python doesn't let you just plain export that function; I'd have to write my own which calls it, that it then exports for me.
<LeoNerd> Seems messy that way
<spiv> LeoNerd: that seems like a large gap in Inline::Python!
<LeoNerd> Yes. A horrendous one
<LeoNerd> but as I said, very narrow field of people who could fix it
<spiv> LeoNerd: A quick glance at the docs I found with google suggest you could do it with py_call_function
<LeoNerd> It requires someone who is an expert in both perl and python; who knows a lot about the sorts of things programs in each language would do, _and_ who knows about the C-level representations internally.
<LeoNerd> Given enough hackery, I could justabout make such objects respond to hash fetch representations... i.e.  $obj->{key}
<LeoNerd> But knowing what to call into python to do that; no idea
<spiv> LeoNerd: the "package" arg would need to be '__builtins__'
<LeoNerd> spiv: Ohsure.. there's a number of hackish ways to do it.. I've got a list of four or so candidates.
<LeoNerd> I'd like to know the best of these, or how to do a Real Solution. but as I said, a real one probably involves C-level hackery
<spiv> LeoNerd: it doesn't seem so hard to make a perl helper called py_getattr(obj, attr_name) than invokes getattr(obj, attr_name) then?
<LeoNerd> Not at all..
<LeoNerd> $object->__getattribute__("foo")   seems already to do it though.
<LeoNerd> sub getattr { some perl level hackery };   then  getattr($object, "foo")  being another
<LeoNerd> A third would be to override specific cases; so     class bzrlib.Revision: def get_repository(self): return self.repository;
<LeoNerd> Then I can  $revision->get_repository()
<LeoNerd> The first two of these require much annoyance at every single callsite.
<LeoNerd> The latter requires adjustment of every one of bzrlib's API points that I want to call.
<poolie> this is silly, let's just talk here
<spiv> poolie: Hi :)
<poolie> hm it's a bit disturbing that in the month 8.10 is meant to release neither of my machines will boot reliably :/
<lifeless> so
<poolie> so lifeless i saw your mail, and i have the numbers
<lifeless> I finished the conversion by hand and sent stats
<lifeless> I haven't altered the cron job in any dimension
<poolie> i was wondering if i should restart the cron job which seems to be blocked atm
<lifeless> so if it was left enabled it should be continuing
<poolie> maybe because the lock file wasn't removed?
<lifeless> could be
<lifeless> there should be disk space to run
<lifeless> note that ~/run can get kinda full easily :>
<poolie> i'll check on that too
<poolie> so for myself today i was going to do more packaging of 1.8, and see about automating packaging of bzrtools and maybe other plugins
<poolie> and work on the review queue
<lifeless> anyhow, when I get back to this, I think we have solid progress - a significant drop in uncompressed data size
<lifeless> LeoNerd: the silly poolie refers to is a voip epic failure.
<poolie> yes
<poolie> Inline::Python may also be silly ;-)
<LeoNerd> It's... not bad.
<LeoNerd> It's quite cute apart from this annoyance on attrs
<poolie> lifeless: so today was going to be sacrificed to administration demons?
<lifeless> yes
<spiv> On Friday I did a couple of reviews, and also some improvements to HPSS client-side error translation (removing duplication and bizarreness in bzrlib/transport/remote.py especially).
<poolie> cool
<poolie> it is a bit bizarre still
<poolie> it would be nice to have less of the return values handled per-rpc
<poolie> what's on the menu today?
<spiv> Right.  That's actually caused at least one bug in bzrlib/remote.py, in RemoteBzrDir.__init__.  So next on my hit list is fixing that bug by refactoring that file so that the "try: self._client.call(...) except ErrorFromSmartServer, err: self._translate_error(err, ...)" blocks are repeated everywhere.
<spiv> Er,
<spiv> *aren't* :)
<spiv> (The flaw in RemoteBzrDir.__init__ is that it does a HPSS call without catching ErrorFromSmartServer)
<poolie> woo
<spiv> I think I should do more reviews today as well, the queue is pretty large.
<poolie> it is
<poolie> i should too
<spiv> Much of that is Aaron's shelving stuff which I'm looking forward to having merged, but I'm not sure I know an awful lot about the relevant code.
<poolie> maybe lifeless can when he's done with paperwork
<poolie> so i think a review from an interested (relative) layman is better than no review at all
<poolie> maybe just asking questions etc
<spiv> Ok.
<poolie> ok, we can sit down now
<poolie> have a good day :)
<spiv> poolie: thinking of administrivia
<poolie> mm?
<spiv> poolie: the mailing list tagging regexes still need some tweaks
<poolie> do you have any expenses etc outstanding yourself?
<poolie> are you referring to the utf8 thing?
<poolie> it's probably technically possible to write a regexp for it
<spiv> poolie: the [Success!] mails (and also my [bzr-usertest:MERGE] mails) got tagged everything else
<poolie> ah, ok
<spiv> The utf8 thing just plain sucks, and needs mailman support to fix; in theory mailman could decode the unicode I think and run the regex on that :)
<poolie> mm
<poolie> though arguably you might also want to examine the uninterpreted form
<spiv> The [Success!] one is probably a straightforward tweak to fix.  For things like [bzr-usertest:MEGE] I guess we want to settle on a convention for "please review this code, but don't bother bundlebuggy with it"
<poolie> spiv, i thought bb left the [merge] behind in the success mails?
<poolie> i guess not
<poolie> do you want to change this?
<spiv> It does, but somehow they are still mistageed.
<spiv> Well, I got mail from someone saying "I didn't want to receive those two patches"
<poolie> actually what i meant was, will you fix this or should i?
<spiv> Oh, I see.  I don't know that I have the rights to fix it?
<spiv> I didn't realise there was a possibility that I might :)
<spiv> poolie: ok, I can't think of an improvement to the regexes, I've replied on the list to the complaint I got.
#bzr 2009-10-12
<igc> morning
<spiv> igc: morning
<igc> hi spiv
<lifeless> spiv: was last monday a public holiday?
<spiv> lifeless: yeah, Labour Day in NSW
<lifeless> ]thanks
<lifeless> -< food >-
 * igc lunch
<Peng_> Lately, Loggerhead is such a memory hog that running it is impractical. It's getting killed for hitting ~250 MB daily.
 * Peng_ whines
<Peng_> ("Lately" being "some time from 2009-07-07 to ~2009-09-07". Maybe it has to do with upgrading everything to 2a?)
<Peng_> Sorry, I'm done now.
<Peng_> That's the kind of thing I should put on Twitter where nobody has to read it. :P
<mwhudson> Peng_: it's probably 2a related at a guess
<Peng_> It ran for 10+ weeks with no intervention, then I upgraded to 2a and it (well, presumably it) OOMed my VPS within a day. :D
<Peng_> Hmm, when there is a MemoryError traceback, it does tend to be 2a-related.
<Peng_> But it could just be that something else uses too much memory, and then that's what pushes it over the edge.
<mwhudson> Peng_: you could try jam's static tuple branch i guess
 * igc dentist - bbl
<Peng_> Being lazy here, how much RAM does that save per tuple?
<spiv> Peng_: lots ;)
<Peng_> It has a significant number of lists, too, though not nearly as many as the tuples.
<spiv> I think at least 16 bytes per tuple, and that doesn't count the interning.
<Peng_> Currently 320,000 tuples, 100,000 lists. :D
<spiv> Whee!
<Peng_> The peak number of tuples is 460,000.
<Peng_> This might crash your browser/X/monitor/desk, but you can see for yourself at http://bzr.mattnordhoff.com/loggerhead/_dozer/index if you want to.
<Peng_> (Adblock http://bzr.mattnordhoff.com/loggerhead/_dozer/chart/ctypes.CFunctionType to avoid the crashiness.)
<Peng_> (FYI, I just blocked the image server-side.)
<Peng_> Oooh, jam has lots of interesting memory-related branches in development.
<spiv> Peng_: IIRC there's just one big branch that's been split into pieces for review
<spiv> Peng_: If I were experimenting with it I'd just jump straight to the end result.
<Peng_> spiv: I'm not sure all of it is merged into the big branch, though.
 * RenatoSilva can't understand very well stuff like this :( http://fourkitchens.com/blog/2009/04/20/alternatives-rebasing-bazaar
 * RenatoSilva still thinks rebase is a very nice way of keeping a private feature branch updated with mainline.
<spiv> RenatoSilva: well, if it works well for you, then keep doing that.
<spiv> RenatoSilva: personally, I find I'd rather keep the original history intact, but I don't mind having a history that's slightly more complicated than linear.
<RenatoSilva> ok I just mean that a good reason against rebase in private branch still misses, I fell like it's the natural way of keeping up-to-date with mainline, that's a bit weird when you see all the folks out there saying it's bad
<johnjosephbachir> hey folks. how do i back out a particular change from a particular file? in subversion this would be: svn merge -c -<any revision number> <any path>; svn commit
<RenatoSilva> I think I shoulld follow you folks and use merges, but rebase "is still in my heart" :D
<spiv> RenatoSilva: well, I don't really understand why you don't like merges
<spiv> RenatoSilva: and you don't really understand why some people don't like rebase, so I guess we're even ;)
<spiv> johnjosephbachir: you can do "bzr merge -r X..X-1"
<spiv> Er,
<spiv> johnjosephbachir: you can do "bzr merge -r X..X-1 ."
<spiv> The "." is important :)
<johnjosephbachir> spcool, just encountered the X..X+1 case in the docs, and was going to try the case you mentioned (and was expecting failure : ) )
<johnjosephbachir> got it, thanks
<spiv> johnjosephbachir: oh, and you can specify a file name at the same time, of course.
<johnjosephbachir> s/spcool/spiv cool/
<spiv> :)
<johnjosephbachir> spiv, okay
<igc> back
<bialix> hello all
<vila> hi all, hi bialix
<smartgpx> igc: hi, Ian - are you free for a moment, please?
 * spiv wonders why Python will make sure numbers will always compare lower than other objects if both sides give NotImplemented...
<spiv> (Oh, except for None, of course, which is special-cased before that special-case...)
<spiv> Oof, it takes a while to review C code.
<spiv> But then, it was > 1000 lines of diff, so maybe it's nothing to do with C :)
<lifeless> spiv: whats id(34) for you
<spiv> 148469204
<spiv> Or thereabouts, anyway ;)
<bialix> bonjour vila
<lifeless> spiv: I'd guess that your objects have a higher id
<spiv> lifeless: by a factor of ~20, it seems ;)
<lifeless> spiv: so I don't think its a deliberate thing :)
<spiv> lifeless: hah!
<spiv> lifeless: you'd think that...
<lifeless> spiv: did you find a check for it in the core?
<spiv> lifeless: read the definition of default_3way_compare in http://svn.python.org/projects/python/trunk/Objects/object.c
<spiv> (that function is invoked when both sides don't implement tp_richcompare or they do and it returns NotImplemented)
<lifeless> spiv: I'll assume thats a yes
<spiv> lifeless: here's the highlight: /* different type: compare type names; numbers are smaller */
<spiv> i.e. PyNumber_Check(v) it uses "", otherwise v->ob_type->tp_name;
<lifeless> bleep
<spiv> s/i.e./i.e. if/
<spiv> After special-casing None, of course.
<spiv> If the type names match, it will compare type pointers, so you weren't totally on the wrong track ;)
<lifeless> how did you end up down there
<spiv> Reviewing jam's StaticTuple patch, he has a test that at one point asserts that 10 < some static tuple.
<lifeless> lol
<spiv> Which seems a bit insane to me, but seeing as I had the Python source handy I thought I'd quickly check to see if it was going to be fragile across runs or platforms as well...
<lifeless> is it deliberate or a typo?
<mneptok> oh, how i miss that phrase in repsonse to my e-mails to Canonical lists.
<spiv> And, at least with CPython 2.6, it seems reliable, but yeesh...
<vila> lifeless, spiv: Working on thread leaks, I realize the root cause of many test bugs is that: SocketServer is *not* intended to be used with a client thread in the same process...
<lifeless> mneptok: which phrase?
<mneptok> "seems a bit insane to me"
<spiv> lifeless: deliberate, but I pretty questionable IMO.
<lifeless> spiv: what does it do for us?
<spiv> lifeless: I can understand testing that comparison with arbitrary types doesn't blow up, but then asserting that they should be always less or greater doesn't seem valuable to me.
<lifeless> is it a proxy for 'the result of __cmp__ is an int', perhaps?
<spiv> mneptok: you're considered wholly sane at your new workplace?
<lifeless> seems a bit insane to me
<mneptok> spiv: i report to Monty Widenius. by comparison, i seem somewhat well-adjusted.
<spiv> vila: really?  yeesh.
<lifeless> vila: can we work around it?
<spiv> vila: I always assumed SocketServer was a toy, but I figured that was because I was a bit biased being a Twisted dev :)
<mneptok> spiv: ill try to get Monty angry and record him swearing in a pidgin of Swedish, Finnish, and C++
<lifeless> mneptok: nice
<lifeless> mneptok: you having fun there?
<vila> It's fixed, that was scary though and hard, hard, hard to not become insane :)
<mneptok> lifeless: very much so.
<lifeless> vila: *insaner*
<spiv> mneptok: "may your compiler always fail with inscrutable template errors!"
<lifeless> vila: :)
<mneptok> lifeless: although i miss Woody. we need a company pony.
<vila> spiv: not a toy, just one assumption was missed: the client can be in the same process
<vila> lifeless: right :)
<lifeless> we don't have woody now, AIUI
<spiv> vila: I told you I was biased ;)
<lifeless> vila: what did they do to make that an assumption that matters?
<mneptok> spiv: "Hjorsorn bjarrtor type identifier;
<vila> lifeless: the point is about what they did *not* ... They did not synchronize their threads
<lifeless> vila: meep; unsafe always
<spiv> vila: I basically don't trust anyone except Twisted to get portable sockets and concurrency in Python right.
<vila> lifeless, spiv : the good news is that synchronizing the threads was easy once I understood what was needed
<vila> lifeless: huh ? not symcing is unsafe or do you mean even syncing result in an unsafe system ?
<mneptok> i rented a movie called "Portable Sockets." i thought it would help me learn Python network programming. it was a porn film about hitch-hiking. :(
<spiv> mneptok: I doubt you'll fare much better with titles involving "Twisted" or "Python"...
<vila> spiv: I don't have experience with twisted to speak, but indeed, I fixed a bunch of micro-bugs around with sockets and threads with spectacular variations in test failures....
<spiv> Well, maybe they'll have less hitch-hiking.
<spiv> vila: right
<mneptok> spiv: something tells me lifeless is away from IRC editing the quotes page.
<vila> so in the end, our code base is safe, our test code base is magnitude *safer* with respect to http, ftp test servers...
<lifeless> vila: using objects across threads is a bad bad bad bad bad bad idea without mutexs
<spiv> lifeless: that's the GIL, right? ;)
<lifeless> spiv: I wish!
<lifeless> it would be great if the GIL only released a thread when C code was reached.
<lifeless> stuff would be so much more debuggable :P
<vila> but the GIL is no magical bullet, you had to have stronger sync points, I used threading.Event objects for that
<spiv> lifeless: Hmm.
<spiv> lifeless: you can approximate that, perhaps...
<spiv> lifeless: sys.setcheckinterval(sys.maxint)
<lifeless> spiv: evil evil man
<spiv> lifeless: check that in your site.py and tell me how it works out for you ;)
<lifeless> be an interesting way to find bugs
<spiv> lifeless: hey, they wouldn't put those two symbols in the same module if they didn't want them to be used together!
<spiv> </undeniable-logic>
<lifeless> s/-.*/>
<spiv> :)
<mneptok> remind me never to share a hotel room with spiv
<spiv> mneptok: They give you shampoo... and a shaver only wall socket!  These *must* belong together...
<lifeless> mneptok: 'they wouldn't put those two employees in the same room if...' ?
<mneptok> lifeless: exaaaaaactly
<igc> mneptok: mariadb on home page now
 * igc dinner
<mwhudson> * spiv wonders why Python will make sure numbers will always compare lower than other objects if both sides give NotImplemented...
<mwhudson> spiv: it's so different numeric types end up "next to" each other
<mwhudson> so sorted([1, 1.5, 'bob']) keeps the numbers together
<idnar> I thought it just compared type(x).__name__ or something silly like that
<mwhudson> idnar: naive!
<mwhudson> mixed type comparisons are inherently as insane as a sack of cats anyway
 * idnar giggles to hide the hysteria in his voice
<spiv> mwhudson: *boggle*
<spiv> mwhudson: because it would be terrible if sorted([1, 1j, 'bob']) didn't keep 1 and 1j together... ;)
<mwhudson> spiv: also see my comment about cats
<Zand3r> Is there any bzr specific documentation covering workflows tied to the Eclipse IDE? Having read the 'known issues' for bzr-eclipse I opted to try qbzr-eclipse but I can not see how I would take an existing eclipse project, create feature-branches and switch between them. I raised this over the weekend and am no further... I'd be happy for the bulk of my bzr interaction to be via bzr explorer but even that doesn't help the feature branches show as ec
<Zand3r> projects without a lot of manual importing each time.
<bialix> Zand3r: is your existing eclipse project is under bzr control?
<bialix> perhaps you want to use workflow with one lightweight checkout and many treeless branches in shared repo?
<Zand3r> bialix: Currently no (I've tried putting it under bzr control using qbzr-eclipse and bazaar explorer.... the former litters it with a couple of directories like 'trunk' but bazaar explorer seems to initialise it correctly..... what I do after that I am stuck (ultimately I will upload the project to a central bazaar repository but that doesn't solve the issue of switching branches so that the eclipse project represents the current branch).
<Zand3r> bialix: Am I correct in thinking that 'many treeless branches' will mean a directory per branch... if so then there does not seem to be a way to have eclipse show all branches and/or have my currently active project 'become' the branch I want to use unless I'm totally missing something obvious.
<bialix> I don't use eclipse, so I can be totally wrong, but IIRC author of qbzr-eclipse said he's using approach of light checkout of many branches
<bialix> Zand3r: current bzr model is always 1 directory per branch
<Zand3r> bialix: Ok... Someone at the start of the weekend also suggested lightweight checkouts for use with eclipse so there must be something in that I just can't see how it works with Eclipse - I need to play some more I think.
<bialix> lightweight checkout can switch between branches
<bialix> wait a sec
<bialix> Zand3r: http://doc.bazaar-vcs.org/latest/en/user-guide/organizing_your_workspace.html#local-sandbox
<bialix> one lightweight checkout allows you to have one working directory for Eclipse
<bialix> and you can create as many feature branches in separate repo as you need
<bialix> to visualize branches in repo bzr-explorer is very good
<bialix> I really don't have experience with bzr eclipse plugins and I dunno if any of them capable to show you shared repo content
<bialix> but you can file a bug as wishlist ;-
<bialix> but you can file a bug as wishlist ;-)
<Zand3r> Interesting... I think I need to create a repository elsewhere on the disk temporarily for testing, import my project into that and perform a lightweight checkout in Eclipse (depending on how well the gui tools support this  - if at all)
<Zand3r> I'll have a play and see what happens - thanks for the pointers
<bialix> mmm, I think it's better to create light checkout from command-line (or bzr explorer) and open it in eclipse then
<Zand3r> I'm looking at this from the perspective of my colleague who i'm going to ask to use this system alongside me so I'm trying to do everything via a gui which would be within his comfort zone (as opposed to the command line) however bzr explorer looks 'really' nice so I see no issues with relying on that for the bzr interaction and using Eclipse only for code editing, etc. assuming Eclipse doesn;t have a problem with that (I'll have to see if Eclipse 
<Zand3r> refresh the project files when bzr explorer switches the branch)
<bialix> qbzr-eclipse and bzr-explorer use dialogs from qbzr plugin under the hood, so there is possible overlap in functionality
<bialix> what is your OS?
<faldridge> is the ability to do a bzr branch on an svn repo built-in, or do you need the bzr-svn plugin?
<jelmer> faldridge: you need the bzr-svn plugin
<faldridge> jelmer: ok, thanks.
<jimmy_dean> Currently while trying to pull from a remote branch to a Windows XP machine, bzr is never able to complete that pull no matter what. I've tried this on several different installs of Windows. Everytime is raises a Memory.Exception error after churning on the pull for several minutes. Any ideas what this means?
<jimmy_dean> the same task on Linux or OS X finishes fine, only does this on Windows
<Zand3r> Can anyone please advise if it is possible to perform a lightweight checkout (and branch/switch) in Bazaar Explorer as detailed here http://doc.bazaar-vcs.org/latest/en/user-guide/organizing_your_workspace.html#local-sandbox - it would appear not but I am new to bzr (and by extension the explorer gui) so want to make sure I am not missing something.
<bialix> Zand3r: sure
<bialix> Zand3r: use menu Bazaar -> Start -> Checkout
<bialix> to switch Bazaar -> Work -> Switch Checkout
<bialix> there is excellent tour, did you saw it?
<bialix> Zand3r: http://doc.bazaar-vcs.org/explorer/en/visual-tour-windows.html
<bialix> there is also pages for GNOME, KDE and MacOSX
<phinze> so why does `bzr switch` require access to the old url?
<phinze> use case: switching from a non-absolute DNS reference to a server ('dev') to an absolute one: ('dev.domain.com') ... switch bailed on trying to resolve 'dev', but unbind/bind worked
<phinze> so no problem really just curious
<phinze> hmmm " For heavyweight checkouts, this checks that there are no local commits versus the current bound branch, then it makes the local branch a mirror of the new location and binds to it.
<phinze> i guess that would do it, so bzr switch --force would probably work
<Zand3r> bialix: I saw the bzr explorer tour thanks... Bazaar -> Start -> Checkout does not give an option to make it lightweight
<bialix> Zand3r: IIRC it will create lightweight checkout by default
<Zand3r> bialix: Oh! - doh! - Thanks.
<bialix> phinze: there is bug about this problem
<bialix> phinze: this partially fixed in bzr 2.0 (--force flag)
<bialix> Zand3r: it's not obvious, I know
<bialix> Zand3r: try it
<j^> if i get AttributeError: 'module' object has no attribute 'ProgressBarStack' in a local loggerhead install with bzr 2.0 is this a known problem and is there an easy fix?
<fullermd> It probably means a plugin is out of date.
<joke> hi. I'm new to using bzr and I would like to know the signature checking works. I asked on the mailinglist but noone answered. Does someone know how it works?
<joke> I configured bzr to sign every commit which works fine. But setting the option check_signatures=require don't seem to activate signature checking.
<dash> jelmer: hi. any suggestions on making svn-import take less than 10G of RAM? :) (using bzr-svn 1.0)
<fullermd> joke: Once upon a time check_ didn't do anything.  I don't know that it's ever been changed to, but I haven't really been paying attention.
<davidstrauss> Is it safe to "cp -R repoA repoB"?
<davidstrauss> I mean, even if people are using repoA?
<fullermd> In an absolute sense, probably not, since there's no guarantee that cp would walk things in the same order as bzr updates them.
<fullermd> You'd probably have to do something like 'loop rsync until nothing has changed' to be certain.
<joke> fullermd: thanks. bzr 2.0 help configuration says bzr should check if signatures are present and valid if set to require. so there should create_signature should create them.
<joke> fullermd: so there should be a different between both options.
<faldridge> I've read the workflow for bzr-svn at <http://doc.bazaar-vcs.org/latest/en/user-guide/svn_plugin.html> but this talks about committing feature branches to the trunk.  What if I want to checkout trunk, create a branch locally, and then only push my branch back up?
<Tak> faldridge: ...to a non-trunk branch?
<faldridge> Tak: yes, I want to create the branch in the remote repo
<jfroy|work> verterok: I'd like to add the fastimport plug-in to the standard core distro
<jfroy|work> yay or nay on that?
<faldridge> Tak: the idea being to submit the branch to the server for code review and then let the trunk committers approve or reject the branch
<Tak> hmm, my gut feeling is that it should Just Work with `bzr push svn://path/to/feature/branch` , but I'm not sure
<faldridge> Tak: ok, I'll give it a shot, thanks.
<Peng_> Crap, the archaic build system on one of my machines doesn't like _simple_set_pyx.pxd.
<Peng_> Wait, what are .pxd files? Pyrex? That's simple enough to upgrade.
<Peng_> What's the minimum Pyrex version that bzr supports?
<gioele> I'm using bzr-git. Is there a way to make bzr produce the git version of a bundle?
<Peng_> Try "bzr send --format git" or so.
<Peng_> Dunno if it's still experimental or not.
<RenatoSilva> If we have deploy.bat in .bzrignore and we change the file name to deploy_server.bat, will bzr know somehow that no deploy.bat exists in the tree and tehrefore the user should either update or delete the pattern? (update in this case)
 * Peng_ /away!
<gioele> Peng: thank you!
<gioele> RenatoSilva: yes if you use "bzr mv deploy.bat deploy_server.bat"
<gioele> or bzr mv --help if you already moved the file
<RenatoSilva> gioele: interesting! what other shell-like commands bzr has?
<jam> Peng: ping
<gioele> not many: ls and mkdir for example. I'd love to have bzr cp but it is not ready yet. Have a look at bzr help commands
<RenatoSilva> bzr mkdir is like mkdir + add?
<jderose> RenatoSilva: yes, exactly
<maxb> How can I tell bzr that I want to diff my current branch with a non-tip revision of a different branch?
<RenatoSilva> ok, thanks all
<gioele> maxb: bzr diff --old revno:431:/path/to/branch
<maxb> aha
<maxb> thanks
<gioele> maxb: bzr help revisionspec
<gioele> np
<RenatoSilva> however, I think in some point bzr could check the ignore changes even if not using bzr mv
<gioele> RenatoSilva: ?
<RenatoSilva> look at my example and forget bzr mvc
<lifeless> maxb: or bzr diff -r 431:/path/to/branch
<RenatoSilva> bzr mv
<gioele> I still don't get it. Are you suggesting bzr should automatically do "bzr mv --auto" (<- this command really exist)?
<Peng_> jam: <3
<RenatoSilva> gioele: somehow bzr could tell the user the pattern is not being used anymore, probably because you have moved or deleted the underlying files
<jam> Peng_: So what platform are you on that had pyrex 0.9.5? (and an easy upgrade to 0.9.6, but not to > 0.9.6.3?)
<jam> hi lifeless
<gioele> ah, you would like to clean up the list of ignore files... I think there are pros and cons to that, it is not a clear-cut situation
<Peng_> jam: Your average, everyday old, out-of-date platform. There's nothing wrong with dropping support for it. And both upgrades were easy, just installing from source.
<Peng_> jam: (Ubuntu Gutsy, but you didn't hear that from me.)
<RenatoSilva> gioele: at least the ones matching single files (without regex)
<gioele> RenatoSilva: on you branch. How can bzr know about what is happening on other people's working trees?
<Peng_> jam: FYI: bzrlib/_static_tuple_c.c:693: warning: function declaration isnât a prototype
<jam> Peng_: can you try to just remove the 'void' from init_static_tuple_c(void) and see if that makes the warning go away?
<jam> line 650 by my count
<Peng_> 737 for me.
<Peng_> Err, wait, from .h or .c?
<Peng_> Never mind.
<jam> Peng_: .c
<Peng_> jam: Did that. Now it warns twice, lines 693 & 738.
<jam> Peng_: hmm... so 693 maybe you want to put *in* the 'void' and leave it for line 737
<Peng_> jam: 693 is _workaround_pyrex_096, fyi
<RenatoSilva> does bzr have a default ignore list?
<Peng_> jam: And that does indeed fix it.
<lifeless> hi jam
<Peng_> RenatoSilva: Yes. It's dumped to ~/.bazaar/ignore too.
<Peng_> RenatoSilva: Or was, anyway. Dunno the situation now.
<RenatoSilva> Id like to print the list, but found nothing in bzr help ignore
<Peng_> jam: I've been wanting to ask you, I'm interested in trying out your memory reduction stuff. Which branch(es) should I try?
<jam> Peng_: wait about 1hr and then try bzr.dev :)
<dash> memory reduction? this is relevant to my interests
<dash> well ok, memory _usage_ reduction would be. Not so much ejecting SIMMs from my motherboard.
<Peng_> jam: <3
<jam> dash: Basically, python 'tuple' objects carry around a large Garbage Collector header
<jam> I wrote a 'StaticTuple' class that refuses to reference objects that could create a ref cycle
<jam> and drops the GC header
<jam> which
<jam> a) reduces peak mem about 20%
<jam> b) Turns out to have a major impact on performance w/ large projects
<jam> because the python "GC" is no longer evaluating these 500k nodes
<jam> "time bzr branch launchpad-2a" was 11m => 8m for me, and about 17% less peak mem
<jam> I'm still looking at other places to improve
<jam> but that was a decent start worth landing... :)
<luks> hm, what about long-running processes using bzrlib?
<jam> luks: I would still expect a decent memory + performance improvement
<lifeless> luks: what about them?
<jam> I don't have any numbers on it
<Peng_> Loggerhead is my main interest in RAM usage. Over the last 3 months it's gotten nearly unusable.
<luks> but it would leak memory wouldn't it?
<lifeless> luks: no
<jam> luks: It isn't going to leak more memory than what we are already doing
<luks> how does it get deleted?
<jam> as these objects cannot participate in ref cycles
<lifeless> luks: same as usual
<jam> luks: standard ref counting
<jam> python has 2 ways to track objects
<lifeless> luks: they just don't participate in GC; refcounting still happens
<luks> I thought you mean they are completely outside fo the GC system
<jam> luks: well, there are 2 "GC" in python
<lifeless> they are :P
<jam> refcounting ,and cycle detector
<luks> jam: I know, I thought you mean both
<jam> it still is refcounted
<jam> I don't think you can avoid that
<jam> without using some sort of proxy object
<jam> and if you have a proxy object... you have a refcounted object
<jam> so if you want to reference one of these individually
<jam> ...
<jam> if we wanted to think harder about it, we could do like "nodes[10]", but you still need that 10 handle, which requires a python object...
<jam> Peng_: the code to expose StaticTuple to the btree reader is in pqm now, so barring any issues, 20-30min it will be in bzr.dev
<lifeless> jam: you've seen the progress bar?
<lifeless> jam: looks like it failed
<davidstrauss> How does Launchpad restrict users from accessing the shell while still offering the bzr+ssh transport?
<lifeless> it does not use openssh
<davidstrauss> lifeless: what does it use?
<vxnick> being stupid here, but how can I specify a new remote location (for pull) for an existing working tree?
<lifeless> twisted conch
<lifeless> more or less
<Peng_> vxnick: "bzr pull --remember ..."
<luks> vxnick: bzr pull URL --remember
<lifeless> vxnick: bzr pull --remember URL
<Peng_> Jinx!
<vxnick> that's the one, thanks all :)
<davidstrauss> lifeless: thanks
<jam> lifeless: yes, it is very nice to see
<jam> (the progress bar)
<vxnick> what about for a checkout? there's no --remember flag in the help for that
<lifeless> vxnick: bzr switch URL
<vxnick> thanks
<jam> lifeless: I had not seen that you have the failure/error tracker, though
<jam> well that and you don't stop on the first error now
<lifeless> jam: I didn't think we'd changed the stop on first error
<jam> Running [ 22% 4836 test(s) 107 failure(s) 127 errors(s) ] Current test ...
<jam> lifeless: ^^ sure looks like it is not stopping
<lifeless> jam: yeah
<Peng_> Some of those are XFAIL/unsupported features, right?
<jam> though: check-nodocs: extensions
<jam>     $(PYTHON) -Werror -O ./bzr selftest -1 --subunit $(tests)
<lifeless> jam: skips/missing dependencies will report as failures normally
<lifeless> Peng_: yes
<lifeless> jam: I smell a bug in the subunit integration
<lifeless> still, I prefer it this way
<jam> lifeless: prefer... ?
<lifeless> you can run the error mail through subunit-filter | subunit2pyunit
<jam> w/ subunit? Or getting "failures" for skips?
<lifeless> jam: not stopping
<lifeless> tells you all the issues in one roundtrip
<jam> lifeless: yeah, long ago it was that way
<jam> I think we changed it because the round-trip time was too long
<jam> by the way, nobody else is stepping up to be the 2.1.0b1 RM, right?
<jam> (so I should start focusing on that tomorrow)
<lifeless> I think you're it, yes
<Peng_> TypeError: can only concatenate tuple (not "StaticTuple") to tuple
<Peng_> Looks like there are some real errors.
<Peng_> That's not the only one, either.
<mathepic> Grr
<mathepic> The Loggerhead for bzr.dev isn't working :\
<Peng_> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/ WFM, if that's what you mean
<lamalex> Can I cherrypick multiple sets of revisions?
<lamalex> something like bzr merge revX..revY,revN..revM branch
<lamalex> ?
<lifeless> yes
<lifeless> do the first one
<lifeless> then the second with --force
<lamalex> lifeless: are you talking to me or someone else
<Peng_> lamalex: You.
<lamalex> how do i do one with --force and one without. two seperate commands?
<lamalex> thanks lifeless
<jam> Peng_: Yeah, it looks like we have more code that expects an explicit "tuple()" object that I didn't catch yet
<jam> like (foo,) + value
<jam> which thought it was concatenating tuples, etc
<jam> and bencode(StaticTuple) fails as well...
<jam> lifeless: can I use subunit without bootstrapping autoconf onto my windows machine?
<jam> argh....
<lifeless> jam: yes
<jam> UnavailableFeature: Internally performed glob expansion
<jam> ... :(
<lifeless> jam: the python stuff is in python/
<jam> lifeless: yeah, I set PYTHONPATH and got it to work
<lifeless> then do:
<jam> but there is no "setup.py" that I could find for subunit itself
<lifeless> cat trace | subunit-filter --no-skip | subunit-ls > failing.list
<lifeless> ./bzr selftest --load-list failing.list
<lifeless> jam: right, its got C and perl and c++ all in the one project; setup.py is epic fail for that
<jam> lifeless: but it should would be nice to put the  'subunit' module into my PYTHONPATH
<jam> "sure would"
<jam> and the pure-python scripts into the Scripts dir
<jam> since I'm not building anything else...
<jam> also, it fails a bit because if I do:
<jam> --no-passthrough
<jam> then it strips the extra context per failing test
<jam> but if I don't
<jam> then I get all the "make" garbage at the beginning
<jam> anyway, I'll work through that
<lifeless> what 'extra context' ?
<jam> lifeless: when a blackbox test fails it includes the log
<jam> ah, perhaps --subunit is stripping that out entirely?
<lifeless> jam: --subunit drops that
<jam> AssertionError: Unexpected return code 0 != 3
<jam> not helpful
<lifeless> my protocol branch of subunit is working towards supporting that
<davidstrauss> Is there an equivalent to --tunnel-user= for bzr?
<lifeless> davidstrauss: I don't know what --tunnel-user= is
<lifeless> davidstrauss: so I can't answer the question
<davidstrauss> lifeless: It's an option for svnserve allowing multiple users to use the same Unix user while forcing the user mentioned in commits, etc.
<lifeless> davidstrauss: no; because commits are done on the client
<davidstrauss> lifeless: Like a global --author
<lifeless> davidstrauss: 'commit' to a smart server is actually 'push'
<davidstrauss> ah
<lifeless> you can write a pre tip change hook to reject users
<lifeless> or you could write a post tip change hook to rebase-and-alter
<lifeless> [though the latter may find bugs/limitations in what that hook is expected to do :P]
<davidstrauss> lifeless: Hmm. Thanks for the suggestions. I think Bazaar will eventually have to find a way to enforce accountability for stuff like this. (Even if it's a separate field like "apparent user.")
<mkanat> Pack -> 2a conversion seems really slow in 1.18.
<mathepic> Update to 2.0
<mkanat> Okay. :-)
<lifeless> mkanat: its largely that 'pack' is much slower.
<lifeless> mkanat: but 2.0.0 is somewhat better at the conversion
<mkanat> lifeless: Ah, okay. :-)
<mkanat> Yeah, I have an Intel X25-M SSD and it's still taken like 3 minutes and isn't done converting 6000 or so revisions yet.
<mathepic> What are the best documents to read to get started in bazaar development?
<Peng_> davidstrauss: People push others' revisions all the time, though.
<Peng_> davidstrauss: I guess requiring GPG signatures would do it.
<davidstrauss> yeah :-/
<lifeless> are you looking for undeniability?
<mkanat> Hmm. I just did "bzr reconfigure --use-shared" on a packs branch above a 2a repository, and it seems that my repository simply disappeared and no longer exists now.
<mkanat> Not my 2a repository.
<mkanat> The packs repository in the subdirectory. I just get: bzr: ERROR: No repository present: "file:///home/mkanat/projects/parse-stacktrace/"
<Peng_> You might have a .bzr/repository.backup somewhere.
<mkanat> Peng_: Actually, not that I see.
<mkanat> I mean, it's ok, this was a checkout, but....
<lifeless> file a bug please
<lifeless> its probably because it was a checkout
<jam> mkanat: the output of ls -R would probably be helpful
<mkanat> lifeless: Okay.
<lifeless> I suspect it changed it from checkout to standalone and didn't add a repo
<mkanat> jam, lifeless: Okay. I'll see if I can reproduce.
<lifeless> mkanat: firstly please just file the bug with all the data you have so far
<mkanat> lifeless: Okay.
<mkanat> Okay, filed: https://bugs.launchpad.net/bzr/+bug/449886
<ubottu> Launchpad bug 449886 in bzr "Converting packs checkout to use 2a shared repository loses checkout repository" [Undecided,New]
<mkanat> And yes, it's reproducible.
<phinze> hey bzr folk, what's everyone using for developer code reviews?
<phinze> basically i'm looking for something that can do a diff between two branches with nice links out to the source code for when the reviewers want context
<phinze> right now we're doing gist.github.com + manual hops to loggerhead, but wondering if there's anything out there people are using
<jam> phinze: launchpad code review
<jam> used to use Bundle Buggy
<mkanat> phinze: I think review-board also supports bzr.
<phinze> jam: oh you guys moved past bundle buggy?  that must have been recently?
<jam> phinze: a few months ago...
<RenatoSilva> can't understand the purpose of bzr merge --pull
<phinze> ah gotchya, how are you liking it
<phinze> mkanat: thanks for the review-board reference -- will check it out
<jam> phinze: things to like, things to not like, I guess. The integration w/ the rest of launchpad is nice. It is missing a few bits that we used to use
<jam> it has been getting better, though
<mathepic> There are a lot of references to the bundle buggy on the site
<RenatoSilva> can I have an alias in the branch rather than ~?
<RenatoSilva> is there a command for that or will I need to manually edit branch.conf?
<mkanat> lifeless, jam: It seems to be happening with branches too, not just checkouts.
<mkanat> Oh, hmm, I might have an idea of what's going on.
<mkanat> It might not actually be so severe.
<lifeless> mkanat: why are you using reconfigure anyhow?
<lifeless> mkanat: I thought you wanted to upgrade?
<mkanat> lifeless: I did the upgrade and it kept it in the repo, didn't realize, and then did a reconfigure.
<mkanat> lifeless: I mean, kept it in the standalone repo.
<mkanat> Okay, I explained what happened, on the bug.
<davidstrauss> Is there a way to include function names in preview patches with "bzr send"?
<lifeless> davidstrauss: not at the moment, there is a general request that we support function names in diffing; that would follow on
<davidstrauss> lifeless: In the mean time, it seems like it would make sense to offer --diff-options for send, just like with diff.
<lifeless> davidstrauss: file a bug :)
<davidstrauss> lifeless: Done :-) https://bugs.launchpad.net/bzr/+bug/449923
<ubottu> Launchpad bug 449923 in bzr "bzr send should offer the --diff-options option" [Undecided,New]
<mathepic> I'm trying to find where bzr send creates the diff
<mathepic> Could someone help me out
<mathepic> Does send create its diff with MergeDirective._generate_diff
<RenatoSilva> IDEs would help on that
<mathepic> Nah, they love to take over the project structure
<mathepic> Not something I want to do
<RenatoSilva> unfortunately Eclipse has not a good Python IDE
<mathepic> I left Eclipse
<mathepic> Now I just use emacs
<mathepic> Bit more primitive, but you can get everything done
#bzr 2009-10-13
<igc> morning
<jam> lifeless or spm: can you go ahead and create a 2.0.1 branch from 2.0 and a 2.1.0b1 branch from bzr.dev@4734 ?
<jam> I'm going to be in and out a bit
<jam> (i decided to not release my last two patches from bzr.dev, instead waiting for 2.1.0b2 for the static tuple stuff)
<jam> I'd like to work on the releases tomorrow, though
<mathepic> I'm doing an update on the format docs
<mathepic> What should I change this to:  For example,
<mathepic> you may need to select 1.9 instead of 1.14 if your project has
<mathepic> standardized on Bazaar 1.13.1 say.
<mathepic> Is this good? "For example, you may need to select 1.14 instead of 2a if your project has standardized on Bazaar 1.18 say."
<mathepic> I'm going to delete the say, it doesn't fit in.
<maxb> Doesn't 1.18 support 2a? (with efficiency caveats)
<mathepic> Oops
<mathepic> When was the version before 2a was released
<mathepic> I'll fix that really quickly
<mathepic> Do I mark myself as the assignee and the status of the bug "Fix Commited"
<mathepic> I'm not sure how the bug-process works
<mathepic> Should I change the status to "In Progress", "Fix Committed", or just leave in the way it is?
<lifeless> jam: I can't anymore
<lifeless> jam: and spm is sick today
<lifeless> jam: you should mail RT
<lifeless> 1.16 and above support 2a
<igc> mathepic: thanks for working on that bug
<mathepic> igc: No problem.
<mathepic> Can anyone confirm that the info contained in it is correct? I don't know my history that well.
<igc> mathepic: while working on a bug, mark it "In Progress"; once you've pushed a branch with the fix, mark as "Fix Committed"
<mathepic> igc: Okay, thanks.
<igc> mathepic: I'd drop all the text about selecting a format prior to 2a. We need to *strongly* encourage everyone to upgrade
<mathepic> Okay.
<igc> mathepic: as lifeless mentioned, 1.16 and above support 2a
<mathepic> should I keep the paragraph about the rich-roots?
<igc> you can mention rich-root in a footnote but not the main text IMO
<igc> it tends to confuse more than enlighten
<igc> most readers
<igc> and after 2a, the issue effectively goes away because all future formats are rich-root implicitly
<igc> (as is 2a)
<mathepic> How about this: "The newest format, 2a, is highly recommended to use. If your project does not support 2a, then you should suggest to the branch owner to upgrade."
<mathepic> (That replaces the whole list thing)
<mathepic> Or simply nothing at all?
<mathepic> I'll just remove that whole block of text.
<igc> mathepic: "does not support" -> "is not using"
<mathepic> Okay, added it back. "Branch owner" or "Project owner"?
<igc> project owner
<mathepic> Okay, I'm pushing it to my branch.
<igc> cool. Then propose it for merging please
<mathepic> Its been proposed.
<igc> ah - then you may need to resubmit the proposal
<mathepic> I sent another review request to bzr-core. Is that what you mean?
<igc> yep. Thanks.
<mathepic> Okay.
<mathepic> Ugh, spotted a type
<mathepic> igc: I pushed it again to fix a typo. Do I send a review request again?
<igc> mathepic: hmm - forget what I said about requesting another review
<mathepic> igc: Okay.
<igc> you need to click "resubmit proposal"
<igc> top right hand corner
<mathepic> Okay, done.
<mathepic> Well, I have to go.
<igc> mathepic: thanks for your work!
<mathepic> No problem. :)
<lifeless> shouldn't need the resubmit anymore
<lifeless> the diffs update
<igc> lifeless: ah - ok
<igc> lifeless: hi btw - welcome back to Oz
<igc> lifeless: I hope the sprint when well
<lifeless> yup
<jam> lifeless: k. Also, I don't think pqm is running the test suite on python2.4 anymore. At least, I thought that was the problem so I installed 2.4, and found out it wouldn't build
<jam> so I sent in a patch to make it build on 2.4, but the previous patch had been accepted.
<lifeless> jam: rt that too :)
<lifeless> jam: the chroot has been upgraded, probably the default python has been altered
<jam> lifeless: is the fix just configuring pqm to do "make check PYTHON=python2.4" ?
<lifeless> yeah
<lifeless> force the version in the pqm config
 * igc lunch
<igc> bbl
<eferraiuolo> I was curious why a Loggerhead Package for Hardy was never released?
<vila> hi all
<bialix> hello all
<trondn> is there an equivalent of the hg export / import functionality in bzr???
<trondn> (export a changeset that I may import into another workspace)
<spiv> thumper: there's 'bzr send'
<thumper> ??
<thumper> spiv: tab fail
<spiv> thumper: er, sorry, wrong nick :)
<mneptok> tab-complte FAIL
<thumper> mneptok: hey
<spiv> trondn: There's "bzr send"
<mneptok> thumper: ahoyhoy!
<trondn> spiv:  and to apply it into the other one (and preserve commit id etc)?
<spiv> trondn: bzr pull or bzr merge from the file, like you would with the branch.
<trondn> spiv but that will make it a merge set??
<spiv> If you use 'bzr merge', yes.  But you can 'bzr pull' if you don't want to merge (assuming the history hasn't diverged).
<trondn> hmm...  bzr send -r -2 -o /tmp/foobar resulted in: Bundling 0 revision(s) ...
<mneptok> "bzr oh_god_i_killed_us_all" should undo the previous push. kthx.
<spiv> mneptok: bzr alias oh_god_i_killed_us_all="push -r -2 --overwrite"  ;)
<mneptok> spiv: but then i can't tell others about bzr's intuitive, natural language feature set
<spiv> trondn: oh, right.  "bzr send" really prefers to have access to the target branch so that it can bundle exactly the right set of revisions.
<spiv> trondn: which is a bit annoying when you don't have the branch accessible :/
<trondn> spiv I have both available... the one I want to put the one changeset in is ../mget... bzr send --help would be a lot more helpful with an example....
<trondn> guess I should just try out the rebase thing.. that's the thing I really want to do...
<trondn> (I just heard that it might not work the way I expected it to work ;-) )
<spiv> trondn: oh, if you have the target available, just "bzr send /url/to/target -o somefile"
<spiv> trondn: or, if the target is writeable, just cd to it and do "bzr pull /path/to/other/branch", you don't need the indirection of a merge directive file.
<spiv> rebase isn't ever exactly "the thing I really want to do" AFAICT; it's a means, not an end.  What's the goal?
<trondn> :( they have diverged so it tells me to merge :(
<trondn> the goal: put my changeset at the _end_...
<trondn> and don't fuck up the history with another merge set..
<spiv> Why is merging so terrible for you?
<trondn> it makes the history unreadable...
<trondn> I'm working on implementing a feature committing multiple times... but I still want to bring in the work happening on trunk...
<spiv> Hmm, I don't find that.  "bzr log" by default only shows the mainline commits.
<trondn> and I want my changes to appear at the end in one bulk instead of a spagetti with the "merge from trunk"..
<trondn> with git I normally just do git rebase, in Mercurial i use export / import... in bzr I currently apply each patch by hand and commits them again :(
<spiv> So, if you want to squash things into a linear history when things have diverged, rebase is an alright way to do that.  I personally find the original history quite readable, though.
<spiv> There is a rebase plugin.
<spiv> But I suggest you play a little bit with "bzr log" and its options, you might be surprised.
<spiv> <https://launchpad.net/bzr-rebase> is the rebase plugin btw, in case you don't already have it.
<trondn> I guess I could.. right now I find it terrible to track down a bug on let's say lp:drizzle.. bzr log mostly shows me merge "foo", so I run it with bzr log -n 0 -v, but then I see changes multiple times because multiple people merged the same changeset into their tree etc...
<trondn> (downloading and installing now)
<spiv> Normally I only want to see the mainline commits, I actually quite like that a long-running feature that took 30 commits to develop is shown as a single mainline commit, rather than as 30 separate pieces.  (But also that the individual pieces are still there when I need them.)
<crisb> when I use bzr qlog it chops off the first digit of the revision number - anyone else seen this before!?
<crisb> also, shouldnt qcommit be a resizeable dialog?
<crisb> i swear it used to be...
<davidstrauss> crisb: It is resizable. Change your monitor resolution.
<crisb> davidstrauss: i'm at 1650x1080!  its not that it appears maximised, it just wont let me resize it or maximiseit
<davidstrauss> crisb: No, I mean reducing your monitor resolution will make the window bigger. :-)
<crisb> :)
<crisb> so its not supposed to be resizeable in the same way as say qlog?
 * davidstrauss actually has no idea.
<crisb> sorted - dodgy qbzr.conf :)
<crisb> revision number chopping still exists though :(
 * igc dinner
<igc> crisb: I'm seeing the first digit being chopped too in qlog if the re count is > 1000
<igc> crisb: can you raise a bug for that please?
<crisb> igc: sure, I already raised 450179 - looks like Alexander Belchenko has confirmed it too
<igc> crisb: ah - I see you already have - thanks
<bialix> is it possible to quickly/cheaply determines how many revisions in the repository? not in the mainline revisions, but in repository overall?
<bialix> crisb: there si hardcode limit for 4 digits in qlog
<bialix> crisb: there is hardcode limit for 4 digits in qlog
<crisb> bialix: yes, I noticed that in logwidget.py - but changing it to more than 4 digits didnt help
<bialix> there is custom painting code
<bialix> without looking into code I'd say there is several places which require to be fixed
<Anteru> Hi
<Anteru> I'm importing a svn repo into bzr, with 2324 revisions, but bzr says copying revision x/2304 -- is this normal?
<jelmer> Anteru: yeah, that could be correct
<jelmer> Anteru: bazaar only imports branches, and some commits in svn might have been outside of actual branches
<Anteru> err, I'm trying to import _the whole repo_
<jelmer> Anteru: if you create a "branches" directory in svn that wouldn't show up in bazaar anywhere
<Anteru> with /branches, /tags, /trunk
<Anteru> hm ok
<Anteru> I previously tried git, where you have to specify the layout
<Anteru> and git imports everything, including branches from svn
<jelmer> Anteru: Git doesn't import these commits either afaik
<jelmer> Anteru: e.g. if you add a file called README in /, which branch would you expect it to end up in?
<Anteru> well, I would expect an error
<Anteru> btw what are the parameters for the repository layout?
<Anteru> it says "Using repository layout: trunk0"
<jelmer> Anteru: yeah, that means the standard /trunk, /branches, /tags layout
<Anteru> and looking at the doc page, it lists none, trunk,, and default: auto
<Anteru> Ok, I'm halfway through, but I still don't get why revisions are missing
<Anteru> I had one branch or so in the past in /branches/, which has been deleted
<Anteru> I simply don't want to loose history
<jelmer> Anteru: are you using --keep ?
<Anteru> nope, will try
<jelmer> and --all?
<Anteru> why would I use keep when I use all?
<Anteru> I just want the whole history
<Anteru> that is, being able to restore anything which was stored in the SVN (d'uh, missed --all)
<Anteru> ah ok, looks good
<Anteru> thanks!
<jelmer> sorry, was aaway
<jelmer> Anteru: np, glad it worked
<Anteru> just double-checking, with --all, it says copying revisions x/2314
<Anteru> du, which is still 10 too few :/
<Anteru> even with --keep --all
<Anteru> I guess tags are skipped?
<Anteru> ah damn, the folder /branches was called /branch some time back in ancient history
<jelmer> Anteru: it should follow that
<jelmer> Anteru: tags are not versioned in bazaar, so they wouldn't count as revisions
<Anteru> ok I got 8 tags
<Anteru> so 2 revisions ... one might be the /branch -> /branches rename
<Anteru> and one might be the initial commit
<jelmer> igc: Does fastexport/fastimport follow renames?
<jelmer> (looking at the samba import)
<Anteru> I guess even if there is something missing, it can't be a lot
<igc> hi jelmer
<igc> jelmer: yes it does, though I think one needs to explicitly ask git-fast-export to detect them
<igc> and export them
<igc> (and I didn't do that)
<jelmer> igc: that might explain the big repo size
<igc> interesting
<igc> not that we've implemented copy support yet
<jelmer> igc: copy support would help too I suppose
<jelmer> igc: samba trunk has two top-level directories that have a lot of code in common
<Anteru> w00t, just managed to work with a SVN repo from bzr
<Anteru> though the "push" speed is kinda slow
<jelmer> Anteru: it should be faster the second time around
<jelmer> Anteru: the first time it has to update caches, etc
<igc> jelmer: fyi, I changed the file-id algorithm and the repo size dropped from 500M+ to 350M.
<igc> jelmer: jam gave me the tip to do that
<jelmer> igc: wow, I wouldn't expect it to matter that much
<igc> jelmer: I was generating file-ids using the full-path - now I just use the basename
<igc> jelerm: scary ah - one line change having that sort of impact!
<jelmer> igc: Yeah, indeed
<jelmer> I should remember to do a similar thing next time I update the mappings for bzr-{git,hg}
<Anteru> jelmer: I tried twice, it says something about finding tags each time
<jelmer> Anteru: what version of bzr-svn are you using?
<igc> jelmer: btw, how easy/hard would it be for you to convert svn-fast-export.py to use subvertpy instead of the std bindings?
<Anteru> jelmer: bzrlib 2.0.0, python 2.5.4 (latest stable installer for windows)
<jelmer> igc: should be fairly easy
<igc> jelmer: it would be sweet if you could take a look - bug 273361 is driving me nuts
<ubottu> Launchpad bug 273361 in bzr-fastimport "svn-fast-export.py crashes with too many open files" [High,Confirmed] https://launchpad.net/bugs/273361
 * jelmer has a look
<igc> jelmer: the all-but-identical C implementation works fine
<igc> jelmer: so I suspect the bindings
<igc> jelmer: and furthermore, using the same bindings you are makes it easier for Windows users because they don't need to install extra pieces IIUIC
<Anteru> jelmer: well, gotta go for a mo', gonna test more thoroughly later, thanks for the starting help! I'm evaluating a switch from SVN -> git/hg/bzr, and right now, bzr is back in the race ;)
<Tak> one thing that makes bzr a big contender in that regard - for commands that apply, `svn blah` almost always maps directly to `bzr blah`
<jelmer> igc: ah, right
<jelmer> Anteru: cool :-)
<Anteru> ciao
<vila> jam: ping
<johnf> jelmer: ping
<johnf> lifeless: ping
<vila> jam: ping
<igc> night all
<igc> hi vila
<vila> wow, Ian, still up ?
<igc> vila: we should catch up soon - I'm heading to bed now
<igc> vila: just packaging up explorer 0.8.3 in time for the 2.0.1 release
<igc> night
<vila> k
 * fullermd sneaks up behind vila and ties his shoelaces together.
<vila> 8-)
<jam> vila: pong
<vila> jam: I'm not sure if this is related to bug #449776, but babune failed hard
<ubottu> Launchpad bug 449776 in bzr "_simple_set_pyx is incompatible with Pyrex <0.9.6.3" [Undecided,New] https://launchpad.net/bugs/449776
<vila> and it's clearly related to not being able to run without extensions
<vila> jam: so frebsd7. freebsd8. tiger and leopard all failed
<vila> jam: can you have a look and tell me ?
<vila> jam: search for the last midnight run on babune, I'm running on specific branches since
<fullermd> I'd hope not.  pyrex is way newer than that on BSD...
<vila> and not installed on my OSX slaves, so :)
<jam> vila: It is giving me times in "CEST", should I look for 00:00 ?
<vila> jam: yes
<vila> jam: build36 for freebsd7
<jam> yeah, looking now
<vila> ok
<jam>     self.assertIs(k1, obj.add(k2)) AssertionError: ('foo',) is not ('foo',).
<jam> that is a bit strange
<jam> it hints that the hashing may be putting objects in different locations
<jam> I know I had a bug there, but I had fixed it before submitting.
<vila> jam: looks like you have another then :)
<jam> vila: are any of the others failing?
<jam> note that I'm planning on cutting 2.1.0b1 from before those patches for now
<vila> jam: hardy, jaunty and karmic are ok
<jam> since if I can't land everything, it isn't worth releasing part of it
<vila> jam: gentoo too
<jam> vila: is this a 32/64 bit issue?
<vila> it shouldn't, karmic is a 64bits slave while hardy is a 32bits one
<jam> k, and do you know the versions of python there ?
<vila> and jaunty is 64 bits too
<vila> freebsd7 is 2.5.4, errr, you have a selftest output, everything is mentioned there :)
<vila>    bzr-2.1.0dev python-2.5.4 FreeBSD-7.2-RELEASE-amd64-64bit-ELF
<jam> mthaddon: ping (are you the LOSA online right now?)
<mthaddon> jam: yep (but we all highlight on losa, so you can just ping losa)
<jam> mthaddon: ah, good. I always have trouble tracking you guys down :)
<jam> I need to cut 2 new branches for pqm
<jam> can you help me?
<mthaddon> jam: I can do, but it'd be ideal if you could put it all in an RT request
<jam> mthaddon: I can, though the rt system honestly confuses me quite a bit
<jam> I'm never really sure what I need to put into the request
<jam> and "RT" isn't a great search term on the canonical wiki
<jam> vila: do you have access to the freebsd machine, that I could try testing directly?
<jam> The test suite passes for me on python2.5.2 on Jaunty
<jam> also, do you know why tiger and leopard are failing the test suite?
<jam> well, failing to build
<vila> jam: not really, I think the MIN MAX are warnings only, the 'lipo: can't figure out the architecture type of: /var/tmp//cczgHHiH.out' is a bit puzzling
<jam> so, warning "MIN" redefined is code I didn't touch., and as you say it is only a warning
<jam> bzrlib/_static_tuple_c.c:32:33: error: bzrlib/_static_tuple_c.c:32:33:_simple_set_pyx_api.h: No such file or directory
<jam> That fails because we need to compile _simple_set_pyx.pyx first
<jam> as it auto-generates the api.h file
<jam> and since you don't have pyrex...
<vila> ..which is a conf we want to support
<vila> ..no pyrex, no C files
<vila> until we version the C files
<jam> *I* don't care to support people building *from source* who don't have pyrex/cython
<vila> ...which we won't do in the coming minutes as you and I know damn well :)
<jam> Tarball is a little bit different
<jam> though again, if you are building from scratch, install dev tools
<jam> we require gcc
<vila> hmm
<vila> yeah right, this predates babune running explicitly without extensions, so indeed I should install pyrex there
<jam> pyrex used to be a lot more rare...
<vila> AIUI I should be able to easy_install it....
<vila> let's check that myth...
<jam> I believe so
<vila> pffff, easy_install is for 2.5 not 2.6.... how do I install it for 2.6...
<jam> vila: I use easy_install here w/ py2.6
<jam> though there is a huge discussion on python-dev about how setuptools is not properly maintained, you should use "Distribute", etc.
<vila> jam: it's a distro problem, OSX came with 2.5 and easy_install, I needed 2.6  and installed it from python.org, but no easy-install there :-/
<jam> vila: http://pypi.python.org/pypi/setuptools#cygwin-mac-os-x-linux-other
<jam> http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c9-py2.6.egg#md5=ca37b1ff16fa2ede6e19383e7b59245a
<jelmer> jopong
<jam> vila: https://code.edge.launchpad.net/~jameinel/bzr/2.1-pyrex-64bit/+merge/13292
<jam> should fix your freebsd issues
<jam> mthaddon: any progress on creating the pqm branches?
<mthaddon> jam: I'm afraid I've been tied up with other things all day and am close to EOD - I should be able to get to it tomorrow if another losa hasn't by then
<jam> k
<davidstrauss> How can I get bzr-svn to not use the svn 1.4 client I have also installed?
<jelmer> davidstrauss: make sure subvertpy is linked against the right vcersion of subversion
<davidstrauss> jelmer: how can i do that?
<jelmer> davidstrauss: when building subvertpy, make sure that it finds the deveopment files for the version of subversion you'd like to use
<jelmer> you can override the svn prefix with the SVN_PREFIX environment variable
<davidstrauss> jelmer: I'm not building it. I'm just using the Bazaar DMG installer
<jelmer> davidstrauss: doesn't that come with its own copy of the svn libs then?
<davidstrauss> jelmer: not sure
<davidstrauss> jelmer: but it keeps complaining about needing a newer svn to use my working copies
<davidstrauss> jelmer: I'm using svn 1.6 for my own work
<jelmer> davidstrauss: I suspect you're out of luck in that case, I think a ndewer version of svn would have to be included in the DMG
<lifeless> moinish
<vila> . o 0 ( fullermd and his jokes...)
<fullermd> Jokes?  Hm, I'm fresh out today.  Maybe there's one in the pantry somewhere...
<vila> You tied my shoelaces earlier and when I stood up... all my PCs crashed (gee, even my macs....
<vila> ... in fact the whole block suffered a power outage....
<fullermd> Crap, you mean I missed the next block over?
<fullermd> I'll try harder next time, I swear.
<vila> ...so thank you very much all the same
<vila> it took nearly an hour to get out of the power outage (ok 45 minutes, 4-5 m-i-n-u-t-e-s ! 2009 !
<vila> :D
<fullermd> http://www.absurdnotions.org/page18.html    :p
<vila> add to that nearly an hour more to get an internet back
<jam> hey vila, /wave
<vila> url ? you think I can already use url ? All I have right now is a poor emacs irc client running on borrowed wifi (thank neighbour !)
<vila> ha jam !
<jam> ouch
<vila> jam: Were you still connected ?
<fullermd> Wait, you can use emacs?  I figure with your shoes tied together, you didn't have enough appendages available to use it...
<jam> I went offline for the last... 30 min or so
 * jam went to the coffee house
<vila> jam: I crashed exactly 3 hours ago
<jam> I saw your client go offline
<vila> and 3 mintes
<vila> jam: that was it, no more power
<vila> jam: I won't restart the full monty until tomorrow, did you have anything important or was everything in your submission already ?
<jam> vila: how big of an outage? (house/street/block/city)?
<vila> block
<jam> vila: I think everything is submitted
<jam> no worries about babune et al
<vila> jam: good, I won't be able to review it tonight either so if you need it for some release, nag the aussies :)
<jam> no, I'm not releasing that code
<vila> good
<jam> I want it to bake in bzr.dev for most of a cycle
<vila> so I can (untie my shoelaces first) enjoy my evening ;-)
<jam> though I won't be releasing until a losa responds to my rt request for new branches anyway
<jam> vila: absolutely
<zsquareplusc> is there any good reason why "bzr explorer" does NOT open a view of the branch you started it in?
<jam> zsquareplusc: 'bzr explorer .'
<jam> igc knows why, my guess is that you have the option by specifying '.', that if you don't specify it, it is assumed maybe you want the generic start
<mathepic> igc: Okay, I fixed that typo. Do I resend merge request or do I resend review request?
<zsquareplusc> heh, i'd make an option for the generic start as i don't care --how-long-an-option-is-when-i-click-a-link. but ok, good to know about "."
<lifeless> mathepic: just reply to the thread saying its fixed
<mathepic> Okay, thanks.
<mathepic> I accidently sent that second review request on my merge, can someone approve that?
<mfer> hey folks. i was wondering if someone could point me to simple (one app install) for bzr explorer or another good mac gui
<ToyKeeper> mfer: I've enjoyed bzr-gtk, but I don't know whether it works on a mac.
<jam> mfer: it is 'being worked on'. PyQt is a major dependency on the Mac, because there isn't a pre-built version
<jam> I'm not sure on the current state, but the 'bzr-mac' mailing list talks about getting one built
<mfer> jam: PyQT is a huge pain of a dependancy
<mfer> jam: thanks, i'll check out the mac list
<ToyKeeper> Any idea how to merge revisions from a git repo?  Someone imported my head revision then made several changes, and I'd like to merge it without manually replaying each revision.
<jam> bzr-mac@lists.launchpad.net
<jam> I think it is a launchpad group
<jam> https://edge.launchpad.net/~bzr-mac
<ToyKeeper> bzr-git can browse and convert the repo, but I haven't had any luck merging.
<ToyKeeper> 'bzr merge' by itself bails due to having no common ancestor, which makes sense.
<ToyKeeper> 'bzr merge -r 1.. ../git-branch' does nothing and claims "All changes applied successfully."
<ToyKeeper> 'bzr merge -c 2 ../git-branch' fails with a conflict (even though the patch applies cleanly).
<beuno> ToyKeeper, why do you need to specify a revision?
<ToyKeeper> This works, except for losing timestams, commit messages, and other metadata:  bzr diff -c 2 ../git-branch | patch
<ToyKeeper> beuno: I'm specifying a revision because 'merge' by itself can't find a common ancestor.
<ToyKeeper> I'd like to tell it "local rev 123 equals remote rev 1" somehow, then merge normally.
<beuno> ToyKeeper, ahd, I *think* you can force it to merge with -r -1
<beuno> or -r 0, I can't remember
<jam> beuno: -r 0..-1, but he at least thought he was doing that
<jam> ToyKeeper: you tried "bzr merge -r 1..-1" ?
<mfer> jam: seems the mac ui isn't going to come soon from the main lists. Most are interested in bzr explorer for mac which is a pain to install with the 140MB/3 dependencies you have to install first. and, the mac ui is only slowly being developed.
<jam> that *might* be equivalent to -r 1..
<ToyKeeper> jam: Similar result as '-c'; it thinks there's a conflict.
<jam> ToyKeeper: are you sure there isn't a conflict?
<ToyKeeper> The resulting commit is basically the same as if I had just rsync'd the content; no metadata or record of any intermediate revisions.
<jam> ToyKeeper: so if you did '-r 0..' then it would record a merge
<fullermd> If merge can't find a common ancestor itself, you're probably going to end up with a bit of a mess...
<jam> but by doing a named rage
<jam> range
<ToyKeeper> There isn't a conflict.  Everything applies cleanly if I "diff | patch" each rev.
<jam> then we are considering that to be a cherrypick
 * ToyKeeper tries again from 0
<jam> ToyKeeper: diff + patch a series of patches can still conflict on the endpoints...
<jam> but I won't say it has to here
<jam> you might try just merging and rejecting the first revision, to create a common ancestor
<jam> and then applying from there
<jam> (bzr merge -r 0..1; bzr revert .; bzr commit -m 'sync at the first rev')
<jam> then again
<jam> my guess is you are getting conflicts because of file-id differences
<jam> but I can't guarantee that
<ToyKeeper> jam: The last approach worked: merge -r 0..1 ; revert ; commit ; merge
<ToyKeeper> I don't think I would have tried that.
<ToyKeeper> Other than that bit of weirdness with merging, the git support works impressively well.  :)
<ToyKeeper> D'oh.  "different rich-root support" made my coworker give up and go back to git.  :(
<ToyKeeper> Perhaps I'll wait until most people have bzr 2 before trying again.
<fullermd> You can use rich-root-pack on anything newer than 1.0.
<ToyKeeper> fullermd: Yes, it just didn't happen that way and I think the guy was looking for an excuse to stop using bzr.  I guess I can't expect much else from kernel devs.
<lifeless> the rich root transition hurts
#bzr 2009-10-14
<ToyKeeper> Heh, I wouldn't exactly say it hurts, but it can definitely confuse people who don't expect it.
<fullermd> NOBODY expects the rich root transition!
<mathepic> I know rich-root adds some info thats not in the others, but what specifically is that?
<spiv> The root of the tree gets a unique file-id and version like any other directory.  This means operations like "bzr mv . subdir" can be tracked accurately, and is also useful for merging a branch into a subdir of an unrelated branch, as well as just generally making our data model a little more consistent.
<spiv> (IIRC some (all?) non-rich-root formats did allow the file-id to be stored, but they didn't support tracking a version; it was just implicitly considered to be last modified by the current revision)
<igc> morning
 * igc lunch
<davidstrauss> Where can I find the docs on X.Y.Z revision numbers?
<Peng_> I know the current scheme was explained in detail on the list back when it was designed . . . .
<RenatoSilva> Is there a way to make 'bzr ignore' use the conf in ~, not the branch?
<bialix> hello all
<mneptok> ssssshhhhhhh! the maestro is decomposing.
<bialix> ?
<mneptok> looking for meaning in anything i say is like looking for the hot dog vendor at a bar mitzvah.
<igc> hi bialix, mneptok
<bialix> hi igc
<bialix> igc: do you need windows installer for bzr-explorer?
<igc> bialix: if you get a chance, yes please
<mneptok> igc: good morning!
<bialix> mneptok: what is mitzvah?
<bialix> mneptok: ok, I found
<bialix> hot dogs are not cosher food?
<mneptok> no. anything from a pig is not kosher.
<bialix> never think that sausage made from pig
<vila> hi all
<bialix> bonjour vila
<vila> hi bialix
 * vila restore babune after yesterday crash, may be on and off for a couple of hours
<bialix> igc: after translations update it makes sense to run `python setup.py build_mo` to refresh auto-generated english translation
<igc> bialix: oh - ok
<bialix> installer has uploaded
<igc> bialix: thanks
<bialix> my pleasure
<igc> bialix: wrt http://doc.bazaar-vcs.org/explorer/en/processes/making-a-release.html ...
<spiv> vila: when are you going to finish and land lp:~vila/bzr/405745-http-hangs btw?  It's been lingering in the queue for a while.
<igc> is step 2 needed there? or only after downloading the translations?
<igc> bialix: I tried python setup import_po btw and it fell over IIRC
<vila> spiv: I should mark it in progress because it hangs under some circumstances,
<igc> see http://doc.bazaar-vcs.org/explorer/en/processes/updating-translations.html
<igc> hi vila!
<bialix> igc: step 2. Build binary translations files (bialix to confirm) -- required for installer
<bialix> step 3 has error: should be iscc extras/explorer.iss
<vila> spiv: that was an important motivation to work on  bug #392127 but,
<ubottu> Launchpad bug 392127 in bzr "bzr >= 1.16 on gentoo: can't start new thread" [High,In progress] https://launchpad.net/bugs/392127
<vila> spiv: while I reached a point where hardy. jaunty and karmic weren't failing nor hanging in any way,
<bialix> igc: fellover?
<bialix> igc: fell over?
<igc> bialix: yes
<bialix> how?
<vila> spiv: I'm now experiencing hangs again on Freebsd and OSX :-/
<bialix> traceback?
<spiv> vila: Ah :(
<bialix> igc: traceback?
<igc> bialix: yes.
<bialix> igc: can I see it?
<igc> it was late so I didn't collect it :-(
 * igc tries again
<bialix> you can run it again
 * vila needs to reboot, bbl
<igc> bialix: http://pastebin.com/d8883196
<bialix> interesting
<bialix> tarball support is broken for you?
<bialix> igc: what is your python version?
 * bialix suspects bad thing
<igc> bialix: 2.6.4rc1
<bialix> python devs killed Kenny?
<spiv> lifeless: Mind if I "bzr upgrade --2a lp:bzr-pqm" ?
<bialix> igc: oh, I see, explorer -> po/explorer <-- there is no file extension, should be explorer.pot -> po/explorer.pot
<bialix> igc: can you send me export tarball?
<igc> bialix: sure
<bialix> it seems lp devs killed Kenny and changed the format of export tarball again
<spiv> lifeless: (I have a slightly rough patch to allow me to pqm-submit branches I don't have locally, but my local copy of the bzr-pqm branch has already been upgraded to 2a)
<lifeless> spiv: doit
<spiv> lifeless: ta
 * spiv blows away the old backup.bzr
<bialix> igc: http://pastebin.com/d36e98da0
 * bialix starts to hate python 2.6
<bialix> igc: I dunno why it does not work for you
<bialix> igc: maybe recent regression in 2.6.4rc1?
<igc> bialix: ok - thanks for looking
<igc> bialix: while I have your attention ...
<igc> that qexport patch?
<igc> what's required to tweak it to make you happy?
<bialix> igc: ha!
<bialix> igc: I've got the same error with pythopn 2.6 on my machine
<bialix> Python 2.6.2
<igc> bialix: I'm planning to fix some qbzr bugs over coming nights
<bialix> igc: qexport?
<igc> bialix: is there a rough date for the 0.15 release?
<bialix> igc: that old discussion how to better
<bialix> igc: when it will be ready
<bialix> igc: I'm too busy at work until the end of the month
<igc> bialix: end of month is good for me fwiw
<bialix> igc: about qexport: I'm not quite agree with your latest changes
<bialix> you saw my comments though
<igc> bialix: I did. There were lots of comments though - I'll take another look soon
<bialix> from other hand I don't have enough time to polish it right now, so I can close my eyes if you merge anything you think is appropriate for you or bzr-explorer
<igc> bialix: ok. I'll land the bits we agree on
<bialix> igc: my main concern is change of controls order
<bialix> igc: I don;t agree that archive format should be first item
<igc> bialix: fair enough
<igc> bialix: my bigger issue was defaulting to zip on Windows ...
<bialix> ping me or send mail to qbzr ml if needed so we can reach some consensus
<igc> and sohlud tar.gz instead of tgz, etc.
<igc> showing
<igc> sure
<bialix> what's problem with zip default on Windows?
<igc> no problem - it defaults to tgz now
<igc> zip is better known to windows users
<bialix> in some unmerged-yet-patch it was changed
<igc> yep - this one :-)
<fullermd> igc: ping
<igc> hi fullermd
<fullermd> Howdy.  You wanna chat about revspecs?
<igc> sure
<fullermd> So, re your (2) (where revid falls in the list), one of my criteria in order choice was a WAG of relative expenses.
<igc> wag?
<fullermd> I figured checking if a name exists as a tag is fairly fast, since it's a list in one place that's probably pretty short.  Checking the history for a revid would take longer 'cuz there's more to look at.
<fullermd> Wild Ass Guess.
<fullermd> And date would take longer than revid, 'cuz you have to peek inside the revs.
<spiv> fullermd: all of a sudden I'm imagining Aretha Franklin singing "R-E-V-S-P-E-C, find out what it means to me..."
<igc> :-)
<fullermd> That was weighed against my feeling for how often we'd enter certain things.  I'd want to paste in tags all the time, and revids probably next.
<fullermd> (though it's kinda a tossup how often I'd put in dates vs revids maybe, but given the expenses...)
<fullermd> And branch:...  well, I sorta threw that in 'cuz I could   :p
<al-maisan> hello there, I have a question re. ignored files: they continue to appear in "bzr diff" output .. is there a way to *not* have ignored files in "bzr diff" output?
<spiv> Although thinking about it, "You wanna chat about revspecs" sounds more like "Let's talk about revspecs baby, let's talk about you and me..."
<spiv> al-maisan: only versioned files appear in "bzr diff" output
<al-maisan> ignored files are versioned files
<igc> spiv: it's clearly late there :-)
<igc> fullermd: hmm
<al-maisan> spiv: so there's no way to exclude them from "bzr diff" output
<fullermd> al-maisan: The main thing 'ignore' directly affects is whether 'bzr add' will add it; it doesn't have any affect on files that are already versioned.
<al-maisan> fullermd: I see, thanks.
<spiv> al-maisan: the ignore rules don't control which files which files are versioned, they control which files are automatically added by 'bzr add', and which unversioned files 'bzr st' will complain about, etc.
<spiv> You can always explicitly add a file that matches an ignore rule.
<al-maisan> OK .. understood.
<igc> fullermd: one simple answer is to take revid out of the dwim list altogether
<spiv> al-maisan: you might find the filterdiff command helpful
<igc> fullermd: we can always add it in later
<fullermd> I don't overly like that.  It and tags are the two things that first occured to me I'd want to DWIM.  What's the motivator?
<al-maisan> spiv: thanks for the hint .. will take a look.
<spiv> al-maisan: it's part of the 'patchutils' package on ubuntu
<igc> fullermd: and the trade-off of speed vs convenience worries me, cause revids aren't convenient regardless
<igc> fullermd: in bzr, revids can worry in form based on where they came from
<igc> vary
<igc> e.g. a svn import has svn:...
<Peng_> For me, DWIM revids are most useful.
<igc> which *looks* like a revspec
<fullermd> Well, but is "-rsvn:asdf" more eyetwisting than "-rrevid:svn:asdf"?
<fullermd> You're probably unlikely to type a meaningful revid without meaning to, thinking you're typing a revno or tag or something.
<igc> the problem is that svn:xxx is a real revspec for xxx in the svn repo
<spiv> Looking to see if a single revid is present or absent in a repo should be pretty quick... what's the concern about speed?
<igc> so, iiuic, a dwim revspec for foreign branches will break?
<spiv> igc: I think the svn revids are svn-v4:...?
<fullermd> Oh.  Well, in that case, that would never get to the DWIM (since it checks for a registered revspec first)
<fullermd> So you'd have to use the full revid:blah form.
<spiv> andrew@steerpike:~/code/twisted/trunk$ bzr revision-info
<spiv> 15278 svn-v4:bbbe8e31-12d6-0310-92fd-ac37d47ddeeb:trunk:27226
<spiv> (or svn-v3 for earlier versions of bzr-svn, and anything before that is simply ancient...)
<igc> spiv: I wonder whether git and hg also have the same form - probably
<fullermd> Well, 'ancient' is no counter-argument; it's a VCS, ancient craps stays around forever  ;)
<spiv> So for the specific case of revisions converted by bzr-svn its shouldn't be an issue.
<spiv> And I think it's probably good practice for foreign revid mappings to be versioned like that.
<fullermd> So, that case seems like "not all revids can just be DWIM'd, 'cuz they'll be grabbed earlier".  I don't think that's a deal-breaker, it just means you can't always use the short form.
<spiv> fullermd: "bzr foreign-mapping-upgrade" :P
<spiv> igc: I'd guess the bzr-git and bzr-hg plugins do, but I don't know for sure.
<igc> spiv: right, but there's no certainly re what form a revid will take
<igc> it can be almost anything
<spiv> Yeah, you're right that a revid could look like a revspec.
<fullermd> Yah.  But "Most Of The Time"(tm), they probably won't start with "valid-revspec:", so would DWIM OK.  And when it does, you'd just have to disambiguate.
<spiv> But weird revids are definitely not the norm.
<igc> spiv: the issue we're discusisng btw is dwim ordering ...
<igc> fullermd is proposing ...
<Peng_> Oh man, I forgot about "foreign-mapping-upgrade" when bzr-git's revids changed, and wound up pulling everything again. Shoot!
<igc> revno, tag, revid, date, branch iirc
<spiv> Peng_: but it's such a memorable command name! ;)
<igc> spiv: I suggested moving revid to last
<fullermd> So the big trap would be when it starts with valid-revspec:, AND the remainder under that revspec actually translates to a revision.  I don't think that's likely enough that it would cause problems in practice.
<igc> or putting it immediately after revno
<igc> fullermd: I agree it's most unlikely
<Peng_> Would the DWIM stuff actually break reverring to revspec:whatever explicitly if "whatever" looks like a revno/tag/etc.?
<Peng_> referring*!
<fullermd> No, once it catches revspec: it passes to that class to handle it.  DWIM only triggers when you fall off the end of from_string()
<fullermd> (the place where it used to assume it was a revno if it were numeric, else die)
<spiv> igc: hmm.  It's too late in the day here for me to form a sound opinion on that, I think :)
<Peng_> fullermd: OK, good.
<fullermd> igc: So, one reason (perf to one side) I like it after tag is because the user controls tags; revids, generally not.
<Peng_> I've always liked that bzr's revspecs are unambiguous, so you can have tags like "123" or "2009-10-14" or whatever you want. :)
<spiv> igc: I do think that in practice there will never be ambiguity between a tag, a date, a branch name, and a revid.
<fullermd> So if there IS a tag that mirrors a revid (unlikely though that may be), it's because the user meant it to, so we should probably prefer that.
<spiv> Er, I mean:
<igc> fullermd: right.
<fullermd> (and in general, if a tag mirrors a valid date/branch/etc, we should prefer it)
<spiv> never be ambiguity between a revid and any one of of those others.
<spiv> (i.e. revid vs. date, revid vs tag, etc.  I can imagine tag vs. branch or date clashing)
<fullermd> I don't have any religious objection to changing the order; it just feels right to me as-is.
<igc> fullermd: i like your order ...
<igc> I'm just not sure where revid best fits within it :-)
<igc> the others are good
<spiv> If we're uncertain, let's try fullermd's ordering and see how it feels?  I don't really see where revid is placed mattering very much, because it's so unlikely to conflict.
<fullermd> Well, until we get branch-by-name rather than branch-by-location, specifying branches is going to be pretty rare.  So having that last fits.
<igc> if a user cut-and-paste a revid, they really would expect it
<fullermd> I mostly added it because I looked at the list of revspecs, and it said to me "Hey, I s'pose people might use me, sometimes..."
<igc> fullermd: so let's go with your order given no-one feels strongly
<fullermd> (also rare because I can never mentally figure out whether/how a branch: spec is going to WORK...)
<spiv> And because revids are so unlikely to conflict, I think that a) we don't need to worry about it now, and b) if we change where revid is in that order later, no-one will be disturbed.
<igc> I just wasn't sure and though we ought to open it up for debate
 * fullermd nods.
<fullermd> 'k, so that leaves your (1) (quick-fail if it looks like a revno but wasn't).
<fullermd> About the only thing that's likely to trigger on if it gets past there is probably tag.  Though I guess you could have a branch at a path like ./5.
<igc> tag is the only clash in my mind
<spiv> fullermd: well, there's another possibility...
<fullermd> So if you expected a revno and one wasn't there (and you don't have a tag named that), it means bzr eats more time before handing you the error.
<spiv> fullermd: try them *all*, and if multiple dwim candidates match refuse to guess.
<spiv> fullermd: (and so force the user to disambiguate with an explicit revspec)
<igc> that gets expensive
<fullermd> Yeah.  I'd guess thatn 95% (or 99%) of the time, you're entering a revno.
<fullermd> So going through the expense of loading the whole history tree and checking the timestamp of each rev would be Bad(tm).
<fullermd> After all the work to AVOID doing all that extra work on simple stuff, I'd get lynched for suggesting that  ;)
<spiv> Incidentally, this discussion suggests to me that perhaps we should disallow tags that look like a natural number...
<igc> spiv: we can't I feel - roundtripping
<spiv> i.e. any matching '[1-9][0-9]*'.  But probably few users would do that, and won't be too surprised by the results if they do.
<spiv> igc: *nod*
<igc> spiv: I just think if something looks like a revno, we should assume it is
<spiv> Yeah.
<igc> not try tags
<spiv> Even if there is no revno 99999, but there is a tag 99999?
<spiv> I think that's probably reasonable.
<igc> and we can encourage projects to use tag names that aren't revno like
<igc> and they get nicer dwim revspecs for their trouble :-)
<spiv> Right.
<spiv> Ok, I'm off.
<spiv> Happy UI designing :)
<fullermd> Is the motivation "If user entered a numeric, they'd be unpleasantly surprised if it hit something that wasn't a revno", or "Get the error back to the user faster without loading all the history"?
<igc> more the former
<fullermd> OK.
<igc> it's not a strong feeling though - more a preference
<fullermd> So I have a mild preference to keep going, on the theory "if it hits something else, it's because the user probably meant to".
<igc> fair enough
<fullermd> It's not a particularly strong conviction, but more than an offhand whim.
<fullermd> We can let democracy take its course on that I guess.
<bialix> igc: http://kashfarooq.wordpress.com/2009/10/12/integrate-bazaar-source-control-with-your-preferred-merge-application/
<igc> fullermd: so I think it's worth emailing the list just to see if others feel strongly either way
<bialix> igc: this man wrote series of articles already
<fullermd> (when two people disagree enough to not just abandon their positions, but not enough to fight for them, you don't even get good flamewars  ;)
<igc> fullermd: otherwise, I'm happy to change my vote to approve
<fullermd> 'k.  I'll drag it onto the list later.  Thanks   8-}
<igc> bialix: interesting. I want to make qconfig easier to configure merge tools. I'll look at that soon.
 * igc dinner
<bialix> yeah, this old nasty problem with merge tools :-/
<bialix> igc: re import_po error: in python2.6 getnames() method of opened tarball archive now returns names of directories as well as plain files. in 2.5 there was no directories in list. and nothing mentioned about this fact in 2.6 documentation. nice, huh?
<bialix> igc: no, I'm wrong! even funny. Now directory name has no trailing slash in 2.6.
<bialix> anybody knows what's difference between REGTYPE and AREGTYPE (re tarball items)?
<fullermd> A glance at google says AREGTYPE is for historic compatibility.
<bialix> hm... ok
<fullermd> (so the same thing, just don't use AREG for new stuff)
<jelmer> igc: hi
<jelmer> igc: I managed to convert svn-fast-export to subvertpy-fast-export
<jelmer> igc: as far as I can tell it's not leaking any file escriptors (highest fd is around 10 or 11 usually)
<jelmer> igc: I'm on GPRS at the moment so uploading is a bit expensive, I'll push later today
<spiv> jelmer: hooray!
<bialix> jelmer: cool
<bialix> igc: problem with import_po has fixed
<jml> what _exactly_ does 'bzr ls' print by default?
<spiv> jml: bzr: ERROR: Not a branch: "/home/andrew/".
<spiv> ;)
<spiv> As for the question you meant to ask, I don't know :)
<jml> spiv, wow, now I feel confused, belittled and still unhelped :P
<spiv> A new personal best!
<jelmer> :-)
<LarstiQ> jml: unrecursive argument listing iirc
<jml> LarstiQ, it also seems to list the contents of the tree. afaict, it behaves like regular 'ls' unless told otherwise.
<LarstiQ> jml: yes
<jml> LarstiQ, ok, thanks.
<igc> jelmer: my hero! thank-you!
<igc> bialix: thanks - I'll try it
<fullermd> jelmer: BTW, re adding a registry for DWIM specs: It's not entirely trivial, since there are differing lists of exceptions to catch.
<igc> night
<bialix> anybody knows the nick of jszakmeister
<bialix> ?
<bialix> what it means "super client" as in jszakmeisterâs article: http://www.szakmeister.net/blog/2009/oct/12/bazaar-subversion-super-client/
<spiv> bialix: https://launchpad.net/~jszakmeister says it is jszakmeister
<spiv> I don't know if that's accurate or not.
<bialix> ok, thanks spiv. because it's not here right now can you shed some light on english words?
<spiv> I've only just glanced at that link, but I think there "super" is in the sense of "better" or "has a superset of features" compared to SVN's native client.
<bialix> ok, thanks
<spiv> No worries.
<bialix> ok, I won't :-)
<ploum> Hello
<ploum> More than a year ago, I've set a shared repository to host our project with loggerhead interface
<ploum> works fine
<ploum> but now I realize that every project is under the very same shared repository
<ploum> which is not, AFAIK, the goal of shared repository (because our project have nothing in common)
<ploum> also, while doing big push the whole server is nearly frozen, all the ram being taken
<ploum> is there a way to optimize this and to "unshare" a shared repository ?
<beuno> ploum, you can unshare a branch with "bzr reconfigure --standalone"
<beuno> ploum, also, what format are the branches?
<beuno> the new format is a *lot* faster
<beuno> (bzr info should tell you the format)
<ploum> I upgraded
<ploum> so it's the latest format
<beuno> ploum, have you run "bzr pack" on it?
<ploum> no
<ploum> what is bzr pack ?
<ploum> I admit that the new format is faster but it also seems to take more ram
<beuno> it should re-pack it to optimize it's size
<beuno> right, I hear that's the current trade off
<ploum> is there any risk to run bzr reconfigure --standalone ?
<ploum> what will it do, exactly ?
<beuno> but, to be honest, I stopped having memoery problems when upgrading 2a, so I'm not sure how true that is
<beuno> ploum, it should create a standalone branch
<beuno> as I understand it, there's close to zero risk
<beuno> as usual, backup, etc
<ploum> on the server, I did bzr reconfigure --standalone then bzr pack in one of the repository
<ploum> now, pushing to it from an existing branch craches bzr
<ploum> ah ok, it was just a permission problem
<ploum> repacking as root, I have to chown everything to www-data
<beuno> yeah, root is always trouble
<ploum> yep but www-data has no shell on the server
<ploum> so, it works
<ploum> do you believe it makes sense to make every repository a standalone one with this method ?
<ploum> and (I ask a lot ;-) )
<beuno> well, if they don't share revisions, then it doesn't make sense to have a shared repo
<ploum> how can I change the repo so, from now, every new repository pushed to the repository is automatically a standalone one
<beuno> not 100% sure that can have such a large impact on performance, but I wouldn't be surprised if it did
<beuno> to do that, you will need to completely remove the shared repo, as bzr will look for it whenever you push
<beuno> be sure that all the branches are standalone before removing it
<beuno> (and that they work properly)
<ploum> ok
<ploum> simply removing the .bzr folder is enough ?
<beuno> yeap
<ploum> nice
<ploum> very informative talk
<ploum> thanks a lot
<beuno> glad it helped
<ploum> is there a way to delete the history of a repository ?
<ploum> I've some old repositories with heavy changes in binary files but I'm not interested anymore in the history
<gioele> ploum: bzr fast-export and bzr fast-import --filter (available in a separate plugin)
<beuno> ploum, me aware that such a change will make existing branches incompatible
<beuno> so make sure nobody has an existing branch if you're going to re-write history
<ploum> understood
<ploum> it makes sense
<ploum> but it's the case here
<ploum> in the case of one of our branch that was used by a student to store big binary files
<spiffyte1h> Does anyone know of a Debian Stable backport for a newer version of bzr-svn?
<spiffyte1h> The version in the Stable repo has a critical bug.
<vila> spiffyte1h: you want jelmer for an answer, providing version numbers for what you found may help him though
<vila> spiffyte1h: Or maybe LarstiQ is aware of the available debian versions and packaging policies...
<spiffyte1h> jelmer, LarstiQ: Debian Stable ships with bzr-svn version 0.4.10-2, which has a critical bug (see bzr-svn bug #343543, Debian bug #496164). the bzr-svn ticket indicates that newer versions of bzr-svn resolve the issue, and I'd like to find a .deb package to upgrade with.
<ubottu> Launchpad bug 343543 in bzr-svn "Segfaults bzr if the first action in a directory is 'ci'" [Undecided,Fix released] https://launchpad.net/bugs/343543
<ubottu> Debian bug 496164 in bzr-svn "[bzr-svn] "bzr selftest svn" crashed" [Normal,Open] http://bugs.debian.org/496164
<spiffyte1h> Ooooo, that's nice.
<vila> ubottu: good bot, have a cookie
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<gioele> ubottu: so you prefer chips to cookies, don't you?
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<jam> mroning vila
<vila> hi jam !
<jam> did you check if my 64-bit patch fixed buildbot for you? (It should be in bzr.dev now)
<vila> jam: I'm running a bunch of runs on babune now if only because installing pyrex on tiger and leopard trigger the leaking-tests bugssss
<jam> really...
<vila> jam: go figure....
<jam> because they actually start running the tests?
<jam> or because that triggers the bug?
<vila> jam: not sure exactly yet, I'm searching for a revision old enough and still passing the whole suite
<jam> there may be a significant bug in the new "SimpleSet" code.
<jam> I'm seeing some weird stuff trying to do a full 'bzr branch'
<vila> my gut feeling is that running with the extensions compiled on OSX brings more tests, change the way they are split, trigger the leak bug, nothing SimpleSet realted
<jam> vila: k, I just wonder if I have a stray pointer somewhere
<jam> which can cause all sorts of undefined behavior
<vila> yeah :-/
<vila> jam: so far, hard(32), jaunty(64), karmic(64), gentoo(??), freebsd8(64) passed the full test suite
<vila> hardY
<awilkins> Ok, weird bug
<vila> err, freebsd8 is still running
<vila> awilkins: no thanks, I have ,u share already
<awilkins>  - I have a file in my tree and bzr has decided that if it's x-bit is set, then it was originally unset, and that's a diff
<awilkins> But if you clear the x-bit, it then thinks that it should be set, and that's also a diff
<awilkins> So you can't win. Every time you revert the file it flips the x-bit and still thinks it's been flipped afterwards
<jam> awilkins: do you know what version of bzr you have? (and what platform)
<vila> awilkins: that vaguely rings a bell, I'm sure it should ring one for bialix or jam too...
<jam> I remember that behavior with really old versions of bzr on win32
<awilkins> jam: bzr 2.0.0 ubuntu jaunty
<jam> and that would just be weird
<awilkins> The one thing I can think of is the file name is fairly unusual in that it has a comma in it
<awilkins> That sounds pretty tenuous though
<awilkins> No idea why all the x-bits are turning up flipped in here anyway, unless someone is using bzr on a posix machine accessing a FAT32 partition
<awilkins> Not using any plugins that claim to handle xbit myself
<awilkins> ls
<awilkins> oops
<awilkins> Still does it without plugins
<vila> awilkins: waitaminute you're seeing that on jaunty ?
<awilkins> vila: Yes
<vila> awilkins: then you can look at the x bit with 'ls -l' and check whether it has changed or not
<vila> if it keeps changing, *someone* or *something* is changing it, but not bzr
<awilkins> Colours say that they are all set in this folder
<awilkins> They have no reason to be set
<awilkins> Now, they came from an SVN repo, so I'll check the x-bit props on the original branch
<awilkins> All these files are DITA resources
<vila> s/D/P/ ? :D
 * vila has no idea what DITA means otherwise...
<awilkins> First time I didn't know what it was and got a lot of nice videos of an attractive lady in a giant martini glass
<awilkins> It's one of the multitude of XML documentation authoring frameworkds
<awilkins> Ok... SVN has not got their x-bits set
<fullermd> Ah, so 'P' is right then.   :p
<awilkins> That's really rather annoying
<awilkins> ONE of the files in this folder has no x-bit
<awilkins> All the others do. One of the files is doing this "flip" thing
<vila> fullermd: hi !
<vila> fullermd: there was rumors about vim on freebsd8 not being recent enough for its fans.... a bit chinese for me so I promised to ask you about that :)
<fullermd> Well, it's currently at patch 239...
 * fullermd checks vim.org.
<fullermd> So 267 is the current patch.
<fullermd> 239 was from July.  David usually updates the pl every few months or so...
<vila> hmm, strange, it looks like vim wasn't installed.... may be "they" used vi instead ?
<vila> thanks for checking anyway
<fullermd> Well, the base system 'vi' is nvi, not vim.
<fullermd> So, I guess you could say it's a really old vim maybe   :p
<awilkins> This x-bit thing is a real bug methinks
<awilkins> I'm getting the impression that one particular inventory item is causing the global xbit state to flip.. and thereafter the xbit gets set for the rest
<awilkins> or maybe it's horrible disk corruption...
<fullermd> Always think positive   :)
<fullermd> "Hey, these new light bulbs are pretty bright...   or maybe the sun's just going supernova."
<awilkins> I have a bad history with USB drive controllers
<awilkins> They last a few months and then go phut
<awilkins> All the ones I've bought use the chipsets from the same manufacturer when you look inside
<awilkins> However, the rest of my system is running off the same drive and isn't dead yet...
<awilkins> A fresh checkout seems better
<awilkins> Or not
<awilkins> Lots of x-bits still
<awilkins> Where none are warranted
<awilkins> Oh boo, maybe I'm wrong
<awilkins> They are set in SVN
<awilkins> Just my lame-ass SVN gui client that doesn't display the properties in a grid properly
<vila> still a bug, different target :)
<awilkins> The flipping thing was weird
<vila> but came from the svn side right ?
<awilkins> I don't know
<awilkins> I don't think it should happen that it considers the original  xbit value to be the opposite value of what's present
<awilkins> I don't think the svn:executable property takes "heisenberg" or "schroedinger" as a parameter
<fullermd> You'll never know 'till you take it out of the box.  And then it's too late to set it.
<ploum> hello
<ploum> does loggerhead now includes smart-server ?
<awilkins> I can't build this damn source anyway... the author has made it depend on a whole toolchain on his machine and not mavenized it properly. Git.
<awilkins> so that was a charming and joyful waste of an hour
<jam> ploum: you can always try it and see... :) but last I checked they had not hooked up calls to .bzr/smart
<fullermd> Well, it took me longer than that to get Mosaic running the other month   :p
<awilkins> The xbit flipping thing is now happening in the other branch too.
<fullermd> So really, you're ahead.  Sorta.
 * awilkins curses
<awilkins> ls
<ploum> jam: because the bug is closed but I can make it work
<jam> ploum: "can't" ?
<awilkins> AHAHAHAHAHAHAHAH
<awilkins> I think I've got it
<awilkins> Maybe
<awilkins> Ah, might be my fault
<awilkins> I ran a "link files to save space" script on this folder
<awilkins> And I think it's linked some files that have an x-bit to some files that don't
<awilkins> Hardlinked, that is
<awilkins> You clear the x-bit on a file that's linked in another folder, and it pops up in the next one
<awilkins> Stupid number of x-bit for files that are resources though
<jam> ploum: it looks like there might be something if you do "bzr serve --http" w/ loggerhead 1.17 or so
<jam> but I'm not user if that also does the smart server
<fullermd> Data compression.  You can use the x bit as an overflow to save a bit in the file contents.
<ploum> jam: indeed, can't ;-)
<jam> looking at it, I don't see it actually setting up the rpc stuff
<jam> ploum: well, nm, it is there
<jam> def app_for_bazaar_data(self, relpath):
<jam>     if relpath == '/.bzr/smart':
<jam>         wsgi_app = wsgi.SmartWSGIApp(self.transport)
<jam>         return wsgi.RelpathSetter(wsgi_app, '', 'PATH_INFO')
<ploum> but I'm using loggerhead through an apache proxy
<ploum> maybe it's related
<ploum> I was also wondering how you could have permission support in loggerhead
<jam> ploum: Are you using loggerhead 1.17?
<ploum> 1.17-0ubuntu1
<jam> second, from the places I've been able to trace, it seems to always go to BranchesFromTransportServer, which handles smart requests
<jam> (or thinks it does :)
<ploum> (not sure I understand everything you are saying ;-) )
<jam> ploum: The code looks like it should be handling '.bzr/smart' requests
<jam> someone like beuno or mwhudson might know more
<ploum> is there a need for any .htaccess in my repository ?
<jam> ploum: so... once I actually got loggerhead to start, it indeed exposes smart requests
<ploum> even through apache ?
<jam> the specific problem *I* had was that inside their code base
<jam> 'import loggerhead' worked
<jam> but 'import loggerhead.apps.branch' did not (from a subdir)
<jam> ploum: doing 'bzr serve --http"
<jam> presumably from apache you just redirect requests to a given ":80/URL" to ":8080/"
<jam> beuno: When you get a chance, I'd like to help debug why loggerhead wouldn't "just work" for me.
<ploum> yes, that's what I'm doing
<ploum> # Loggerhead proxies.
<ploum> RewriteRule ^bzr2/(.*)$ http://localhost:8080/$1 [L,P]
<beuno> jam, hi
<beuno> jam, what's up?
<jam> beuno: https://bugs.edge.launchpad.net/loggerhead/+bug/451335
<ubottu> Launchpad bug 451335 in loggerhead "serve --http fails to find 'loggerhead.apps.branch'" [Undecided,New]
<jam> basically, from inside 'bzrlib.plugins.loggerhead/__init__.py"
<jam> "import loggerhead" seems to work
<jam> but "import loggerhead.apps.branch" fails
<jam> I'm guessing a subtle python2.6 breakage
<jam> I'm running from bzr source and loggerhead in my $PLUGINS directory
<beuno> jam, I think the LH plugin broke a while back
<jam> anyway, if i change the line, the import fails, so it sets the path, and things work again
<jam> I don't quite understand why just "import loggerhead" works
<jam> my short guess is that python2.6 is trying to be somewhat compatible
<jam> but fails at full backwards compatibilty for relative imports
<jam> of course, my recommendation is to switch to absolute imports ... :)
<jam> though I guess the code base is a bit divided
<jam> between wanting to be a plugin
<jam> and wanting to be a standalone app
<jam> with the latter being the original code
<ploum> must go
<ploum> thanks for the chat and the informations
<jam> beuno: maybe something like this: http://docs.python.org/whatsnew/2.6.html#pep-366-explicit-relative-imports-from-a-main-module
<beuno> jam, can you see if it happens with 2.5 as well?
<beuno> ah
<beuno> that sounds like it's it
<jam> I get stuff like: "No module named pkg_resources" I assume I need to install more of the dependency chain, etc.
<jam> give me a bit
<beuno> I thought we removed the deps on setuptools
<jam> beuno: obviously not entirely
<jam> I did see that commit
<jam> I get the same failure w/ python2.5
<jam> $ bzr serve --http
<jam> bzr: ERROR: No module named loggerhead.apps.branch
<jam> You may need to install this Python library separately.
<jam> sorry
<jam> well, the first line is wrong, but the rest is the same
<beuno> I did see it break with a landing, I don't recall which
<beuno> I think mwhudson knows about it
 * beuno tries to remember what the issue was
<jam> well, I can't run using bzr.dev with anything less than 386...
<jam> with the 'bzr-2.0.x' branch, I get the same failure at revno 370
<jam> and the first version that supports bzr-2.0.x is 368, also has the failure
<beuno> jam, I'll try and look into it this afternoon. I'm sure I have a note *somewhere* about the problem and the potential fix
<beuno> thanks for filing the bug
<jam> beuno: well, IME the fix is as simple as updating the import line :)
<jam> also, the original fix that jelmer did to 'avoid polluting sys.path' means that it probably actually runs the wrong version of loggerhead
<jam> at least, it would run one from a different location.
<beuno> jam, to what would you update it?
<jam> 'import loggerhead.apps' is enough to trigger the bug
<jam> and get sys.path updated
<jam> the alternative is to just *always* update sys.path
<jam> well, *an* alternative
<beuno> jam, as in every __init__?
<beuno> sys.path.append(os.path.dirname(__file__))
<vila> jam: so it seems that bzr.dev pass the full test suite for freebsd8 after all but I can't find any revision passing for OSX (tiger & leopard), and I'm back to 1.16 :-/
<jam> beuno: in 'serve_http'
<jam> vila: ouch... but not *my* fault :)
<jam> I thought you submitted quite a few patches for a clean test suite on OSX
<beuno> jam, ah, so basically remove the try
<vila> jam: not your fault at all, except for pushing me to install pyrex..
<vila> jam: Oh yes, I fixed a bunch of visible issues, now I'm discovering new ones :-)
<jam> *argh****
<jam> PyObject_IsTrue(Py_NotImplemented) == TRUE
<jam> bastards
<vila> now that I started scratching that thread/socket leak bug, it's triggering all over the places, even where it was silent before, well know fact about vicious bugs that behaviour :)
<jam> beuno: right
<beuno> jam, we have 5 failing tests due to this same problem: http://paste.ubuntu.com/293202/
<beuno> removing the import doesn't fix them
<jam> beuno: that only triggers if you are running serve_http
<jam> and why are you running 'nosetests' rather than
<jam> bzr selftest -s bp.loggerhead
<jam> I would at least think the latter would be the way to test loggerhead as a plugin
<jam> ah, you know what
<jam> the issue is that "." is called "loggerhead" *and* it has an __init__.py
<jam> I bet when doing "import loggerhead.apps" it is trying to import higher up
<jam> though in your case it is named 'trunk'
<jam> so that wouldn't necessarily be it
<jam> I don't know how nose sets the path, thuogh
<jam> though
<beuno> me neither. Imports make me dizzy, which is why I haven't addressed this yet  :)
<beuno> if I remove the __init__.py on the root dir, the tests work just fine
<jelmer> spiffyte1h: You should be able to use the package from testing
<jelmer> spiffyte1h: it wouldn't be very trivial to get a fixed version in, we'd need to also upload subvertpy
<spiffyte1h> jelmer: OK, thanks
<phinze> alright, i've run into this problem so many times, that i've attempted to document it along with a couple of potential solutions
<phinze> http://gist.github.com/210162
<phinze> if anyone is willing to take a look and give me a "you're doing it wrong" with some advice, i would appreciate it muchly :)
<luks> question in form of a blog post?
<luks> :)
<phinze> luks: well it turned into that
<phinze> summary would be: how to handle directories shared across multiple branches of mainline development
<phinze> perhaps 'mainline' is not proper term, perhaps 'heavy active'
<luks> I'm not sure I understand the branch structure
<luks> as long as I understand if, you are using bzr branches like a svn repository
<luks> that is, you have several "projects" in one branch
<phinze> luks: yeah sorta... mostly centralized development too
<phinze> luks: ack i gotta run to lunch now -- back in ~1hr... :(
<luks> ok, so that would be the "you're doing it wrong" point
<luks> the best solution is to use one branch per project
<phinze> luks: oh sorry no each project is it its own branch
<luks> where the shared libraries should be considered separate projects
<phinze> ahh
<phinze> yes so that would be #3 below
<phinze> but how do we pull the libraries in to BLUE and RED?
<phinze> svn:externals is dead, no?
<luks> bzr doesn't have a good built-in solution for that yet
<luks> in svn I'd use svn:externals
<phinze> yeah
<luks> there is http://bazaar-vcs.org/ScmProj which might or might not work for you
<phinze> ahh that looks interesting
<phinze> i'll have a look at that this afternoon, thanks luks :)
 * phinze zooms
<luks> if you have a problem with scmproj, you can ask on the mailing list
<luks> bialix (the author of scmproj) is usually active there
<jam> phinze: the other possible solution is to have your developers *not* commit changes to BLUE at the same time they commit changes to SHARED_LIB-X
<jam> so that 'bzr merge -c1001' can grab just the changes you want.
<luks> jam: you would still have to cherry-pick
<jam> luks: sure, but it would be a bit cleaner
<luks> I expect that would turn bad eventually
<jam> luks: I completely agree that separate projects is the $RIGHT way
<jam> but it is not trivial to set up (yet)
<eross> should I use sourceforge or launchpad for simple game development in ubuntu/linux and prob cross-platform? which represents the open source ideal better?
<beuno> eross, for starters, Launchpad's full source code is open source
<vila> eross: which one runs with open source ?
<vila> beuno: That's cheating ! You shouldn't give the answers before the question !!
<beuno> :)
 * beuno always blows it
<eross> thanks beuno, sorry vila.. i've got googly eyes :P
<eross> oh gawd.. it tracks 'karma', i'm going to be so negative on my simple project
<eross> have to purchase $250/year for a commerical project
<beuno> yes, didn't you say it was for open source?
<eross> yes but i like to twist the knife
<beuno> then sure
<jam> is there a losa around?
<jam> like, perhaps, mthaddon ?
<Chex> jam: hello I am around
<jam> hi Chex. mthaddon just created a couple of pqm managed branches for me, but when I try to submit anything to them
<jam> they seem to get blackholed
<jam> I don't get an error
<jam> but I don't see any progress, either.
<jam> ah... maybe it just took a hile
<jam> as I finally see something about 10min later...
<jam> Chex: however, I submitted from a couple different places. Can you check if there are some failures in the log that I'm missing?
<Chex> jam: can you give me a link to one of the branches, please? I am missing context
<jam> lp:~bzr-pqm/bzr/2.0.1
<jam> Chex: maybe it is just something weird about the email setup. As suddenly I'm seeing everything in the queue. But usually it takes <1min, and this time it took > 10
<jam> Chex: anyway, you probably don't need to spend a lot of time on it. as things seem to be working. I just got a bit concerned, as I'm trying to get a release out.
<mathepic> When you made a branch specifically for a bugfix and its merged now, should you remove it from LP if you don't think it needs any more development?
<beuno> mathepic, I don't see any reason to
<beuno> branches stack on launchpad, so they don't use up much space
<jam> mathepic: also, the default view hides branches marked as 'Merged'.
<jam> I generally don't bother deleting old things, especially since they might be useful later
<jam> (tracking down a bug, etc.)
<mathepic> k
<mathepic> I'm giving -p to bzr mkdir
<mathepic> When it adds, should it always use smart_add
<mathepic> or only use smart_add if -p is enabled
<mathepic> And same thing for adding the directories (always use os.makedirs or use os.mkdir if -p is not enabled)
<mathepic> Oops, I need to check
<jam> mathepic: I don't think you want 'smart_add' during makedirs because I *think* it adds all children, and you probably just want to add that one dir
<jam> also, I would say "makedirs" is dangerous if you are intending to create only one entry.
<jam> typos, etc.
<mathepic> Can you take a look at the diff at https://code.edge.launchpad.net/~mathepic/bzr/mkdir-recursive/+merge/13380?
<mathepic> Oh, your right
<mathepic> Does add add recursively
<mathepic> I checked the docs, apparently not
<mathepic> Since it is working with "bzr mkdir", in theory, there wouldn't be any files in the directory anyway
<mathepic> Because "bzr mkdir" fails if the directory itself already exists
<mathepic> Oh wait, it won't work because if its multiple directories, then the files in the lower directories would be added as well
<mathepic> is there any method in bzrlib that adds directories recursively but does not add the files?
<jam> mathepic: tree.add(['dir', 'dir/subdir', 'dir/subdir/subdir'])
<mathepic> So I just need to build that list myself in the code?
<jam> mathepic: probably
<mathepic> Question about smart_add: Does it add files in parent directories of the target subdirectory?
<jam> you also don't want to add things that are already there
<jam> smart_add does add parent dirs, IIRC
<mathepic> Okay
<mathepic> I'm looking at the smart_add code to try and find a way to do this - Is this the part where it finds all the parent dirs it needs to add?
<mathepic>         # only walk the minimal parents needed: we have user_dirs to override
<mathepic>         # ignores.
<mathepic>         prev_dir = None
<mathepic>         is_inside = osutils.is_inside_or_parent_of_any
<mathepic>         for path in sorted(user_dirs):
<mathepic>             if (prev_dir is None or not is_inside([prev_dir], path.raw_path)):
<mathepic>                 dirs_to_add.append((path, None))
<mathepic>             prev_dir = path.raw_path
<mathepic> L429 in mutabletree.py
<jam> mathepic: i think that is 'minimizing' the set of paths passed in, but I may be wrong "or_parent_of_any" makes me wonder
<mathepic> The help of cmd_mkdir is that it is equivalent to constructing the directory and then adding it
<mathepic> So therefore, is it possible that it SHOULD use smart_add since "mkdir DIR + bzr add DIR = bzr mkdir DIR"
<mathepic> I just did a test - bzr add does not add files in parent directories of the target directory
<mathepic> So therefore it should work fine
<mathepic> Is there any particular reason why lazy_import generates an error when attempting to host a pydoc server over bzrlib?
<venia> Ok, need to ask a quick question.
<venia> I'm involved in a project on launchpad, pulled the code off and everything, made some changes.
<venia> Now I go to push it back and it gives me this error: bzr: ERROR: RemoteRepository([...]) is not compatible with KnitPackRepository([...]) different rich-root support
<venia> Any ideas how to fix that?
<fullermd> Well, depends on which is which (I wish the error message told more details).  But probably the remote is RR and your local isn't.
<fullermd> If that's the case, upgrade your local to a RR format (2a probably, unless the remote is on an older one)
<mathepic> When making a blackbox test, what do I need to include in load_tests
<venia> Thanks for the reply fullermd. So I just run 'bzr update --default-rich-root'?
<bob2> --2a
<venia> Ah, thanks
<fullermd> venia: Yeah, that'll probably work.
<fullermd> The potential downside is that if you go 2a and the remote is in a pre-2a RR format (1.9-rich-root, say), shuffling data between them could be slow.
<fullermd> It's probably fairly likely that the remote IS 2a though.  If they made the poor->rich transition since you branched (otherwise you'd have a RR branch already), they probably went 2a.
<venia> Wait, (I'm new to bzr) the project leader told me to get the code by doing a bzr pull. Was that wrong? If so, what was I supposed to do?
<fullermd> Well, it's not obviously wrong.
<venia> Sorry, but nothing is "obvious" to me right now. Still trying to get my head around bzr. Are there any decent starting documents out there? (I looked at the manual and it was so immense it made my brain hurt) :p
<fullermd> Well, what you're "supposed to" do depends on what precisely you're trying to accomplish.  Without knowing the former, it's impossible to judge the correctness of means   :)
<venia> Ah, gotcha. :)
<fullermd> However, "pull" is how you (roughly speaking) update a mirror of code, so it stands a reasonable chance of being the correct thing to have done.
<venia> Well, let me explain.
<venia> I didn't have the code or the bzr repository.
<venia> And I needed to get them. So I used pull.
<fullermd> No, you didn't, 'cuz that wouldn't work.
<venia> (which apparently something didn't sink or was changed on the server)
<fullermd> You used branch.
<venia> sync*
<fullermd> (pull only updates, it won't create)
<venia> I'm pretty sure--oh.
<venia> In my naive-ness I must have 'bzr init' then done a 'bzr pull'
<venia> Which probably cause those errors, correct?
<fullermd> No, not really.
<fullermd> When you 'branch', it uses [some of] the format[s] of the remote branch to determine the local formats (in this case, the repository format).
<venia> Alright.
<fullermd> Well..  wait.  Maybe I'm...   mmm...
<fullermd> Alright, let's stop guessing.  What format does 'bzr info' say your local branch is in?
<mathepic> Can someone help me with making a blackbox test for Mkdir?
<mathepic> I have the functions written out
<mathepic> I just need the load_tests()
<mathepic> Whatever
<jam> mathepic: you probably don't need a 'load_tests' function, just add the 'test_mkdir.py' to blackbox/__init__.y
<jam> lifeless: are you around?
<venia> fullermd: Which version thing? It has 3.
<jam> lifeless: I'm on my way out... pqm tests seem to be running slow (about 2hrs to run 2.0.1's test suite). ISTR something about /tmp getting full on that machine, does it ring a bell?
<fullermd> venia: Just the rollup name from the first line.
<fullermd> venia: Unless it's 'unknown', of course.  In that case, the Repo format is probably enough.
<venia> repository: Packs containing knits with rich root support
<venia> That the one?
<fullermd> Huh.  That's weird.  You must have specified a --format to 'init'; no rr pack format was ever the default.
<fullermd> OK, so the problem is the other way around; you've got a rich root repo, and the remote doesn't.  That's uglier.
<venia> So what are my options? To upgrade the server (probably to be avoided at all costs even if even possible) or to start over?
<fullermd> venia: So the basic issue is that you can't put rich-root revisions in a poor-root repo.
<fullermd> So you'd need to either get the remote side moved to RR (which WILL happen sooner or later, but they may not be ready to do right now), or recreate your revs in a poor-root repo.
<venia> My revisions will be easy, I didn't do much actual editing, just added some files
<venia> So to proceed from here I actually do the 'bzr branch' thing?
<venia> And then move my files over?
<mathepic> I've been running the development bzr directly with bzr.py in my bzr.dev directory
<mathepic> But I just tried to selftest
<mathepic> bzr: ERROR: exceptions.ImportError: cannot import name user_encoding
<mathepic> It works fine on bzr 2.0
<lifeless> jam: we've had various things; /tmp is in a chroot, but its still worth checking.
<lifeless> jam: we haven't had a repeated 'X makes it slow and happens repeatedly' though - we've fixed each occurence completely each time.
<fullermd> venia: Yah.
<venia> fullermd: Alright, thanks I think that answers my question :)
<venia> Oh, one other thing. What's the difference between checkout and branch?
<fullermd> A checkout is a working tree (which is hooked to a branch somewhere).  A branch is...   well, a branch.
<fullermd> So the difference is whether your changes are made on the existing branch, or on a new one.
<venia> Ok.
<venia> Switching computers really quickly
<venia> Alright, back, sorry about that.
<venia> So a checkout it linked, say the remote server and all commits go straight to it?
<venia> Whereas a branch is a copy of whatever is on the remote server and your commits to your copy, then you 'push' them to the remote server, correct?
<fullermd> That's a way of looking at it, yah.
<fullermd> When you run 'branch', what you [generally] get is a branch, and a colocated checkout of that new branch.  When you run 'checkout', you get a local checkout of the remote branch ('remote' may just mean somewhere else on the local filesystem of course).
<venia> So I guess what had me confused was branches as the command, and branched as the launchpad thing.
<fullermd> So any time you run 'commit', you're technically doing it in a checkout, not a branch; and the new rev goes into the branch that checkout points at, whether it be right-there or off-somewhere.
<mathepic> checkout = centralized, branch = distributed.
<venia> I see now.
<venia> So what's the benefit of using either way?
 * jelmer hugs spiv
<jelmer> ~ expansion in bzr+ssh URLSs \o/
<fullermd> Well, that you use the means what fits what you're trying to do   ;)
<venia> Ah. Makes sense. :)
<fullermd> Checkouts can certainly be used for all sorts of setups, but the most common (and mathepic alluded to) is a centralized dev style, where multiple people work on a single branch.
<spiv> jelmer: :)
<venia> Thanks, this discussion has enlightened me much more than 10's of manuals and technical documents. :p
<fullermd> (everybody just has their own checkout; it's just like working with CVS/SVN)
<venia> Ah, gotcha.
<mathepic> Benefit of using branch is that you don't have to waste time with net connections and such
<venia> So just to clarify this again, a when you commit and push a branch, it goes straight to the original, correct?
<fullermd> Mmm.  Kinda.
<fullermd> I'd avoid thinking in terms like "original"; it biases you toward thinking of a hierarchy of some sort.
<venia> Ok, the "trunk" I think they call it.
<fullermd> Which is perfectly correct socially, but meaningless technically.  Technically, all branches are peers.
<fullermd> 'push' takes revs from one branch and stuffs them into another.  Usually, the 'one' is a local branch you're in [a checkout of], and the other is a branch "off somwhere".
<venia> I'm really getting tempted to write a bzr for utter newbies right now. :p
<fullermd> And it can be common to 'branch' from one place, 'commit' some changes, and then 'push' back to the same place.  But it's far from the only place you might push, so...
<fullermd> Give in to temptation.  It might not pass your way again.
<venia> Yeah. It'd be helpful, but I've got NO experience writing docs.
<fullermd> That's too ba...   hey, I just thought of a neat way you could get some experience writing docs!
<venia> So if you have a fork (that's what they're called right?) how do you get changed from one to the trunk?
<venia> Uh-oh! 0.o
 * venia looks for a place to hide.
<venia> Err, get the changes*
<fullermd> Not quite sure I'm parsing the question...   ah.
<fullermd> So phrase it as "How can I see the differences between one branch and another".
<venia> And move those changes between branches.
<fullermd> The answer is probably 'missing', which shows you which revs each branch has that the other doesn't.
<fullermd> (possibly, you might mean 'diff', looking at the actual textual differences between branches, but you probably mean 'missing')
<venia> Sorry, sometimes my typing/grammar skills aren't up to par, especially when I'm tired.
<venia> Gotcha.
<fullermd> As for shuttling the changes amongst branches, the general ways are 'push', 'pull', and 'merge'.
<fullermd> I did a big elaboration on that a few weeks ago here...  I should really pull it out of my logs and stick it somewhere to reference.
<venia> Gotcha, so you can push and pull between repos's? I'll have to look the syntax up on that.
<venia> Yeah, totally.
<venia> Bazaar has a wiki, right?
<fullermd> Don't really have time now, though; I've got a lot of work to try and get done tonite   :|
<fullermd> Yah.  Not quite sure how to directly hit it since the new site was rolled out though, other than by knowing a URL that's on it.
<venia> I'll probably look around and maybe start building "For Newbs" document
<venia> Best way to learn is by doing! :)
<venia> That's fine, I know the feeling of a crunched schedule. School does that to me. =\
<venia> Thanks for the help!
<fullermd> Ask me again in a week or so, hopefully I can find time to at least C&P the logs somewhere.
<venia> Sure.
<fullermd> (it's the best way, really.  I get to act like I'm all helpful, while actually being lazy as hell.  Win-win  8-)
<venia> Hehe. Totally.
<venia> Anyway, again, thanks for the help, now I need to go get my fixes up!
<igc> morning
 * fullermd waves at igc.
<mathepic> Hi.
<igc> hi fullermd, mathepic
<fullermd> igc: I forwarded some notes on that review to the list; make sure I didn't misrepresent your position.
<igc> ok
<fullermd> (I'm all scatterbrained today  :|)
#bzr 2009-10-15
 * venia greets everyone.
<eyda|mon> is there a good way to do a side by side diff? (example: tkdiff, vimdiff)
<spiv> eyda|mon: you can use 'bzr diff --using=gvimdiff'
<spiv> There are also plugins to extend bzr diff in various ways.
<spiv> http://bazaar-vcs.org/BzrPlugins
<spiv> Also, the bzr-gtk and qbzr plugins provide that sort of functionality too.
 * igc lunch
<igc> back
<spiv> Hmm, lunch.  That's a good idea.
<mtaylor> bzr: ERROR: exceptions.AssertionError: second push failed to complete a fetch set([('inventories', 'brian@gaz-20091012224641-gjo56i190y8c98xg'), ('inventories', 'brian@gaz-20091012172541-ta8k2ejioknnexab')]).
<mtaylor> that's not fun
<spiv> mtaylor: huh
<mtaylor> spiv: repeatable for me at the moment
<spiv> mtaylor: ooh, good.
<mtaylor> spiv: I have a copy of that branch on another machine, so I could re-push - but I thought I'd leave it there for you guys :)
<spiv> mtaylor: I think there's an unsolved bug about that at the moment, IIRC it's stalled due to not being able to reproduce
<mtaylor> spiv: yay! maybe I'll be helpful then :)
<spiv> https://bugs.edge.launchpad.net/bzr/+bug/437626
<ubottu> Launchpad bug 437626 in bzr "exceptions.AssertionError: second push failed to complete a fetch set" [Undecided,New]
<mtaylor> hey look at that
<spiv> mtaylor: if you can provide something along the lines of tarballs and a recipe to reproduce with them I will be very grateful!
<mtaylor> spiv: you want me to tar up my local repo .bzr ? lemme try to see if that does it
<spiv> mtaylor: yeah, please do
<Peng_> Somebody should mark the new bug as a dupe, then, no?
<mtaylor> Peng_: yeah... I can do that
<spiv> Peng_: probably, I haven't seen it yet..
<spiv> Actually,
<spiv> Well, I guess it's probably the same bug, but it's not certain.
<spiv> But I note that mtaylors' bug report only involves inventory records, which *might* mean it's a different issue.  I guess it's easy to unmark it as a dupe later if necessary.
<mtaylor> spiv: shit. sorry. I have altered my local repo already
<spiv> mtaylor: that's ok
<spiv> mtaylor: can you still reproduce?
<mtaylor> spiv: I branched a different branch, which I'm guessing filled in something
<mtaylor> spiv: nope
<spiv> mtaylor: if not, a tarbll will still be handy
<mtaylor> k. well, I can give you that
<spiv> mtaylor: along with the details of the last change you made to it.
<spiv> Chances are I can take out the most recent pack file with some simple surgery and get it back to the problematic state.
<mtaylor> spiv: last thing I did was "bzr branch lp:drizzle/build fix-include-issues"
<mtaylor> which is the only repo operation I did on it since the problem was reproducable
<spiv> But it's also interesting to know that it's so easy to lose the state that triggers the bug.
<vila> hi all
<phretor> hi, how do I branch a specific revision? For instance when I bzr branch lp:django-modeltranslation I always get the latest stable branch rather than the trunk.
<happyaron> hi, I got Format <RepositoryFormatKnit1> for file:///home/aron/main/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance when checkout a branch, what's this mean?
<Peng_> happyaron: Exactly what it says.
<Peng_> happyaron: /home/aron/main/ is using an old, slow, inefficient repository format. Upgrading will make things faster and use less disk space.
<happyaron> Peng_: so run "bzr upgrade"? but this will only effect in my local copy I think
<Peng_> happyaron: What version of bzr are you on?
<happyaron> Peng_: I have 1.13.1 installed
 * happyaron on my box
<Peng_> Ah. Uh. Err. If you were on 2.0, by default "bzr upgrade" would upgrade to a format that you can't downgrade back to RepositoryFormatKnit1 from, but that's not the case in 1.13.1.
<Peng_> So, sure, upgrade, if you don't need your repo to be compatible with really old (<0.92) bzr versions. Take a backup first, of course, and run "bzr check".
<Peng_> And yes, it would only upgrade your local copy. Perhaps the remote copy already has been upgraded. If not, you can go and upgrade it too.
<happyaron> Peng_: how to upgrade the remote one?
<Peng_> Also.. 1.13.1 is rather old. You might want to upgrade to a newer version. That'll offer even faster and more disk-efficient formats, too.
<happyaron> Peng_: the branch is hosted on launchpad
<Peng_> happyaron: "bzr upgrade bzr+ssh://..."
<Peng_> happyaron: It won't be very fast, but it'll work fine.
<happyaron> oh
<happyaron> I know, I will first upgrade my bzr package, then run check, and finally upgrade the format
<happyaron> Peng_: thanks
<Peng_> happyaron: Sounds good. Like I said, though, if you upgrade to 2.0, by default "bzr upgrade" will switch to a format that you can't downgrade back to RepositoryFormatKnit1 from.
<Peng_> Not that there's anything wrong with that, unless you have a really ancient bzr install somewhere.
<Peng_> See http://doc.bazaar-vcs.org/latest/en/upgrade-guide/index.html about that.
<happyaron> Peng_: so if I upgrade the one using a 2.0 version, will it accessable for those who still run like 1.13?
<Peng_> happyaron: By default, 2.0 uses the 2a disk format, which was only added in, uhh, 1.17, IIRC. Maybe 1.18.
<Peng_> happyaron: You could use an older format if you need to, such as 1.9.
<happyaron> Peng_: oh
<Peng_> It'd still be much better than the one you're currently on. Just not as awesome as 2a.
<happyaron> Peng_: thanks
<Peng_> FWIW, even if you do upgrade to 2a, you can downgrade it back down to 1.9-rich-root (added in 1.9) or rich-root-pack (added in 1.0).
<happyaron> oh
<Peng_> I suck at explaining things. Upgrading to a rich-root format like 2a is a bit inconvenient (particularly if a lot of other people have copies of your branches), but not a big deal. The upgrade guide I linked to goes into more detail.
<Peng_> (FYI, rich-root formats contain a bit more meta data. Specifically, the root directory of the branch gets a file ID like all other directories do. It's not that important for most uses, but once you upgrade to a rich format, you can't just downgrade to a non-rich format again, throwing out that information.)
<happyaron> Peng_: I am now upgrading it to the 2a format since this branch wasn't used by more than 5 persions, I will notify them (we were blaming the low speed, hope this can help)
<Peng_> happyaron: It will. 2a rocks!
<happyaron> freeflying: :)
 * Peng_ goes /away
 * igc dinner
<bialix> hello all
<awilkins> join : after you join a subtree, can you  continue to pull revisions from it's original branch... particularly, I'm thinking of trees derived from SVN branches
 * awilkins is about to try this anyway
<awilkins> Neato, that works really well
<awilkins> I'm guessing that pushing it to the SVN repo would be a bit of a disaster though
<jml> hmm
<tmartin> Hi there, I'm an engineering student and I'm starting a computing project with two other people. We could do with a some sort of (very basic) distributed revision control. Is Bazaar more or less what I'm looking for?
<jelmer> igc: I've pushed the updated subvertpy
<jelmer> igc: (including bin/subvertpy-fast-export.py)
<Peng_> tmartin: Those aren't very complicated requirements, so many DVCSes would work, including Bazaar.
<Peng_> tmartin: Bazaar has the advantage of working over plain old SFTP or (god forbid) FTP, though.
<tmartin> Peng_:  cool. The reason I'm keen on Bazaar is that the other two people I'm working with aren't familiar with version control, so it's useful that the clients are the same across platforms so I can talk them through it
<Peng_> Well, hg has that advantage too.
<tmartin> hg?
<tmartin> ah, mercury
<Peng_> Well, the VCS is called "Mercurial", but yes.
<Peng_> Erm. I am a bzr proponent, but it's not the only good VCS, and which one you like best is a personal thing.
<Peng_> me sucks at advertising. :P
<bialix> tmartin: bzr has very good giu
<bialix> gui
<bialix> bzr-explorer
<bialix> if it matters
<tmartin> My main issue is with hosting. I can't host myself because I'm behind a NAT that I can't forward ports through (we're just using the leftover Internet in our flat from the last tenants until the new line rental comes through) so I need some project hosting. Using the Bazaar hosting for a small university project wouldn't be considered abuse of the service, would it?
<Peng_> ...Is it a software project?
<bob2> s/a/a free/
<tmartin> it's definitely a software project. It's of dubious use to anyone but us. Basically it models the performance of a Rover 826 accelerating to 100 kph subject to various conditions
<SamB_XP> but is it free software?
<tmartin> At the moment it's as-is, but yeah, I can BSD it if I need to
<bialix> tmartin: you can use `bzr send` command to send new revisions via e-mail. in this case you won't need separate hosting
<bialix> although it can be a bit tedious
<tmartin> bialix: Perfect!
<tmartin> no, it won't be
<tmartin> It's such a ridiculously small project
<bialix> tmartin: then you need to have one reference branch and one working branch and create bundle to send against reference branch
<tmartin> bialix: you've lost me a bit there, hang on, i'm looking it up in the manual
<bialix> there is nothing in manual
<bialix> `bzr send` require reference branch to produce valid output
<bialix> your reference branch should be equal to other people unupdated branch
<tmartin> bialix: okay, i think that's clear
<bialix> `bzr send` automatically determines then what revision missing based on the info from reference branch
<bialix> that's why it can be tedious
<bialix> maybe using Launchpad.net will be much simpler solution
<bialix> just set free licenseon your code
<SamB_XP> like the MIT one
<bialix> or Apache 2
<SamB_XP> it's nicer than BSD because you don't have any blanks to fill in, I believe
<bialix> new BSD does not require any blanks, IMO but IANAL
<Peng_> MIT is still shorter.
 * bialix nods
<Peng_> Besides, we all know MIT is cooler than Berkeley. :P
<bialix> this tiny details is out of understanding of non-US guy like me
<SamB_XP> I'm not sure MIT really is ;-P
<Peng_> I was just kidding anyway.
<SamB_XP> I suppose it may depend on where your allegience lies: Lisp, or *nix
<SamB_XP> are you in the "worse is better" camp, or the "oops we never got around to adding syntax" camp?
<SamB_XP> ... though I guess MIT did make X, but then again that might just be a reason to hate them ;-P
<Peng_> Well, MIT has Clocky, the alarm clock that rolls away from you, and Berkeley has, what, LSD?
 * bialix wonders why fullermd does not say anything yet
<SamB_XP> is that because MIT is so demanding you would oversleep without a clock that evades you?
<Peng_> But Berkeley is so demanding you need drugs. :D
<fullermd> Hmmwhat?  Sorry, I was off doing LSD...
<fullermd> I long ago developed remarkable agility while asleep.  I don't think it would be very easy for an alarm clock to evade me...
<Peng_> The only thing I can do while asleep is drool. :(
<SamB_XP> hmm. I can sleep
<SamB_XP> and have strange dreams
<fullermd> I had an alarm clock in college that I measured at around 145dB/1 meter.
<fullermd> It worked, in a roundable way.  It woke up my whole hall, who then got the RA to open my door and woke me up.
<Peng_> That causes hearing damage!
<fullermd> Once, famously, by picking me up, carrying me out of the dorm, down the hill, and throwing me in the lake.
<SamB_XP> fullermd: roundabout, you mean
<fullermd> I woke up about the time I hit the water.  I guess I was kinda tired or something.
<SamB_XP> that's an understatement ...
<Peng_> You're lucky you woke up instead of drowning. :\
<SamB_XP> I hope you didn't have any 7:00 classes
<fullermd> Oh, I'm a good swimmer.  I can probably do that in my sleep too   :p
<fullermd> Anyway, it was college; if you're not exhausted, you're doing it wrong, right?
<fullermd> 7:00 classes are easy.  You just stay up late for 'em.
<Peng_> I once slept through a fire alarm (no fire; it was broken), but I have no problems with my quiet alarm clock.
<SamB_XP> fullermd: I meant 7:00 AM
<fullermd> SamB_XP: So did I   :p
<SamB_XP> oh
<SamB_XP> what if you have OTHER classes that day?
<fullermd> Well, I went a couple months sleeping 4 hours a night, on Tue and Fri...   I made it to all my classes, though it's possible I might not have been entirely lucid on occasion.
<fullermd> (but then, it's _me_.  I'm not sure you could tell the difference anyway.)
<SamB_XP> meaning you're never sane ?
<fullermd> Sanity is for the unimaginative.
<SamB_XP> yeah, it does seem overrated ;-P
<fullermd> Anyway, back to only vaguely off-topic, the MIT license and the 2-claues BSD license are isomorphic, so that's a matter of taste.  3-clause BSD is slightly more restrictive.
<fullermd> ... and the main reason to choose a 4-clause is to tick rms off   :p
<SamB_XP> sadly it will also tick a lot of others off if they for some reason end up wanting to combine your software with something that's under the GPL ...
<fullermd> Their own fault for picking such a B&D license  :p
<SamB_XP> they might not have written that part
<Peng_> ...ISC! :D
<fullermd> We should write an Escher license, granting all rights to users in a 4-dimensional space.
<SamB_XP> or on a mobius strip?
<Peng_> The ISC license is nice. It's equivalent to 2-clause BSD, but shorter. http://en.wikipedia.org/wiki/ISC_license
<bob2> ...from the Internet Systems Consortium, or NAMBLA...
<Torne> is the right syntax for a password for svn:// repo just scheme=svn ?
<Torne> if i put my credentials for this svn repo in authentication.conf and try to push, bzr-svn dies with TypeError: password should be string
<Torne> it works if i just let it prompt me for it
<bob2> if the svn command line tool caches it, I belive bzr-svn will pick that up
<jelmer> Torne: Sounds like a bug in bzr-svn
<Torne> bob2: i've never touched this one with actual svn, so i don't have it stored there :)
<jelmer> Torne: please file a bug and include the backtrace
<jelmer> with a bit of luck we should be able to fix it for the 1.0.1 release
<Torne> jelmer: ok
<Torne> jelmer: submitted, https://bugs.launchpad.net/bzr-svn/+bug/452121
<ubottu> Launchpad bug 452121 in bzr-svn "Putting svn password in authentication.conf doesn't work" [Undecided,New]
<jelmer> Torne: thanks
<Torne> I *nearly* copypasted my password into the report. :)
<jelmer> heh
<Torne> while i'm here: bzr-svn is fantastic other than that :)
<Torne> i've just never had to actually push before ;)
<jelmer> cool, great to hear :-)
<Torne> anyway, bye for now ;)
<bialix> spiv is here?
<bialix> spiv: when you'll back here: please comment somehow on bug #430382
<ubottu> Launchpad bug 430382 in qbzr "qcommit crashes during Cancel" [High,Confirmed] https://launchpad.net/bugs/430382
<jelmer> jam: If you have time, any chance you could have a quick look at my lp:~jelmer/bzr/foreign-tests1 branch and see if the way the tests are set up is ood?
<awilkins> Ood? http://tardis.wikia.com/wiki/File:Ood.jpg   (joke)
<jelmer> *good
<jelmer> awilkins: :-)
<idnar> Peng_: the thing I find stupid about all of those licenses is that the DISCLAIMER OF WARRANTY WHICH IS IN ALL CAPS FOR SOME BIZARRE REASON is longer than the actual license
<fullermd> Well, that's easily solved, just make the actual license part 10 or 15 pages long.  Then it's shorter   :p
<gnomefreak> n/win 3
<Pegasus_RPG> howdy
<Anteru> Hi
<Anteru> Probably one for the FAQ, but I cannot find it: How do I remove a local branch? Just deleting the folder works -- I wonder whether there are any ill effects of that?
<Anteru> i.e. I have /trunk, /feature-branch locally, and I merged /feature-branch back into trunk, so I don't need it
<awilkins> Anteru: No ill effects, if you merged it the revisions are all somewhere else. If it's in a shared repo, the revisions don't evaporate, the branch is a pointer.
<Anteru> ok, cool, thanks!
<bialix> fullermd: ping?
<jam> jelmer: I'll try to get to the review. Sorry about the delay
<jam>  /cry, wordpress doesn't auto-save your document, and it crashed while trying to insert and move an image...
<jam> back to blogger for me....
<jam> I liked parts of the interface better, but crashing w/ no autosave is just out
<jam> heck, this post may never be written now...
<bialix> jam: blogger has feature to send post via e-mail
<jam> I was writing up a fairly involved post about what it took to release 2.0.1 and 2.1.0b1
<bialix> but I'm unable to send images with my post
<jam> I got things mostly written, was inserting an image, tried to move it....
<jam> and then firefox hung with 100% cpu
<bialix> bad
<bialix> I like your posts
<jam> w/ blogger, at least it would have saved for me
<bialix> do you have twitter account?
<jam> perhaps WP has a ^S
<jam> I do not have twitter
<bialix> np
<jam> seems... silly to me so far
<Anteru> wp has autosave, at least my installation saves every 5 minutes or so
<jml> where's my bzr-backed wiki
<jml> it's almost 2010 and I have no flying cars, no hoverboards, no pony and no bazaar-backed wiki
<Tak> trac?
<beuno> jml, you mean ikiwiki?
<jml> beuno, maybe I do.
<beuno> http://ikiwiki.info/
<beuno> I think it's in perl though
<jam> I know people have worked on a bzr back end
<LarstiQ> james_w (and myself very minimally)
<LarstiQ> of course, it has a svn and git backend, so..
<awilkins> Was there a plugin that pushes the revisions AND the current working tree to another machine?
<LarstiQ> jml: there is als Hatta, which is hg backed
<james_w> awilkins: push-and-update?
<james_w> I can't remember now if the bzr backend for ikiwiki was merged
<awilkins> james_w: Not quite, I have uncommitted state that I want to end up in the target
<jam> awilkins: rsync ?
<awilkins> jam: I was just using a tree-comparision client :)
<jam> pushing uncommitted changes isn't something that is likely to be supported 'out-of-the-box' for us
<jam> if you want them pushed, why not commit and push ?
<jam> (why is it important that they not be committed ?)
<jml> LarstiQ, yeah, I saw a talk about Hatta at EuroPython, you probably did too
<LarstiQ> jml: yup
 * LarstiQ forgot there was lightning talk about it
<awilkins> jam: Just my inner voice saying "no, don't push incomplete changes!"
<awilkins> jam: Or commit them, rather
<LarstiQ> awilkins: yet you want to deploy them?
<awilkins> LarstiQ: It's not deployment, it's moving workstation
<awilkins> I suppose what I really want is shelve-and-move-to-another-machine
<LarstiQ> awilkins: ah, yes
<LarstiQ> awilkins: or just diff, rsync, apply
<awilkins> Shelves are basically orphaned revisions (as I understand them now)
<jam> awilkins: I don't think they are put into the repo, but otherwise, yeah
<Keybuk> so you know those archive inconsistencies I keep getting
<Keybuk> theory: they're ghost revisions
<Keybuk> ie. where I've overwritten one head with another
<jam> awilkins: bzr commit; bzr push; bzr uncommit...
<awilkins> jam: More ghost revisions :-)
<jam> awilkins: those aren't ghosts
<jam> ghosts are ancestors we don't have
<Keybuk> jam: what are those?
<jam> those are just heads that aren't in a branch
<Keybuk> bzr commit; bzr push; bzr uncommit; bzr commit; bzr push --overwrite
<awilkins> Ah, loose heads
<Peng_> Keybuk: A ghost is a revision in the branch's history, except we don't actually have a copy of that revision.
<Peng_> Or something!
<Keybuk> hmm, actually I'm not sure that's right
<jam> Peng_: something spookier I believe :)
<Keybuk> so I have the following error on push now
<jam> not sure how...
<Keybuk> inconsistent details in skipped record: ('scott@netsplit.com-20091014154035-x6fdt088smfxy63j',) ('518 291 0 266', ((('scott@netsplit.com-20091014154020-3j2udgsm15lbdfm4',),),)) ('93400 238 0 266', ([('scott@netsplit.com-20091014154020-3j2udgsm15lbdfm4',)],))
<Keybuk> but the revision ids on each side *do* match
<Keybuk> what's more interesting is that each of the revisions were made *after* I upgraded to bzr 2.0
<jam> Keybuk: the warning there is saying that we have revision ids which claim to match, but *content* which claims to differ
<Keybuk> jam: isn't that bad?
<jam> Keybuk: potentially, though abentley claims that there were ways of getting into this situation that weren't terribly
<jam> terrible
<Keybuk> I'm getting into this situation with ordinary use of bzr
<jam> hence why he made it a warning when it used to be an error
<Keybuk> I'm really worried that bzr 2.0 has some *serious* data corruption issues now
<jam> the way of triggering it that he knew of
<jam> was that launchpad had bad history
<jam> and different people had different *amounts* of bad history
<Keybuk> this is on *new* revisions
<jam> Keybuk: right, but if you base a commit off of X, and someone else sees that as X'
<jam> the new commits can disagree
<Keybuk> but that hasn't happened here
<Keybuk> this is just an archive
<Keybuk> one is the LP push of the other
<Keybuk> and bzr is throwing up all sorts of errors with it
<jam> Keybuk: so to start with, try to get a tarball snapshot of the state, so that one of us can take a look at it
<Keybuk> jam: it's on LP
<Keybuk> I can't login to that and give you a tarball
<Keybuk> I suspect you can
<jam> Keybuk: I don't have access to your branches
<jam> you can use "lftp" to mirror the remote to local
<jam> and then tarball that
<Keybuk> afaict it's the LP-hosted branch that has the issues
<jam> Keybuk: right, and I can only see the "LP-mirror" of your branch
<Keybuk> got an example lftp incantation?
<jam> Keybuk: I think "lftp -c mirror sftp://bazaar.launchpad.net/~keybuk/... local"
<jam> is what you can use to get an exact copy of the launchpad branches
<Keybuk> ok, grabbing that down
<Keybuk> reconcile on this fails
<Keybuk> http://people.canonical.com/~scott/ubuntu-core-dev--upstart--ubuntu.tar.gz
<Keybuk> there you go
<Keybuk> that's the .bzr
<jam> Keybuk: it says it is stacked on "~scott/upstart/trunk" can I get a copy of that as well?
<Keybuk> yup
<Keybuk> that one happens to fail reconcile too iirc
<jfroy|work> verterok: ping
<Keybuk> (this is somewhat larger, so give me a few minutes for it :p)
<verterok> jfroy|work: pong
<jfroy|work> I just made a few fixes to my packaging branch
<jfroy|work> including a critical fix for an issue I just found in the current distribution / build.py script
<jfroy|work> that would replace /usr/local/share/man/man1 with the bzr man page (instead of installing it into that directory)
<jfroy|work> fortunately, Installer is smart enough to move man1 to "man1 1", so I also added a pre-install script to the distro to fix up that mess.
<jfroy|work> Anyways, I merged your branch into mine, made the fixes and pushed to LP.
<jfroy|work> Trying to find how to send you a merge request...
<jam> Keybuk: so it is possible, that the above warning is bogus. I have to dig into it, but I'm noticing that one side says:
<jam> (((revid,),),)
<jam> and the other side says
<jam> ([(revid,)],)
<jam> (one side has a tuple, the other has a list)
<Keybuk> jam: why does reconcile fail on that branch?
<jam> it is possible that it is comparing the objects and failing.
<verterok> jfroy|work: oh, nice!
<jam> Keybuk: I haven't gotten that far yet. And certainly there is a bug if [] vs () was triggering a warning
<verterok> jfroy|work: as there is no project we can't do merge proposals
<Keybuk> jam: the branch it's stacked on seems to not fail reconcile fwiw
<jfroy|work> verterok: ahhh, that explains a lot :p
<Keybuk> just uploading for you atm
<stianhj> i just installed Bazaar 2.0.0.2 on a Vista 64-bit machine. Running bzr st in an existing bzr repo gives this: "No module named commands" and "Unable to load plugin u'explorer' from u'C:/Program Files/ .. etc'. Bazaar Explorer doesn't seem to be working either. Any ideas?
<jam> thx
<jfroy|work> just merge lp:~jeanfrancois.roy/+junk/SnowLeopard-package then
<jam> stianhj: you might try "bzr -Derror status"
<jam> it sounds like it is unable to load bzrlib
<jam> which is fairly serious
<jam> I'm wondering about a permissions issue
<jfroy|work> I was going to submit Bazaar-2.0.0-5
<jam> do you have any other copies of bazaar?
<jfroy|work> but with 2.0.1 around then corner, I guess we could wait for that.
<jam> jfroy|work: 2.0.1 has 'gone gold'
<jfroy|work> jam: my point exactly
<jam> so feel free to package Bazaar-2.0.1-1
<jfroy|work> verterok: want to do it?
<jam> the tarballs should be uploaded, etc.
<jam> also, packaging Bazaar-2.1.0b1-1.pkg would be nice
<verterok> jfroy|work: the merge or the build? :)
<jfroy|work> both :p
<verterok> jfroy|work: :)
<jfroy|work> well you *need* to merge
<jfroy|work> trashing man1 is *bad*
<stianhj> jam: http://pastebin.org/46041
<jfroy|work> Oh, the distro version is in config.py
<jfroy|work> (I added it)
<verterok> jfroy|work: I'll merge it in my next boot into OS X, proably to build 10.5 installer ;)
<jfroy|work> I guess I can build the 10.6 one
<jfroy|work> so, let's see
<jfroy|work> how would I get the 2.0.1 sources?
<stianhj> jam: bzrlib seems to be the problem I guess
<jfroy|work> erm, I mean, w/r to your auto-fetch thing
<verterok> jfroy|work: please, I don't have 10.6 and I'm not sure if it will work if I build it against non system python
<jfroy|work> verterok: it won't
<jam> stianhj: so it would look like 'bzr' itself is working, but that explorer is failing to find something
<verterok> jfroy|work: PYTHONPATH=. python tools/fecth-external.py -p
<jam> specifically, it is looking for: from bzrlib.plugins.qbzr.lib.commands import (
<jfroy|work> verterok: oh, I moved fetch-external.py out of tools :p
<jam> so it is *qbzr* which it isn't finding
<verterok> jfroy|work: heh, ok
<verterok> jfroy|work: so, python fecth-external.py -p  :)
<jfroy|work> yeah basically
<verterok> *fetch-external.py -p
<jam> stianhj: can you try just doing "bzr qbrowse" ?
<jam> or "bzr qlog" ?
<jfroy|work> I just tweaked config.py to get 2.0.1
<verterok> jfroy|work: and you can get the docs too, I don't remember the switch
<jfroy|work> I'll check the plug-ins and update them as well
<jfroy|work> I don't bundle the docs in the core package
<verterok> jfroy|work: right, I missed that...update config, run the script
<jfroy|work> but I saw the o[tion
<jfroy|work> *option
<verterok> jfroy|work: ok
<stianhj> jam: yes, bzr seems to be working. qbrowse seems to be working, as well as qdiff, qcommit, etc
<stianhj> qlog as well
<jam> stianhj: and I assume that doing "bzr explorer ." is failing?
<stianhj> no wait, qlog doesn't work
<stianhj> jam: i get a bunch of errors on the console about drawDisplay, and my commit messages aren't showing
<jfroy|work> oh well, the tar.gz isn't up yet :p
<jfroy|work> or the URL is wrong, lol
<verterok> jfroy|work: you need to update the url in the config too
<jam> Keybuk: so I don't know why 'reconcile' is failing, but it does look like the warning is triggering because of () != []. I don't quite understand how we are getting a list there, though. As we generally always use tuples.
<stianhj> jam: the commit messages in the list that is. clicking on items gives me all the info at the bottom of the screen
<jfroy|work> verterok: I did, with a wrong one ;p
<jam> So bug #1 is that the comparison is giving you a bogus warning.
<ubottu> https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout)
<verterok> jfroy|work: heh
<jfroy|work> worked fine with the actual URL.
<jam> stianhj: do you know if you have another copy of 'qbzr' installed? Say in your $APPDATA folder?
<jam> You can try "bzr plugins -v" to help figure it out
<Keybuk> http://people.canonical.com/~scott/scott--upstart--trunk.tar.gz
<Keybuk> jam: that's the stacked branch
<Keybuk> or the under-stacked
<Keybuk> dunno the term there ;)
<jam> Keybuk: stacked vs stacked-on
<jfroy|work> verterok: pushed the update for bzr 2.0.1 to my branch
<verterok> jfroy|work: ok
<stianhj> jam: appdata only has one bazaar folder that is from the 2.0 installation. Just before installing Bzr 2.0.0.2 I uninstalled Bzr 1.7.1 and rebooted.
<stianhj> jam: was QBzr a part of Bzr 1.7.1 or did I install it seperately?
<jam> stianhj: 1.7 ? probably installed separately. "bzr plugins -v" should show you what qbzr we are finding
<stianhj> jam: qbzr is version 0.9.3, and is in $APPDATA\Bazaar\2.0\plugins\qbzr. So doesn't seem to be any conflicts
<stianhj> i think
<stianhj> jam: here's the error from qlog http://pastebin.org/46047
<mtaylor> can a shared repo dir be somewhere other than in a directory ancestor and specified explicitly?
<jam> stianhj: we bundle qbzr 0.14.3 and it should be in C:/Program Files/Bazaar/...
<jam> mtaylor: no
<jam> though you could use a lightweight checkout
<jam> etc
<mtaylor> jam: k. that's what I thought, but I thought I'd check
<jam> stianhj: so try moving the qbzr in "$APPDATA/Bazaar/2.0/plugins/" to another directory
<Keybuk> http://people.canonical.com/~scott/scott--upstart--0.6.tar.gz
<Keybuk> jam: ^ that one also fails reconcile, and may be stacked on the same branch?
<Keybuk> random thought, could the [] vs () thing be across the stack point
<jam> Keybuk: it *is* stacked, I'll let you know the rest as I get a chance to investigate
<dash> i'm trying to convert twisted's bzr mirror to 2a
<dash> I initially used bzr upgrade
<dash> but when that proved slow, I decided to just do a fresh svn import
<dash> problem is, bzr consumes about 10G of memory when doing so
<dash> and this box only has 6G of RAM. :)
<dash> so it's really unable to make any headway
<LarstiQ> dash: did you talk about that with jelmer?
<jam> Keybuk: so I see reconcile fail @
<jam>     source_parents = file_id_parent_map[key]
<jam> KeyError: ('test_job.c-20060802025841-69d13b49cc35d5ec', 'scott@netsplit.com-20090709110153-7dcfrdmjwojak3ud')
<dash> LarstiQ: apparently I am never on IRC at the same time as him :)
<jam> sound about like what you are seeing?
<LarstiQ> dash: shoot him a mail?
<Keybuk> jam: that looks right yes
<dash> LarstiQ: Oh email
<dash> LarstiQ: I guess that's still around.
<jam> Keybuk: so my initial impression.... is that something about the upstart-0.6 branch thinks that 'test_job.c' was modified in 200907
<jam> however, that revision is not in the stacked branch
<jam> so I assume it should be in trunk
<jam> (revision-info says rev 1173)
<jam> my quick guess is that whatever source upstart-0.6 was created from
<jam> different from the source that '~scott/upstart/trunk' was created from
<LarstiQ> dash: he has an identi.ca account if you prefer :)
<jam> *specifically* about the revision 200907
<dash> LarstiQ: Heh hee.
<Keybuk> jam: let me check the histories
<Keybuk> jam: the branches should be identical up to -r1204
<Keybuk> 1205 in both branches is where they diverge
<Keybuk> 2009/08/02
<Keybuk> that fits with my zsh history as well
<Keybuk> the last time test_job.c was changed was -r1173
<Keybuk> that was before, even, the release of 0.6.0
<Keybuk> so that would have been from trunk
<Keybuk> just to confirm, the branch point of trunk and 0.6 is well after that revision
<Keybuk> so they should be identical
<LarstiQ> Keybuk: how far back does your zsh history go?
<Keybuk> LarstiQ: I allow 1MB for it
 * LarstiQ already feels like SAVEHIST/HISTSIZE=50000 is a lot
<LarstiQ> Keybuk: I see
<Keybuk> you can never have too much history
<Keybuk> "I want the command I ran last month that did foo" :p
<LarstiQ> I entirely agree, but I'm not sure my acer ssd does ;)
<Keybuk> pah, your SSD will last just as long as a hard drive these days
<LarstiQ> not quite :/
<LarstiQ> it's already becoming very slow
<LarstiQ> Keybuk: so yeah, rewrites is not a problem, but at this point vim writing to its swap file when I build my tex can take up to two seconds
<LarstiQ> which is starting to become irritating
<Keybuk> yeah, don't bother with swap on ssd
<Keybuk> it's rarely a good idea
<Keybuk> or use swap files
<LarstiQ> right
 * fullermd is looking forward to SSD's, in about 6 or 8 years when he comes to trust them.
<LarstiQ> same thing goes for firefox cache etc
<LarstiQ> fullermd: I'm just waiting for trim support
<fullermd> I'm still iffy on the longevity of SLC.  MLC is right out.
<dash> fullermd: really? why
<fullermd> Because they wear way too fast.
<fullermd> (I mean, the prices are still way high, but that's just waiting; I'm sure they'll be reasonable in a few years)
<fullermd> But still.  In June I retired some hard drives I bought in 1998, and they worked hard their whole life.  I have zero faith a MLC SSD will be holding data for crap at that point.
<fullermd> Think about how flash wears; it's not like you write, and write and write and write, and one day it just *ploop* stops working suddenly.
<stianhj> jam: deleting the $APPDATA\bazaar folder worked. Bzr Qlog works fine, as well as Bzr Explorer, and I get no error messages in the console. Thanks
<jam> stianhj: always happy to help
<jam> fullermd: well they load balance while they are wearing
<fullermd> Every write reduces the time the charge holds, so you're in trouble long before they "wear out" totally.
<Keybuk> fullermd: that's the same for a hard drive though ;)
<fullermd> Strictly speaking, yes, but there are orders of magnitude difference.  It's not technically a different of kind, but it's practically equivalent.
<jam> I thought http://www.anandtech.com/storage/showdoc.aspx?i=3631 was a pretty good article on it.
<jam> http://www.anandtech.com/storage/showdoc.aspx?i=3631&p=6 has a specific focus on wear leveling
<jam> which is "writing 7GB of data to disk per day will take ~986 years to wear out all 10k cycles"
<jam> so even if that is off by 20x or so
<jam> it still has a reasonable safety margin
<fullermd> I'm aware of the claims made.  I don't buy them yet, by quite a ways.
<jam> the main thing for me was that I could get a 250GB drive as a "free upgrade" or pay $300 for an 80GB SSD for my laptop
<jam> at $1k for the laptop, 30% for the hardrive was a bit more than I wanted to spend
<jam> though sometimes I sure wish I had...
<jam> note, though, that I don't expect my laptop to last me 10 years anyway.
<fullermd> Well, a laptop would be a different story   :p
<fullermd> I don't expect that much longevity, don't put important data on it, and laptop drives are scary crap in the first place.
<jam> fullermd: besides, if you really cared, you'd put it all on tape with a lifetime of 30 years and a rewrite of 1M cycles :)
<fullermd> But I've got Velociraptors in this workstation, and SCSI drives for the years before that.  More IOPS would be nice, but I don't spend all that much time waiting on them.
<fullermd> Man, I've used *WAY* too much tape to trust a 30 year figure for that  :p
<jam> fullermd: well it depends if you put it in controlled storage
<jam> or leave it on your desk under the coffee cup
<fullermd> Yeah, I don't have quite enough free cash to build a climate controlled storage closet for backup tapes in my house...
<fullermd> Maybe after I win the lottery.
<LarstiQ> :)
<LarstiQ> fullermd: mine is, of course, a laptop
<jam> fullermd: I would think a cardboard box full of LTO tapes would still out-last your raptors :)
<jam> LarstiQ: mine is launchpad
<jam> ...
<fullermd> Unless you've got a 7 digit backup budget, hard drives are the best and most reliable backup means around these days.
<fullermd> I wouldn't.  I don't have faith in tapes lasting more than a year or two (never mind the relative costs of tape vs. HDD)
<Peng_> Was this the channel that suggested beaming your data into space, then inventing FTL travel to go record the signal whenever you need it?
<fullermd> What a terrible idea.  Who wants to look at a bunch of red-shifted pr0n?
 * Peng_ wonders why pushing the last 2 revs of bzr.dev took 1100+ KB of data transfer.
<luks> indexes?
<jam> Peng_: the last 2 revs probably include the merges from the releases I made
<jam> so it is a bunch of changes to NEWS, and probably some non-trivial amount of history
<jfroy|work> verterok: pushed another revision to update the package content and readmes :|
<Peng_> jam: Duh, you're right. jam++. Pulling them was quick because I already had most of the revisions in the repo from the 2.0 etc. branches, but the repo I pushed to didn't.
<verterok> jfroy|work: ok, I'll merge it tonigh. thanks!
<Peng_> Although it was still barely 300 KB of packs+indices.
<jam> jelmer: ping if you are around. 'lp:bzr-rewrite' has a tag for 'bzr-rewrite-0.5.4' but that revision is not in the ancestry of "bzr branch lp:bzr-rewrite"
<jam> which points over to your http://people.samba.org branches
<jam> jfroy|work: are you working on 2.1.0b1 packages?
<jfroy|work> No
<jfroy|work> Well, not today.
<jfroy|work> I have very limited time for doing packaging...
<jfroy|work> (not my day job, etc.)
<jfroy|work> I'll try to get around to it
<jam> LarstiQ / jelmer: Where is the 'bzr.debian.org' branches?
<LarstiQ> jam: http://bzr.debian.org/pkg-bazaar/ you mean?
<jam> probably
<jam> thanks
<jam> mostly I'm trying to find the 0.5.4 revision
<jam> which doesn't seem to exist anywhere I can get to yet
<jam> (I'm guessing jelmer merged it to trunk, but forgot to commit before pushing)
<jam> it seems his "unstable" branch also has the tag but not the revision... :(
<LarstiQ> jam: and his samba.org branches?
<jam> LarstiQ: well, the official trunk doesn't have it
<jam> are there other samba branches to check?
<LarstiQ> ah no, sorry
<jam> anyway, for now I'll just downgrade to 0.5.3 since I can find that one
<jam> brb, rebooting
<mathepic> For fixing a small bug (which is more of a feature request), for NEWS, do I put the bugfix under 2.1.0 or 2.0.2?
<Peng_> jam: <333
<Peng_> (I hope that didn't make his computer beep.)
<jam> Peng_: of course it did, but why the love?
<Peng_> jam: "(jam) Start using StaticTuple as part of the btree_index parsing code."
<Peng_> Plus, why not? Love is fun!
* jam changed the topic of #bzr to: Bazaar version control system | 2.0.1 and 2.1.0b1 has gone gold! start building those installers |  try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/
* jam changed the topic of #bzr to: Bazaar version control system | 2.0.1 and 2.1.0b1 have gone gold! start building those installers |  try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/
<jam> Peng_: love is grand, I just figured you had a specific reason :)
 * Peng_ wonders how many StaticTuples Loggerhead will create.
<awilkins> Will that make things fast? It has C in it. Vitamin C.
<mwhudson> it will make things small, is the idea
<mwhudson> small is fast to some extent though
<jam> mwhudson: actually it makes things faster than smaller
<jam> as an interesting side effect
<mwhudson> jam: really?
<mwhudson> oh right
<Peng_> All the StaticTuples in the world wouldn't make Loggerhead "small".
<jam> mwhudson: well for "bzr branch launchpad" it made it 17% smaller and 40% faster
<mwhudson> oh yeah, less objects doing gc
<jam> mwhudson: right
<awilkins> I find the smaller you make things the more they fit in the CPU cache
<jam> awilkins: true, but in this case it is GC overhead
<jam> and when you have 500MB, *nothing* fits in CPU cache :)
<Peng_> That'd be an awesome CPU.
<mwhudson> jam: is there any progress on ways to do branch without the whole index?
<awilkins> I think modern CPUs are pretty awesome anyway
<jam> *argh* the windows installers just refuse to build...
<jam> mwhudson: even if we do it in pieces, I think we'll end up caching most of the index
<awilkins> Bah, I deleted my win32 build VM
<jam> however, last check shows that bulk of memory is in the groupcompress block caches
<jam> w/ ~160MB in or "LRUSizeCache(50MB)"
<Peng_> So far, peak of 110,000 tuples. Dozer doesn't see any StaticTuples.
<jam> in our
<jam> Peng_: you did "make" again, right?
<jam> Peng_: and Dozer won't see StaticTuples
<jam> because they aren't in gc.get_objects()
<Peng_> Oh, of course. No fun!
<jam> just as, I'm pretty sure, it won't see Strings
<jam> mwhudson: though I'm still concerned that Meliae shows 250MB when 'debug_memory()' shows 500MB in use.
<Peng_> You're right, no __builtin__.str or __builtin__.int.
<jam> Peng_: yeah, and for us, a *lot* of memory can be in strs
<jam> mwhudson: anyway, my target is to cut memory consumption to about 50% for 'bzr branch launchpad', which should be reasonably attainable
<jam> I'm just worried that I'll cut X amount of memory, and have no clue where the rest is
<mwhudson> jam: still, that'd be cool
<jam> sure
<jam> Peng_: and we still have quite a few code paths that can be tweaked to use StaticTuple
<jam> like the fetch code re-converts all the StaticTuples back to regular tuples for the target repo, etc.
<fullermd> Well, you want it cut it in half, and Meliae is showing half of the usage.  So just eliminate everything it shows, and you're done   ;)
<dash> Hm
<dash> is is safe to delete things in .bzr/repository/obsolete_packs or do those still contain actual data
<jam> dash: generally you can remove the files from obsolete_packs, just don't remove the directory itself
<dash> OK
<dash> it's just bigger than the 'packs' dir now :)
<jam> they contain the "previous copy", as we can't really be sure that the OS will sync things in the order that we've written them
<dash> cool
<jam> (if we deleted them ourselves, the OS may decide to write the 'delete' down before it writes the "and write all this data over here".)
<dash> well it looks like 'bzr upgrade' worked fine on a machine with a decent amount of RAM.
<dash> filesystems are pretty bad, yeah.
<jam> naoki: ping, I'm having some troubles building the win32 installers, I'm getting an error of:
<jam> "no module named 'tbzr'"
<jam> any ideas?
<jam> mwhudson: what is "ellipsis" ?
<mwhudson> jam: a total weird appendix-like useless thing
<jam> mwhudson: hm... I have a list that 1.5MB in size, and the first entry is "ellipsis" and the next two are "imp.NullImporter"...
<mwhudson> jam: weird
<mwhudson> jam: it's used by numeric
<mwhudson> http://pastebin.ubuntu.com/294223/
<mwhudson> jam: and, it seems, by something else!
<mwhudson> jam: is it sys.path_importer_cache or something?
<jam> at the end of this list is some big strings
<jam> I'm almost wondering if it something like a stack frame
<jam> ah... I think I did 'gc.get_objects()' in the debugger
<jam> and it is dumping extra stuff
<jam> probably self refers to the local function refers to the local frame, and that makes things screwy
<jam> not sure ,though
<jam> mwhudson: One sucky thing about debugging memory in meliae, is that normal objects have a dict attribute, which is "in the way" between the instance and its attributes
<jam> I'm wondering if there would be a reasonable way to collapse that structure
<mwhudson> jam: yeah
<mwhudson> you get that when debugging via gc.get_referrents too
<jam> especially since most members will have one reference to a string, as the name of the member
<mwhudson> jam: there are probably some heuristics we could use
<jam> and the next entry is the actual object
<jam> which means you *could* recreate something nice looking
<jam> maybe
<jam> anyway, I *think* I'm seeing that GroupCompressBlock somehow contains a direct pointer to itself
<mwhudson> jam: also, when tp_traverse yields the object at tp_dictoffset in the object, you can treat that specially
<jam> which is probably screwing up GC
<jam> mwhudson: interesting thought
<mwhudson> jam: you mean instance.attribute = instance ?
<jam> mwhudson: that is what it looks like
<mwhudson> jam: the gc should cope fine with that
<mwhudson> i guess it won't be terribly performant
<mwhudson> but it shouldn't leak
<jam> ah, I see what it was
<jam> I was getting "refs" confused with "referrers"
<jam> because of wrapping issues
<jam> so it was just me
<mwhudson> :)
<jam> mwhudson: anyway, I'd really like to get a gui on this
<jam> but I'm not sure how to represent it
<jam> having a "dot" graph that I could expand would be cool
<mwhudson> pypy has a pygame graph viewer
<jam> I've looked a bit at "runsnakerun" which has a square-map stuff
<jam> the main problem is the cycles
<jam> as you end up with infinite recursion which doesn't display so well :)
<mwhudson> well, i'd hope a graph viewer would expect cycles really
<jelmer> jam: bzr-rewrite tag should be fixed; sorry about that
<jam> well, runsnakerun is meant to track how time is spent (similar to kcachegrind), and there is  some recursion there, but not really infinite cycles :)
<jam> mwhudson: anyway, thanks for the pointer, I'll take a look
<mwhudson> jam: ah
<mwhudson> jam: it'll probably require some head scratching and hacking
<jam> mwhudson: and pygame and numpy and ...
<jam> but I'll get there
<jam> also, I'm doing a checkout of pypy and it... just keeps going
<jam> I'm only grabbing "dist" and its already at 20MB
<mwhudson> it's pretty heft
<mwhudson> y
<mwhudson> my svn checkout is 192 megs
<mwhudson> probably has some .o files and so on in it though
<jam> mwhudson: argh.... and pygame may not even be *in* dist...
<jam> pypy/translator/tool/pygame/ isn't in my checkout yet, at least, though pypy/translator/tool/ is
<mwhudson> oh maybe it's an external
<jam> download done, and I did set 'fully recursive'....
<jam> hm... .../pygame isn't in trunk either
<jam> maybe they just deleted it?
<jam> the mailing list entry I see is from 2004
<jam> naoki: it is probably your recent change to setup.py that I need.... damn, out-of-order changes...
<Peng_> Loggerhead's peak number of tuples is still over 400,000, so I'm not sure StaticTuple helped much. OTOH, RAM usage might be suspiciously low.
<jam> mwhudson: do you have a copy of it in your checkout, such that you might help point me to the correct location
<jam> ?
<jam> Peng_: what branch are you viewing?
<mwhudson> jam: i can try and find it
<jam> "bzr branch launchpad" can create 1.8M tuples
<Peng_> jam: I'm just looking at my Loggerhead instance, which gets random traffic from Googlebot.
<Peng_> Because I'm being completely unscientific, it's hard to say anything for sure. :\
<jam> Peng_: so StaticTuple isn't a 'it just works' you have to go around using it... :)
<mwhudson> jam: probably you should ask in #pypy when europe is awake
<jam> however, the Btree reader uses it, which is generally a main source of tuples
<jam> mwhudson: what is 'pyrepl' given that it is (c) you and imports pygame
<jam> otherwise it looks like "translator/goal/translate" may be what I want
<jam> or maybe "dotviewer" up above the 'pypy' sources
<Peng_> I'm afraid to look at Dozer's HTML page listing all of the thousands of tuples.
<jam> mwhudson: it looks like "dotviewer.py" is a generic method for viewing .dot files, which I can easily generate
<Peng_> OK, I stopped loading the list of tuples after 400 MB of RAM was used. :D
<Peng_> That was about...35 MB of HTML total.
<Peng_> I have lots of lists with tuples with revids and stuff in them, from Loggerhead's graph caches.
<Peng_> I have lists of stuff like "('equal', 507, 510, 511, 514)". Diffs, I guess?
<Peng_> That looks like a nice place for StaticTuple.
<mwhudson> jam: yeah, dotviewer
<mwhudson> jam: pyrepl is a command line interface that supports multiline editing
<jam> Peng_: well, ATM StaticTuple won't accept ints, but we can change that
<jam> and yes, both places would be good for ST
<Peng_> FWIW, anyone else can wade through my Dozer stuff too, if you want to: http://bzr.mattnordhoff.com/loggerhead/_dozer/index
<Peng_> Seems Dozer *is* aware of strings, when it's aware of an object referring to one.
<Peng_> StaticTuple too.
<Peng_> but it can't actually show any information about them.
<jam> well they aren't in the GC so "gc.get_referents()" returns nothing
<jam> though I *do* implement tp_traverse
<jam> and meliae knows how to use that
<jam> my system is unhappy about my 30MB dot dump :)
<jam> no doubt having 1 object referring to *everything* doesn't help :)
<jam> anyway, EOD
<jam> thanks for the pointer mwhudson
<mwhudson> jam: np
<awilkins> Heh, I'm also memory optimizing on my Java stuff, must be catching
<Peng_> A large portion of LH's tuples are just normal stuff, not torrents of data.
<mwhudson> Peng_: a lot of loggerheads tuples will be the merge sorted revision graph i bet
<mwhudson> which could use static tuples i guess
<Peng_> Maybe 40%.
<Peng_> There's a frightening amount of the "normal stuff".
<mwhudson> Peng_: what do you mean by that?
<Peng_> mwhudson: There are tens of thousands of tuples with stuff like None or VfsRequest or docstrings or bits of TAL templates.
<Peng_> mwhudson: Things like the graph are in the minority.
<Peng_> Actually, I forgot, I stopped loading the page 4 MB before the end. So maybe things like the graph are, ehh, up to 60%?
<Peng_> Lists, OTOH, are dominated by the revision graph.
<mwhudson> jam: i'm told that http://codespeak.net/svn/pypy/trunk/pypy/translator/tool/reftracker.py might be interesting
<mwhudson> loggerhead should use statictuple for that if it can
<mwhudson> it may not help much but it will certainly help and not hurt
<Peng_> Software sure is complicated.
<Peng_> I never really think about the _scale_ of it all.
<mwhudson> jam: and http://domino.research.ibm.com/comm/research_people.nsf/pages/nickmitchell.pubs.html
<mwhudson> "Making Sense of Large Heaps"
<Peng_> What should Loggerhead do for static tuples when used with older versions of bzr? Storing a copy of _static_tuple_py.py is actualyl pretty reasonable.
<Peng_> s/storing/bundling/
<mwhudson> Peng_: yeah, that might work
 * Peng_ goes with that.
<Peng_> Peng_ almost wants to go crazy and use StaticTuples *everywhere* possible.
<igc> morning
<Peng_> Is it just me or is "_revision_graph.keys()" a somewhat bad idea?
<mwhudson> Peng_: yes, probably
<Peng_> Such a bad idea that mwhudson ran away?
#bzr 2009-10-16
<spiv> Peng_: Apparently!
<jfroy|work> The link to reverse cherrypicking in http://doc.bazaar-vcs.org/latest/en/user-guide/undoing_mistakes.html is broken
<Peng_> mwhudson: wb
 * Peng_ pushes
<mathepic> How can I accept a list as an argument for a command?
<spiv> mathepic: in a bzrlib.commands.Command subclass?
<mathepic> spiv: Yes, I'm trying to make remove-tree accept multiple trees as arguments
<spiv> mathepic: something like takes_args = ['file*']
<spiv> see e.g. cmd_dd
<spiv> er,
<spiv> cmd_add
<mathepic> Thanks
<spiv> (my 'a' key is becoming a bit dodgy)
<mathepic> And add a ? after the * if I want it to be optional, right?
<mathepic> It doesn't seem to work with optional...
<spiv> No, just *
<spiv> If you don't pass any, then the list will be empty :)
<mathepic> In my parameters for run, I have location_list=['.']
<mathepic> But it still gives an error if I don't specify a directory
<mathepic> bzr: ERROR: exceptions.TypeError: 'NoneType' object is not iterable
<mathepic> Oh wait, it passes an empty list
<mathepic> So I need to check if its empty, and if its empty, assign ['.
<spiv> Right.
<mathepic> Okay, got it. It works now.
<Peng_> Revision graphs contain lots of ints and bools, no?
<spiv> Bools?  Not off the top of my head, but ICBW
<Peng_> Eh. I don't know if Loggerhead's graph structure is the same as bzr's.
<Peng_> Anyway, it would be a great case for StaticTuple, but it has ints and bools. :(
<Peng_> There's are a bunch of diff-related tuples that include ints, too.
<Peng_> jam: It'd be awesome for Loggerhead if StaticTuples could include Python ints and bools.
 * Peng_ /away!
<Peng_> LH doesn't have any interesting str-only tuples. :\
<Peng_> Graph.iter_ancestry could use StaticTuples.
<spiv> Peng_: patches welcome!
<spiv> I think jam is choosing where to introduce it by profiling rather than inspection.
<spiv> But if it fits, there's no reason not to use it.
<spiv> lifeless: good morning
<lifeless> spiv: hai; internode outage ;)
<spiv> :)
<Peng_> spiv: Yeah, that makes sense. I'm doing simple profiling ("scroll through Dozer output") and skimming through the code. Still, LH has a lot of tuples from iter_ancestry.
<lifeless> spiv: bug 449923; I think its wishlist more than invalid - just a thought
<ubottu> Launchpad bug 449923 in bzr "bzr send should offer the --diff-options option" [Undecided,Invalid] https://launchpad.net/bugs/449923
<spiv> lifeless: yeah, good point
<bialix> hello all
<bialix> spiv: thanks
<spiv> bialix: no worries, thanks for bringing it to my attention
<bialix> I suspect the bug traffic is too high to see every sepearte bug report
<bialix> *separate
<bialix> spiv: I'm not sure I'll be able to work on fixing this bug in bzrlib until december or january... So I'll try to invent some workaround
<spiv> bialix: I expect I'll get to it before December :)
<bialix> spiv: I'll respect this
<bialix> though the bug triggered by QBzr non-trivial usage
<spiv> Yeah.
<bialix> though abentley suggest using dicts, but anyway today it's our (qbzr) problem
<igc> hi bialix, spiv
<bialix> hi igc
<bialix> igc: re http://doc.bazaar-vcs.org/migration/en/foreign/bzr-on-svn-projects.html
<bialix> is it now official?
<igc> in which sense?
<igc> bzr-migration-docs is a separate project to bzr core fwiw
<igc> but the core docs link to the latest copy of the migration docs
<bialix> oh, I saw http://doc.bazaar-vcs.org/... URL and thought it's part of official documentation
<bialix> it seems there is too much different branches with different docs, site etc. I've lost the track
<igc> bialix: it's meant to look like one set of doc :-)
<igc> bialix: behind the scenes though, I need to build different bits on different timelines
<igc> with different dependencies
<igc> migration is migration - it's not really tied to 2.0.1 vs 2.1.0b1 say
<bialix> I'd like to link to your document in bzr-day blog. May I cal it semi-official tutorial/guide then?
<igc> it's more tied to bzr-fastexport patches
<bialix> *call
<igc> yes
<igc> bialix: like the plugin guide, it is official documentation, just not "core" documentation
 * igc off for some medical stuff - bbl
<treeform> hey guys i did not have internet for a while, so i used bzr commit --local, now i got internet and repo has moved.  I tried to commit to the new reposatry (via bind to it first) but it made such a mess
<treeform> whats the best way to deal with --local?
<treeform> i have now over 18 conflicts
<dash> 'bzr push'
<dash> oh
<treeform> thats odd being the only developer
<dash> what did you do?
<treeform> i used commit --local couple of times
<dash> right
<dash> and then what did you do, later?
<treeform> then i did bzr commit ( when i got internet setup)
<treeform> it said
<treeform> no address
<treeform> so i did bzr bind to new address
<treeform> then i did bzr commit ( then i got message that i need torun bzr up)
<treeform> i run bzr up
<treeform> now every thing is confused
<treeform> and i have 18 conflicts
<treeform> and conflicts are crazy too:
<MTecknology> conflicts in any vcs blow :(
<MTecknology> bzr isn't too bad though
<treeform> http://dpaste.com/107979/
<dash> MTecknology: it's better than not having them
<MTecknology> yup
<treeform> the problem is that i am conflicting with myself
<spiv> treeform: yeah, bzr up when you have local commits *and* uncommitted changes tends to give nasty double conflicts.
<treeform> spiv: is there a way to undo
<treeform> and do some thing better?
<MTecknology> So.. I want to have a group of users that can access a bzr branch - what's the best way to handle that?
<mzz> I tend to make sure "bzr st" is clean before doing pretty much anything important
<mzz> well, before doing pretty much anything that might involve a merge
<treeform> howly fuck bzr st is even crazier
<spiv> treeform: so a good thing to do if you have local commits is make sure you have no uncommitted changes (i.e. shelve or commit your changes) before doing bzr up
<treeform> i have hunders of moded, unkown, delted, undelete ... files
<mzz> yeah, if you're already in weird merge territory "bzr st" is going to be pretty confusing too
<mzz> err
<mzz> that sounds excessive. Any idea what happened?
<mzz> sometimes certain large tree reorganizations cause this
<treeform> yes
<treeform> how can i roll back that update?
<treeform> without causing even more strife?
<mzz> you can just revert, but that'll kill your existing local changes
<treeform> yeah
<mzz> I'm not sure if there's a sane way to preserve those at this point :(
<spiv> You can do "bzr revert", but as mzz says that'll forget your uncommitted changes.
<treeform> ill copy the folder first?
<treeform> and copy it back?
<mzz> that won't necessarily give helpful results, although I guess it's better than nothing
<treeform> well i use all local changes?
<treeform> lose*
<mzz> I know this doesn't help at all with your problem now, but if "bzr st" was originally clean being able to just revert a merge that went wrong is extremely useful
<spiv> Yeah, so copying the current mess, doing a revert, then doing an update into a clean tree is probably simplest.  And then manually copy across any local changes from the copy.
<mzz> yeah
<mzz> I don't think you actually have better options, since your local changes are tangled into this confused merge now and bzr doesn't store enough information to untangle them
<treeform> man thats sound like what reversion controll made to avoid
<mzz> yes, and you can just revert *if* your original status was clean
<mzz> so I tend to either commit or shelve local changes before doing something that'll involve a merge
<spiv> I think https://bugs.launchpad.net/bzr/+bug/120970 is the relevant bug report, they may be others.
<ubottu> Launchpad bug 120970 in bzr ""bzr update" reports spurious conflicts when local commits added a directory." [Medium,Confirmed]
<MTecknology> I need to learn how to shelf something
<spiv> MTecknology: bzr help shelve :)
<treeform> yeah me too
<treeform> never sued shelve
<spiv> It's pretty easy
<treeform> used*
<mzz> although I don't think I've dealt with unshelving onto a very different tree than what I shelved from using the new shelve yet
<mzz> the old shelve stored changes as plain diffs, so I was always sure I'd be able to manually apply them if I confused shelve
<treeform> i think fixing the conflicts might be eser then redoing everything
<treeform> i did lots of stuff
<spiv> (And also see http://doc.bazaar-vcs.org/latest/en/user-guide/shelving_changes.html)
<treeform> if i fix all the conflicts i shoudl be good riht?
<mzz> treeform: downside of that is that you're going to end up with your local changes and the merge being in the same commit
<vila> hi all
<dash> treeform: well
<dash> treeform: what i'd do first is revert the changes
<mzz> treeform: the resulting history will be cleaner if you manage to revert, commit just the merge, then commit the local changes on top of that
<mzz> but at this point it'll be painful no matter what you end up doing
<vila> Sorry to begin the day with bad news, but babune is fully *red*: as of revno 4750, not a single successful selftest, with default locale and extensions compiled, pass
<vila> the most disturbing is that this is the run that pqm is supposed to run, any info I may have missed that occurred during my night ?
<vila> the failures (6) are related to: TypeError: can only concatenate tuple (not "StaticTuple") to tuple
<vila> occurring in _commit_write_group
<treeform> mzz, dash: so you say revert, and then copy all the files from the safe folder i just did?
<treeform> but that does not take care all the files that i removed
<dash> treeform: no, don't copy
<dash> merge
<vila> jam, spiv, lifeless, igc: ^
<treeform> dash: resolve conflicts?
<mzz> treeform: I'd back up the current tangled state somewhere, just in case, then revert, redo the merge (the one "bzr up" triggered), then reapply the local changes from the backup of the mess
<treeform> i am merging v n-1 with version n .. its utter crap
<fullermd> vila: See what happens when you wake up early?   :p
<mzz> treeform: but that's just me, and I don't know exactly what state your tree is in
<spiv> vila: huh
<dash> treeform: 'bzr vis' might help, maybe :)
<MTecknology> so - handling groups with bzr?
<dash> what's a group
<fullermd> MTecknology: Well, I use...   y'know.  Groups   :)
<spiv> vila: that is weird
<treeform> dash: i dont have it instaled
<fullermd> viz probably wouldn't help when you're in a twisted up state.
<mzz> MTecknology: err, I haven't done this in ages, but I think the last time I did we used a separate user account on the server with the keys of the developers supposed to be able to push to it in authorized_keys
<vila> spiv: I haven't investigated yet, but yes that's very very weird
<mzz> MTecknology: which gave those users access to quite a bit more than just bzr, but that wasn't an issue for us
<fullermd> treeform: Are you still sitting with the giant pile of conflicts?
<treeform> yeah
<treeform> and lost histry
<fullermd> OK.  So you've got two sets of changes here.
<MTecknology> mzz: sounds interesting
<mzz> treeform: you really shouldn't be losing any history, but it's hard to reliably preserve uncommitted changes across something like this. That's why they're uncommitted, I guess
<fullermd> The ones you commit'd (--local), and the ones that were sitting uncommitted in the tree.
<MTecknology> mzz: last time I used actual group accounts but I needed to miss with sticky bits
<fullermd> treeform: The former are still in your repo, so that's all recoverable.  The later, unless you can puzzle them out of the mess you have, are gone.
<spiv> vila: btw, it would be neat if babune used --subunit
<mzz> MTecknology: yeah, if you rely on groups it'd take a bit of effort to keep permissions consistent (everything group-writable). This was easier for us.
 * fullermd marks up another tick in the "get rid of fscking ci --local already" column...
<MTecknology> mzz: thanks
<treeform> fullermd: i dont want to loose stuff
<treeform> but i think revert will cause even more pain
<vila> spiv: full agreement, I want to switch to hudson first though... or to anything that allow a better tracking of runs
<treeform> then resolving 18 conflicts
<mzz> MTecknology: but in this case everyone being able to do a full ssh login as that project user was a feature, allowing them to update the website and the like
<mzz> ymmv and all that.
<spiv> vila: so, I see that failure locally, and it disappears if I delete _static_tuple_c.so
<spiv> vila: which suggests that PQM isn't building that extension :(
<fullermd> treeform: Well, unless you can sort out the big mess there, you're not going to get a hold of your uncommitted changes.  And even sorted out, it's a big ugly knothole in history because of all the unrelated changes mixed in.
<mzz> MTecknology: I'd expect the groups approach to also work, I just don't know the best approach to forcing bzr to use the right umask so everything stays group-writable
<MTecknology> mzz: that's what the sticky bit was for
<MTecknology> I wonder how LP handles it
<mzz> yeah
<fullermd> treeform: The changes you _committed_ are fine, we can recover those easy.   Presumably, you're committing often enough that the uncommitted bits are easy to redo, right?  ;)
<treeform> yes
<mzz> treeform: I'd be pretty surprised if the revert loses any *committed* changes. It'll eat the uncommitted ones.
<spiv> mzz: right
<treeform> ok will resolve
<treeform> o will revert*
<treeform> its reverting...
<MTecknology> spiv: how does LP handle teams?
<spiv> MTecknology: LP doesn't use filesystem permissions at all, it handles all that internally
<fullermd> treeform: 'k.  Do you have bzrtools installed?
<MTecknology> oh
<mzz> treeform: after the revert I'd manually delete any cruft left behind ("bzr st" is your friend here)
<treeform> ok i reverted
<mzz> ah, nvm, I'll stop interfering with the others helping out
<spiv> MTecknology: you can take a look at the source these days :)
<treeform> what do i do?
<MTecknology> spiv: I will when I start trying to do some dev on it - but I've been lacking time
<MTecknology> I just realized I spaced on an assignment..
<fullermd> treeform: Have bzrtools so you have the 'heads' command, and run a 'bzr heads --dead-only'.
<fullermd> treeform: That'll list the head revs in the repo that aren't on the branch; one of them will be the head of your local changes.
<fullermd> (you'll have to look at timestamps and log messages to figure which one; should be easy to tell)
<spiv> MTecknology: but briefly it implements a custom bzrlib.transport.Transport that a) translates paths from the user to how things are actually stored on disk, and b) does acceses control checks based on team membership
<mzz> fullermd: isn't he already on that head if he reverted?
<vila> spiv: thanks, good to know
<MTecknology> spiv: Sounds tricky
<fullermd> mzz: No, he's on the head of the 'remote' branch.
<mzz> fullermd: I haven't commit --local'd anything recently, but I'd expect this to just do the right thing
<mzz> urgh?
<fullermd> mzz: The update pivots over to that branch and stuffs your local commits as a pending merge.
<mzz> that sounds like a misfeature
<treeform> fullermd: getting bzr tools
<fullermd> treeform: Once you find it, grab the revid and run "bzr merge -rrevid:$WHATEVER ."
<spiv> MTecknology: it's not too hard, actually.
<spiv> MTecknology: you can basically do it all as a bzr plugin
<mzz> heh
<fullermd> treeform: That'll set up a pending merge with those local changes; then you can check and commit it, and you'll be where you want to be, minus the uncommitted stuff.
<fullermd> mzz: You're too kind.
<mzz> spiv: you can do tons of stuff as a bzr plugin, doesn't necessarily mean they're easy :P
<spiv> mzz: :)
<spiv> mzz: well, you can look at the code an judge for yourself ;)
<fullermd> Yeah.  I mean, theoretically you write write a svn gateway as a bzr plugin, but who would...    oh.
<treeform> fullermd: where do i install bzrtools on windows?
<spiv> Actually, the bzrlib.transport.pathfilter module in recent bzr would make this even easier.
<fullermd> treeform: Mmm.  Dunno.  Doesn't the windows installer come with bzrtools?
<fullermd> treeform: (try 'bzr help heads')
<mzz> treeform: which installer did you use?
<mzz> treeform: (for bzr itself, that is)
<treeform> oh its there
<treeform> but not bzr vis
<mzz> ah, nvm then
<MTecknology> chmod +s = :) ;; when used correctly
<treeform> bzr merge --rrevid:me@centurion-20091012170842-puyjiezcx4dw6noc
<treeform> bzr: ERROR: no such option: --rrevid:me@centurion-20091012170842-puyjiezcx4dw6noc
<fullermd> One dash
<fullermd> (and don't forget the " ." at the end; that's important)
<treeform> same thing
<treeform> dot or not
<mzz> treeform: single -
<treeform> oh ok
<mzz> treeform: (it's the option -r, taking an argument of revid:...
<treeform> its spinning
<mzz> treeform: ("-r revid:..." also works. It's not the option --rrevid)
<spiv> vila:
<spiv> -            all_missing.update([(prefix,) + key for key in missing])
<spiv> +            all_missing.update([(prefix,) + tuple(key) for key in missing])
<spiv> vila: that seems to be an effective band-aid
<MTecknology> Is it possible to have something like lp: instead of a site name?
<treeform> fullermd: its done
<treeform> bzr st is soo confused
<mzz> MTecknology: lp: already works (it's builtin). You might want the "bookmarks" plugin for other sites.
<fullermd> treeform: Confused how?  Just "a lot of stuff"?  It should just be the changes from your local commits.
<treeform> yes i guess it is
<treeform> i was just not ready for 25 page report ;)
<treeform> what is this > pending merge tips: (use -v to see all merge revisions) me 2009-10-12 fixed the errors from major renaming spree
<MTecknology> mzz: yup - that plugin is what I was asking for :)
<fullermd> treeform: That's the head of the revs you're merging.
<treeform> what do i do next
<fullermd> Check that everything looks right (no conflicts etc), then commit 'em.
<spiv> treeform: basically local commits makes a temporary branch, and when you do "bzr update" it's bascially the same as "bzr merge" of the main branch with that temporary branch.
<treeform> i see
<spiv> treeform: so, your local commits show up as a pending merge.
<treeform> but why did the uncommited stuff cause so much problem?
<MTecknology> I need to install bzr on the server first.. huh..
<mzz> MTecknology: depends on what you're pushing over
<mzz> MTecknology: you can do sftp pushes, for example. But installing bzr on the server may be preferable performance-wise.
<MTecknology> ya
<MTecknology> anyway - I'm getting permission errors but I'm in the group that has access for it
<MTecknology> chmod 770 /bzr/test     bzr push bzr+ssh://192.168.1.6/bzr/test
<MTecknology> anything wrong with that?
<vila> spiv: +1, please land :-)
<mzz> MTecknology: not offhand, no. ~/.bzr.log?
<vila> spiv: or tell me to land it, I really don't like having the test suite failing that way, so let's fix that first and then fix it best (with jam input) and let's address the root cause (not building extensions if that's it)
<MTecknology> woah.. http://dpaste.com/107985/
<spiv> vila: go ahead and land it for me, I'm playing with making tuple + StaticTuple work
<vila> spiv: ok
<spiv> vila: but I agree, the root bug is that PQM should not pass if that extension doesn't build
<vila> spiv: just running a full test suite to make sure
<spiv> vila: ta
<MTecknology> bzr: ERROR: Server sent an unexpected error: ('error', "'Bazaar repository format 2a (needs bzr 1.16 or later)\\n'")
<MTecknology> so - I need to update my server?
<spiv> MTecknology: that error is probably because you're trying to push a 2a format branch to a server that can't read 2a
<spiv> so, yes
<MTecknology> both client and server are Ubuntu 9.10
<vila> MTecknology: what does 'bzr version' says  ?
<MTecknology> ooh... the server's 9.10
<MTecknology> 9.04*
<MTecknology> I should upgrade it to 9.10
<mzz> MTecknology: if you just need a newer bzr: bzr 2.0 is in the bazaar ppa
<vila> MTecknology: I don't know by heart what bzr version are proposed by default to 9.04 and 9.10 so try 'bzr version' in both places
<MTecknology> server - 1.13.1
<vila> MTecknology: you can then look at https://launchpad.net/~bzr/+archive and foolow the instructions to update your source lists
<MTecknology> I guess I just need to either upgrade the entire server or use a pp
<MTecknology> ppa*
<MTecknology> I like the server idea
<vila> MTecknology: you may be able to upgrade bzr only instead of the whole system, but you decide...
<MTecknology> I thought the guy was installing 9.10 :P
<MTecknology> thanks for all the help
<MTecknology> I imagine that's what caused the other error too
<MTecknology> "This session appears to be running under ssh. It is not recommended to perform a upgrade over ssh currently because in case of failure it is harder to recover."
<MTecknology> :P
<MTecknology> shower and sleep time - I'll catch you all later
<vila> spiv: sent to pqm
<igc> vila: I'm fine with you landing that revdwim patch from fullermd
<igc> vila: also, https://code.edge.launchpad.net/~vila/bzr/405745-http-hangs/+merge/13050 is approved. Can we land that one as well?
<vila> igc: ok for the dwim patch
<vila> igc: no, fixing bug  #405745 makes the leaking tests more sensitive to a yet-to-fix other bug
<ubottu> Launchpad bug 405745 in bzr "blackbox.test_check.ChrootedCheckTests.test_check_missing_branch hangs on AIX" [Medium,In progress] https://launchpad.net/bugs/405745
<vila> see my comment there
<igc> vila: what's the buildbot url again?
<vila> igc: can't remember, never use it myself :)
<igc> vila: I some a url with pretty pictures/tables I can reference :-)
<igc> showing our cross-platform testing
<vila> http://babune.ladeuil.net:26862/
<vila> igc: the pretty pictures are planned after a switch to hudson so far...
<vila> igc: especially because tracking the overall behavior across the revisions is not that easy with buildbot, but I get that feeling progressively by using it daily
<awilkins> Been using Maven / Archiva / Hudson .... we've been having real headaches but I suspect that's because of the module graph we've been building
<vila> babune progressively recovers some green color ;) Thanks for the quik help spiv :)
<spiv> vila: cool
<spiv> vila: I'm just finishing for the day
<spiv> vila: I just sent a patch to John for making tuple + StaticTuple work though
<vila> spiv: good, I wanted to give you some feedback before :)
<vila> great, I'll track that later today !
<spiv> vila: I'll leave it to jam to polish and merge if thinks its a good idea
<vila> sure
<spiv> vila: (it's visible in a comment at https://code.edge.launchpad.net/~jameinel/bzr/2.1-static-tuple-btree-string-intern/+merge/13296 if you're curious)
<spiv> vila: it makes the test pass without the bandaid though :)
<spiv> Ok, have a good weekend everyone
<vila> s
<vila> spiv: sorry keyboard battery failure here, have a good weekend !
<spiv> :)
<vila> spare batteries to the rescue !
<fullermd> igc: I seem to be outvoted on the 'keep going if it looks like a revno' thing; I was gonna wait a day or so for any more weigh-ins and then push up a change to stop searching there.
<igc> fullermd: ok
<fullermd> I still like it going ahead and keeping trying, but if the majority opinion is the other way, I won't kvetch too much about it.  I don't use pure-numeric tags anyway  ;)
<vila> fullermd, igc: what did I miss here ?
<fullermd> Oh, heck, you sided with me.  Shucks, now it's even again.
 * fullermd catches up on mail after writing stupidly long-winded PM posts...
<vila> I think the performance issue should be balanced by the time the user will spend understanding the error and typing the new command
<vila> performance and DWIM doesn't have to be compatible as long as an explicit way exists to disable dwim to get performance, and I think your approach is sound for that
<fullermd> Yeah, the only case where it (currently) adds a meaningful performance hit above the status quo, is if the user enters a revno that doesn't exist; it'll do more searching.  If they keep using explicit revid:'s and such, they'll never need to hit those cases in the DWIM.
<fullermd> (well, there's trivial overhead from instantiating another class and calling some functions, but that's negligable)
<vila> fullermd: if you want to further improve your patch you can do so or let me land that one and build on top of it, your call, unless igc revert his "vila, go land it" message from some minutes ago
 * vila nods to fullermd 
<vila> igc: I suspect you missed some of the last messages right ?
<vila> igc1: even
<fullermd> Mod lifeless's larger concerns, the only thing is the whether to keep the fallback on "looked like a revno, but wasn't" or cut off the search then; votes seem about split on that.
 * fullermd hopes his high school English teacher doesn't get a look at that 'sentence'...
<vila> yeah. if lifeless could shime in to say whether he strongly vetoed or is ok for a further submissions can clear that bit
<vila> but if you plan to tweak some more you can also address that even if I think it will be a yagni,
<vila> at least it would make it possible for someone else than you to try another DWIM approach
<vila> and DEIM, by experience, tends to evolve incrementally so what sounds perfect today may be more polished  tomorrow
<vila> s/DEIM/DWIM/
<Tak> vila meant: and DWIM, by experience, tends to evolve incrementally so what sounds perfect today may be more polished  tomorrow
<vila> Tak: wow ! Hurrah ! Someone can fix muy tupos ! WOnderfulk  1
<vila> fullermd: all of that to say: you've been waiting with your proposal a bit too long to see it land, I think we can land the actual one and wait for improvements in another one OR, if you feel like it, you can address the concerns you feel like addressing and resubmit
 * igc1 dinner
<vila> from babune, instant feedback, jaunty fully green, hardy and karmic coming along nicely
 * fullermd polishes up another response to lifeless.
<fullermd> So, yeah, the only concern I have open is whether the bulk of opinion wants to stop the fallthru on revno-looking stuff.  Opinion seems split, so either way.
<lifeless> fullermd: attributes on the revspec classes would do it easily without needing another registry or lots of cruft.IMO
<lifeless> fullermd: as for the exceptions; I hear standardising interfaces is useful :)
<vila> lifeless: agreed on both point, I was about to say roughly the same (attributes and exceptions)
<lifeless> :)
<vila> lifeless: Do you agree to land it as is and to file a bug for that requirements or do you want them implemented before that is landed ? (Given that fullermd implied he will not do them soon, I'd rather land that now)
<fullermd> Well, there's a limit to the standardizability...  I mean, if RevisionSpec_date ever started raising errors.TagsNotSupported, I'd look a little squirrely at bzrlib...
<fullermd> Ditto NotBranchError, etc.
<vila> fullermd: they can inherit from a common exception
<lifeless> so, (NoSuchRevision, UnsupportedFeature, RevisionNotPresent)
<fullermd> I'm sure a lot could be achieved by rototilling how all the RevisionSpec_*'s work, but that's definitely in the "way more scope than I wanna get within 10 blocks of" area.
<lifeless> NotBranchError should bubble up
<vila> fullermd: or have an attribute list the raisable exceptions
<lifeless> +1 on ^
<vila> lifeless: sorry, what are you referring to ?
<fullermd> Well, NotBranchError is somewhat special since branch: is the last thing tried, but it doesn't necessarily HAVE to be, in which case we'd need to catch it.
<lifeless> 20:36 < vila> fullermd: or have an attribute list the raisable exceptions
<vila> ok
<fullermd> Anyway, it's doable with more or less pain in various ways, probably.  But it's not as simple as "slap it in, you're done", 's what I was aiming for.
<fullermd> Holy crud, it's almost 0500??
<vila> wow, tiger slaves fails but leave a running selftest process that generates log in /tmp of ~3GB size.... triggering OSX warnings about boot disk almost full until I kill them 8-/
<fullermd> Well, bzr can use a lot of resources.  Selftest has to try overloading the system to make sure it can handle it   :p
<vila> process leaks now...
<vila> yeah, but I'd like to get better control on that kind of experiment :D
<vila> I just freed 10GB on a 32GB partition... that should *never* occur or I will really become insane without any hope to cure that...
<fullermd> Cure?  Why waste a good insanity?   :p
<vila> Because it's good as long as I'm still enjoying it, if it goes too far, I may forget than I enjoy it, and *then* it would be wasted !
<vila> from babune: gentoo back in green, waiting for freebsd[78], OSX failed because of yet another hidden aspect of the leaking tests
<SamB_XP_> fullermd: well, there's insanity and there's insanity
<SamB_XP_> some of it's not so great :-(
<fullermd> The way I see it, that's the world's problem, not mine...
<SamB_XP_> it *will* be yours if you get one of the not-so-great kinds!
<SamB_XP_> it's not fun to be paranoid-delusional, for instance!
<fullermd> It's not delusional if they really ARE out to get me.  The bastards.
<SamB_XP_> well, if they are out to get you, you aren't insane
<SamB_XP_> but it's still not that much fun
<fullermd> That's what *I* keep telling people, but they still cross the street when I walk by...
<SamB_XP_> lol
<SamB_XP_> but, wouldn't you want someone to stop you if you started thinking PHP was a good idea?
<fullermd> Well, true, it doesn't have the power and flexibility of VB...
<SamB_XP_> I hope you mean VB.NET
<fullermd> Well, I'm holding out for VB.ORG, actually...
<SamB_XP_> because the other kind is pretty crappy, IMO
<SamB_XP_> hehehehe
<SamB_XP_> I always thought .net was the coolest suffix ;-P
<oleavr> hi.. is there any way to merge from a 2a branch to one with knitpack-experimental? (which I cannot upgrade yet)
<fullermd> No.  Your best bet will be rich-root-pack, assuming everybody's on 1.0 or later.
<fullermd> (and will jump over the flag day, natch)
<fullermd> But you're already on the 0.92 format, so it's only one prettydurnoldversion higher.
<oleavr> fullermd: so I can upgrade the knitpack-experimental one to rich-root-pack, pull in changes from the 2a one, then from the original knitpack-experimental pull in changes from the rich-root-pack one?
<fullermd> No, once rich root, always rich root.
<fullermd> Once one corner of a project crosses the Rubicon, everything's gotta.
<asabil> oleavr: bzr has historically had 2 format families: rich root and non rich root
<asabil> rich root can pull from non rich root, but not the other way around
<oleavr> fullermd: ok.. guess I'm screwed then (cannot upgrade the knitpack-experimental branch yet because the whole continuous integration system uses such branches and won't be upgraded just yet)
<oleavr> asabil: yep.. meaning I'm screwed :P
<oleavr> so guess bzr diff | patch will have to do for now then :/
<fullermd> Why won't be upgraded yet?  Just practical 'doing it all' issues?
<asabil> oleavr: you can
<asabil> rich root formats has been available since bzr 1.0
<fullermd> And with some kinda ugly hackish work, you can get rich root revs back into an 0.15 format, which predates any pack format by several versions.  But you don't wanna do that.
<oleavr> fullermd: I see.. they'll upgrade the continuous integration branches to 2a next week. hey, I just got an idea.. I can 'bzr replay' the commits on top of the crappy in-house branch which is knitpack-experimental, then uncommit all those commits in the public branch (which I control and no-one else pulls from anyway), and finally pull from the in-house branch
<fullermd> Well, if they're going to upgrade next week, you could just take a long nap   ;)
<oleavr> shit.. replay won't work for the same reason. ah well, long nap it is ;)
<SamB_XP_> or, at least, you'll have to wait to have your branch(es) merged :-(
<fullermd> I totally vote for nap.
<fullermd> There may be things better than sleeping, but they're probably all illegal and fattening.
<SamB_XP_> a week seems a bit long
<SamB_XP_> ... and since when is using IDA Free to disassemble itself illegal or fattening?
<fullermd> Are you kidding?  Look at me; I haven't even done it yet, and already there are these extra inches around my waist...
<fullermd> It's kinda depressing.  BRB, gotta go eat some chocolate to ease the pain.
<oleavr> lol
<oleavr> hmm..screw replay, I'll write a shell script that uses bzr diff and bzr log to replay commits the dumb way
 * oleavr is out of patience
<fullermd> "Ed Gruberman, you must learn patience."  "Yeah, yeah, yeah, patience, how long will that take?"
<oleavr> :D
<vila> from babune: back to green except for the known OSX leak related failures, pfew, sleep well spiv :)
<johnf> are lp:bzr  and pqm missing the 2.0.0 tag or is it just me?
<wlawless> is there a download mirror for bzr2.0.0-setup.exe?  the launchpad site is running VERY slow
<igc1> well done vila!
<igc1> night all - have a good weekend
<vila> igc: thks :-) Have a nice week-end too and sleep well :D
<theLawless1> is there a non-launchpad.net hosted version of the windows bzr setup file?
<mathepic> I have no idea, but the file isn't all that big, it shouldn't be much of a deal to download from Launchpad even if its a bit slower
<theLawless1> 4 hours currently....
<theLawless1> 1.2k is the fastest I can get from launchpad
<mathepic> Wow, only 1.2k? I guess Launchpad is being slow...
<vila> theLawless1: this is really surprising
<theLawless1> that's why I was hunting for a mirror
<vila> theLawless1: I can get 1.5MB/s from lp right now
<vila> where are you ?
<theLawless1> Toronto, Canada
<abentley> vila, jam: I've got three outstanding merge proposals.  Could one of you please review them?
<vila> theLawless1: you should ask about that in #launchpad, some devs are in canada
<theLawless1> awesome thanks, didn't know they had their own channel
<vila> abentley: the most ugent seems to be the limbo one right ? The other two are targeted at 2.0 so I'd let jam at least says whether or not he want them in 2.0.1 or 2.0.2
<jam> vila, abentley: so 2.0.1 is cut, anything else will go to 2.0.2, that and I'm on vacation today
<vila> jam: sorry, enjoy your vacations !
<abentley> vila: All of them are addressing oopses, so we will cherrypick them when a fix is ready.
<vila> abentley: Do you have URLs for the bzr versions run on launchpad ?
<abentley> vila: lp is currently running unpatched 2.0.0
<vila> abentley: oh, and why are most (if not all) recent submissions contain conflicts in the NEWS file ?
<vila> abentley: ok, but you seem to suggest that you will run a customized version soon no ?
<abentley> vila: Right.
<abentley> vila: I guess the conflicts are because the 2.0 branch was updated after I branched from it.
<abentley> vila: The diffs used in code reviews are now "merge --preview" diffs, so they reflect what would happen if you merged, not what changes were made.
<vila> abentley: haaaaa
<vila> so there was a change, thanks for confirming
<vila> abentley: is limbo-renames a fix on top of ascii-preview ?
<abentley> vila: limbo-renames is a bug affecting bzr, but once ascii-preview is applied, it will stop affecting launchpad.
<gioele> What is the current status of nested trees? The wiki page has a (broken) link to a bundlebuggy merge proposal that I cannot see on launchpad
<abentley> gioele: I have submitted a new spec, but has not been approved yet.
<gioele> abentley: where is that available?
<abentley> gioele: The spec is here: https://code.edge.launchpad.net/~abentley/bzr/devnotes
<bialix> hello jam
<bialix> jam: can I ask about your workflow described http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html
<vila> bialix: he's in vacation today
<bialix> rats
<bialix> hi vila
<bialix> vila: you're also expert in annotations, right?
<vila> ask the next question and we'll see :D
<bialix> I have feature branch nt ready to merge to trunk
<vila> nt == not ?
<bialix> but I want to peek some work from it to trunk
<bialix> *not
<bialix> I think about using jam approach to merge and selective revert
<bialix> I'm not quite sure is it will work fine if I'll revert part of file
<vila> you can't revert part of the file, you can shelve part of the changes and revert the whole file and unshelve
<bialix> for example: https://code.launchpad.net/cfifo
<bialix> well, I can just delete half of file
<abentley> vila: Wouldn't it be easier to just do "merge -i" in the first place?
<bialix> because this file will be added by merge, I can't shelve part of it
<vila> abentley: I was about to mention that :)
<bialix> abentley: what is merge -i?
<vila> abentley: but this has landed ?
<bialix> bzr merge --usage mention -i in 2.0
<abentley> bialix: It's a selective merge that uses the same code as shelve.
<bialix> aha
<bialix> but my problem is that I want to selectively merge half of newly added file
<bialix> is it possible?
<bialix> I suspect -- it's not
<abentley> bialix: it's not something merge -i supports directly.
<bialix> IIUC it's related to feature request about splitting hunks, right?
<abentley> bialix: Sure.
<abentley> bialix: Your whole newly-added file is a single hunk.
<bialix> I understand
<abentley> bialix: But it should be simple enough to remove the parts of the file that you don't want in your editor, right?
<bialix> right
<bialix> my initial question was: does it preserve annotations for me?
<abentley> bialix: I don't know.  The lines will be introduced in two different commits, and I don't know which one bzr will prefer.
<bialix> I'd like to keep annotations if possible, though I won't worry too much if there is no direct way. I'm not quite understand jam approach, mostly because he don't have added files IIUC
<abentley> bialix: All the options we've discussed have the same chance of preserving annotations.
<bialix> OK, perhaps it's too much nosie for simple thing. I'll cherrypick and will see
<vila> annotations depend on the per-file graph, depending on  your *future* merges the annotations will reflect them, the question you ask, I think, is if two revisions seem to introduce the same lines which one will win ?
<bialix> something like that, yes
<bialix> jam approach is nice hack, though maybe I don't quite understand all tiny details how he did all these merges
<vila> this apply to cherry-picks too, in that case, we chose the first revid in the lexicographic order, there are plans (and already a hook) for people who want (for example) chose the oldest one instead
<bialix> ok
<bialix> interesting, how hard to follow content moves between 2 files?
<bialix> I mean to annotate
<vila> bialix: we miss GUID for lines
<bialix> :-)
<abentley> vila, bialix: It seems like it would quickly fan out to performing annotate across the whole source tree.
<vila> that's an important challenge yes
<bialix> I've heard git do something similar
<bialix> so at least it possible in theory
<abentley> bialix: I've heard of git doing it with merge.  Are you sure it does it with annotate?
<bialix> some people talking about annotating functions
<bialix> and they insist that git track moves of function body between files
<bialix> but I don't use git so I can't insist I understand it right
<abentley> bialix: It's an easier problem with merge than with annotate.
 * bialix trying jam hack
<bialix> why?
<abentley> bialix: Because typically you're only talking about three revisions.
<bialix> ah, I see
<abentley> bialix: So you only have to worry about the files modified in those revisions.
<bialix> ok
<abentley> (Actually, the files that *vary* among those revisions, not "are modified")
<bialix> jam wrote: Create a new branch from it (bzr branch --switch ../dogpile ../feature1), and remove all of the changes but the 'first step'. I personally did that with "bzr revert -r submit: file1 file2 file3" but left "file4" alone.
<bialix> what is -r submit:
<bialix> ?
<vila> bialix: =~= send --preview
<bialix> mmm?
<vila> err, what 'bzr send' outputs
<vila> bialix: try bzr diff -rsubmit:
<vila> in any feature branch it will show you your submission
<bialix> C:\work\MyCode\APMoney\ChainedFifo\nodes-for-trunk>bzr diff -r submit:
<bialix> Using parent branch file:///C:/work/MyCode/APMoney/ChainedFifo/nodes/
<bialix> <nothing more>
<vila> your branch has been merged
<bialix> nnope
<bialix> nope
<bialix> I did bzr branch nodes nodes-for-trunk
<bialix> cd nodes-for-trunk
<bialix> I'm trying to follow jam articla
<bialix> article
<vila> hmm, there should be some parent location to tweak
<bialix> but it seems he wrote it from memory, there is something missing
<vila> 'bzr info' should report nodes as parent when run in nodes-for-trunk
<bialix> so -r submit: means the branch where I want to merge? it makes sense
<vila> yes, and it fallback to parent
<vila> abentley: reviews done
<abentley> vila: Thank you very much.
<vila> abentley: if you can make new releases for bzrtools.... some RM will rejoice :)
<abentley> vila: Sure, I'll do that today.
<vila> abentley: thank you very much :D
<bialix> vila: IIUC you said half hour ago that latest revision used as annotation origin?
<bialix> so if I'll remove half of file and later merge entire file then full annotation will be used?
<vila> bialix: I don't remember that, annotations are built from the oldest revision and adding annotations for the newer revisions
<bialix> hmm. perhaps I should stop here
<vila> bialix: sounds correct
<treeform> hi guys
<treeform> the bzr says its Uploading data to master branch - Stage : Copying content
<treeform> while i see 0 network trafic
<treeform> how can i find out what is going on?
<beuno> treeform, take a peak in ~/.bzr.log
<djmitche> I'm maintainer for buildbot, and we have a problem of file descriptor consumption when buildbot interfaces with bzr -- http://buildbot.net/trac/ticket/621#comment:9
<treeform> beuno-lunch: i did but there is nothing conclusive there
<djmitche> does the bug look familiar?
<djmitche> the line -- bzrlib.trace.enable_default_logging()
<jml> djmitche, looking
<djmitche> tx
<jml> djmitche, I'd guess that there's an equivalent disable_* method that's not being called...
<djmitche> I think that it's being called within bzr library code, though -- I don't find that string in buildbot
<jml> ahh ok.
<djmitche> oh -- it's a really old version of bbot
<djmitche> hang on
<jml> well, I don't know much about buildbot's bzr integration
<djmitche> neither do I :(
<djmitche> ok, well, I'll ask the user where that line appears, and see if they can upgrade buildbot
<djmitche> thanks for looking
<djmitche> sorry I didn't spot the old version :)
<MTecknology> What permissions should I have on a bzr branch that a few people will access? 770?
<mathepic> Is it open source?
<MTecknology> there we go, o+x
<MTecknology> mathepic: is bzr open source?
<mathepic> Yes.
<MTecknology> ya
<mathepic> Then I don't see anything wrong with giving others read-access
<flacoste> hello bzr!
<flacoste> how do I fix the problem of things in ~/.bazaar/locations.conf overriding things in .bzr/branch.conf
<flacoste> especially the push location
<flacoste> i use puish --remember, but then get warning about stuff in locations.conf shadowing it
<flacoste> shouldn't it work the other way around? (branch.conf always taking precedence over locations.conf)
<mathepic> I would say thats a bug
<mathepic> Checking out the source code, one second
<jelmer> flacoste: I think locations.conf has precedence over branch.conf since you might not always have write access to the latter (i.e. in case of a remote read-only branch)
<jelmer> flacoste: older versions of Bazaar used to write to locations.conf in "bzr push --remember", newer versions write to branch.conf
<flacoste> right
<flacoste> and since locaitons.conf is the place for global configuration (based on patterns), the fact that it takes precedence of branch.conf is unfortunate :-/
<mathepic> I do not have a locations.conf
<jelmer> Perhaps "bzr push --remember" should update locations.conf if there is something set there already that matches the branch URL, rather than writing to branch.conf
<jelmer> That might get complex in some situations though..
<flacoste> i prefer that --remember writes to the branch
<flacoste> otherwise, locations.conf gets cluttered
<flacoste> i like the fact that locations.conf makes it easy to have a set of rules/default for development
<flacoste> that's especially useful for LP-based dev
<flacoste> i basically have <launchpad>/<project>/<branches> directory
<jelmer> ah, so you use branch.conf as a way to override the defaults set in locations.conf rather than the other way around.
<flacoste> and I can set the defaults for all of these projects / branches in locations.conf using very few stanzas
<flacoste> yes
<flacoste> because i can set multiple branches in locations.conf
<flacoste> and only one in branch.conf
<jelmer> That seems like something that would be nice to support. Perhaps we could have something similar to '<variable>:policy = norecurse' that specified the precedence.
<jelmer> The other alternative would be another configuration file similar to locations.conf that branch.conf would take precedence over.
<jelmer> I guess this is a good topic for the bzr UI discussion :-)
 * jelmer -> sleep
<kees> hi!  I'm trying to convert a subversion dump into bzr with svn2bzr, but I'm hitting these bugs: 407256  343922  any chance I can help test/motivate their fixing?  :)
<jam> mwhudson: when you wake up, I went ahead and tried out using 'dot' to format my graphs. I gave it a 'small' dump, which had ~350k nodes. It has peaked at 1.4GB of memory used, and has been running for 6 hours now (after pruning nodes with lots of edges).
<jam> Until that finishes 'dotviewer' won't work. Though I have my doubts about it working once I'm done... :)
<jam> thanks for the pointer to the 'large heap' paper, though
<jam> (when i tried with all edges, I just got an OOM error fairly early... :)
<jam> bug #407256
<ubottu> Launchpad bug 407256 in svn2bzr "branchcreator.py:720: ValueError: list.remove(x): x not in list" [Undecided,Confirmed] https://launchpad.net/bugs/407256
<mwhudson> jam: the reftracker thingy doesn't go via dot, it allows you to navigate around the object graph
<jam> bug #343922
<ubottu> Launchpad bug 343922 in svn2bzr "add svn:ignore to .bzrignore conversion" [Wishlist,Confirmed] https://launchpad.net/bugs/343922
<jam> kees: you might try an svn => git fast-import stream => bzr fast-import instead of svn2bzr. Just a thought
<jam> I don't think it would handle the ignore stuff for you
<jam> also, svn ignores are pretty crappy (non recursive), so I'm not sure that they translate well
<kees> jam: will that retain all the branch and tag histories?
<jam> kees: going through fast import should be able to retain branches and tags, though it depends more on the svn exporter
<jam> the data stream can cope with ti
<jam> it
<kees> jam: I had to use rsvndump -- I'm a bit worried it might have created problems.
<jam> mwhudson: 'reftracker' is for viewing live content, right?
<jam> I guess I could customize the "get_referents" and "get_referrers"
<jam> mwhudson: so I can do a 'live' reftracker, the only problem is that it all too often finds a node like '__builtins__' which is referenced by 100+ modules
<jam> and then the graph goes unreadable...
<jam> and that doesn't count the 500k StaticTuple references that will be in my intern structure...
<jam> it does seem interesting though
<jam> thanks for the pointer
<lifeless> hmm, I may need reftracker for that failed netbeans import ;P
<lifeless> I did get it into sqlite
<jam> lifeless: :). Question2 is whether you could build the backwards mapping from node to referrers
<jam> you probably could in sql at least
<jam> as you can build the links one-by-one
<Zand3r> Hi all... i'm new to bzr and playing with Explorer and qbzr-eclipse to evaluate for my purposes... I've noticed that neither Explorer not qbzr-eclipse report an error when you try to 'switch' branches whilst having uncommitted work. I'm looking for advice as to whether I should report this to each of those projects or is this something that should be reported to the core qbzr project?
<jam> Zand3r: that is intentional so that you can create a new branch, switch to it, and commit the new work to the target branch
<jam> anyway, I'm off for now, perhaps someone else can help explain
<Zand3r> jam: Thanks, perhaps I have overlooked something but it appeared that switching did not work prior to committing as you are going perhaps someone else might know.
<jam> Zand3r: I use "bzr branch ../bzr.dev ../new-bugfix --switch" all the time when I'm working on feature X and realize I should create a new branch for this bugfix
<Zand3r> Maybe the issue is specific to light checkouts which I am using... I should maybe have noted that in my original enquiry but I'm new to bzr as I said so am still learning what is relevant.
<jam> Zand3r: should still work
<Zand3r> jam: ok... thanks.. I will go back and re-trace my steps now I know it 'should' work and see what is going on.
<Zand3r> Thanks for the help
<dash> o/`
<dash> I am happy that bzr does reasonable things in cases where it would be very easy to do unreasonable things.
<dash> in particular, cherry-picking from trunk into a maintenance branch Just Works, even when done out of order.
#bzr 2009-10-17
<Peng_> mwhudson: Who's the copyright owner for your contributions to Loggerhead? You or Canonical?
<lifeless> Peng_: most if not all were done on canonical time
<baccenfutter> hey folks... I read through most of -> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html   but was wondering if there is a document saying in like 10-20 lines: first do bzr init, then bzr add, this is how to set acls, this is how to branch and merge, done
<baccenfutter> so basically, what I am looking for is a bzr in 60 seconds
<baccenfutter> nayone know if such doc is available anywhere
<baccenfutter> unfortunatly I can't expect all of my users to read through the entire users guide
<baccenfutter> surely I could write a 10-20 liner myself, but why should I if such a doc allready exists...?
<baccenfutter> plus, I'm not even sure, if I'm getting everything right
<wgrant> baccenfutter: http://doc.bazaar-vcs.org/latest/en/mini-tutorial/
<baccenfutter> wgrant: nice, thx
<baccenfutter> now all I need is acl and I am set
<mwhudson> Peng_: canonical
<Peng_> mwhudson: OK, thanks. I wanted to know because I was thinking of putting the GPL header in some of the files that lack it. (But I'm probably not gonna do much of it.)
<Peng_> (IANAL, so I'm kind of afraid of getting it wrong.)
<baccenfutter> I could use some advice on setting up a working centralized bzr repo. I'm member of a local computer club with about 300 members. each member has a user acc on our shell server. Inside each $HOME there is a /public_html/ which is linked to our apache2. Now what I want to achieve is to have my very own bzr repo which is writeable only to certain users, while it is readable to 'world'. I can't find anything about acls though. If I place the rep
<baccenfutter> Or am I getting this completly wrong?!
<mathepic> Yay 2.0.1 Ubuntu Package is out now. Upgrading.
<baccenfutter> anybody...?
<Peng_> baccenfutter: Eh. You got cut off at "If I place the rep"
<baccenfutter> the repo in $HOME, it is only acessable through ssh if I put it into $HOME/public_html/ it is writeable to 'world'. Now how would I have to go about?
<Peng_> ...public_html is world-writable?
<baccenfutter> In svn I had acls to take care of this
<baccenfutter> Peng_: no, but it is world accessable its like you would place your repo in /var/www/
<Peng_> Sorry, but I really don't have experience with this. Launchpad does it using anonymous HTTP access + a custom SSH server.
<baccenfutter> so I see it crrectly there is no such thing like acl
<baccenfutter> ?
<Peng_> baccenfutter: Maybe the contrib.bzr_access script would help?
<Peng_> Err, contrib/bzr_access.
<baccenfutter> I'll chack that out, thx
<Peng_> Like I said, I don't have experience with this stuff.
<baccenfutter> Peng_: where would I find that?
<Peng_> baccenfutter: contrib/bzr_access? In the source tree.
<Peng_> baccenfutter: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/contrib/bzr_access if you don't have it handy
<nyu> hi
<nyu> I branched from svn trunk, then made a few commits.  now I want to push just one of them, and keep the rest in my local branch.  I checked the docs but don't know where to look;  anyone can point me in the right direction?
<Peng_> nyu: You can push all revisions up to and including revision N with "bzr push -r N".
<nyu> Peng_: and if I wanted to push only revision N ?
<Peng_> nyu: You want to push revision 123 but not 122? Not pisslb.e
<Peng_> Wow, that sentence fell apart. "possible."
<nyu> ah, maybe I'm not using the right approach
<Peng_> Well, technically, it's more or less possible with history editing from the bzr-rewrite plugin, but mostly you shouldn't do that.
<nyu> on one hand, I like the "patch stack" model in which I stack lots of patches in, but I also like being able to stuff unrelated patches in my repository
<nyu> as a replacement for .diff files liing around in my filesystem
<Peng_> I guess you should create a branch for each one.
<nyu> is there no easier way?
<Peng_> Eh. I don't think so.
<nyu> ok, I guess I can live with adding more branches
<nyu> what if I want to modify one of my commits before pushing it?
<mathepic> Commit again?
<nyu> you mean on top?
<nyu> but then I'd be pushing the broken commit + the fix, what if I'd rather only push the fixed version?
<nyu> e.g. imagine I send a patch for review and commit it locally, then someone notices a typo
<nyu> how can I commit the right thing in trunk?
<Peng_> In Bazaar, you typically just create a second revision fixing the typo.
<nyu> when you push a set of commits, they become a single commit in svn, or multiple ones?
<Peng_> Multiple
<Peng_> If you were using pure Bazaar instead of svn, and merged them into the target branch, the log view would only show the merge revision by default.
<nyu> not an option right now
<nyu> the project trunk is on svn.  some people use git to manage their own patchsets
<nyu> and I'd like to use bzr to do the same
<nyu> my workflow is not very organized;  I have a directory full of patches that I move back and forth manually
<Peng_> Git might work better for you.
<nyu> oh, c'mon don't tell me this :-)
<jszakmeister> nyu: I haven't tried myself, but I hear bzr-pipeline is good for managing patchsets
<jszakmeister> or loom
<nyu> what if I manually extract a set of commits, then commit them into svn, then bzr pull?
<Peng_> Oh, I forgot about pipeline.
<Peng_> nyu: bzr-svn won't see them as the same revisions, but you can do that, yes.
<nyu> so what will bzr believe after pull?
<nyu> will it still think it has diverged from trunk?
<Peng_> nyu: Yeah. You can use "pull --overwrite" tohough
<Peng_> trhough. though. There, got it.
<nyu> but that gets rid of all my commits, right?
<nyu> not just the ones that were merged
<jszakmeister> pipeline manages your patches as branches.  Once it's merged, you just drop it.
<jszakmeister> (from what I understand.  I haven't used it myself, but it's at the top of my list of things to learn)
<Peng_> nyu: Yes, sorry.
<mzz> I need to figure out which, if any, of bzr-pipeline and loom are useful to me
<mzz> iiuc there's some overlap between the two
#bzr 2009-10-18
<RenatoSilva> Is --fixes info displayed only in bzr qlog? Bzr log -v is not working.
<bob2> and in lp
<bob2> don't think the bzr ui itself exploses it
<RenatoSilva> it should
<RenatoSilva> imo
<davidstrauss> Is there a simple way to set the public branch from the command line?
<davidstrauss> I mean *parent* branch.
<dash> bzr pull --remember
<treeform> hey all is there a way to make bzr ignore ownership and permission changes?
<Peng_> It does ignore ownership, and the only permission it tracks is the exec bit. But if you want to ignore that, I don't know how.
<treeform> oh
<treeform> hmm
<treeform> it seem to go away after i reverted
<mdke> does anyone know the cause of this - http://paste.ubuntu.com/296071/ - and if I can work around it?
<mdke> I'm rather stuck otherwise :(
<jelmer> mdke: does bzr check pass on that repository?
<mdke> jelmer: running now
<mdke> jelmer: it crashes too, with what looks like a similar error message
<mdke> jelmer: I guess I could get the branch again without a repository, and then copy my changes across wholesale
<jelmer> mdke: yeah, that might work - it looks like corruption of some sort in the repository you're committing too
<jelmer> s/too/to
<jelmer> mdke: Please also file a bug report
<mdke> jelmer: ok, noted thanks
<mdke> jelmer: there seems to be a problem with the branch on Launchpad too, I can't branch it - http://paste.ubuntu.com/296099/
<LaserJock> is BzrBranch5 and old format?
<LaserJock> I'm getting "bzr: ERROR: Tags not supported by BzrBranch5" when I bzr pull from a branch
<dash> what does 'bzr info' say?
<dash> about your branch directory
<LaserJock> Repository tree (format: unnamed)
<dash> Hmm
<LaserJock> ah, if I go up into the shared directory I get:
<LaserJock> Shared repository with trees (format: pack-0.92)
<dash> yes, that is quite old. :)
<LaserJock> is the ERROR about tags important?
<dash> not necessarily
<dash> for best results you want your local repository to be in the same format as the remote one though, I think
<fullermd> Yes, Branch5 is pre-tags.
<fullermd> The error is important if you care about missing the tags   :p
<dash> yes.
<fullermd> (and Branch5 is ooold too; you surely don't really want it)
<dash> LaserJock: ideally, both the remote and the local repos would use the default format for bzr 2.0
<fullermd> Certainly no reason to have it if your repo is in pack format; Branch6 is the default for pack-0.92.
<LaserJock> well, it's not my repo
<LaserJock> I just wondered if the tag error would cause problems
<dash> if you want to use tags, yes.
<fullermd> Generally, you'd only see that error on the target branch (since it's the only one that might be considered writable), so if you're getting it on pull, it's telling you _your_ branch is Branch5.
<fullermd> (and presumably the far side is Branch6+_
<dash> LaserJock: one last check
<dash> LaserJock: what's "bzr info <remote url>" say? (where <remote url> is the address of the branch you are pulling from)
<LaserJock> dash: Standalone branch (format: unnamed)
<dash> Heh
<dash> well that isn't very informative, is it. :)
<fullermd> Try -v.
<dash> oh i forgot about that
<dash> LaserJock: so yeah, maybe 'bzr info -v' will help
<fullermd> As fate would have it, 'central' branches are often going to be 'unnamed', since they often won't have WT's...
<LaserJock> what am I looking for in there, it's got stats
<dash> specifically under 'repository'
<fullermd> The several lines of 'format's.
<LaserJock> control: bzr remote bzrdir
<LaserJock> branch: Remote BZR Branch
<LaserJock> repository: bzr remote repository
<fullermd> Gruh.
<dash> I forgot about that.
<fullermd> Stuff a nosmart+ on the start of the URL.
<dash> LaserJock: I hardly know more about this than you, apparently :)
<LaserJock> control: Meta directory format 1
<dash> fullermd: oh cool, I didn't know about that
<LaserJock> branch: Branch format 6
<LaserJock> repository: Packs containing knits without subtree support
<dash> there we go.
<dash> still old, but not as old.
<fullermd> Yeah, so that would be pack-0.92.
<LaserJock> so I'm at Branch5 and remote is at Branch6?
<fullermd> Yah.
<fullermd> You should just move your local stuff to pack-0.92.
<dash> LaserJock: so doing "bzr upgrade --pack-0.92" will make that error go away
<fullermd> Actually, I'd move it to 1.9; going between those two is cheap&easy, and it'll be a bit smoother for you locally.
<dash> ah.
<dash> so that would be "bzr upgrade --1.9"
<LaserJock> k, thanks
<Mez> hey people. Just a couple of things.
<Mez> I think that you probably need to update the messages for upgrading stuff. I just tried to commit to a bound branch, and it seems I couldn't (because I needed to upgrade the repo on bazaar.lp.net)
<Mez> also, with bzr-gtk - is the nautilus stuff meant to work ? cause I'm not seeing any embelems in nautilus
<mdke> argh. The different formats of branches are a never ending source of problems :(
<mdke> I checked out a branch which is 2a format, and I can't push it to launchpad as a new branch, because the "default stacking branch" is a different format
<mdke> any ideas for working around that?
<mdke> specifically the error message is http://paste.ubuntu.com/296256/
<davidstrauss> Is there a Bazaar shell?
<luks> depends on what do you think by 'bazaar shell'
<luks> er, s/think/mean
<davidstrauss> luks: A shell you can run bzr commands from without the "bzr" prefix.
<luks> `bzr shell` from bzrtools
<luks> (the other alternative was something like git-shell, which is used for restricted ssh, and for which bzr has no equivalent)
<SamB_XP_> luks: though it would be fairly trivial to make one, wouldn't it be?
<davidstrauss> luks: bzr shell was exactly what i wanted
<luks> I don't know, never needed it
 * SamB_XP_ wonders why the configures for Cygwin's setup.exe are investigating fortran compilers ...
<igc> morning
<igc> hi lifeless
<lifeless> hi igc
<jelmer> hi igc, lifeless
<igc> hi jelmer
<igc> jelmer: thanks for the svn-fast-import stuff - I'll test it this morning
<lifeless> hi jelmer
#bzr 2010-10-18
<peitschie> jelmer: thats what I was fearing would be the case... it seemed like a very complex solution to solve!
<peitschie> jelmer: do you have a goal timeframe in mind (e.g., days/weeks/months/years?)
<poolie> jelmer: i'd be interested in your review of https://code.edge.launchpad.net/~mbp/bzr/deprecation/+merge/38647 if you get a chance
<peitschie> jelmer: i'm interested primarily to see which direction "the majority" of our devs end up going.  A battle-hardened few find the "new" way of working more straightforward and easier than svn branches still, but a lot of the devs are a little on the fence not being so comfortable away from the tortiseXXX guis
<poolie> spiv will be away sick today, in case anyone was hoping to talk to him
<jelmer> peitschie: It really depends on how we decide to fix it. My guess it will be weeks at least.
<jelmer> poolie: Sure, I'll have a look.
<poolie> tell me if you think it's actually cleaner
<peitschie> jelmer: ok.  it is understandable :).  we'll limp along and keep waiting then!
<jelmer> hmm, I think I might also have fixed the hdb_asn1.h issue
 * jelmer gets bit by his middle mouse button again
<mgz> will the universe hate me if I change the duplicates of some AttributeError bugs are for the third time...
<mgz> +grammar
<mgz> in my defense, this was very confusing.
<jelmer> mgz: I think we'll be ok :-)
<jelmer> poolie: I've followed up to your MP.
<mgz> wait, am I even more of a total idiot?
<lifeless> yes
<mgz> poolie's mp is exactly the same thing?
<lifeless> no, wait, whats the question
<mgz> but done properly?
 * mgz branches it too see if it incidentally fixes the same bug
<mgz> didn't even register it was about smart_add as well, thought it'd just be... deprecating some things
<mgz> phew. still fails. my change may not merge now, but at least it wasn't completely pointless.
<mgz> bed before I get myself in any more of a tizz.
<poolie> mgz, seriously?
<poolie> mgz, it was part of a saga towards fixing all the add bugs (and introducing shiny new ones :-) but it doesn't specifically fix anything
<poolie> except by pure luck
<poolie> thanks jelmer
<adamdv> I'm using bzr+ssh, and am attempting to use it on windows. Only, the ssh server uses public key authentication. How can I get bzr to recognize a public key to login to the server with?
<poolie> AdamDV: see http://wiki.bazaar.canonical.com/Bzr_and_SSH
<poolie> and if that's incomplete/unclear, please ask
<AdamDV> Nope, makes sense.
<AdamDV> bzr always amazes me at the simplicity :)
<poolie> we should move/copy that to the user manual
<poolie> :)
<AdamDV> You should :)
<poolie> AdamDV: bug 662448
<ubot5> Launchpad bug 662448 in Bazaar "docs should describe how to set up ssh keys (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/662448
<poolie> you could do it if you want :)
<AdamDV> How do I edit the docs?
<poolie> there's a document about that too :) ...
<poolie> http://doc.bazaar.canonical.com/bzr.dev/developers/contribution-quickstart.html
<poolie> and http://wiki.bazaar.canonical.com/ContributingToTheDocs
<AdamDV> Will do :)
<poolie>  the best documenters are those who've just worked out how to do the thing they're describing
<poolie> they're not so prone to assuming things are obvious
<AdamDV> Mhm :)
<AdamDV> So, let me get this straight
<AdamDV> I have to use bzr to checkout the bzr documentation?
<AdamDV> and fix it, and then recommit the bzr doc with bzr?
<AdamDV> Irony..
<AdamDV> poolie: Okay, so how do I start? I have never used launchpad before :P
<poolie> hm, so you need an account?
<poolie> https://help.launchpad.net/YourAccount/NewAccount
<AdamDV> REgistered
<AdamDV> And I've assigned it to me
<poolie> ok so
<poolie> bzr init-repo ~/bzr
<AdamDV> (I've used launchpad before, never actually helped with anythnig)
<poolie> oh ok
<AdamDV> alright, ran that
<poolie> actually the quickstart guide should tell you how to make a branch...
<AdamDV> reading..
<AdamDV> Lotsa code to check out..
<AdamDV> poolie: Shall I put this new documentation in user-guide?
<poolie> that'd be good
<MeaCulpa> Hi! I have trouble using bzr windows stand-alone binary on ssh inplemention... bzr keeps looking for /home/%CURRENTUSER%/.bzr directory, which is useless in Windows
<MeaCulpa> I need bzr to look after %DOCUMENTROOT%\%CURRENTUSER%\.ssh
<MeaCulpa> Perhaps there is some messing on ssh? I have putty with pegeant, my non-ssh branch works okay
<poolie> MeaCulpa: it's looking for the ssh key in .bzR?
<poolie> .bzr
<poolie> adam was just updating the docs about that
<MeaCulpa> I've been using bzr for years, but only the python version, My desktop have py2.7 now so I wanna try bzr standalone
<MeaCulpa> I guess pure python ssh is long-time okay
<MeaCulpa> poolie: it is looking on .ssh under /home/user thing, tis unix style
<poolie> oh, i see
<poolie> that is odd
<MeaCulpa> maybe it is because my windows is messed up with opensource tools... :(
<poolie> we're using os.path.expanduser
<MeaCulpa> poolie: then this shall not be a problem... strange
<poolie> MeaCulpa: what are %HOME% and %USERPROFILE% set to?
<poolie> maybe the unix tools changed them
<MeaCulpa> userprofile is set under documentroot/user
<MeaCulpa> and I don't have %HOME%
<MeaCulpa> maybe... there are many cygwin hacks hidden somewhere in my tools
 * MeaCulpa hate cygwin
<adamdv> poolie: Should I use rest format when writing doc?
<adamdv> Or can I just format it as a txt file?
<poolie> adamdv: ideally, rest
<poolie> but plain txt is pretty close
<adamdv> Alright.
<adamdv> I can use rest, I think.
<poolie> we can fix any markup bugs
<adamdv> Its going to be alot like the web equivelent, but I'll throw in a few tidbits from my personal bzr+ssh experience :P
<MeaCulpa> poolie: hand-tuned bzr from source proved to be well-isolated and safely pythonic in my windows box, thank you for your concern!
<adamdv> poolie: Alright, I checked out, locally copied, added the file and wrote it, locally committed, and now am attempting to 'bzr push'
<adamdv> I get: bzr: ERROR: Not a branch: "/home/adam/bzr/.bzr/branch/": location is a repository.
<poolie> what command?
<adamdv> bzr push
<poolie> adamdv: i think you need to cd into the branch directory
<poolie> and probably also specify a location on lp to push ot
<adamdv> according to the quickContribGuide, bzr push will work
<poolie> like 'bzr push lp:~adamdv/bzr/662448-ssh-docs'
<adamdv> :|
<adamdv> Gotta register my ssh keys
<adamdv> pushing..
<adamdv> Done. So, uhh, now what?
<adamdv> I'm guessing my change has to be approved?
<poolie> AdamDV: normally you'd click then 'propose for merging' or type 'lp propose-merge'
<AdamDV> Clicking.
<AdamDV> Merge proposed :)
<AdamDV> https://code.launchpad.net/~adam-delvecchio/bzr/662448-sshkey-doc/+merge/38682 (I believe thats the link?)
 * poolie looks
 * adamdv crosses fingers
<poolie> i'm reading it now
<adamdv> k
<poolie> ok, replied
<poolie> let's see what maritza says too
<AdamDV2> Internet sucks at my house :/
<AdamDV2> poolie: I'm going to fix it, and probably make it more easily readable as well.
<poolie> thanks
<cody-somerville> lol, bzr-stats's --show-class argument sure makes bzr stats have an appetite for memory, lol; its at over 1.5G and isn't even done with the first contributor yet
<vila> hi all !
<peitschie> hi vila :)
<poolie> hi there vila
<vila> poolie: hey !
<poolie> cody-somerville: ouch; on what tree?
<jelmer> moinmoin
<vila> jelmer: \o_
<vila> poolie: you're at UDS with jam next week right ?
<poolie> correct
<vila> poolie: so maybe one of you should switch with spiv as PP this week ?
<jelmer_> thumper: The problem with the mesa branch appears to be caused by the fact that it's still in the 1.9 format rather than 2a.
<thumper> jelmer_: I had the 1.9 one blown away though
<thumper> jelmer_: the one that is importing is 2a
<thumper> at least I thought as much
<thumper> I'll get spm to check tomorrow
<jelmer_> thumper: The web page claims it's 1.9
<thumper> jelmer_: that is because the branch won't get mirrored until it is fully imported
 * thumper afk
<jelmer_> thumper: ah, ok :-(
<poolie> good idea; maybe i will because spiv was sick today
<poolie> on phone
<vila> mgz: could you send an mp with your hack_transport branch cleaned if needed (but really if needed) waiting for the hook one to get fully discussed ?
<vila> mgz: it's a shame to still get leak related failures and block the osx slave when we fully understand the cause and have a available fix even if it's not perfect
<vila> mgz: *AND* a better one worked on...
<ibxth> hello, sorry for my english, how can i export only diff files between two revision?
<fax8> hi there, just installed bzr on 8.04 from https://launchpad.net/~bzr/+archive/ppa .. but I got bzr 2.2 .. shouldn't it be 2.1?
<GaryvdM> ibxth: bzr diff -r x..y
<GaryvdM> fax8: No -  2.2 is now the stable release
<ibxth> GaryvdM, it give me a difference between revision. i need the files that have changed
<GaryvdM> ibxth:  bzr status -r x..y
<GaryvdM> ibxth then bzr cat FILE -r y
<ibxth> but i need ALL the files than have changed between two revision
<GaryvdM> ibxth: What are you going to do with the files?
<ibxth> Upload to server.
<GaryvdM> ibxth: Do you know that the bzr-upload plugin does this for you
<ibxth> GaryvdM, thanks
<ibxth> I did not know about this plugin
<fax8> GaryvdM: thanks, than this has to be updated http://wiki.bazaar.canonical.com/DistroDownloads#Ubuntu
<GaryvdM> fax8: ok
<fax8> GaryvdM: saw the page updated, thanks!
<fax8> GaryvdM: I would say that the two lines:
<fax8> Stable version: 	2.2.1
<fax8> Test version: 	2.3b1
<fax8> under the bazaar logo on the bazaar website homepage need more visibility.. I spent the some time trying to find what was the latest stable version
<GaryvdM> fax8: That would mean that we would have to update that page a lot more often
<Glenjamin> Could these things be pulled from a central source somewhere?
<GaryvdM> I see the 2.2.1, and 2.3b2 announced on http://bazaar.canonical.com/en/
<GaryvdM> under the Core News heading.
<fax8> nope. I mean this http://img26.imageshack.us/img26/8591/bzrhomepage.jpg
<GaryvdM> fax8: Oh - I understand now. I don
<GaryvdM> I don't know who would be able to fix that. poolie?
<vila> GaryvdM: should be in bzr-website
<Kaamos> hi
<Kaamos> can someone answer a question?
<jelmer> Kaamos: Depends on the question. :-)
<jelmer> Kaamos: Just ask the question, if there's somebody around who knows the answer or can help they'll speak up.
<Kaamos> =), i want to know how the bazaar keeps track of the changes made to the files
<jelmer> Kaamos: how does it store the deltas between in the repository you mean?
<Kaamos> im not quite familiar with those tools, im writing a college paper about those SCM tools comparing to the caracterisitics of the ISO 140102
<Kaamos> and one of these caracterisitics is keep track of the changes
<Kaamos> by the example, it means to know who changed the fyle, what change was made, and when it was made
<GaryvdM> Kaamos: I would recommend this as a good first read: http://www.ericsink.com/scm/scm_repositories.html
<GaryvdM> bzr is different in some details, but it will give you a good picture.
<Kaamos> thank you gary i will look it right now
<mgz> vila: will do.
<vila> mgz: great !
<vila> mgz: by the way, shouldn't you land https://code.edge.launchpad.net/~gz/bzr/require_unicode_committer_614593/+merge/38334 ?
<mgz> possibly. was wondering if jam would save me from my fretting with more sage advice.
<vila> mgz: k, request a review then, it's more likely to get  you an answer for an mp already approved ;)
<mgz> that might be wise. was just going to try and glomp him here.
<mgz> okay, put a mp up with the hack vila, and sent a message to the list.
<Kaamos> how does bazaar handles the history of a file?
<fullermd> Gently?  :)
<Kaamos> =D
<Kaamos> for what i see, it is using the diff command
<Kaamos> but i dont know how it works
<Kaamos> if he displays who have done the change
<roryy> Kaamos: what do you want to do?  maybe you want "bzr log" ?
<Kaamos> yeah something like that
<Kaamos> What was changed
<Kaamos> When the change was made
<Kaamos> Who did it
<Kaamos> Why (the comment entered at checkin time)
<Glenjamin> that bzr log, yeah
<Kaamos> bzr log provides all this informations?
<roryy> yip; take a look at "bzr help log"
<Kaamos> i will tkz guys
<GaryvdM> Kaamos: Also bzr annotate FILE
<roryy> i've added 'missing' to 'bzr status' for bug 134168; i've updated BranchStatus.test_tree_status_specific_files -- what other tests should i change?
<ubot5> Launchpad bug 134168 in Bazaar "status does not show missing files that are newly added (affected: 0, heat: 3)" [Medium,Confirmed] https://launchpad.net/bugs/134168
<Glenjamin> if all the tests pass, and whatever you added is tested by that - then in theory that should be enough.
<roryy> ok.  there's a whole mishmash of testing non-existent file cases
<jelmer> maxb: Will you have a chance to follow up on my comments to your subvertpy branch?
<jelmer> maxb: ping
<pinguin> hi how to ignore a single collom of a file?
<txdv> hello guys
<txdv> what is a revision? is it a commit in the mainline?
<luks> it's a state of the source code tree
<txdv> is it possible to calculate the revisio number just based on the commit tree?
<luks> it's a graph, not a tree
<luks> but yes, that's how bzr revision numbers are calculated
<txdv> just going down the mainline and adding the commit?S
<luks> oh, but perhaps you meant a different tree
<luks> for the mainline yes
<luks> it get's complicated with merges
<txdv> i'm using git and i want to calculate that pesky bzr revision number
<luks> hm?
<txdv> i converted a bzr repo to a git repo
<txdv> but even excluding the merges will generate revnumber which is toobig
<txdv> to be true
<luks> well, I'm not sure what are you really asking
<txdv> i want to know how the revision number is generated
<luks> http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/RevNumbering
<txdv> omg
<txdv> your google skills are better
<txdv> then mine
<txdv> thanks
<luks> I didn't have to google :)
<txdv> yeah you used your ninja skillz
<fullermd> The author is a genius.  Handsome, too.
<txdv> what are you talking about?
<fullermd> Oh, just passing the time   :)
<roryy> and humble
<txdv> If the either the author or you are not female please do it somehow different xD
<fullermd> I heard a rumor he once saved a bus full of school children from certain death in a volcano eruption.  Might just be a rumor though.
<txdv> who did that?
<txdv> Superman?
<fullermd> Nah, Superman just saved some chick from an earthquake as I recall.  He thinks so small...
<pinguin> hi how to ignore a single collom of a file?
<GaryvdM> fullermd: :-p
<GaryvdM> pinguin: what is a collom? column maybe?
<pinguin> yes
<GaryvdM> pinguin: Maybe content views may help.
<GaryvdM> pinguin: What type of file is it?
<pinguin> python
<pinguin> GaryvdM: have you a link to content views doku?
<GaryvdM> pinguin: Why? What column? (/me didnot know the python had columns)
<GaryvdM> pinguin: I'm trying to find what I was thinking about
<fullermd> Well, it's hard to do much python without using Coulombs...
<pinguin> i want to exclude a single line from a commit
<GaryvdM> pinguin: I was thinking about content filters ttp://doc.bazaar.canonical.com/latest/en/user-reference/content-filters-help.html
<GaryvdM> pinguin: But you probably  just want to shelve  + commit + unshelve
<pinguin> for example we have a password in our file and that should not be under version control
<pinguin> hmmm
<GaryvdM> Oh  - The best thing is to probably extract it a config file that does not get versioned.
<pinguin> no we need the file under version control (only one line ignored)
<txdv> fullermd: he thinks with his penis
<txdv> :>
<txdv> but even so he should have saved a bus full of cheerleaders
<peitschie1> mornin all :)
<pattern> "bzr launchpad-login foo" will tell bzr to set my launchpad username to "foo"
<pattern> how can i unset it or set it to nothing?
<james_w> you have to edit the config file as far as I know
<pattern> which config file?
<mwhudson> ~/.bazaar/bazaar.conf
<poolie> mkanat, hi?
<mkanat> Hey poolie. :-)
<pattern> mwhudson: thank you
<dOxxx> evnin'
<peitschie> hi dOxxx
#bzr 2010-10-19
<spiv> Good morning.
<peitschie> mornin spiv
<poolie> jelmer, hi, still awake?
<poolie> hi spiv
<jelmer> poolie: Hi!
<jelmer> poolie: Apparently :-)
<spiv> Ooh, I'm patch pilot this week.
<spiv> poolie: perhaps you should review https://code.edge.launchpad.net/~gz/bzr/smart_add_former_file_dir_251864/+merge/38676 ?  I think you may have touched that code or near it with your smart_add deprecation patch.
<poolie> spiv, actually i was going to propose swapping with you because i'll be away for the next two
<poolie> i have, i'd be happy
<poolie> to
<poolie> (otp)
<spiv> So you'd pp this week, and I'd pp the week of Nov 1?  I'm happy to do that.
<dOxxx> spiv, pooile: y'all are just afraid to review my monster mergetools mp ;)
<dOxxx> poolie^
<spiv> Heh
<spiv> dOxxx: pfft, I had patch with a 26000 line diff last week ;)
<dOxxx> I don't blame you. Took me 3 months.
<dOxxx> Automated refactorings don't count! :)
<poolie> :)
<poolie> spiv of course you can still do reviews this week
<poolie> spiv, are you all better? or a bit better?
<spiv> poolie: I'm mostly better.
<spiv> Well enough to continue looking at https://bugs.edge.launchpad.net/udd/+bug/653307 at least :)
<ubot5> Launchpad bug 653307 in Ubuntu Distributed Development "Import fails with missing referenced chk root keys (affected: 1, heat: 8)" [Critical,In progress]
<poolie> want a quick catchup call or pm (depending on the state of your voice)?
<zamabe> so. debian and bzr
<zamabe> i hear they don't mix
<zamabe> and i can't exactly download it
<poolie> what is 'it'?
<spiv> poolie: a catch up would be good, but maybe just after lunch as I'm in the middle of digging through a udd/bzr-builddeb maze right now
<poolie> ok, thanks
<zamabe> poolie, i've recently decided to download the tarball and build it
<zamabe> what i mean by 'it' is this
<zamabe> http://wiki.bazaar.canonical.com/DistroDownloads#Debian
<poolie> zamabe, you just need 'sudo apt-get install bzr' or the equivalent
<jbowtie> FryGuy-, thanks for those branches; I've already merged one and will create patches based on the other two soon.
<jbowtie> FryGuy-: I was also surprised to see that it worked with 2010 with such a small change. They actually did pretty well with backwards compatibility.
<jbowtie> FryGuy-: unfortunately I can't use the branch directly, need to put in conditional version checks.  ;)
<jbowtie> poolie: My "chopping up the file" proposal was based on what ZFS, Dropbox, et al do for versioning large files. Memory usage was a side effect.
<jbowtie> poolie: Do you know of any better algorithms I should be looking at, maybe in the literature somewhere?
<poolie> i think the basic idea of chopping it up based on a rolling checksum is not too bad
<lifeless> it might be nice to just be deterministic
<lifeless> every 128K for instance
<lifeless> so that we don't have to /diff/ to do it.
<lifeless> in fact, thats probably a must-do, not a might-do.
<jbowtie> lifeless: Should that apply to large text files as well or just binaries.
<jbowtie> ?
<poolie> well, rolling checksums are deterministic
<poolie> spiv, can you reproduce that bug in bzr alone?
<lifeless> poolie: they are, but using them to find the boundary between and old and new version means that partial branches cannot reproduce the result
<lifeless> poolie: which is a significant concern
<poolie> maybe we're talking about different things?
<poolie> i understood jbowtie to be considering using them to chop single large files
<jbowtie> Yes, trying to find a way to solve some of the issues around large binaries.
<lifeless> that would be fine, I understood him to be using delta logic based on that
<lifeless> via the reference to zfs and dropbox
<spiv> poolie: no, at least not without intentionally driving the bzrlib APIs to generate two inventories with the same ID but different details.
<poolie> jbowtie: so are you saying that dropbox chop the files on boundaries and then apply librsync?
<poolie> i know they at least used to use librsync
<jbowtie> poolie: AFAICT yes, that lets them do data deduplication as well as versioning.
<poolie> mm
<poolie> jbowtie: i'm wondering: in which layer should this be done?
<poolie> should the repository present the abstraction that you're just dealing with files, some of which may be extremely large?
<poolie> or do you want to expose it at a higher level?
<poolie> to me it seems pretty clear it should be behind that abstraction if at all possible
<poolie> so then we do need to make sure all those interfaces work with iterators of bytes (or some similar convention)
<poolie> otherwise we'll just propagate this problem
<jbowtie> poolie: I'd like to keep it confined to the repository if possible, but I think I need to spend some time trying to implement it to come up with something workable.
<jbowtie> poolie: Figured I'd put together something experimental this week if I can find the free time.
<jbowtie> Speaking of which I have to go offline while I travel home; pick up the conversation on the mailing list if necessary.
<poolie> i don't really understand the relevance of the xemacs startup to hooks...
<poolie> spiv: now?
<spiv> poolie: now is good
* poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | Release Manager: vila | 2.3b2 is officially released, test it  ! | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/
<vila> hi all !
<spm> yo vila!
<vila> spm: hey !
<vila> poolie, spiv: Hmm, did I miss something ? jam and poolie are at UDS next week, so PP should be either me or spiv for week 43 (starting 25 oct)
<poolie> that is what i meant to make it
<poolie> ... and i got it wrong
<poolie> i'll fix it
<vila> poolie: done
<vila> was doing it in parallel but wanted to give a heads-up
<lifeless> spiv: you should get a twitter account ;)
<poolie> vila, did you get to talk to charline?
<vila> poolie: no, she never ponged, I will try again today
<vila> poolie: hmm, she's not online currently though...
<vila> poolie: I will mail her
<poolie> ah, she might have already gone to the US
<poolie> that would be good
<vila> argh, goodbye same-TZ-ness
<poolie> i thought she wasn't leaving til later this week
<vila> and I can't find here on the UDS-N attendees :-? >-/
<poolie> vila, ok, i sent her a mail
<poolie> you could call later today?
<vila> poolie: sure
<poolie> what a day
<poolie> i'm going to sign off, good night
<vila> poolie: night !
<thevibe> morning anyone
<thevibe> does anyone of you have a post_commit update hook/plugin ?
<lifeless> what do you mean?
<thevibe> I mean if you have an already running post_commit hook/plugin that does an update on the server
<thevibe> lifeless - I'm just at the beginning with python so I don't want to jump over my level with a plugin that needs to serve a development environment
<lifeless> oh, I think someone may have written one
<lifeless> check the plugins page?
<thevibe> lifeless, I checked google up to page xx and I can't find one
<lifeless> hmm
<thevibe> honestly the problem is that I can't wait till I get a ggod grip of python for this
<thevibe> I need it and that's why I am asking for help
<lifeless> I'd ask on the list
<lifeless> more people see questions there
<thevibe> I built the development environment in a semi-decentralized manner
<thevibe> and because is the developement server and we have a routine in place
<thevibe> an update run after commit will display everything in the broser straight away
<thevibe> which is what I want
<thevibe> I've sent my question there but not very successful
<thevibe> because of that I said I will come here maybe someone has one and maybe will be willing to share it
<thevibe> the other problem is that I need to put everything in place to close the gates for svn fans asap
<thevibe> :)
<GaryvdM> thevibe: Not sure if I understand you correctly, but maybe the bzr-upload plugin will do what you want.
<thevibe> bzr-upload will be used to deploy things but I don't think it does what I want
<thevibe> I just want an equivalent of an svn post_commit hook that runs an update on the server after any commit
<thevibe> it should be in the same category with hooks that send an email after commit or something similar
<thevibe> to describe the structure this is how it looks
<thevibe> we init a project on the server
<GaryvdM> thevibe: What does "runs an update" entail?
<thevibe> the developer will checkout a branch which is bound to the main one
<thevibe> after any chaneg the developer will commit the changes to the main repo
<thevibe> after that cmmit I need a hook that will execute a bzr update
<thevibe> so I can see the changes in the browser straight away
<thevibe> is being used for web dev mostly
<thevibe> GaryvdM, after a commit I need a hook that will execute bzr update on the server
<thevibe> it is something like push-and-update but I need commit-and-update
<GaryvdM> thevibe: Ok - bzr update needs to be run on the server. Do the devs all have ssh access?
<thevibe> everything is run under ssh
<thevibe> bzr+ssh
<thevibe> so yes they have as the server is inside
<thevibe> but I need an automated process
<thevibe> I don't want them to login and run the command by themselves
<GaryvdM> thevibe: You will want a post tip change hook on the master branch, rather than a post commit hook on the devs branch, so that if they unbind, and push, it still works.
 * GaryvdM looks at the push-and-update to see if it can be made to do this
<GaryvdM> * push-and-update code...
<GaryvdM> thevibe: Note that you can get bzr-upload to do this...
<thevibe> as I was saying I am not very advanced with python so I don't want to digg in an area where I can miss things and not understand others
<thevibe> GaryvdM, can you give me more details on how bzr-upload can do this
<thevibe> ?
<thevibe> I trust you about the post tip change hook but the issue is still there: how can I get one of those? :)
<GaryvdM> thevibe: step 1: in the master branch  on the server, run bzr remove tree
<GaryvdM> thevibe: step 2 : from your pc run bzr upload sftp://server/path-to-branch  -d bzr+ssh://server/path-to-branch --auto
<GaryvdM> thevibe: that will get bzr-upload to do a post tip change hook on bzr+ssh://server/path-to-branch to upload to sftp://server/path-to-branch
<GaryvdM> thevibe: step 3: make all the devs install bzr-upload.
<Glenjamin> s/remove tree/remove-tree/
<GaryvdM> Glenjamin: yes - thanks
<thevibe> excellent
<thevibe> I will do that
<thevibe> one more thing
<thevibe> some of the are front-end developers or even designers and I suggest them to use bzr explorer as it can be installed on multiple OS's
<thevibe> I use Ubuntu, for me it's easy
<GaryvdM> Hmm - push-and-update date has a post_push hook, but that limits it to push. It would be much more useful if it used post-tip-changed, like bzr upload..
<thevibe> can I create a tool in bzr for this command?
<thevibe> you're right and I told you I tried that plugin and is not exactly what I need
<thevibe> it has his good parts but probably a post-tip-changed would be much more useful in real-world
<thevibe> I think at least
<thevibe> :)
<mgz> I'm pretty sure using bzr with gunicorn is just a bad idea.
<jam> mgz: but... but... unicorns, man
<mgz> the problem on the list doesn't look intermittent though, so I won't start yelling about signals just yet.
<jam> mgz: signals shmignals, unicorns man, its all about the unicorns
<jam> (and the fairy dust, but that is harvested from the unicorns anyway)
<mgz> shouldn't animal welfare have something to say about covering a unicorn in green paint?
<GaryvdM> Hi mgz, jam
<jam> hi GaryvdM
<mgz> have you got any smart ideas on bug 663234 Gary?
<ubot5> Launchpad bug 663234 in Bazaar Windows Installers "qlog fails after loading bzr 2.2.1 on Windows 2000 (affected: 1, heat: 6)" [High,New] https://launchpad.net/bugs/663234
<GaryvdM> He He, was about to ask you....
<GaryvdM> * I was...
<mgz> well, Alexander might be right, it's hard to tell without more information
<mgz> suggesting the guy tries do just do python -c "import PyQt4.QtGui" might help.
<GaryvdM> He said that it was working with 2.2.0, so I wonder if he removes the msvcp dlls and manifest, if it will work
<mgz> yeah, I wondered if it was something I'd broken, but I'm not even sure which installer he used
<GaryvdM> I've been assuming 2.2.1-2, but I may be wrong.
<GaryvdM> I looked, and I can't find any window 2000 cd.
<mgz> yeah, not sure it's really worth us trying to test it.
<mgz> working out some sensible things for him to try might be worth it though.
<GaryvdM> I was still in school when win2000 came out - Seems so long ago.
<mgz> ehehhe
<mgz> I have a box with win98 on it still!
<GaryvdM> :-0
<mgz> but I was in school when I got it.
<GaryvdM> I never used 98 much. I went from 95 -> nt 4
<GaryvdM> btw - I got my build host working finally :-) I need to document how I did it with vs express .
<mgz> cool.
<GaryvdM> And I have built a 64bit python installer, which I need to upload. But I think what people will really be looking for is the standalone 64bit installer.
<mgz> I did wonder what people were going on about on the mailing list with 64 bit windows.
<mgz> ...if you care that much, just download a 64 bit python and install bzr yourself
<GaryvdM> I'm busy in building a 2.2.1-3, with bzr-explorer 1.1.1. 1.1.0 had a bug thats getting alot of heat.
<GaryvdM> mgz: Did you see my mail about using build out for the dependences?
<mgz> ...no, what list was it sent to?
<GaryvdM> mgz: bzr-windows
<GaryvdM> Ah - just got jam's reply
<jam> GaryvdM: well, I just sent it now, too :)
<jam> I like the idea
<jam> not sure about the path
<jam> I would be fine using a default that fits the build machine
<mgz> I'd really like a way of bypassing buildout, but using it for more things is also good.
<GaryvdM> jam: I finally managed to create a bundle on ec2, but the name I gave it was not very good. Sorry
<mgz> jam: if you have a mo, could I have some input on my worrying in <https://code.launchpad.net/~gz/bzr/require_unicode_committer_614593/+merge/38334> ?
<jam> mgz: commented
<mgz> thanks!
<mtaylor> is there already a bug out there requesting that bzr launchpad-login set bzr whoami based on metainfo on launchpad
<mtaylor> I _keep_ having folks who have obviously dong lp-login (since they are pushing) but skip the whoami step because nothing reminds them to
<fullermd> Don't recent versions just refuse to commit if you haven't whoamied?
<fullermd> (whoami'd?  How do you conjugate that?)
<mtaylor> fullermd: not that I can see ... although maybe that's in newer revs than what we have
<mtaylor> fullermd: do you mean post-2.2?
<fullermd> Looks like it was in 2.2.
<mwhudson> jam: hi
<jam> hi mwhudson
<mwhudson> jam: did you see the lp-service failure?
<jam> yes, I wasn't 100% sure about what it was telling me
<mwhudson> jam: i think it's an unbound variable 'socket_path'
<jam> mwhudson: what I saw was "exited without failures but with nonzero exit code"
<mwhudson> $ pyflakes lib/lp/codehosting/tests/test_acceptance.py
<mwhudson> lib/lp/codehosting/tests/test_acceptance.py:81: undefined name 'socket_path'
<mwhudson> jam: ^
<jam> AttributeError: 'TestProtocolClient' object has no attribute '_exc_info_to_unicode'
<jam> mwhudson: so it certainly could have failed randomly because of a broken exception handler
<jam> but all the test_acceptance tests seemed to pass here
<mwhudson> jam: you haven't forgotten to push to lp?
<mwhudson> jam: because there's pretty clearly a socket_path that needs to be self.socket_path in the branch i just pulled
<jam> it is possible
<jam> or I pushed without commit, etc
<mwhudson> jam: the deprecationwarnings are probably from the atexit stuff
<mgz> <jam> AttributeError: 'TestProtocolClient' object has no attribute '_exc_info_to_unicode' <- this is subunit bug 635702 and indicates an old testtools version
<ubot5> Launchpad bug 635702 in subunit "addError broken with some versions of testtools (affected: 1, heat: 7)" [Undecided,New] https://launchpad.net/bugs/635702
<jam> mgz: someone should tell launchpad to update their testtools :)
<mgz> There's probably an rt on it buried somewhere.
<mgz> content filtering hits before diff, right?
<mgz> so, content filtering a utf-16 file to utf-8 in the repo would mean you could diff it?
<mwhudson> jam: lifeless tried (to update testtools), it uncovered some broken tests
<lifeless> mwhudson: I'd be delighted if you wanted to tug on them.
<poolie> jam, shall we talk in a bit?
<mwhudson> lifeless: two of the tests are really easy to fix, i guess i can look at them in a bit
<peitschie> mornin all :)
<vila> ouch, now is already tomorrow, night all ;)
<peitschie> night vila lol
<jelmer> Bonne nuit vila
#bzr 2010-10-20
<spiv> Good morning.
<peitschie> mornin spiv
<lifeless> mgz: anythong ?
<mgz> I generally go for boxers...
<peitschie> mgz: on your self or the other? :P
<lifeless> mgz: (typo in your testtools branch)
<mgz> blast, and I thought I'd lowered my tyopage with that branch
<mgz> I'll push a fix.
<poolie> hi spiv, mgz
<mgz> hey poolie... I need to get to bed...
<dlbike76> Hello.  Is there a way to assign a name or tag to a revision number?
<spiv> dlbike76: bzr tag NAME -r REVNO
<spiv> And more generally see 'bzr tag --help' :)
<dlbike76> thanks I had to update to the newest bzr version
<dOxxx> good evening, everyone
<peitschie> hiya dOxxx
<poolie> hi dOxxx, peithschie
<dOxxx> hi poolie
<dOxxx> how are things down under?
<poolie> good
<peitschie> hi poolie
<poolie> getting ready to go to UDS next week
<poolie> spiv, shame we didn't remember ian's plugin earlier, can they merge?
<poolie> is there any point putting them in the plugin guide or are they too nerdy/
<dOxxx> nevar
<dOxxx> no such thing in a DVCS
<dOxxx> ;)
<spiv> poolie: yes, they can merge, mine and his actually do slightly different things.
<spiv> His checks that two branches have identical history and that the revisions are identical.  Mine checks that all copies of inventories in 2 or more repos are identical.
<spiv> They are a bit nerdy, but it would be good to have a place to put things like this.
<spiv> e.g. I also have a 'bzr chk-used-by' command in another plugin that was handy in diagnosing a previous bug, and it probably shouldn't languish in total obscurity.
<spiv> There are probably others like that to be found in others' junk code or home dirs (or possibly even in my own...)
<peitschie> spiv: it'd definitely be worth having a "diagnostics" plugin that can either ship with release, or have an easy method for setup to diagnose some of these problems
<peitschie> spiv: ideally something that could be used to generate extra data for use with bug reports (such as the extra revision data you helped me get out of my repo)
<spiv> peitschie: well, there are a few builtin facilities already
<spiv> peitschie: obviously 'bzr check', but also some hidden commands like dump-btree (see 'bzr help hidden-commands')
<peitschie> spiv: ahh.  fair enuf :).   it seems that for quite a few of the various chk-node related bugs that (at least for bzr-svn) no extra information was really ever sought, which I had assumed was due to no tools being easily available for those
<spiv> peitschie: I think ideally diagnostics that prove useful repeatedly rather than one-offs would be added to the core like that so they are always available
<spiv> (and are tested)
<spiv> peitschie: right, we hadn't made convenient tools for diagnosing that class of chk issues.  We did already have some useful APIs though, but those are a bit harder to ask users to use :)'
<peitschie> spiv: for sure! i've been thinking on and off since the various hiccups as to ways i could have helped speed up troubleshooting the issues in any way
<GaryvdM> Hi all
<peitschie> hi garyvdm :)
<GaryvdM> I have a bzr-svn branch. When I pull, it says No revisions to pull.   But I can see through the web ui that there are new revisions.
<GaryvdM> http://pastebin.ubuntu.com/516663/
<GaryvdM> http://code.google.com/p/synergy-plus/source/list
<GaryvdM> Not sure how to fix this?
<GaryvdM> Using bzr-svn 1.0.3
<peitschie> garyvdm: what's the results of running bzr log -l2 in the bzr-svn branch?
<GaryvdM> peitschie: http://pastebin.ubuntu.com/516670/
<GaryvdM> I think I know what it is.
<GaryvdM> The most recent changes are to /doc/, and I am checking out /trunk/...
<peitschie> garyvdm: oh... that might do it :).  There is actually an open bug somewhere about finding a way to make bzr-svn behaviour in this fashion a little more informative (i.e., I know about revision <X> but am up to revision <Y> which is the latest one with changes to this branch)
<GaryvdM> I can see in qlog that bzr rev 175 is svn rev 753 :-)
<vila_> hi all !
<vila_> wut, who is using my nick ?
<peitschie> vila_: hi ghost of vila
<GaryvdM> Hi vila_
<vila_> hehe :)
<GaryvdM> peitschie: Are you Philip Peitsch?
<peitschie> garyvdm: i yam indeed :)
<vila> GaryvdM: careful, he could be ghost ;)
<peitschie> :O
<vila> a ghost, damn tyops
<peitschie> lol
<GaryvdM> vila: I'm not scared - qlog can handle ghosts now
<vila> \o/
<peitschie> vila: i seem to be pretty corporeal... it hurts to compile code... that makes me real right?
<peitschie> garyvdm: lol
<vila> http://www.youtube.com/watch?v=iCHFVTQKqdQ
<peitschie> ack... that could be me! "If there's something strange... " >.< ... totally busted
<peitschie> garyvdm: did you see the latest wishlist request I posted to qbzr?
<GaryvdM> peitschie: sorry - I'm not keeping up with the waterfall. What's the url?
<peitschie> garyvdm: it's nothing important :): https://bugs.launchpad.net/qbzr/+bug/663684
<ubot5> Launchpad bug 663684 in QBzr "qswitch: remember recently switched branches (affected: 1, heat: 6)" [Undecided,New]
<peitschie> garyvdm: I was just going to ask if there is much by way of approval process to getting an idea "accepted" before I start working on it :)
<GaryvdM> peitschie: Sure. Similar to bug 419758 . It would be cool if you could maybe have the storage code in bzrlib.
<ubot5> Launchpad bug 419758 in QBzr "File menu: add MRU files list (affected: 1, heat: 5)" [Wishlist,Confirmed] https://launchpad.net/bugs/419758
<peitschie> GaryvdM: sounds good.  Are you aware of any "similar" pieces of code to draw from for this type of thing?
<GaryvdM> Maybe make it accessable to the command line via tab completion.
<GaryvdM> peitschie: It would also be cool if such a thing worked for pull/push.
<GaryvdM> peitschie: Not sure what code to look at.
<peitschie> garyvdm: i'll have a look... at this point i'm still treading carefully so i don't accidentally bite off more than i can chew :).  still slowly getting my head around bzr+qbzr (i have no other experience with heavy python code)
<peitschie> garyvdm: having said that... you make convincing points :D.  I might look at getting something like this in bzr core CLI only first... then i don't have to deal with the Qt side of things until I know how to do the storage & retrieval part
<GaryvdM> peitschie: I would look at the code that stores the parent/push/bound branches.
<GaryvdM> peitschie: It would also be cool to show these locations in bzr info.
<peitschie> garyvdm: a thought with that is that it may be preferrable to have such locations stored by user/repo rather than checkout/branch potentially
<peitschie> hmm... i might check out bzrtools stuff... they have some kind of tab-completion stuff in their plugins
<spiv> vila: I'm partial to http://www.youtube.com/watch?v=8u5SSQEY8oo myself...
<vila> spiv: hehe, I wouldn't expect less with such a nick :D
<vila> spiv: excellent :) I love the jumping glasses around 2:15
<spiv> There's lots to like!  If you're into that sort of thing, anyway :)
<vila> spiv: from the same people you mean ?
<GaryvdM> How does his jacket change colour? CGI?
<spiv> vila: oh, I just meant the silliness they squeeze into the one clip :)
<vila> spiv: oh ok
<vila> Regarding the "diagnostics" plugin, how about using bzrtools instead ?
<vila> It's already packaged widely but doesn't get a lot of attention/additions for several releases
<poolie> hi vila
<poolie> that sounds good
<vila> the ghostbuster song ? :-D
<poolie> to run with LANG=C
<poolie> maybe we should think about running plugins though perhaps that's gated on working out the right way to integrate their test
<poolie> anyhow, i'm off; have a good day!
<poolie> i hope to do more reviews tomorrow
<vila> poolie: I finally managed to address some deep configuration issue and I should now be able to add far more jobs more quickly
<poolie> excellent
<vila> also, with the mgz hack transport fix, the doors are open to add an OSX slave...
<poolie> S is standing here
<poolie> bye!
<vila> hehe, cu :)
<lifeless> spiv: around, perchance?
<spiv> lifeless: not really, no :)
<lifeless> kk
<lifeless> wondering how to do dynamic port allocation in a tac file
<spiv> port=0
<lifeless> thanks
<spiv> Finding out what the port number turns out to be might be a bit messy
<lifeless> well
<lifeless> I'm already parsing the log from the parent process :)
<spiv> But then so is finding out when the tac is running enough for something to try connecting.
<spiv> So, yeah :)
<lifeless> class LibrarianServerFixture(...):
<Tak> what's the best way to branch or import a range of revisions from a svn repo?
<Tak> (assuming that I don't care about operating with the svn repo ever again)
<jelmer> Tak: Importing a single branch can be done using "bzr branch"
<Tak> but can I specify the revision range for the import?
<Tak> like ideally I'd do: bzr branch -r KnownGoodRevision..-1 svn://someplace
<jelmer> Tak: No, we don't support partial clones at the moment.
<jelmer> Tak: Why would you want to though?
<Tak> like everyone else, I have broken revisions in my svn repo
<Tak> can I do it with fast(im|ex)port?
<jelmer> Tak: You should be able to work around that by cloning into a clean repository though.
<jelmer> Tak: Alternatively, fastimport/fastexport should indeed work.
<Tak> by cloning into a clean repository?
<jelmer> tak: yeah
<Tak> sorry, I don't know what you mean by "cloning into a clean repository"
<Tak> the problem isn't with bzr-svn, the problem is with the svn repo itself
<jelmer> tak: Oh, ok. In that case it won't help.
<jelmer> tak: fastimport is the only option then I guess
<Tak> ok, thanks
<peitschie> Tak: wat do you mean by the problem is svn repo itself?
<Tak> I mean, at some point in the past, the repository was modified in such a way that certain revisions are invalid
<peitschie> jelmer: does the latest bzr-svn deal with these skipped revisions?
<GaryvdM> Tak: Do you get an error when you run bzr branch svn://someplace ?
<maxb> Tak: Can you elaborate on what you mean by "broken" ?
<peitschie> I think tak is talking about https://bugs.launchpad.net/bzr-svn/+bug/515850
<ubot5> Launchpad bug 515850 in Bazaar Subversion Plugin "Revisions added while a commit is happening are ignored (affected: 5, heat: 29)" [High,Triaged]
<maxb> oh. that could be pain
<maxb> Tak: If so, is your bzr-svn metadata in revprops or fileprops?
<peitschie> maxb: that is assuming this is the problem tho ;)... it may also be missing chk nodes or similar
<peitschie> tak: are you able to give any more detail about exactly which "error"  you're seeing with the broken svn repo?
<Tak> it's not just bzr-svn
<Tak> the same thing happens with git svn
<peitschie> tak: can svn do a checkout?
<Tak> svn can checkout head
<Tak> I believe there are some revisions that can't be checked out
<maxb> Tak: Exact error messages please
<maxb> Do you actually have filesystem access to the repository? If so have you considered 'svnadmin verify'?
<Tak> grr, I can't even fast-export with a revision range: http://paste2.org/p/1046398
<Tak> heh, I'm not touching the repo
<maxb> Tak: ok, let's start eliminating things - can you run 'svn log -v url-to-repo-root' without an error?
<maxb> What version of bzr-svn? Can you try the latest release?
<Tak> bzr 2.2.0 with 1.0.4dev (that /is/ the latest release for osx)
<Tak> svn log completes
<maxb> <Tak> like everyone else, I have broken revisions in my svn repo
<maxb> What exactly do you mean by broken?
<Tak> ok
<Tak> I inherited this repo
<Tak> and we've been evaluating moving to a dvcs
<Tak> and every export and import tool fails - and when I ask people about it, the response is like, "Yeah, we did some voodoo way back when to get some stuff imported and make it Just Work, but now a bunch of revisions are broken"
<Tak> and I get the impression that it's impossible to checkout certain revisions, etc.
<maxb> Right. Well, the very first thing you should be doing is figuring out the nature of the breakage.
<Tak> so that's why I asked my initial question about a partial export - I'd be willing to lose some history, and right now this is only for a test anyway
<maxb> So, please run 'svnadmin verify' on the repository
<GaryvdM> Tak: This error  http://paste2.org/p/1046398 is using bzr fastexport, which uses bzr-svn. Have you tried to use svn fast export (google reveals that there is more than one. Can anyone advise which is the best?)
<Tak> I also tried fast-export-from-svn
<maxb> I think layering two bzr plugins (bzr-svn and bzr-fastimport) on top of a svn repository of questionable integrity is unwise
<maxb> I think you should assess the integrity of the repository with native svn tools, and then move on to using bzr-svn (without fastimport) and finding where it fails
<napster> I've accidently deleted files on my local bzr branch. And bzr pull lp:backman gives me error
<GaryvdM> napster: what error?
<GaryvdM> napster: bzr revert FILENAME will restore your file.
<napster> GaryvdM: How can I restore all the files at once?
<GaryvdM> napster: bzr revert - but that will also revert changes to files not deleted
<napster> GaryvdM: By the way, the error is : bzr: ERROR: Connection error: while sending CONNECT xmlrpc.launchpad.net:443: [Errno 110] Connection timed out
<GaryvdM> napster: if you have qbzr use bzr qrevert
<napster> GaryvdM: I don't use a gui
<GaryvdM> napster: also bzr revert DIR will revert everything in the dir.
<napster> GaryvdM: Thank you
<dobey> hey
<dobey> with bzr reconfigure, how do you reconfigure a remote branch to be stacked on a different remote branch? --stacked-on doesn't seem to like lp: arguments, and passing a full local path makes the stacking invalid on the server
<GaryvdM> dobey: Maybe ask on #launchpad
<mgz> or bzr info the lp: url then use the bzr+ssh: url that gives you?
<dobey> mgz: well, i'm not sure that will help in this case? https://pastebin.canonical.com/38844/
<dobey> mgz: or http://pastebin.ubuntu.com/516867/ rather
<mgz> thanks, <h1>You do not currently have access to the pastebin.</h1> isn't very encouraging.
<dobey> yeah, sorry.
<mgz> try and trick it with ../ maybe?
<mgz> otherwise, file bug.
<dobey> mgz: well passing full path to the local checkount of the branch 'worked' but the server says "Invalid stacked on location: file:///home/vds/canonical/desktopcouch/trunk" now
<maxb> dobey: --stacked-on=bzr+ssh://bazaar.launchpad.net/~whatever/whatever/whatever
<dobey> maxb: hmm, ok
<mgz> that's what I said!
<mgz> lp: really should work though, so file a bug.
<maxb> The launchpad server will understand what to do and rewrite it so that it also works for http clients
<dobey> maxb, mgz: hrmm. now it shows "Invalid stacked on location: ../../../~ubuntuone-control-tower/desktopcouch/trunk" on lp
<dobey> ah well, lunch and then lots of bug filing i guess
<maxb> dobey: Which branch?
<tsmith> are there any plans to be able to use bzr-svn switch and be able to switch all svn:externals repos, too?
<jelmer> tsmith: Yes, when svn:externals are supported. This requires nested tree support in bzr itself though.
<tsmith> jelmer, is that on the radar for 2011, at least?
<tsmith> i've been waiting years
<jelmer> tsmith: Unfortunately it's a hard problem to solve.
<jelmer> tsmith: I don't know what the exact plans are, but IIUC it's higher on the list than ever before.
<tsmith> awesome
<dobey> maxb: https://code.edge.launchpad.net/~vds/desktopcouch/strip_reconnection
<maxb> dobey: ok, can you try bzr reconfigure --stacked-on=bzr+ssh://bazaar.launchpad.net/~ubuntuone-control-tower/desktopcouch/trunk lp:~vds/desktopcouch/strip_reconnection ?
<mgz> what plugin's version has been 0.95 and 0.98 recently?
<maxb> define recently?
<maxb> bzr-gtk not-so-recently
<vila> mgz: testtools ! :-P
<vila> ha no, 0.9.7 :)
<dobey> maxb: we did. that's what put it in the current state it's in
<maxb> oddness
 * maxb experiments
<mgz> I've seen two bug reports with a follow on traceback like:
<mgz> 3.711  Traceback (most recent call last):
<mgz>  File "/usr/lib/python2.6/dist-packages/bzrlib/plugin.py", line 471, in _get__version__
<mgz>    version_string = _format_version_tuple(version_info)
<mgz>  File "/usr/lib/python2.6/dist-packages/bzrlib/__init__.py", line 107, in _format_version_tuple
<mgz>    raise ValueError("version_info %r not valid" % (version_info,))
<mgz> ValueError: version_info (0, 98, 0, 'final', 1) not valid
<mgz> so, whatever plugin that is needs to not be using 1 as the last tuple entry for 'final'
<vila> that.... rings a bell
<maxb> dobey: oh dear
<maxb> something has broken reconfigure --stacked-on= on launchpad
<mgz> oo, oo, oo, osx slave
<maxb> If you download a script I wrote from http://j.maxb.eu/~maxb/bzr-set-stacked-url and run "bzr-set-stacked-url lp:~vds/desktopcouch/strip_reconnection lp:~ubuntuone-control-tower/desktopcouch/trunk" it should fix that branch
<mgz> vila, want bugs filed on your osx failures?
<vila> hehe
<vila> That's an offer I can't refuse :)
<mgz> hm, odd, why is CaseInsCasePresFilenameFeature letting these two win32utils tests run...
<vila> Note that the extensions are not compiled so far
<mgz> hfs is case sensitive, no?
<vila> case preserving
<mgz> ha, so... why are they not passing :P
<vila> dunno if that make the probe fail
<mgz> probably a bad platform detect in the glob code.
<vila> I haven't look at them yet, I've been fighting with .profile .bashrc madness on OSX (three use case, three different setups >-/)
<mgz> I shall investigate.
<vila> no hurry, I'll polish the setup tomorrow
<mgz> there's also one socket thing, and the rest look like package thingies.
<vila> bzrlib.tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh ... once more
<vila> IPV6 may be involved too so it may well be paramiko again
<mgz> that's the paramiko wotsit right?
 * vila off, dinner time
<vila> dunno yet but I won't be surprised
<mgz> have a nice meal!
<vila> one more nail in this test coffin IMNSHO
<AfC> Does `bzr push` push the GPG testaments?
<dobey> maxb: that script seems to have fixed it now, thanks
<maxb> dobey: Will you file a Launchpad bug about reconfigure --stacked-on being broken?
<dobey> maxb: well i guess there are a few bugs that need to be filed, but yes
<jelmer> maxb: hi
<maxb> hi
<kiko> bzr: ERROR: exceptions.NotImplementedError: should resend request to http://feeds.edge.launchpad.net/bazaar/, but this isn't implemented
<kiko> has anyone seen this before?
<kiko> any attempt to bzr branch lp:foo is failing with that
<kiko> i.e.
<kiko> kiko@gasolinux:~$ bzr branch lp:linaro-image-tools
<kiko> -> /home/kiko/.cache/crash/bzr-20101020201652-19812.crash
<lifeless> old bzr
<kiko> Bazaar (bzr) 2.1.1
<lifeless> Fixed in an upcoming SRU, or 2.2
<kiko> okay let me get the ppa going
<kiko> thanks!
<kiko> lifeless, is it a problem that it's not fixed yet?
<lifeless> kiko: that exception? I fixed it before I moved to the LP TA position :)
<kiko> lifeless, I mean, in lucid current or something
<lifeless> theres an SRU process underway
<lifeless> the wheels, they turn
<jelmer> maxb: I've merged your subvertpy branch with some additional changes. I was wondering if you had an easy setup to run a quick make test against svn 1.4 and 1.5.
<kiko> cool then
<maxb> I can hack up a source package and run cowbuilder on it
<maxb> I'll look into that later, need to dash now
<poolie> jam: still here? want to join #ubuntu-meeting?
<mwhudson> hey, is there an easy way to get bzr to run ssh -v for bzr+ssh urls?
<lifeless> mmm
<lifeless> export BZR_SSH=ssh -v ?
<lifeless> perhaps
<fullermd> You can specify LogLevel in ~/.ssh/config for a particular hostname...
<jam> hi poolie
<mwhudson> fullermd: yeah, that'll probably work
<mgz> <lifeless> export BZR_SSH=ssh -v ? <- not this way, we don't parse the value as a shell command
<fullermd> You could export BZR_SSH=~/my_ssh_with_-v.sh
<mgz> that... would work.
<mgz> your first answer was better though.
<fullermd> For bonus points (and many days of Real Work Avoidance), you could even write a special execfs that accepts a path, splits by directory components, and exec()'s, so you could BZR_SSH=/exec/ssh/-v   8-}
<mwhudson> fullermd: i don't think that would work either
<mwhudson> $BZR_SSH is used as a key in a dict iirc
<mgz> used to be, I fixed that over a year ago.
<fullermd> BZR_SSH  Path to SSH client, or one of paramiko, openssh,  [...]
<mwhudson> aah
<mwhudson> there you go, something getting better while I wasn't looking
<mwhudson> better hope you never want to use a binary called 'paramiko' i guess :-)
<fullermd> Ooh.  Are you available for hire?  I have a list of things for you to not look at...
<mgz> hey, this comment has Gary's face next to it, I wonder what he has to say.
<poolie> hi fullermd, mwh, mgz
 * fullermd waves at poolie.
<mgz> ...will people cry if I put a big scary branch for review when I've already got a bunch of little ones pending.
<mgz> most of all me, when it comes to merging them.
<poolie> heh, no
<poolie> i'm going to try to be a more active pilot today...
<peitschie> mornin everyone :)
<mgz> I've been meaning to review Gordan's mergetools change for a few days as well
#bzr 2010-10-21
<spiv> Good moring.
<spiv> morning, even.
<mkanat> It is amazing how popular a topic "I have a ridiculously large repo" is.
<spm> mkanat: it's the old "my keyboard is bigger than your keyboard" ego thing ;-)
<mkanat> spm: lol
<peitschie> mornin spiv :)
<spm> depressingly I don't get any spam about how to make my keyboard bigger tho. other things, but not keyboard. shame.
<peitschie> lol
<peitschie> mkanat: it may also be that bzr is just tipped the scales into "serious DVCS" ;)
<mkanat> peitschie: I think it sort of did!!
<spiv> spm: I'd have thought "make your monitor 20% BIGGER" would be more tempting for many?
<mkanat> peitschie: I wonder what the trigger was! Maybe the 2a format.
<mkanat> spiv: LOL!
<mkanat> Well, my keyboard is probably 2000% more expensive than your keyboard.... :-D
<mkanat> I mean, provided that you have a plain old keyboard. :-)
<spiv> mkanat: depends on if you count the rest of the laptop that it's attached to ;)
<mkanat> LOL
<fullermd> My keyboard can beat up your keyboard   :p
<mkanat> Dude, I dunnow, my keyboard is five pounds of steel.
<peitschie> mkanat: personally it has been a maturity thing i think... bzr has now been around long enough that most companies have enough ppl that have heard of it to convince projects to move
<peitschie> mkanat: i actually met a *new* dev the other day that uses it personally... which is an infinite number of times the number of bzr-using devs i've met b4 in person
<fullermd> Obviously we need to setup a deathmatch.  Two keyboards enter; one keyboard leaves!
<mkanat> fullermd: LOL!!
<mkanat> KEYBOARD-DOME!
<Kobaz> so i'm trying to do a bzr fast-export... and i'm getting bzr: ERROR: bzrlib.errors.KnitCorrupt: Knit KnitVersionedFiles(_KnitGraphIndex(CombinedGraphIndex(
<mkanat> peitschie: That's pretty cool.
<Kobaz> it exports about 100 revs out of 300ish, and then dies... is there a way to repair the repo?
<peitschie> mkanat: it is very :).  One of the key things bzr has going for it as well I think is a strong focus on svn integration as well.  the fact that core bzr think it is important (well, core enough to have invested a lot of time in it) is a good sign... so even the current troubles is not too concerning because i know that bzr will work best with my svn repo
<mkanat> peitschie: That's awesome. :-)
<mkanat> Kobaz: Does "bzr check" pass?
<peitschie> mkanat: which while not really the best result, allows me to "lead" more conservative programmers into it than jumping to a brand new repo format
<peitschie> mkanat:... that and i like devs who get together and compare keyboard sizes :P
<mkanat> peitschie: lol
<Kobaz> mkanat: no it doesnt
<Kobaz> r(Error -3 while decompressing: invalid distance too far back)
<peitschie> Kobaz: are you windows or linux-based?
<mkanat> Kobaz: Okay, that's probably the problem. I'm not familiar with what to do about that, but I'm guessing that poolie, jam, or perhaps some others will know.
<Kobaz> linux
<Kobaz> bzr 2.1
<peitschie> kobaz: cool... no ideas from me then unfortunately :S
<Kobaz> heh
<Kobaz> lovely
<Kobaz> so there's no repair?
<mkanat> Kobaz: There probably is, we just don't know it.
<mkanat> Kobaz: Somebody else will probably be along later who would know it.
<spiv> Kobaz: that unfortunately means suggests the data on disk has been corrupted
<Kobaz> hmm
<spiv> That's an error from zlib
<Kobaz> i guess i can just repull... it's just a copy of what's on the server
<spiv> That would be the simplest thing to try.
<spiv> I'd also be a little worried about the integrity and robustness of your filesystem, though.
<Kobaz> ext3
<Kobaz> never had a problem on this box with anything else
<Kobaz> did a repull, it seems to be working now
<mkanat> Kobaz: Might want to fsck just to be sure.
<Kobaz> spiv: it might be bzr though, i had some nasty corruption problem when i tryed to do a merge a month ago... i did a merge and then it broke itself
<Kobaz> took me a bit of playing to get it working again
<spiv> Depending on how ext3 is configured it can result in zero-length files after a system crash.
<spiv> Hmm, what format repo?
<Kobaz> the old format
<lifeless> mgz: love the stuff you're working on
<spiv> I'd definitely suggest upgrading, for many reasons
<Kobaz> yeah i know
<spiv> :)
<Kobaz> well. i am upgrading actually... switching to git
<Kobaz> heh
<spiv> Hah
<mgz> lifeless: I think mostly I'm working on annoying people with better computers than me :)
<Kobaz> we're moving to a bunch of atlassian tools, and none of them work with bazaar
<lifeless> mgz: smaller is faster often
<lifeless> mgz: its good stuff
<Kobaz> and i'm very interested in all the security that gitolite supports... it's quite cool
<Kobaz> it was so much easier to set up than the http+ssl bzr :/
<i386> Kobaz: ping
<Kobaz> pong
<Kobaz> the re-pull now passes bzr check
<i386> Kobaz: I work for Atlassian and lifeless ping'd me about bazaar support in our products
<Kobaz> ah
<i386> what apps are you starting to use?
<Kobaz> Jira, Confluence, and going to start using Fisheye soon
<i386> cool
<i386> so you would like to see some bzr love in Fisheye?
<Kobaz> well, we're moving to git for other reasons
<Kobaz> if i was staying with bzr, i would
<lifeless> Kobaz: oh :(
<i386> aww
<Kobaz> we're also going to use bamboo and crucible
<i386> Kobaz: well we have good git support in Fisheye..
<i386> Kobaz: nice I work on Bamboo
<i386> You get the new shiny-we-just-rewrote-it Bamboo :)
<Kobaz> nifty
<Kobaz> hehe
<i386> blogs.atlassian.com/devtools/2010/10/bamboo-27-beta-parrallel-builds.html
<i386> yeah
<i386> we still need bzr support
<Kobaz> yeah probably
<i386> There is a bzr bamboo plugin
<i386> but I don't think its maintained anymore
<jbunting> looking to get my feet wet with development...any reason not to work on bug 644990?
<ubot5> Launchpad bug 644990 in Bazaar "After carrying out loacal commit update to trunk fails. (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/644990
<spiv> jbunting: looks like a good bug to get your feet wet with
<spiv> jbunting: so go for it! :)
<jbunting> spiv: alright
<poolie> hi spiv, mkanat
<poolie> and all
<peitschie> hi poolie
<cr3> is there a way to bzr builddeb without having to commit files first? ie, take the files in the cwd as they are?
<lifeless> its the default
<cr3> lifeless: it complains that there's no debian/changelog though
<lifeless> you may have it configred in a nondefault mode
<vila> hi all !
<peitschie> hiya vila :)
<vila> peitschie: istm we're relaying online for quite a few days which in turn means one of us spend too much time online :-P
<peitschie> vila: :$... perhaps lol
<peitschie> vila: i'm 9-5 + home programming... wat's ur excuse? :P
<vila> hmm, if you're online 8hrs does that mean I'm on for 16h.... eeerk ;)
<peitschie> mmm... possible... prolly not tho lol
<peitschie> i was 9am - 12am yesterday :$
<peitschie> yeck... i need a life lol
<vila> well, it *is* a life ;)
<peitschie> true... i must say, i don't begrudge time spent hanging out here :)
<jlebar> How can I use bzr's patience diff as a stand-alone diff program?
<jlebar> Ah...I figured it out.
<jlebar> PYTHONPATH=.
<jlebar> indeed.
<rom1> hello
<rom1> i have a question : is it possible to retrieve a revision that is not linked anymore to a branch, and thus, is it possible to create a branch associated with this revision ?
<rom1> i am in a shared repository enviroment
<fullermd> Yes, you can init a new branch in the repo, then pull that rev from itself.
<fullermd> e.g.: bzr init foo ; cd foo ; bzr pull -rWHATEVER .
<fullermd> (don't miss the '.' at the end)
<rom1> fullermd : you mean that we can retrieve any revision even if it is not part of the branch log ?
<fullermd> If it's in the repository.
<rom1> good to know !!
<fullermd> It's just harder to find if it's not in a branch you have around.
<rom1> it was my next question...
<rom1> is there a way to do it ?
<fullermd> Well, there's probably an API to list every rev in a repository.  Then it's just a lot of reading   ;)
<fullermd> There's a 'heads' command in the bzrtools plugin you can list to list all the heads in the repo.  That's usually the way you go about it.
<jelmer> fullermd: Repository.all_revision_ids()
<rom1> ok, time to do a plugin !
<rom1> i had this concreate case : on of my users did a push with --overwrite option, removing some revisions (that are not linked anymore to any branch). Of course, he required that i revert his mistake :)
<rom1> Thx fullermd and jelmer
<fullermd> Yeah, that's what heads is for.
<fullermd> Two heads, really.  One command to find the revision, and his head to smack  ;)
<rom1> :D
<rubbs> if only I was allowed to smack the heads of some of my devs
<rubbs> mainly my boss :/
<fullermd> Oh, yes, in shops of any size, walking around smacking people is impractical.
<fullermd> You have to design in network-controllable shock electrodes to the chairs from the get-go.  It's a nightmare trying to retrofit.
<rubbs> good to know. I'll work on that. also I think it's time to propose a new bzr command: bzr dopeslap. I think it needs to add some metadata to a revision telling everyone that so and so broke everything.
<rubbs> similar to annotate/blame
<Glenjamin> hey guys, is there a way to get "bzr switch" to show me what changes are happening?
<jelmer> Glenjamin: not really; though "bzr diff -rbranch:<thenewbranch>" should tell you what the changes will be.
<Glenjamin> would it be complicated to add "bzr update" style output into "bzr switch -v" ?
<jelmer> Glenjamin: not really, although I personally wouldn't want to see that output by default.
<jelmer> (I tend to switch between unrelated branches)
<Glenjamin> mm, but -v seems a reasonable place to put it
<jelmer> yeah, a -v seems perfectly reasonable
<Glenjamin> my use-case is a bunch of different demos on a server. which i switch between different branches
<Glenjamin> it's handy to know if i need to re-run migrations
<Glenjamin> i suppose i could use pull actually, and pull --overwrite when it switch
<abentley> jam: what happens if I specify a bzr-history-db location in bazaar.conf, and then try to use a branch that I haven't run history-db-create on?
<GaryvdM> rubbs: You can turn on append_revisions_only on your central branch to prevent that from happening again.
<GaryvdM> http://doc.bazaar.canonical.com/development/en/user-reference/configuration-help.html#append-revisions-only
<rubbs> GaryvdM: oh, I was more or less just joking. I havne't had that kind of issue... yet ;) but thanks, I'll take a look at it. It might be very helpfull for when we grow.
<vila> rubbs: I'm sure I read some man page about a lart(1) command in emacs sources decades ago but I never found it again :-(
<vila> rubbs: there were options like --AC or --DC, things like that
<rubbs> heh
<vila> rubbs: if you ever found it back, just ping me ;)
<vila> s/found/find/ ?
<rubbs> villa: will do, but I don't use emacs so the likelihood of me finding it is small.
<vila> rubbs: in the mean time, you can use http://www.bofh.net/man/lart.1m.html
<rubbs> oh nice. I"m totally going to use this ;)
<vila> rubbs: wait ! There is also: http://www.bofh.net/man/bosskill.8.html
<rubbs> oh nice, exactly what I needed ;)
<fullermd> Yeah, there's a pile of those sort of manpages.  Used to be a dist called 'asrpages' of them.
<GaryvdM> vila: lol lol lol - people are looking as if I'm weird.
<fullermd> How do they look at you the rest of the time?
<GaryvdM> like I'm weird....
<GaryvdM> Just right the intensity is higher...
<vila> hehe, does this mean this is your first exposure to BOFH ?
<vila> man, how lucky you are, you've got *hours* of laugh ahead of you :)
<fullermd> That's one way of looking at it.  The other is to tally up the hours you've spent reading it in your lifetime, and multiply it by your hourly rate, and ask how much it costs   :p
<GaryvdM> Reminds me of "Who Is Joe Bloggs?" - http://www.techbookreport.com/whoisjb.html
<vila> laugh is priceless :-D
<fullermd> Well, they're really freakin' expensive.  That's the next best thing to priceless  :p
<Buttons840> i've added many files to my working tree (just beginning, haven't commited r1 yet), and i want to remove some of the added files; how can i remove the added files from version management without doing a revert?
<CcxCZ> bzr remove --keep
<lifeless> Buttons840: bzr revert filename
<lifeless> Buttons840: will take out of revision control and leave it behind (because the original state was 'present but unversioned'
<Buttons840> when i do a revert it takes a really long time to process (it's a large project)
<lifeless> of a single file ?
<mgz> GaryvdM: I'm not here yet, but if you're still around could you look at bug 663957 and see if you kno of anything relevent that changed in the -3 installer?
<ubot5> Launchpad bug 663957 in Bazaar "TransformRenameFailed and Unprintable exception (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/663957
<GaryvdM> mgz: hi
<GaryvdM> so it's mysteriously fixed
<GaryvdM> mgz: it was failing with bzr-2.2.1-(-1)setup.exe - so it may have been fixed in -2 with the msvc*.dll changes...
<GaryvdM> mgz: The only thing different between -2 and -3 is the BE version.
<mgz> GaryvdM: and there was nothing else different between -1 and -2? Because I don't really see how the dll thing would have affected anything.
<GaryvdM> mgz: nothing intentional.
<GaryvdM> mgz: between -1 and -2, the ec2 host was shutdown, and I failed to get a snapshot.
<mgz> ;_; I hate bugs that mysteriously vanish.
<GaryvdM> for -1, we downgraded pyqt
<GaryvdM> So I had to do that again for -2
<GaryvdM> I also had to install pycrypto 2.3, and paramiko with my patch
<GaryvdM> those 2 were changed for 2.2.0
<GaryvdM> the ec2 host was on from the build of 2.2.0 till I built 2.2.1
<poolie> hello all
<GaryvdM> Hi poolie
<GaryvdM> Maybe something was done to it during that time that caused that bug, and was reverted after.
<GaryvdM> mgz ^
<mgz> but... but... what?!
<mgz> I guess I'll just have to close the bug and ask him to reopen if he ever runs into it again.
<GaryvdM> mgz Is the bug the TransformRenameFailed, or the Unprintable exception?
<mgz> the TransformRenameFailed.
<mgz> something is causing a permission error on rename, reproducably.
<mgz> this generally means the process has an open handle on either the source or the target/
<GaryvdM> a windows sdk issue seems plausible to me.
<peitschie> mornin everyone
<mgz> what's bug 664990 ubot5?
<ubot5> Error: Could not parse data returned by Launchpad: 664990 (https://launchpad.net/bugs/664990)
<GaryvdM> Hi peitschie
<jbunting> mgz:  mistyped that bug # :-(  it's really 644990...description is fixed now...
<peitschie> mornin garyvdm :)
<mgz> ehe, okay jbunting
<mgz> "file:///C:" is not actually a valid file url.
<mgz> or at least explorer doesn't like it.
<mgz> jbunting: you can use --fixes lp:BUGNUM when committing to get the branch to auto link the bug
<jbunting> mgz:  cool...i can take the other direction on handling that form
<jbunting> mgz: would that be preferred?
<mgz> I think so, you basically want to check that it goes ("file:///", drive letter, colon, "/")
<jbunting> alrighty
<mgz> (for the case without a local host name)
<mgz> ha, can use vertical bar rather than colon, didn't know that.
<jbunting> i didn't either...
<jbunting> mgz: so should i change the description for the merge proposal?
<jbunting> mgz: or just add a comment?
<mgz> a comment would be fine
<mgz> nits just on the last rev, you added a tab rather than spaces, and rather commenting the previous test like could just delete it
<mgz> otherwise looks good now.
<mgz> you could uncommit from lp: and no one would ever notice :)
<jbunting> doh...sounds like an excellent idea
<mgz> I have done `bzr uncommit --force && bzr uncommit --force lp:...` more than once myself :)
<mgz> evil, but works.
<GaryvdM> or uncommit > fix > commit > push --overwrite
<mgz> push --overwrite scares me, I've done silly things with it in the past
<jbunting> all fixed
<jbunting> and yes, uncommit seems evil
<mgz> looks good!
<mgz> last thing that'll need doing before this can land, while I have you,
<mgz> read <http://www.canonical.com/contributors> and follow the directions
<mgz> if you've got any queries about what it means, feel free to ask.
<jbunting> will do
<jbunting> mgz: project lead address - martin.pool@canonical.com ?
<mgz> yup.
<spiv> Yep
<mgz> morning to you spiv.
<jbunting> good deal, thanks for the help
#bzr 2010-10-22
<GungaDin> is it possible to merge into a branch if there already is an ongoing merge?
<mgz> I believe it is these days, it's certainly possible for there to be more than two parents.
<mgz> not actually tried it recently though.
<GaryvdM> GungaDin: bzr merge --force
<GaryvdM> If I recall correctly - Bzr has been able to do that from pre 0.17 days - if not the beginning
<GungaDin> they're not really done from the same machine.
<mgz> ha, clearly I didn't try hard enough last time then.
<mgz> thanks Gary.
<GaryvdM> GungaDin: then I think I we miss understand you - Could you try describe in more detail what you are wanting to do?
<GungaDin> there's a branch stored in a shared on machine S. there are 2 checkouts of it on machine A & B. both users on A & B want to merge something into this branch.
<GaryvdM> GungaDin: Yes - person A commits - cause it's a check out it gets pushed to the master branch.
<maxb> One should merge and commit. The other should then update, merge and commit
<GaryvdM> then person b ties to commit - It wont let him/her because of person a's commit
<GaryvdM> so b must update before he commits
<GaryvdM> and the update will merge a's changes with b's changes
<GungaDin> I'm talking about the situation before anyone commits.
<GungaDin> one has started a merge... can the other one start his now?
<dash> GungaDin: merges don't happen in branches, they happen in working copies.
<GungaDin> or is that branch locked until the commit of the first one?
<maxb> There is no locking, but if they both start simultaneously, one will have to update before committing, and may have to resolve conflicts as a result
<poolie> hi guys
<poolie> i'm going to be at uds next week so i'll be offline a bit
<poolie> and i have been busy a bit this week getting ready
<spiv> GungaDin: a merge is basically just another kind of uncommitted edit you can make to a checkout, like modifying or adding files.
<spiv> GungaDin: and the branch isn't affected by uncommitted changes until they are committed.
<GaryvdM> mgz: see revno 4825.1.1 in bzr.dev
<mgz> ...appears to be doc fixes from nmb?
<GaryvdM>  mgz: hint - count the parents :-)
<mgz> ah, I see what you mean.
<GaryvdM> I had a script to find octopus merges, but I've lost it. There are others...
 * KombuchaKip is very much enjoying the soundtrack to The Fountain by Kronos Quartet. Every time he sees their name on a soundtrack, he's confident it will be stellar.
<poolie> hi there spiv
<spiv> Hey
<poolie> sorry i haven't piloted much
<poolie> having one of those about-to-go-away weeks
<poolie> the lp-dev review thread is interesting, isn't it
<poolie> it reminds me how much easier things seem to flow for us compared to a few years ago
<spiv> Yeah, definitely
<spiv> It's partly also that they have such a large team, so naturally there's a little more divergence in understanding of the norms and rationales for reviewing.
<spiv> Such a large review team, that is.
<spiv> We actually have a pretty large set of people generating merge proposals, really :)
<poolie> mm
<mwhudson> i think launchpad and bazaar are really quite different projects
<mwhudson> in ways that i can't quite put my finger on
<poolie> probably
<poolie> hm, gmail seems to be down?
<mwhudson> not for me
<mwhudson> but then the way that sort of thing works, partial outage is hardly surprising
<spiv> On another channel I'm on someone else had gmail be down just for them for a while this morning.
<spiv> Or more facetiously, http://downforeveryoneorjustme.com/gmail.com
<poolie> hm, maybe this is a good chance to get something done :)
<spiv> Hah
<poolie> hm the docs are indeed broken by danilo
<poolie> by his name occurring in a tex document
<poolie> spiv what did you change there?
<spiv> Nothing much I would have thought...
<spiv> Where does his name occur?  In release-notes?
<poolie> in bzr-en-release-notes
<spiv> I didn't look at the tex generation at all
<spiv> I believe that's done by sphinx?  So in theory nothing significant has changed there...
<spiv> Yeah, nothing obvious... will look again after lunch if you're still having trouble.
<poolie> i can reproduce it locally
<poolie> and yes, it does seem to be produced by sphinx
<gilaniali> whats the bzr of eqivalent of gitosis and gitolite
<jbowtie> I think that's Sphinx issue 432, fixed 5 months ago in http://bitbucket.org/birkenfield/sphinx/changeset/28e9f10c1f34
<dash> gilaniali: what do those do?
<gilaniali> dash: they help in managing a gitserver by providing an easy way to add user users, manage group permissions and such
<poolie> gilaniali: i believe there is a fork of gitosis that runs bzr, bzrosis or something
<poolie> jbowtie: i don't think it is that issue ,but thanks
<jbowtie> poolie: sorry, correct URL is http://bitbucket.org/birkenfeld/sphinx/changeset/28e9f10c1f34
<poolie> mm, i found it, but that's not the error i'm getting
<poolie> i'll file a bug
<jbowtie> Hm, Maverick still has 0.6.6, bug was fixed in 0.6.7 but it could be down to latex version being used I suppose.
<poolie> https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/39115 skirts around it
<poolie> jbowtie: but the one i get is an error during pdflatex, not while producing the tex
<poolie> i suspect the bug if anywhere is in their tex templates but i really don't want to dig into that now
<jbowtie> Oh, that might be the moving arguments bug in pdflatex. I'll have a closer look over the weekend when I push my documentation bug fixes.
<poolie> great
<poolie> do you want to rubberstamp <https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/39115> in the interim?
<poolie> i'd be happy to leave the bug open
<jbowtie> poolie: Yes, just did so.
<poolie> thanks
<jbowtie> Hmm...apparently I'm 'community'.  Is that a new launchpad feature?
<poolie> i think it means you're not in the team of reviewers for the target branch?
<jbowtie> Maybe. I just requested bzr-core membership.  Already in bzr-qa and bzr-doc
<jbowtie> I would have thought that would have been within the purview of bzr-doc anyhow.
<poolie> mm
<poolie> bzr-core is just the default reviewer and i didn't change it
<poolie> it's totally fine as it is
<jbowtie> Is bug 388249 still an issue?
<ubot5> Launchpad bug 388249 in Bazaar "2a format doesn't support Revision.message = None (affected: 1, heat: 8)" [High,Confirmed] https://launchpad.net/bugs/388249
<abentley> poolie: bzr-core is not merely the default reviewer, it is the designated review team for that branch.  Anyone doing a review for that branch who's not a member of that team is "(community)".
<lifeless> poolie: http://bzr.bz/
<poolie> wow
<poolie> nice domain
<spiv> Ooh, some excellent lightning and thunder where I am atm.
<glyph> "It's not launchpad.net"?
<poolie> mm me too
<poolie> apparently not
<mtaylor> lifeless: what an interesting thing that is
<lifeless> indeed
<peitschie> i can understand the sentiment slightly
<peitschie> it'd be very nice to get something simpler to play with than launchpad for hosting bzr projects
<peitschie> having said that... i wouldn't trust that place from teh looks of it with my code ;)
<poolie> i think it's nice to have an alternative that is seems to be taking a very kind of dry approach
<poolie> in fact it's good to have alternatives full stop
<poolie> has anyone else tested bzr from maverick-proposed?
<spiv> Hmm, I have the bzr from bzr-beta-ppa, haven't tried maverick-proposed.
<lifeless> do you have maverick ?
<lifeless> 'you' should talk to marjo about getting testers
<vila> hi all
<poolie> that would be good
<poolie> lifeless: what do you mean?
<lifeless> the ubuntu qa folk are discussing how to attract testers at themoment
<lifeless> mainly for iso testing I think
<poolie> ok, maybe i'll see him next week
<lifeless> but SRU is pretty important, I would be surprised if they aren't thinking about it
<poolie> spiv, can you downgrade and test that, and then comment on the bug? or vila?
<vila> hmm... I've got so many different configurations flying around that the main problem will be to find the right one where I can be sure to test the right bzr 8-)
<vila> poolie: on the other hand, I've *already* tested it one way or the other...
<poolie> vila actually if we have room to spare, an infrequent babune job that checks bzr selftest from maverick-proposed, and other things where it should be green, would be good
<poolie> i should add babune to my 'poll' bookmarks
<poolie> i wonder too if we can separate them into 'should be green' and 'not yet'?
<poolie> or maybe you already did?
<vila> poolie: you know there are news feeds there
<poolie> mm, i don't really believe in rss though
<vila> poolie: toying around with ppas or other things requiring root access is outside babune capacities so far (and will remain for the foreseeable future)
<poolie> even in a vm?
<vila> poolie: the focus is on running from branches, not toying with system setups
<vila> another maverick vm then or may be I should instead look into *not* running from source
<vila> I haven't looked from this angle yet
<poolie> on the whole i would say source is a higher prioirity
<peitschie> (hi vila :) )
<vila> babune slaves requires an available bzr, whatever it is, just a running one
<poolie> since we can change it much faster
<vila> peitschie: hey :)
<vila> poolie: +1
<poolie> vila i see for instance http://babune.ladeuil.net:24842/job/selftest-jaunty/321/ failed
<poolie> with a subunit 'connection broken' message
<poolie> which is not much of a message at all
<poolie> what does that mean?
<vila> poolie: now, it's conceivable to run an hudson job without tying it to a bzr branch and look into configuring the vms with -proposed
<vila> poolie: shudder
<spiv> poolie: replied to your bug 653307 comment: I think we are closer to a diagnosis now
<ubot5> Launchpad bug 653307 in Ubuntu Distributed Development "Import fails with missing referenced chk root keys (affected: 1, heat: 7)" [Critical,In progress] https://launchpad.net/bugs/653307
<poolie> right, just do it every day or every few days
<poolie> oh good
<lifeless> poolie: you don't like rss?
<spiv> poolie: unfortunately, it involves the word "stacking" :(
<poolie> lifeless: i just tend to find i don't want to read a whole bunch of news mashed together
<vila> that's the remaining pain point with subunit/testtools/hudson: random failures, not reproducible at will, unknown cause
<poolie> i check different things at different intervals
<lifeless> poolie: I do quite like google reader
<poolie> i know
<vila> poolie: best guesses includes: hangs or.... whatever can make a selftest subprocess die... no traces, go figure
<poolie> lifeless: this is one of my grumbles about subunit; it tends to fail opaquely in practice
<lifeless> poolie: :(
<poolie> vila i wonder if it crashed in C, or ran out of memory, or something like that
<poolie> very good in other ways mind you, and i'm sure this is tractable
<poolie> vila is it possible to see the raw streams?
<vila> poolie: for a while I just hit delete and re-run, now I keep them but still re-run
<vila> poolie: could be, but it hasn't reach the top of my TODO list yet (and I suspect it won't for quite some time ;)
<poolie> just wondering
<vila> poolie: my gut feeling is more around timing issues than OOM or crashes
<vila> poolie: could also be virtualbox related
<poolie> in some cases if unexpected output gets into the noise subunit will disconnect
<poolie> that too
<vila> there are a couple or network bugs randomly occurring here and there even at boot time for karmic/lucid/maverick where the eth0 interface is not properly configured/initialized including avahi failing or dhcp or goat or chicken
<vila> and sometimes the network connection is lost or the autofs fail or...
<vila> you know, the kind of bug that disappear as soon as you try to look at them ?
<vila> just like them
<vila> anyway, to come back to the initial question: I don't feel qualify to test '-proposed', there are too many reasons that my tests won't be representative
<vila> imbw
<vila> by the way, natty is not yet installable right ?
<vila> I mean, with a reasonable effort
<vila> like: download a bootable iso or tweak an apt sources files on a maverick vm :)
<vila> hmm, so looking a bit at my vm configs: the idea is to test whatever is packaged by the distro, except for ubuntus where I add the stable ppa
<vila> and this rule is not fully enforced for windows and osx (but well, I'm just adding osx to the mix)
<vila> this is partly due to hudson requiring a system-wide available bzr to bootstrap the jobs
<vila> so I'm not super keen on introducing possible failures there... and setting up alternative install of bzr kind of defeat the purpose of testing -proposed, so this will require different vms...
<vila> said otherwise: there are ways to inject -proposed in babune but any failure there will induce significant fallouts
<vila> which may be a good thing... or not at all
<poolie> ok
<poolie> well, maybe we should wait for the existing ones to stabilize more
<vila> what do you mean ?
<spiv> Ok, I should finish work for the day.  Happy weekend (and happy travelling if appropriate)!
<poolie> to get all the existing jobs continuously green
<jbowtie> Hey, hey, I'm in bzr-core!  I feel happy!
<poolie> thanks spiv, have a good weekend, thanks for the updates on the bugs
<poolie> keep status-ing :)
<poolie> congrats!
<vila> poolie: ha right, yes, that why I just added osx now that windows is close to green
<poolie> vila, so i think the thing to do is: boot a vm that's configured to use maverick-proposed; aptitude upgrade; run bzr selftest; see what happens
<vila> poolie: I had a hudson plugin that was re-running some failures automatically but it stopped working, I didn't find the time to disagnose that one
<poolie> i don't know how hard this is to put into hudson but it's only a few shell commands so it seems it shouldn't be all that hard
<vila> oh, *that* shouldn't be hard, right, but that's indeed adding other vm
<vila> poolie: But I did this test manually... can't remember when
<poolie> they're pretty cheap though
<poolie> at least if they can be shut down when they're not actually running
<poolie> which test?
<vila> running selftest from a ppa installed bzr
<vila> you make me doubt now...
<vila> ha no, -proposed not a ppa, meh
<poolie> ah, you've tested 2.2.1 that way?
<poolie> then you should say so on the bug...
<vila> poolie: no, I did test from the stable ppa not from the -proposed pocket
<vila> poolie: sry for the confusion
<vila> poolie: meh, bug you already did the test yourself if I read bug 636930 correctly right ?
<ubot5> Launchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' (affected: 10, heat: 92)" [High,Triaged] https://launchpad.net/bugs/636930
<vila> oh, you want one more verification
<poolie> right
<vila> why didn't you start with that ? :-p
<poolie> sorry :)
<vila> hehe, kidding
<Ng> hrm
<Ng> today's maverick package update just failed because of bzr whoami
<Ng> which would presumably be because I have etckeeper installed
<Ng> have we managed to yet convince people that requiring identity to commit is bad, harmful and wrong?
<GaryvdM> Ng: To fix I did :
<GaryvdM> sudo -i
<vila> poolie: grumble, subunit/testtools bugs, can't run -proposed on hudson
<spiv> Ng: have we managed to yet get etckeepr to take care of setting one for you? ;)
<GaryvdM> bzr whoami "Root <root@hostname>"
<Ng> spiv: my laptop having a failed apt transaction suggests not
<GaryvdM> Which is a work around...
<Ng> and you question answers mine that we continue to fail :(
<Ng> please change bzr's behaviour, this is madness
<jpds> Ng: Is that not bug #616878 ?
<ubot5> Launchpad bug 616878 in Bazaar "bzr commit error because of no identity (affected: 3, heat: 60)" [Medium,Confirmed] https://launchpad.net/bugs/616878
<Ng> jpds: it very likely is
<GaryvdM> You can't keep everybody happy :-/
<vila> Ng: what do you think will be faster: issuing 'bzr whoami "junk <me@exmaple.com>"' or getting an updated bzr in maverick ?
<Ng> even a change in behaviour to s/error/warn/ for id 0 would be something
<spiv> Or more precisely perhaps bug 647475
<ubot5> Launchpad bug 647475 in bzr (Ubuntu) "etckeeper with bazaar stopped working for the update manager on upgrade to maverick (affected: 3, heat: 135)" [Undecided,New] https://launchpad.net/bugs/647475
<spiv> I suggest grabbing poolie at UDS
<vila> Ng: not that we shouldn't *refuse* to change bzr behaviour, just proposing you a workaround to address your problem *now*
<Ng> vila: sure, a workaround is no problem for me at all, but tools that build on bzr, like etckeeper, are very likely to be used by people who don't understand (or indeed care) the ins and outs of this, which is why I asserted that changing the behaviour in this way is bad, harmful and wrong
<Ng> it probably seems very correct from a perspective of develoeprs working on code where every bzr interaction is human driven, but that's not the full reality of bzr's usage
<Ng> I will gladly talk to pooli e about it at UDS :)
<vila> Ng: I indeed use bzr unattended and find it good to know where a commit is coming from
<Ng> vila: I use bzr more with robots than people and username@hostname was fine for me
<poolie> ng, i may even fix it on the plain
<poolie> especially if you tell me what you think a good tradeoff would be
<poolie> s//plane
<vila> Ng: then I suggest you contribute to bug #647475 or bug #616878 both of which give a good summary of the issues
<poolie> i guess you want to go back to just no check, no warning?
<ubot5> Launchpad bug 647475 in bzr (Ubuntu) "etckeeper with bazaar stopped working for the update manager on upgrade to maverick (affected: 3, heat: 135)" [Undecided,New] https://launchpad.net/bugs/647475
<ubot5> Launchpad bug 616878 in Bazaar "bzr commit error because of no identity (affected: 3, heat: 62)" [Medium,Confirmed] https://launchpad.net/bugs/616878
<poolie> would it be reasonable to rely on /etc/mailname being set?
<Ng> poolie: so ultimately the limit of my real caring is breaking automated root committing, so I'd be happy if it would notice it was running as uid 0 and just warn, then go with root@hostname
<Ng> erroring for users is, I think, a bit annoying, but it's way less likely to break critical things like package transactions
<vila> Why isn' etckeeper setting the proper default ? Istm we're bikeshedding about what bzr default should be with a conflict between protecting unaware users of the consequences and third-party tools on top of bzr using it in an unusual way (running as root)
<Ng> vila: it's not bikeshedding dude, bikeshedding is arguing about trivial details, this is me advocating for people whose critical systems are being broken by a significant change of behaviour
<vila> Ng: the fix was about addressing a problem seen as critical by other users, so I still call it bikeshedding as far as different users want different defaults
<Ng> vila: I think your characterisation of bug #549310 is misleading, it's not described as critical, it was not assigned a critical bug status and the requested just asked for a warning to be printed
<ubot5> Launchpad bug 549310 in Bazaar "bzr should not try to guess username but require setting it with whoami (affected: 1, heat: 1)" [Wishlist,Fix released] https://launchpad.net/bugs/549310
<GaryvdM> Ok - this is really bike sheading: For a new qlog option: --show-wt or --show-trees?
<lifeless> --show-iterables
<vila> GaryvdM: --show-trees
<peitschie> garyvdm: +1 for show trees
<vila> Ng: well, this has been discussed in other places than here, and I was the one setting it to Wishlist at first. Nobody changed its status but it's hardly relevant now. Can we focus on what the problem is and the various ways it could be addressed ?
<vila> Ng: critical for bzr is only used for bugs that should block a release (including data loss for example), *not* for that kind of problems which could be addressed by explicitly setting a default with a single bzr command
<Ng> vila: I think my suggestion for handling uid=0 cases takes care of the most obviously dangerous scenarios
<Ng> I'd be happy to repeat that suggestion as bug commentary
<vila> Ng: thanks
<Ng> :)
<poolie> ng hang on, you're saying we shouldn't have fixed 5493
<poolie> 549310
<poolie> because it's not critical?
<poolie> thanks for talking about this btw
<poolie> oh, nm, i see you're disputing vila calling it critical
<Ng> poolie: indeed, I'm all for encouraging users to set good metadata, I just think the fix went too far
<Ng> perhaps bzr could notice that it's not attached to a terminal and not error, but that sounds like a potential rats nest of fragility
<poolie> Ng would a warning rather than an error be ok?
<Ng> poolie: I think at one point james expressed a preferences for it to warn once only. Wearing an ubuntu user hat, if a warning stops things like etckeeper commits from failing, then yes
<jbowtie> Two more bug fixes and bzr-tfs should be good enough to use with codeplex, should make jelmer happy.
<poolie> nice one
<poolie> good night all
<GaryvdM> Night poolie. Travel well, and enjoy uds!
<vila> poolie: night !
<jbowtie> poolie: Good night.
<Tak> when using the command api, is there any point to calling cleanup_now() ?
<gthorslund> when moving around between versions is there any advantage of doing "bzr revert -r <revno>" instead of "bzr update -r <revno>"? with revert "bzr version-info" doesn't get updated, while it does with update.
<maxb> gthorslund: revert is primarily useful if you wanted to commit the old tree state as a new revision, e.g. to back out changes
<maxb> update is normally more useful for inspecting previous tree states, plus it will retain local modifications in your tree whilst you traverse through history
<gthorslund> maxb: so for a plugin like bzr-bisect it would make more sense to use update then? appears it's using revert now and then version-info fails.
<maxb> Indeed.
<maxb> AFAIK, bisect uses revert purely because 'bzr update -r' was not implemented until recently
<gthorslund> maxb: thx. I'm looking at that plugin anyway. I'll look at writing a bug report + patch later.
<gthorslund> have to go now
<GaryvdM> How do you fix a Conflicting tags error?
<GaryvdM> I have established that the tag is wrong in my branch, correct in the parent
<GaryvdM> So I want to pull the tag from the parent.
<maxb> GaryvdM: pull --overwrite will do it, if you're happy for all that entails
<maxb> otherwise, locally delete the selected tags you don't want, then pull
<maxb> erm
<maxb> s/don't want/know to be wrong/
<GaryvdM> maxb: thanks - --overwrite did the trick.
<abentley> jam, does history_db use PQM or should I just push to trunk?
<jam> abentley: just push trunk
<abentley> jam, what happens if I specify a history_db, but that db doesn't have any information about my branch?
<jam> it gets populated
<abentley> jam, is history-db-create optional?
<abentley> jam, or is it needed to create the database if it doesn't exist?
<jam> abentley: yes, but faster for the initial import
<jam> I'm not sure what happens if the file itself doesn't exist
<RenatoSilva> what is bzr+ssh exactly? how does it work exactly?
<LeoNerd> It ssh's to the server, and runs 'bzr serve' as a remote command over SSH
<RenatoSilva> bzr serve, not bzr <the-desired-command>?
<LeoNerd> Correct..
<LeoNerd> E.g. if you   bzr branch bzr+ssh://....     there's no point running  bzr branch  on the server, because the new workspace needs to be written on the client.
<LeoNerd> So, it ssh's to the server, and runs  bzr serve  which acts as a remote agent for the (local) bzr to talk to; taking commands on stdin, issuing responses on stdout.
<RenatoSilva> complicated...
<LeoNerd> It's a fairly simple way to do it, really. A lot of tools do things this way. svn's ssh support did that. My own IPC::PerlSSH does that; it ssh's to the server and runs "perl" to accept a program on STDIN
<LeoNerd> It means you only have to open the ssh port, and most servers already have that, and the ssh server itself doesn't have to understand anything special. It already has all the user auth, for example.
<RenatoSilva> I definitely don't understand, it may be easier but I don't get it :(
<RenatoSilva> Maybe someday I'll see step by step or so, but now...I just can't grok it
<RenatoSilva> I use putty on windows and my private key is protected by password, ssh on Linux doesn't have password protection, besides it'd be necessary to export the ppk to ssh format, creating two files for the same thing
<RenatoSilva> I'd like to use putty on linux exactly the same way I do on windows, or at least use the ppk on linux (some other program to load it after asking passowrd)
<jbunting> i'm not very familiar with putty's private key handling, but does adding a passphrase to your private key on linux not do what you want?
<RenatoSilva> does ssh on linux support protecting the key with a password? In putty, I just click over the file and it shows a dialog asking the password, and in linux, how is that?
<maxb> ssh-keygen -p -f I think
<LeoNerd> It's called a passphrase.
<LeoNerd> But yes, either supply one when you generate the key, or you can alter an existing one as maxb suggests
<maxb> And frankly, I blame Putty for not supporting openssh's key format
<LeoNerd> Yeah. It's very annoying. I had to jump thruogh many hoops to put a PuTTY SSH key on my phone
<RenatoSilva> maxb: so when I do bzr push lp:project it will ask me the password in the terminal?
<LeoNerd> passphrase.  Perhaps. Depends if you're using an agent, and if it's loaded into it
<LeoNerd> But this is now just a general "how to use SSH" question, and not directly the fault or control of bzr itself
<maxb> I assume so. Personally I've never tried it that way. I always load my key into ssh-agent so I don't have to enter the passphrase once per connection
<LeoNerd> Yeah.. it gets very tedious very quickly :)
<RenatoSilva> how to tell bzr to use "the ssh agent"? In windows it's BZR_SSH=plink for putty's agent
<LeoNerd> (though, less so in bzr because e.g. the branch is still local..)
<LeoNerd> It should just happen automatically
<RenatoSilva> automatically? bzr guesses it's meant to use ssh?
<vila> RenatoSilva: bzr on linux (but tell us which one you use if you want more precise answers) relies on openssh. Configuring the ssh agent there is... generally taken into account by your distro
<RenatoSilva> sorry for the offtopic but just one more question? does "ssh-agent" / ubuntu  have a GUI interface for loading keys?
<RenatoSilva> ok will reboot to linux, brb...
<LeoNerd> ssh-add  without a tty ought to do that, but easier just to run   ssh-add
<maxb> Recent Ubuntu will run a GNOME reimplementation of the ssh agent which does have all manner of GUI nonsense
<maxb> However, I like the CLI much better, so can't tell you much about that :-)
<LeoNerd> Also, the CLI has much less cope for a security attack
<LeoNerd> If "some GUI box" pops up and asks for your passphrase, and you neter it... how did you know it wasn't a Javascript box on some webpage, or whatever?
<vila> LeoNerd, maxb: You mean you use 'ssh-add <key>' only ?
<LeoNerd> If you see it in the very xterm you ran 'ssh-add' from, there's a much greater chance of it being legit
<LeoNerd> vila: Yes. See my reason above
<maxb> vila: Well, no, I mean my .bash_profile does stuff for me :-)
<vila> maxb: your.... where do you get the passphrase from ? smart card ?
 * vila keep for himself that he just add some 'ssh-add' for passwordless keys in a cron job :D
<maxb> My .bash_profile inspects .ssh/* and builds a list of keys, and invokes eval `keychain --eval $keys`
<maxb> keychain then ensures an agent is available and invokes ssh-add
<maxb> I then get prompted either on the console or via pinentry-gtk for the passphrase
<vila> what is keychain ?
<vila> not installed here apparently
<maxb> keychain is a manager for ssh-agent
<vila> an equivalent to seahorse then ?
<maxb> It will inherit a running ssh-agent from the environment, or start a new one if not found, and then write the necessary envvars to a file, so that future invocations of keychain can then reload the environment in another session
<maxb> So basically "find me my running ssh agent or make a new one if necessary"
<maxb> plus, inspect the ssh-agent for what keys are loaded, and load any that are missing
<vila> oh, right, synaptic is telling me about it, thanks for the pointer
<vila> hmmm, so that allows you to run cron jobs under password protected keys
<vila> maxb: I have a corner case that isn't covered here: I need to start a daemon on reboot, so there is noone to type the passphrase... any idea ? (I've gove with passwordless keys but...)
<maxb> right, no other solution there
<maxb> ideally the passwordless keys will have forced command restrictions on the other end
<vila> hmm
<mgz> hey all.
<vila> mgz: hey !
<vila> maxb: anyway, I will re-think about it now that I see what keychain offer
<mgz> vila, does <https://code.launchpad.net/~gagern/bzr/bug663773-help-requires-testtools/+merge/38926> look okay to you?
<vila> argh, totally forgot about this one
<mgz> also, a second review on <https://code.launchpad.net/~jared-bunting/bzr/644990-win32-path-length-check/+merge/39104> and I'll land that as well.
<vila> hmm, I think I'm vaguely uncomfortable splitting the command in its own file instead of digging a bit more for lazy loading but... so little time
<mgz> importing bzrlib.tests.script will import bzrlib.tests because that's how packages work
<mgz> and bzrlib.tests *can't* lazy import testtools
<mgz> it needs it for class definitions and such like.
<vila> mgz: thanks, that's the bit I wanted to check
<vila> mgz: pff, tell what you want, a good regexp for the jared patch will be *far* clearer :-p
<mgz> :D
<vila> mgz: we need a commit message for the jared patch, I can't summarize the fix there... my english fails :-/
<mgz> I'm doing it.
<vila> well, let's be honest, the patch is too small for me to understand where this is used ;-)
<mgz> done done done, thanks vila.
<jbunting> and thanks to you both
<vila> jbunting: hey ! Thanks for the fix :)
<dooferlad> Hi, I have a bzr-svn checkout that I am having trouble with - the file contents doesn't match an svn checkout of the same trunk.
<dooferlad> I assume I am having trouble pulling the latest changes from the server. I have been using bzr pull
<peitschie_> mornin all :)
<vila> mgz: sorry, I was on other subjects this week and couldn't find the time to discuss about the transport hook. I just saw you put in mp into wip, does this mean you get new ideas ?
<vila> s/in mp/your mp/
<mgz> vila: decided to think about the testcase collection branch first, then come back to it
<mgz> I still need to absorb jam's post on the mailing list
<vila> :-/
<vila> mgz: which thread ?
<jam> mgz: basic idea, just add a per-transport test that the connect hook gets called
<vila> jam: I think bzrlib.tests.commands is full of tests ensuring that the connect hook is called
<vila> not proper unit tests though
<jam> vila: mgz was saying explicitly that he was having problems getting smart transport to fire the hook
<jam> so add a per transport hook
<jam> s/hook/test/
<vila> ha, but smart transport doesn't respect the specific part we're interested in there, but let me read your mail first as I lack the context
<jam> vila: I haven't followed in detail either, but as I understand it:
<vila> which means I may be misunderstanding you
<jam> 1) we want to make sure the test suite cleans up after it connects
<vila> right
<jam> 2) we want to use a hook so we know what was connected so we know what to disconnect
<vila> right
<jam> 3) add a test that ConnectTransport classes call the hook
<jam> 4)?
<jam> 5) profit
<vila> yeah, but the evil is in the details
<vila> The proposal as it is can fit the definition you gave above
<vila> mgz, jam: In which thread could I find this mail, I have some backlog :-/
<mgz> vila: the original one about sorting out get_transport
<vila> mp or ml discussion ?
<mgz> list, sec, I'll find it in the online archive
<mgz> https://lists.ubuntu.com/archives/bazaar/2010q4/070670.html
<vila> thxs
<vila> ha, right
<vila> the problem here is that we'd like to put it on the transport object, but the smart transport one define the connection point in code that doesn't get access to the transport object itself: the medium
<vila> hence the nudge to spiv to shed some light here, but AIUI he has been pretty busy with quite a nasty bug
<vila> This means we can't just put a hook here since we require a transport object to call the disconnect() method
<vila> jam: and you know mgz, if we embed a transport reference in the medium and/or the connection object, he willl run all over the place yelling: 'ref cycles ! ref cycles !!!!'
<mgz> :)
<mgz> spiv did give some useful pushback on that front, I might scale the branch back to a big list of weakrefs and a gc.collect call.
<vila> mgz: I still haven't understood where the cycle occur which a bit frustrating (as in: If I don't grok this one, how could I know if I'm introducing cycles without realizing it)
<vila> and how on earth do you say 'without realizing it' in a shorter form in English ?
<mgz> unwittingly?
<fullermd> Cycles just mean the bits of code are friendly with each other.  Who can be opposed to friendly code?
<dash> it's like how you aren't supposed to date people in your office
<fullermd> That's a pretty unpleasant prohibition if you work at home...
<mgz> I agree it can be pretty obscure, but there are really not many places that do it, and most would be clearer written another way (eg, rather than putting testcase instance methods on an object instance to override, use a subclass
<mgz> )
<fullermd> (Though actually, back when I worked in an office and dated somebody in it, it worked out OK)
<vila> Indeed, who said you can't date in your office ?
<vila> mgz: can't you just add cleanup for these instances methods (yeah, yeah, I know, I know, not the same, but still) or are they needed *after* the cleanups are called (define another cleanup list in this case ;-p)
<mgz> I have been!
<vila> Can't you also replace the ugly except/finally by a simpler call so that the ugly construct is defined only once with a loooong docstring ?
<vila> mgz: You have been... what ?
<vila> :)
<mgz> adding cleanups for the tests that do slightly odd things with bound methods
<vila> ha, right, sorry, not sure I read the last diff :-(
<mgz> I've only done try/finally in a few cases where the code just wants to get ripped out later anyway, and for lock decorators where I can't think of a better idea.
<vila> mgz: I'm not against the construct itself (I trust you about breaking the cycle this way, it's just that I'd like to *see* it), it's about its repetition in several places
<vila> It spread FUD, literally :)
<mgz> yeah, but, blame the existing lock decorator code for that, has the same thing four times.
<vila> mgz: one more reason to address it in a cleaner way :-D
<mgz> patches welcome! :p
<vila> mgz: The underlying fear in my case is that closure create cycles in an unexpected (to me) way
<vila> mgz: you're right, I should do that
<vila> mgz: except you're taking my offer to collaborate on one mp and divert it to *another* mp which is... border line ? :-D
<mgz> right, I think that's a small but potentially valid fear, hence the testing for that and printing if a test isn't freed
<mgz> not caring about it unless a big gc at the end doesn't shift the test is the other option
<vila> mgz: Well, all I can say at this point is that this sounds a lot like: mp author: "We need this because X", reviewer: "Why not Y instead", author . o O (You have no idea about what X means, don't you ?)
<aaronfay> Hello all, just started looking at bazaar.  I'm interested in the push ftp feature, and I'm trying to stage an existing Wordpress setup with bzr.  I guess my question is: can I have bzr ftp files into an existing scenario?
<mgz> aaronfay: yes. it's not nessersarily the best way of doing deployment, but it can work.
<aaronfay> mgz: Thanks, I'm green with bazaar, longtime svn user.  This is probably not the best way to deploy sites, I know.  My problem is: I'm a django developer but more and more I'm working on client wordpress sites.  I generally don't have shell access, so I need a sane way to manage versioning themes/plugins/etc.  I've known I needed to switch to a dvcs anyway...
<mars> abentley, ping, if you have a moment, I have a question about bzr send with pipelines
<vila> aaronfay: lp:bzr-upload
<abentley> mars: sure.
<mars> abentley, so I've done this before: 'bzr send -r ancestor::prev..'.  Is it supposed to set the prerequisite branch on the merge proposal for me?
<aaronfay> vila: fantastic, thank you.
<rocky> is there an easy way to see what the date/time was that a revision was pulled into a branch (not the original date/time of the actual revision)
<vila> aaronfay: feedback welcome
<abentley> mars: no.  Prerequisite branches are a Launchpad thing, not a Bazaar thing.  The Bazaar merge directive format does not support them.  I recommend using lp-propose.
<mars> abentley, great, thanks
<mars> abentley, so lp-propose understands pipelines?  Or is there some other mechanism linking the two branches?
<abentley> mars: lp-propose provides hooks that bzr-pipeline uses to set the prerequisite branch to the previous pipe.
<mars> ah, cool
<abentley> mars: It's all a bit cute, because it's my own code cooperating with my own code.
<mars> abentley, its well worth it.  bzr-pipeline is awesome
<abentley> mars: I'm glad you like it.
<peitschie_> rocky: no clue here sorry
<konr> why do you personally use bzr?
<dash> konr: 'cause it's the best
<dash> obviously.
<konr> haha
<konr> But Git has github, in which you can post your photo and have friends and followers!
<dash> launchpad's better.
<peitschie_> +1 for launchpad
<peitschie_> issue tracking & integration with bzr is very handy
<peitschie_> other big plus is the low barrier to mods through the rather nice bzr plugin system
<peitschie_> took me about an hr to figure out how to write a few basic plugins
<peitschie_> which have since easily been worth the time spent writing them :)
<Kobaz> i find launchpad to be a bit slow
<dash> i don't mind, i am too.
<RenatoSilva> why does bzr branch lp:project work if I have no key loaded in ssh-agent?
<RenatoSilva> it's http not ssh? it defaults to http transport if no ssh key is loaded, that's it?
<Kamping_Kaiser> i'd have expected it to use bzr:// if bzr+ssh isn't available
<Kamping_Kaiser> but i'm not ina position to answer your question
<RenatoSilva> it's worse actually, even after ssh-add, I can't push to Launchpad
<RenatoSilva> I was missing bzr launchpad-login (I thought my private key would act as identifier but ok)
<fullermd> Launchpad doens't serve bzr://
<konr> oh god, 300mb and Emacs's repo is still at 68/113 :(
<RenatoSilva> anyhow I'd like to understand this, in windows bzr doesn't default to http, but here in linux it does
<Kamping_Kaiser> fullermd: really? i'm supprised but ok :)
<RenatoSilva> hmmm it was because of launchpad-login, if it's empty then bzr uses http it seems
<fullermd> Yes, that's how the lp: lookup chooses.
 * RenatoSilva pushed succesfully his tool for using ppk keys in linux: https://code.launchpad.net/~renatosilva/+junk/loadppk
<aaronfay> vila: what is the advantage of bzr_upload vs bzr push sftp://...
<aaronfay> I'm seeing now that push sftp isn't doing what I want.  I see it's created a directory remotely, but there are no files in it
<RenatoSilva> how to delete a lp branch from bzr?
<aaronfay> Hmm, ok, using both push sftp and push ftp (--create-prefix) I see the folder is created, but no files are added, any recommendations?
<fullermd> Push pushes the VCS info, not the working tree files.
<aaronfay> fullermd: Thanks for clarifying that.  What is the advantage/purpose of that?
<fullermd> I...   um...   I don't know how to answer that.   :)
<aaronfay> vila: Fantastic plugin, I like the 'using saved location' feature.  That's what you call a time saver :)
<fullermd> That's just what it's for...
<aaronfay> fullermd: Hmm, no worries, I'm sure it will become apparent to me down the road
<fullermd> It's the dual to pull.  Pull is for syncing the local branch to a branch $THERE, push is for syncing a branch $THERE to the local branch.
<aaronfay> But not the files?
<vila> aaronfay: pushing the VCS info (the .bzr directory) is publishing the whole history of your project, if it's behind an http server, everybody able to reach your site can download it
<vila> aaronfay: bzr-upload, by contrast, only upload the working tree and *none* of the history
<aaronfay> Okay, I see
<aaronfay> bzr-upload isn't a branch then
<aaronfay> So it would be safe to say I could create a branch remotely with both push and bzr-upload
<vila> aaronfay: if you want *both* then bzr-upload is not the solution, you want bzr-push-and-update (but this requires ssh access AFAIR)
<aaronfay> Okay, makes sense
<aaronfay> Thanks for the clarification
<vila> aaronfay: 'using saved location' was 100% borrowed from bzr itself :)
<vila> push/pull/update/missing/merge/send and I forget some certainly, all use the same principle
<aaronfay> vila: as a cheat, could you "bzr push <location>" and then "bzr upload <location>" ?  That would effectively upload the .bzr folder and the files, correct?
<aaronfay> I'm having trouble finding paramiko, is my problem
<vila> aaronfay: yes
<aaronfay> vila: Okay, sounds like a good scenario for fab
<vila> aaronfay: OS/bzr versions ?
<vila> fab ?
<aaronfay> vila: XP sp3 (fab -> fabric)
<aaronfay> vila: bzr 2.2.1
<vila> aaronfay: if you use the bzr installer, paramiko should be included... jam, GaryvdM or bialix or any windows user will answer that better than me
<aaronfay> vila: fabric is a python library for deploying stuff/automating stuff.  It will SSh and do all kinds of funky stuff, basically you set up a fab.py file, write a couple functions (that can do thinks locally or remotely) and then you run (for example) fab update
<vila> aaronfay: but it's rather unusual to upload the wroking tree *AND* push the branch
<aaronfay> vila: the 'update' function might commit local changes, log into a server, and then svn up the changes remotely, delete a few things, etc, all in one command
<vila> aaronfay: as soon as you have access via ssh on the server, 1) use a smart server, 2) update the working tree locally
<aaronfay> vila: my issue is: I need to be able to push files to a server I don't have ssh access to, and it would be equally nice to leave a copy of the branch there for future usage if possible
<vila> aaronfay: just use hooks either in the bzr client or the bzr server, if you're already writing python code, you'll feel at home and get access to all the needed objects
<aaronfay> vila: in most cases I can't run bzr server :(
<vila> aaronfay: you'd better push the branch in another place
<aaronfay> vila: Thanks for your input, I have a much clearer idea where to start now.  Cheers
<vila> aaronfay: if you have an ssh shell access and can run bzr there, you already have a bzr server
<aaronfay> vila: sorry, can you elaborate on the last part?
<vila> aaronfay: there is *nothing* to configure
<aaronfay> vila: how do you "start" it?  Or do you serve it over apache?
<vila> aaronfay: all the client has to know is where bzr is on the remote side if it's not in default path
<vila> aaronfay: roughly: 'ssh <server> bzr serve' is launched on the client and we send commands and receive answers
<vila> aaronfay: so if you have a branch in your home directory at example.com you do: bzr branch bzr+ssh://example.com/~/my/branch
<aaronfay> vila: Okay, very good to know
<vila> aaronfay: if bzr is not in the default path you do: BZR_REMOTE_PATH=/path/on/remote/bzr bzr branch bzr+ssh://example.com/~/my/branch
<vila> aaronfay: or the equivalent on windows
<aaronfay> Heh, this is very fantastic, I'm quite excited about Bazaar.
<aaronfay> Thanks again for all your input.
<vila> Always happy to help (tm jam)
 * vila off to bed 8-/
#bzr 2010-10-23
<pynonoir> hi there. Should I set an incomplete bzr bug as new once completed ?
<pynonoir> (on launchpad)
<vila> pynonoir: no, wait for an answer from someone that will set it to confirmed and set the importance
<vila> pynonoir: what's the bug number ?
<pynonoir> https://bugs.launchpad.net/bzr/+bug/665100
<ubot5> Launchpad bug 665100 in Bazaar "bzr+http does not send x-www-form-urlencoded data (but pretends to) (affected: 1, heat: 6)" [Undecided,Incomplete]
<vila> ha, this one, the mysterious :)
<pynonoir> :)
<pynonoir> it's because of urllib
<vila> amazing
<vila> pynonoir: would you like to write a patch for that ?
<vila> pynonoir: Can you try http://paste.ubuntu.com/518575/ ?
<pynonoir> vila: trying that patch
<pynonoir> vila: I probably won't have time before tonight
<vila> pynonoir: nevermind, I just finish writing it with tests and also handling pycurl, thanks for reporting it, its' .... amazing nobody encountered the issue before
<pynonoir> too fast for me :)
<vila> pynonoir: what OS are you using and why still bzr-2.1.2 ?
<pynonoir> thanks
<pynonoir> debian testing
<vila> pynonoir: hehe, np, I'm still drinking my first coffee and was really curious
<pynonoir> well, i probably need to uprade
<vila> hmm, yeah, or run from sources
<vila> grr, I wish we have a better answer for that, it's a shame we can't build packages for debian in ppas like we do for Ubuntu...
<vila> pynonoir: can you mention that (debian testing) in the bug report ?
<pynonoir> np, i'm not a bzr power user and 2.1 is probably good enough for me
<pynonoir> which bug report ? 665100 ?
<pynonoir> what for ?
<vila> pynonoir: so we don't forget to backport it to  2.1 or 2.2 (I've forgotten again the rules that apply here to ensure you get the fix from your usual repo )
<vila> pynonoir: said otherwise: give us feedback about the bug and tell us how you get the fix whatever the way you use
<vila> pynonoir: this will help people that encounter the same problem, bugs are often used for that
<pynonoir> i'll do it but I bet that nobody will notice this one for a long time ;)
<vila> hehe, you never know, once a bug starts to manifest itself, it has a tendency to spread :)
<pynonoir> I saw it because there was also a bug in a wsgi framework I'm using
<pynonoir> this framamework re-encoded it with urlencode
<pynonoir> but it could not be reverted
<vila> pynonoir: what are you using bzr for here ?
<vila> pynonoir: https://code.edge.launchpad.net/~vila/bzr/665100-content-type/+merge/39194 is up for review
<pynonoir> vila, I was starting a forge for bzr projects with fine grained access levels to branches, over http
<vila> pynonoir: interesting ! You should write to the ML for feedback, we don't have yet a definitive good answer to this kind of setup and several people have already ask for such a feature
<vila> pynonoir: with different setups, but I'm sure discussing yours could help
<pynonoir> vila: yes, I just want to have something to show up before talking too much about it
<pynonoir> and i don't have a lot of time to hack with it
<vila> pynonoir: no problem, take your time :) And happy hacking !
<pynonoir> :)
<pynonoir> ty
<dnivra> hello. I just filed a bug at launchpad https://bugs.edge.launchpad.net/bzr/+bug/665560. I downloaded the source of bzr and found that almost all errors do not give any GUI feedback. I was just wondering if this is an implementation feature?
<ubot5> Launchpad bug 665560 in Bazaar "bazaar preferences window closes immediately on opening (affected: 1, heat: 6)" [Undecided,New]
<dnivra> the problem arises because the details are not set-"bzr whoami". hence the preferences window doesn't open.
<NET||abuse> hey there, i'm on windows at home (due to a laptop return to my old employer) and branching code from my server hits a problem when it reaches the symlink i put in there :(
<NET||abuse> i guess you shouldn't track symlinks
<NET||abuse> problem none of the files are getting put out to the working copy.
<NET||abuse> the .bzr directory is created, just no files.
<NET||abuse> bzr: ERROR: Unable to create symlink 'system' on this platform
<NET||abuse> goddamn windows
<NET||abuse> so how do i get my code out of the repo??
<NET||abuse> how can i pull the code out of the branch and ust ignore symlinks?
<NET||abuse> infact, if i have the branch in the local background repo( .bzr/ directory) but no working copy files in the location, how do i get at one particular working copy path ? eg, my projects /assets  path is fine, it's just there's a /framework   symlink in the root dir, but ijust specify the /asets dir can i just ignore any other paths?
<NET||abuse> ok, so i'm on windows, a repo has 1 symlink on the root dir, how do i just get all the dirs of a branch that have no symlinks?
<RenatoSilva> The authenticity of host 'bazaar.launchpad.net (91.189.90.11)' can't be established.
<RenatoSilva> how to be 'sure' it's the right host?
<RenatoSilva> connect through https and check if "fingerprint" matches?
<jam> here is my fingerprint: 024 9d:38:3a:63:b1:d5:6f:c4:44:67:53:49:2e:ee:fc:89 bazaar.launchpad.net,82.211.81.254 (RSA)
<jam> different ip address, though
<RenatoSilva> how to actually check the fingerprint? I thought it would be listed somewhere in the website through https (assuming the server is not compromised of course)
<jam> RenatoSilva: I don't know that the ssh fingerprint is going to be available via ssh
<jam> but when you connect for the first time, it should tell you what it thinks the fingerprint is
<RenatoSilva> what do you mean
<jam> RenatoSilva: when I connect it says "the fingerprint of the server is XXXXX are you sure you want to connect"
<RenatoSilva> right, and how can I trust it is the real fingerprint, that is, no one is on the middle changing the original one?
<jam> RenatoSilva: well, you can compare it to the one I just pasted.
<NET||abuse> ok, so i'm on windows, a repo has 1 symlink on the root dir, how do i just get all the dirs of a branch that have no symlinks? or just exclude the symlinks?
<jam> NET||abuse: afaik, it isn't directly possible. there is a 'bzr-win32symlinks' plugin that you can try
<RenatoSilva> jam: you could be exactly the cracker trying to fool me
<jam> RenatoSilva: yep.
<jam> depends on how paranoid you want to be about ssh
<RenatoSilva> jam: I don't think it's paranoid
<RenatoSilva> jam: it's just about using the feature correctly
<jam> RenatoSilva: it is a paranoia feature. And you have to decide what your risk vs reward tradeoff is worthwhile
<jam> if I was going to be sharing my deepest darkest secrets, then I would worry
<RenatoSilva> jam: otherwise you're fooling yourself with a false sense of security
<jam> if I'm publishing source code that *is going to be free and in the open anyway* I don't care about pushing it to a site that might publish it...
<RenatoSilva> jam: bzr server could be a hack stealing my sensitive data
<jam> RenatoSilva: well there you have to decide how much you trust your client...
<jam> your local 'ssh' process could be a hack
<RenatoSilva> jam: I just think there's a simple solution for that: put the fingerprint somewhere in the website through https
<jam> RenatoSilva: makes sense, but it isn't anywhere on launchpad that my quick googling found
<jam> up to you
<RenatoSilva> put it? no, some admin
<NET||abuse> i pulled down the win32 symlinks bzr plugin, i put it in /users/me/AppData/bazaar/2.0/plugins/
<NET||abuse> it's not loading seemingly.
<mgz> NET||abuse: wow, how long have you been trying to branch your symlink?
<NET||abuse> ahh, on and off all afternoon :)
<mgz> if it's a public branch, I'll just branch it for you, delete the symlink, and give you a link.
<NET||abuse> it's a saturday :)
<NET||abuse> no, not public
<NET||abuse> a site i biult for a friend good while back
<mgz> otherwise, you pretty much need a unix environment
<NET||abuse> arse.
<mgz> so, cygwin, or a vm, or a nix box.
<NET||abuse> have to open up the lil' laptop oh nightmares.
<mgz> and yes, this sucks.
<NET||abuse> could export it on the server then download
<NET||abuse> hmm
<NET||abuse> but then' i'd not be ableto commit the changes to the site inside of bzr so effectively
<mgz> if you can ssh to the server, make a branch there, delete the symlink, commit and branch that.
<NET||abuse> SUCKs that my old company wanted my linux laptop back.
<NET||abuse> eh, that's  aperfectly reasonable approch, so obvious
<NET||abuse> god i hate the windows tool set, putty.exe    yuch
<NET||abuse> I WANT MY LINUX ENVIRONMENT BACK
<NET||abuse> how can i  just expose a target directroy within my branch in the working copy?
<NET||abuse> ok, never mind, did what you suggest.
<NET||abuse> but i have the bzr branch downlaoded, but none of the files are in the working area, they're all in the db in the .bzr/ directory
<NET||abuse> i do not want to download 800MB of repo again.
<NET||abuse> how can i get it to output the files now?
<NET||abuse> when i do bzr status,, i get a huge list of files, but no idea what the heading they're all in is about?
<NET||abuse> the cmd.exe buffer is only 999 lines long.
<NET||abuse> can't extend it.
<mgz> | more ?
<NET||abuse> windows, not linux
<mgz> cmd has more just not less
<mgz> you should just be able to do `bzr pull` if you updated the branch on the server
<NET||abuse> ohhh, haha, didn't know windows had that.
<NET||abuse> yeh, i pull'd but the files are only in the background branch,
<NET||abuse> not out where i can edit them.
<NET||abuse> ahh, it says all those files are removed?
<NET||abuse> which isn't the case
<NET||abuse> the whole project is apparently "removed"
<mgz> probably just an artefact of of failing to create the working tree
<NET||abuse> exactly what i'm thinking now.... hmm, ok , so how to un "remove" everything?
<mgz> once the symlink is gone in the latest revision, `bzr revert` will get your tree back
<NET||abuse> just tried that
<NET||abuse> bzr: ERROR: No final name for trans_id 'new-10'
<mgz> that's... interesting
<NET||abuse> file-id: None            root trans-id:'new-0'
<mgz> you did the pull?
<NET||abuse> yes
<NET||abuse> i did pull, i tried pull, then tried revert, tried pull again, revert again.
<NET||abuse> nothing.
<mgz> what does `bzr log -l 1` say?
<NET||abuse> gives me the log from the server where i removed the symlink
<NET||abuse> and the previous log from work
<mgz> okay.
<NET||abuse> where i fixed a php issue
<NET||abuse> although in the same message as the last log.
<mgz> new idea:
<NET||abuse> ...
<mgz> do `bzr branch . ..\new_copy_of_branch`
<mgz> so you create a new local branch, but without redownloading 800MB
<NET||abuse> ye, giving that a gol
<NET||abuse> ahhhhrrrrggg
<mgz> ...same error?
<NET||abuse> same error unable to create symlink
<NET||abuse> but i removed that damn sim link and commit ed it on the server
<mgz> meph, the local branch has apparently not picked up that rev.
<mgz> okay, how about this
<mgz> `bzr branch --no-tree . ..\another_new_branch && bzr pull --remember url:original_branch && bzr reconfigure --tree`
<mgz> get me?
<mgz> gra
<mgz> change the cwd between step 1 and 2.
<NET||abuse> ...
<mgz> `bzr branch --no-tree . ..\another_new_branch && cd ..\another_new_branch && bzr pull --remember url:original_branch && bzr reconfigure --tree`
<mgz> (sorry)
<NET||abuse> :P
<NET||abuse> one sec.
<NET||abuse> I hate windows
<NET||abuse> 2 people in this world need to die
<NET||abuse> jobs and gates
<NET||abuse> grrrrr
<NET||abuse> arrrggggg
<NET||abuse> nope, on the last step, bzr reconfigure --tree    it throws that damn error agian
<mgz> which one? symlink or trans-id?
<NET||abuse> symlink
<mgz> ...and log shows that the last rev is the one where you removed the symlink?
<NET||abuse> yep
<NET||abuse> can i hire some terrorists to bomb redmond now?
<NET||abuse> not only that but the putty  TCP_KEEPALIVE doesn't work....
<NET||abuse> damn ssh session to the server keeps dying.
<mgz> okay, I'd double check that the top rev on the server really has no symlinks, and if you missed one, commit and pull again before doing the reconfigure.
<mgz> otherwise... out of ideas.
<NET||abuse> hmmm, wait.
<NET||abuse> the log is not the same number
<NET||abuse> the server is on rev 44, the local is only 43,
<NET||abuse> arrrg,, ok,,  tried that 6 times before,,
<NET||abuse> finaly pull worked
<NET||abuse> and revert worked now
<NET||abuse> bloody hell.. what a mess
<NET||abuse> mgz, thanks for all that.
<mgz> cool.
#bzr 2010-10-24
<KombuchaKip> Zeitgeist 3 trailer: http://www.youtube.com/watch?v=QYLLFpNn4lM
<johnjosephbachir> howdy.
<johnjosephbachir> i'm in the middle of a product launch and i'm getting some errors
<johnjosephbachir> https://gist.github.com/6d733b2c122c2a9d0be6
<ebichete> Hello. I am trying to send a merge request to the mailing list using the instructions on the bzr-gtk wiki but receive an error "No mail-to address or output specified". Is there a special dance required to do this ?
<yann2> hello! I am trying to understand why bzr push doesnt update the working tree - cant I do a push that does update the working tree?
<bob2> not with bzr
<bob2> there's a plugin for it
<bob2> or you can run 'bzr up' on the other side
<yann2> via ssh eh... I guess I'll do that
<peitschie> mornin every1
#bzr 2011-10-17
<spm> http://www.drive.com.au/used-cars/lotus/elise/sydney/detail.aspx?id=28665759&lid=28665759&pg=1&pp=3&d=0&SG=-648505432&pt=1 <== poolie, is there something you're not telling us?
<poolie> :)
<poolie> http://www.carsales.com.au/all-cars/dealer/details.aspx?Cr=0&R=10735936&keywords=&trecs=200057&__sid=131D45747131&__Ns=pCar_PriceSort_Decimal|1||pCar_RankSort_Int32|1||pCar_Make_String|0||pCar_Model_String|0&__Qpb=1&tsrc=allcarhome&__Nne=15&seot=1&__N=1216%201246%201247%201252%201282&silo=1011#
<spm> some missed a decimal place....
<poolie> i don't know about them
<poolie> it seems very oddly specific
<spm> algorithmic updates gone bad?
<poolie> could be
<poolie> some weird attempt at SEO by making them sort to the top?
<jam1> morning all
<poolie> hi jam
<vila> hey jam, hey gang !
<Riddell> hola
<jelmer> Goeiesmorgens deze morgen!
<poolie> hi riddell, jelmer
<Merwin> Hi. I just did a merge and got a "Contents conflict" in some files, but there is no ">>>" things to resolve in the file, and only a .BASE and .OTHER files, what should I do ?
<poolie> Merwin: it may have been added with different contents on different branches
<poolie> so see if they're different
<poolie> then probably 'bzr mv foo.BASE foo' and then edit it to taste
<Merwin> ok I'll make a diff on BASe and OTHER to check
<Merwin> There is a difference, something changed in .OTHER
<Merwin> Isn't it better to take .OTHER as reference ?
<Merwin> I meav, replace xxx with xxx.OTHER?
<Merwin> mean*
<mgz> morning all
<Riddell> good morning Norwich
<mgz> :)
<poolie> hi mgz
<mgz> does the package importer still need sorting out?
<poolie> in general yes :)
<poolie> i'm not aware of any critical issues but i also haven't looked today
<poolie> i think dpkg did import
<mgz> okay.
<jelmer> poolie, mgz: thanks for the reviews!
<jelmer> I managed to get the number of failing tests from running bzr's interface tests against bzr-svn down to 9 over the weekend
<jelmer> with 3 underlying remaining issues, one of which is the get_revision_delta thing I mailed the list about
<mgz> Riddell: how do we land things for qbzr? merge to trunk and push?
<mgz> jelmer: cool
<awilkins> jelmer, How well does the gnome-keyring support in bzr-gtk work with bzr-svn ?
<Riddell> mgz: yes just so, no pqm or the like
<mgz> thanks!
<jelmer> awilkins: IIRC there were some issues, somebody worked on a patch to improve it but I'm not sure what the status of that is
<jelmer> awilkins: https://code.launchpad.net/~chy-causer/bzr-gtk/fix-svn-keyring/+merge/60817
<awilkins> jelmer, I think I've avoided this so far because something always forces plaintext auth storage in SVN, but I've just installed oneiric and I don't think that thing has forced this yet
<awilkins> Comparing the ~/.subversion auth configs for this repo, the old one uses plain, the new one uses gnome-keyring, and my old SVN config has an empty list for the password stores (which I think is set by something that prompts you to do so automatically)
<awilkins> Shall try this patch, it's v.small
<jelmer> awilkins: please do comment on whether the patch works for you
<jelmer> I should really take some time to review it
<awilkins> jelmer, It didn't work for me ; but it may be because I'm using an explicit svn+https:// url
<awilkins> jelmer, I need to look and see but for now I've reverted the SVN config back to the old plain auth file
<jelmer> awilkins: ok, thanks for letting me know
<awilkins> jelmer, Have to use that explicit URL because this repo emits server errors instead of 404s if you as for .bzr smart URIs
<jelmer> awilkins: have you tried https recently? bzr-svn now probes before the bzr smart server
<awilkins> Not tried that recently, I'll have to have a go at it
<mgz> ha, I'm not actually a member of qbzr developers
<mgz> perhaps I should ask Alexander if I can join.
<jelmer> mgz: you should :)
<awilkins> jelmer, Here's a case - another user is using SVN to perform merges outward from trunk. Have pulled his branch and subsequently merged outward also ; lots of "duplicate" conflicts. Looking in the SVN log, the files were copied correctly by the SVN merge (as hardlinks in the SVN FSFS) and preserve history - they should have the same file-id and not conflict, no?
<jelmer> awilkins: no, as bzr doesn't support copies
<awilkins> jelmer, But it does support adding files to separate branches with the same file-id ; it should already know about these files in the repository because they are copies from a branch I have already pulled.
<awilkins> They are not copies within the scope of the branch, they are copies from the other branch for the purposes of the merge outward by the SVN client
<jelmer> awilkins: sure, but they have a different file id - and file ids are the only thing that's used to prove that two files are in fact the same by bzr merge
<jelmer> awilkins: until copy support is added to bzr, I don't see how this would work
<awilkins> jelmer, Should it be possible to assign them the same file id though - SVN knows the file is a copy ; if in that case, we assign the file-id based on the copied-from file rather than the place it was copied to, the file-id will be the same (if the file is not modified at the same time it is copied, it is the same file - right down to the inode in the SVN repository)
<jelmer> awilkins: bzr-svn doesn't have access to the inode information in the svn repository, that's not exposed by the svn protocol
<jelmer> awilkins: it could do analysis to see if the file was only copied and then scan history to see no other copies are left around
<awilkins> jelmer, the svn log viewer knows it's a copy from a particular branch / revision
<awilkins> Would it be possible to infer from that?
<jelmer> awilkins: yes, but we can only keep the file id if it is the *only* copy
<jelmer> and that's the tricky bit
<awilkins> Does that hold for the more specific case  "we can keep the file id if it is the only copy in the current inventory" ?
<jelmer> awilkins: yes, but note that it can be hard to determine that too
<awilkins> I feel like I'm missing something - the inventory has the list of all it's file-ids in .. what's the difficult case (I know too little about internals)
<jelmer> awilkins: what if a file is being copied in from elsewhere, how do you know its file id?
<jelmer> awilkins: you have to do the same analysis all over again for all inventories it has ever been part of
<jelmer> awilkins: and at each step determine whether or not it could keep its id
<awilkins> This is becoming more complex than I have time for... :-( git does better at this because the objects are the same (same content) but of course not at explicit renaming.
<jelmer> right
<awilkins> But I prefer bzr-svn because it makes pushing much less ... fraught
<jelmer> git doesn't store renames or copies and always infers them later on, so it doesn't matter how they were in svn
<awilkins> I don't like the git-svn design of storing metadata in the git commit log which is an effective rewrite of your git branch which ruins it for sharing with people
<jelmer> bzr should support inferring renames from copies (that's basically what you're asking for), but I really think that support should be in bzr core, and not in bzr-svn
<jelmer> and that shouldn't have to involve the file ids staying the same, as keeping the file ids the same has a lot of performance impact
<awilkins> I shall just have to browbeat the person doing the merges into using bzr :-)
<awilkins> For the time being....
<jelmer> awilkins: did you see my last few lines?
<awilkins> The bit about inferring renames from copies?
<awilkins> Last log I have from you was at 1100 UTC when you rejoined the channel
<awilkins> jelmer, Sorry, forgot to prefix see above ^
<jelmer> <jelmer> awilkins: it's one of the things I would really like to work on, and we're slowly getting rid of the assumptions in the code that two files that are the same necessarily have the same file id everywhere
<jelmer> <jelmer> that is, not abandoning file ids to prove equivalency in inter-tree operations, but allowing them to be different despite two files being the same
<awilkins> jelmer, So a slightly more enlightened merge that knows two files with the same path and same content but with different file-id might not be a merge conflict?
<jelmer> awilkins: right
<Riddell> how can I forcibly create the conditions where I have to run bzr break-lock?
<Riddell> the bzr server seems very good at not lockings, it seems I can even push to the same repository from two places at the same time
<jelmer> Riddell: I suspect just opening a write lock and not unlocking should be sufficient
<jelmer> Riddell: have you looked at bzrlib/tests/blackbox/test_break_lock.py for inspiration?
<Riddell> good idea
<spiv> Riddell: python -c "from bzrlib.bzrdir import BzrDir; b = BzrDir.open('some/path').open_branch(); b.lock_write(); b.leave_lock_in_place()"
<mgz> ah, neat spiv, I thought it was more of a pain than that.
<Riddell> spiv: thanks, I'd worked that out :)
<vila> hu ho, what happened to the package importer ?
<vila> mgz: any idea ^ ?
<vila> It looks like someone killed it.  Should I just restart it ?
<mgz> vila: I stopped it as part of the release process
<vila> oh, ok
<mgz> and after build-distro failed, no one was sure if it was safe to restart or not
<vila> what's build-distro ? An lp thing ?
<mgz> so, it's waiting for someone who knows what they're doing to take over
<mgz> yeah, basically making new branches for the P-series
<vila> hmm, I think wgrant did it last time
<vila> probably sleeping right now
<mgz> I have a log of the output that gnuoy got, with some warnings about stacking then an uninformative error at the end
<mgz> wgrant is who told me to look at the log.
<mgz> so, I guess we still don't have anyone who actually understands this? :)
<vila> oh, so something failed on lp, ok
<vila> hmm
<mgz> I think I worded my question about this to poolie poorly this morning, he didn't seem to think there was an issue
<mgz> so, I probably should write up a summary and send it to some list (which?) so anyone concerned knows where we ar
<mgz> +e
<Riddell> canonical-bazaar and lauchpad-dev maybe
<mgz> thanks Riddell, I'll do that now.
<mgz> I see from ubuntu-devel cjwatson fixed (a different) issue with syncpackage
<mgz> that's completely unrelated I think.
<vila> may be not
<cjwatson> it is completely unrelated
<vila> ha
<vila> :)
<vila> cjwatson: you didn't create any precise branch on lp ?
<cjwatson> loads of precise branches have been created (though not by me personally)
<cjwatson> the question was whether that process has definitely been completed, not whether it was started
<vila> cjwatson: yup, AIUI, the process failed midway, so I was wondering if some branches were created later and may have fixed the original issue
<cjwatson> no idea, sorry
<vila> np, thanks anyway
<DonDiego> moin
<DonDiego> i have trouble with ~/.bazaar/rules not working as promised
<DonDiego> wildcard rules appear to override more specific rules before them, contrary to what the documentation claims
<DonDiego> is this some sort of known problem?
<mgz> DonDiego: I think this may be a sort-of known issue with conf sections, but I don't see a bug entry for .bazaar/rules so I'd file a bug
<redwyre> when using bzr-svn to push to an empty svn depo, should I be getting correct times and authors?
<DonDiego> author will be the svn commit nick and not the real author (if they are not the same)
<DonDiego> mgz: thanks, will do
<redwyre> shouldn't it keep the original authors of the changes?
<mgz> hm, the prediction of fullermd on friday came true.
<mgz> okay, I've sent a message to launchpad-dev containing the sum total of my knowledge related to the stopped package importer
<DonDiego> redwyre: impossible, svn does not differentiate between author and committer - you could add the author to the log message, that's all
<redwyre> svn calls it author
<redwyre> but in my case all the svn change lists have the account I used to push as the author
<redwyre> not their original authors
<DonDiego> what is your question then?
<redwyre> how do I get it to push with original authors and timestamps
<DonDiego> still impossible with svn
<redwyre> how so?
<DonDiego> i repeat: svn does not differentiate between author and committer
<mgz> bazaar stores more information than svn, if you put your bzr repo in svn some of that information isn't represented by the svn format
<mgz> I think it's actually kept as hidden properties though.
<mgz> the alternative is dpush, which does throw away information, but might do the right thing with your commit id.
 * fullermd is a cheenius.
<mgz> you're a little ray of sunshine is what you are.
<fullermd> I know.  It's my finest quality.
<redwyre> I know I can't have author *and* commiter, but all I care about is author from bzr
<jelmer> redwyre: how are you pushing to svn?
<jelmer> redwyre: there is an option in bzr-svn that allows you to have svn:author set to the bzr author or committer
<redwyre> bzr push ~/svn/trunk
<redwyre> how do I get access to this option?
<jelmer> redwyre: the option is called "override-svn-revprops"
<jelmer> redwyre: see the bzr-svn FAQ
<redwyre> ah cool, does that work for the timestamps as well?
<jelmer> IIRC yes, if you set svn:date
<jelmer> arguably these options need better documentation
<redwyre> I think that FAQ should be part of the online docs ;)
<jelmer> redwyre: I don't think there are bzr-svn online docs..
<redwyre> this: http://wiki.bazaar.canonical.com/ForeignBranches/Subversion
<jelmer> ah, the wiki
<redwyre> jelmer: thanks for your help, I'll let you know how it goes tomorrow
<jelmer> redwyre: np
<michaelh1> Hi there.  How can I pull a commit from a tree into a vendor branch and re-use the author, comment, etc?
<lifeless> replay
<poolie> hi all
<michaelh1> That's a tricky one to find.  The hidden replay command from bzr-rewrite...
<poolie> hi all, hi michaelh1
<michaelh1> Hi poolie
<maxb> Note that replay constructs a history-rewritten version of a commit, rather than merging and committing re-using the original commit's metadata
<maxb> that may or may not be what you want, I don't quite know from your initial question
<michaelh1> Hmm.  Here's the situation:
<michaelh1>  * Upstream is crosstool-NG and is hosted in Mercurial
<michaelh1>  * We work upstream, sending many small patches.  Using Mercurial is fine for this
<michaelh1>  * I need a product/vendor branch for release workings and non-upstreamable stuff
<michaelh1>  * Upstream is mirrored down into a Launchpad/bzr branch
<poolie> hi maxb
<michaelh1>  * I want to minimise the overhead of pulling in upstream to our product branch but would prefer to keep the top level history.
<michaelh1> bzr merge is fine, but retyping the message might be longer than the patch!
<maxb> right... so you really want something that prepopulates the commit message from the revision(s) being merged
<maxb> I'd like something like that too :-)
<maxb> Doesn't seem like it would be hard to write as a plugin
<maxb> I'm pretty sure all the hooks are there for it
<wgz> I think I've even seen vila use something along those lines, though maybe his looked at NEWS or such like.
<michaelh1> In some ways I want the product branch to be an overlay of trunk, but I can't see how to make it usable day-to-day.
<wgz> and as the antipodes are up, it must be bed time.
<poolie> hi there, sleep well
<poolie> michaelh1: can you expand on that last bullet point?
<wgz> night!
<michaelh1> Yip.  So upstream is quite stable and using tip is fine.  This is nice as our release could be tip + things that are in flight + local only changes.
<michaelh1> Having a product branch gives control, but this means that the workflow is:
<michaelh1> Develop upstream, post, upstream merges, appears in bzr mirror, manual merge out to product branch
<poolie> so the product branch is a bzr branch, separate from the main import?
<michaelh1> Yip.  That seems best?  The import is supposed to be a mirror of upstream.
<michaelh1> I still want control of when 3rd party changes come into the product branch
<poolie> so you want every revision on trunk to appear as one mainline revision in your product branch, but also there'll be some other changes in between them?
<michaelh1> If I make a change upstream and they accept it, I want to pull it into our bzr product branch very cheaply.
<michaelh1> (also, what they commit may be a tweak over what was sent)
<poolie> so you could have just one commit to your product branch saying 'merge from trunk'
<poolie> but, then the product branch main line will look bad
<michaelh1> Ugly, yeah.
<poolie> and do you want one commit on the product branch every time you merge, or one for each thing from trunk?
<poolie> either way it sounds pretty feasible; the first perhaps a bit easier
<michaelh1> I could script it so that it pulls the summary line from the import so it becomes 'Merge r1234: cc/gcc: add the latest foo" and then you get detail through bzr log --include-merges
<michaelh1> There's two types of merge: pulling my feature in vs re-syncing with mainline.  I'm happy for the re-sync to lump revisions and have a unhelpful comment.
<poolie> right
<poolie> possibly just scripting it, even from bash, would be enough
<poolie> if you file a bug we could do a more integrated thing, especially if this is a pressing problem
<michaelh1> It's not pressing but we're just starting and I want to make sure the process is right.
<poolie> k
#bzr 2011-10-18
<Amis> Hello o/
<Amis> Are there any Bazaar branches out there that could be used as an example when having a presentation about Bazaar itself? (one that has a few commits and forks and stuff)
<AuroraBorealis> lp:bzr i think would be good
<AuroraBorealis> has a pretty log graph
<Amis> Lemme check
<AuroraBorealis> has lots of branches that have been merged into the main branch, etc
<Amis> Hmmm... I'm having trouble getting the source :/
<Amis> It must be that I don't have a Launchpad ID
<AuroraBorealis> it should work without it
<AuroraBorealis> just do bzr branch lp:bzr
<Amis> Yeah, I did that but it seems to be hang
<AuroraBorealis> are you able to branch other things?
<AuroraBorealis> check the .bzr.log file
<Amis> I am, even though I'm not used to the command line way
<AuroraBorealis> if you type bzr --version it should tell you where the log file is
<Amis> Hmm.. the log says it's actually doing something, if a flood of "25 bytes left on the HTTP socket" can be called something
<AuroraBorealis> sounds like a weird network problem o.o
<mgz> morning!
<AuroraBorealis> launchpad seems to be working for me but i'm logged in sooo
<AuroraBorealis> ask mgz, hes better :D
<Amis> Hehh
 * Amis pokes mgz
<mgz> what's the issue?
<Amis> Hmm, it may be the certificate
<AuroraBorealis> <Amis> Hmm.. the log says it's actually doing something, if a flood of "25 bytes left on the HTTP socket" can be called something
<AuroraBorealis> when trying to branch lp:bzr
<Amis> Do I need a Launchpad ID for that? I could pull the certification but that again requires a Launchpad ID
<mgz> did you supply a launchpad login first Amis?
<Amis> mgz, nope
<mgz> okay, so you're branching over http, which is generally slower
<Amis> So that wall of text is okay?
<AuroraBorealis> is the console giving any output?
<AuroraBorealis> there should be a progress bar of sorts
<mgz> I think without the smart server the progress is rather less informative
<Amis> AuroraBorealis, nope, but checking the console right now it seems to be finished even though there were no output at all beside the warning of missing Launchpad ID
<Amis> Let me check the folder
<mgz> yeah, it's probably done now.
<AuroraBorealis> i branch local stuff and it doesn't have a smart server and i still get the progress bar
<Amis> I thought it would be a lot more informative like "Working... Please wait!" or something :>
<mgz> locally doesn't go over http
<AuroraBorealis> bah
<mgz> for whatever reason that way gives less feedback... but it should really give *some*
 * Amis nods
<poolie> hi mgz, all
<mgz> hi poolie!
<Amis> Haha, I guess I killed the GUI by trying to get the log
<Amis> Thanks for the help! I gotta hop out for a few hours. Bye!
<jelmer> hi all
<mgz> morning jelmer.
<poolie> hi jelmer, mgz,
<poolie> hm shall we chat? i think it's now
<poolie> might give riddell a moment; vila said he won't be here
<jelmer> he is there actually :)
<Riddell> I was all on my own!
<poolie> https://dev.launchpad.net/LEP/SSH_OAuth
<poolie> bugs.launchpad.net/~sabdfl/+affectingbugs
<poolie> Riddell: well, there's all of https://bugs.launchpad.net/bzr/+bugs?field.tag=easy
<Riddell> poolie: yes that's what I was doing yesterday
<poolie> 4 of which are high, and all the high ones do seem plausible
<poolie> well i suppose it's fairly obvious :)
<Riddell> I'll try some more of the high ones
<mgz> the user interface bugs you've been doing have been a good bet Riddell
<mgz> for a different kind of thing, there are a few bugs against bzr for stuff it's hard to reuse in qbzr, we filed one for bzrlib.crash for instance
<mgz> then means thinking about the right way of redesigning the code without assuming a console interface
<vila> hey guys !
<mgz> morning vila!
<vila> mgz: so, should we restart the importer and monitor it ?
<jelmer> 'morning vila
<vila> mgz: if the fear is about stacking issues, I *was* already afraid when oneiric opened. But nothing happened.
<vila> That doesn't mean there are no issues, but if there are, they don't seem to bite us yet
<mgz> well, ideally we need to fix the list of misstacked branches
<mgz> which surely can't be impossible.
 * vila nods
<vila> but that can happen even with a running importer
<vila> in fact, I'd rather fix them *while* the importer run if only to catch issues in this kind of operations
<mgz> that sounds... reasonable to me.
<vila> my present fear is that we're building up a queue of potential issues
<vila> if this queue becomes too big... it will become harder to get back on track
<vila> ok, I'll restart it then
<vila> and stop it
<vila> Exception: ValueError: list.index(x): x not in list
<mgz> heh.
<vila> never saw that one
<mgz> pastebin the traceback?
<vila> rsyncing the log files
<vila> oh, probably requires to declare precise here and there...
<mgz> that sounds likely.
<mgz> if the series are hardcoded.
<vila> http://paste.ubuntu.com/711766/
<mgz> so... what's the branch with all these troublesome scripts in, so we can add the new name?
<vila> lp:udd , http://paste.ubuntu.com/711773/ is close enough to revno 425 there
<vila> start again
<mgz> cool.
<vila> stop again
<vila> I've deployed the pending revisions from lp:udd where jml shuffled scripts around, probably a typo somewhere:  http://paste.ubuntu.com/711774/
<mgz> fun.
<vila> starting again :)
<vila> now we need an import to succeed
<vila> bingo
<vila> 2 imports for precise already
<vila> jml: your script refactoring have been deployed and are live \o/
<vila> jml: I had to tweak import_package.py, if you can have a look at the latest lp:udd and check that would be nice
<vila> mgz: sounds good to me, I'll wait for the backlog to clear before requeuing the failed ones
<poolie> hi vila, welcome back
<vila> poolie: :-)
<poolie> ok, night all
<bialix> hi mgz
<bialix> mgz: do you remember why paramiko my trigger Access denied error while trying to talk with pageant on Windows? http://pastebin.com/FFSGgQ5n
<mgz> bialix: looking
<bialix> mgz: I think I found https://answers.launchpad.net/bzr/+question/166751
<bialix> mgz: congrat btw, I hope you enjoy your new job :-)
<mgz> bialix: previously people got that problem from running paramiko without installing it
<mgz> ...and that question suggests it's about the version used
<mgz> bialix: thanks!
<bialix> many thanks for the hints
<mgz> ^not paramiko, putty
 * bialix understood
<mgz> basically, pageant needs to be running as the same user and with the right privs, otherwise things go wrong
<mgz> bialix: I have a qbzr favour to ask
<bialix> your patch is ok for me, sorry for not responding so far
<mgz> no problem.
<bialix> maybe I'd use unicode-escape rather than utf-8. but...
<mgz> I wondered if I could join the qbzr developers group
<bialix> my RL consumes too much time, we need to release new version, very much
<mgz> ^I know, you have bad experiences with passing utf-8 around :)
<bialix> mgz: course, YOU CAN
<mgz> as long as its before the next beta that should be okay, it's getting some good testing still at least
<bialix> that's not question for me
<mgz> (this issue was found pretty promptly)
<bialix> mgz: I ought to make maintenance release for 2.4.x too :-/
<mgz> okay, I've proposed myself for ~qbzr-dev
<bialix> it will be honor for me to accept you
<bialix> thank you
<mgz> Riddell: I might be being dopey, by why trace.mutter(traceback.format_exc()) not trace.log_exception_quietly()?
<Riddell> mgz: I just didn't know about trace.log_exception_quietly()
<mgz> ...I think I may have formatted my review confusingly, my fault
<mgz> I should have a different way of spelling suggested changes from extracted existing changes
<Riddell> mgz: just don't include the "+" at the start of the line, that makes me read it as part of the existing changes
<Riddell> canonical types, what am I doing wrong with my smtp settings in bazaar.conf that feed-pqm doesn't want to send an e-mail?  https://pastebin.canonical.com/54491/
<Riddell> do I need to tell it to use ssl somehow?
<jelmer> Riddell: seems alright to me
<jelmer> Riddell: I have the exact same configuration
<jelmer> Riddell: are you running the old hydrazine or the new one from a couple of days ago?
<jelmer> perhaps one of the hydrazine changes broke things
<Riddell> 0.1-0ubuntu1+r99~oneiric1 from the PPA
<Riddell> http://paste.kde.org/135097/  bzrlib.errors.SMTPError: SMTP error: server refused HELO: 501 Syntactically invalid HELO argument(s)  could be hydrazine
<jelmer> mgz: ^
<mgz> looking.
<mgz> really, the way we're using email and smtplib they shouldn't let us break that.
<mgz> google suggests you may have a host name the internet doesn't like.
<mgz> could try using smtplib from a repl
<mgz> and what does `python -c "import socket;print socket.getfqdn()"` give you?
<jml> vila: thanks
<Riddell> mgz: gallus.(null)
<Riddell> mgz: hah, fixing that in /etc/hosts sorted it
 * Riddell files bug 877411 and bug 877413
<ubot5> Launchpad bug 877411 in Hydrazine "incomplete domain name fails to send e-mail" [Undecided,New] https://launchpad.net/bugs/877411
<ubot5> Launchpad bug 877413 in Hydrazine "feed-pqm error at end of approved proposals" [Undecided,New] https://launchpad.net/bugs/877413
<mgz> ha, second one is my fault.
<mgz> ...I'll just fix it now as it won't take long
<mgz> hum ho hum
<mneptok> dum dee dee
#bzr 2011-10-19
<poolie> hi all
 * slangasek waves to poolie 
<poolie> hey
<slangasek> does anyone here know why the openldap import is failing? the error message looks pretty wrong, openldap didn't exist in Debian woody. http://package-import.ubuntu.com/status/openldap.html#2011-06-15%2000:44:51.442540
<slangasek> (and that version number never existed for the openldap package)
<poolie> !
<slangasek> well, actually, I guess openldap *might* have existed in woody... but it was a completely different package back then, *before* it was renamed to openldap2 :)
<poolie> perhaps that's connected to the '2' epoch
<poolie> i need to reboot and perhaps debug something weird here, biab
<poolie> let's file a bug first
 * slangasek files
 * fullermd questions the meaningfulness of the microseconds term   :p
<poolie> patches welcome :)
<fullermd> I've been looking for the proper place to submit patches to physics for _years_!
<slangasek> poolie: bug #877827 filed
<ubot5> Launchpad bug 877827 in Ubuntu Distributed Development "openldap fails with "marked but not imported" for an ancient package version" [Undecided,New] https://launchpad.net/bugs/877827
<vila> hi all :)
<vila> poolie: ping
<poolie> hi vila
<vila> poolie: I pushed the importer too much ? :)
<poolie> how's it going?
<poolie> i think that trying to catch up with Precise opening made it too excited
<vila> hehe
<vila> that was me, I progressively raised max_threads to 24 and it was going well for several hours
<vila> looks like it's at 2 right now
<poolie> yes
<vila> I'll have to look at the logs
<vila> I'll put it back to its regular 8 now
<poolie> mm. if you want to
<poolie> please don't
<vila> why ?
<vila> (just reverted it to 2)
<poolie> why did you think you should?
<vila> to catch up the ~18.000 pending imports faster
<poolie> it's an operational issue for lp so we shouldn't put it back up until we can do so without slamming them
<vila> oh, we did ?
<poolie> yes, i replied in gz's mail thread
<vila> oh, I should read that then
<poolie> oh i thought you had
<psycose> Hi I got the following error while using bzr https+urllib://......    bzr: ERROR: wanted 1433 bytes but next hunk only contains 848: 'gcb1z\n1417\n2632\nx\x9c\xcdV'    I did bzr check and bzr pack on all side, any tips ? thanks       Repository tree (format: 2a)
<poolie> psycose: my guess would be there is a proxy interfering with traffic
<poolie> though that seems a bit unlikely for https
<AuroraBorealis> oh god that error sounds terrible
<vila> poolie: I replied to the thread
<psycose> As it seems to be an application level error, it does not seems to come from the HTTP server, if ever you have any tips for me to investigate, the server and the client are on the same computer.
<poolie> !
<poolie> what's the server software?
<mgz> morning all.
<poolie> hi mgz
<vila> mgz: hey !
<marcamilly> trying to install bazaar on os x lion
<marcamilly> got the dog from the canonical site
<marcamilly> *dmg i mean
<marcamilly> installed it
<marcamilly> but when I go to terminal, bzr returns 'command not found'
<AuroraBorealis> are you on lion
<marcamilly> yep
<marcamilly> i did set Python to 2.6
<AuroraBorealis> have to do something
<AuroraBorealis> that worked for me
<marcamilly> what else do I have to do?
<marcamilly> do I do that after the install?
<AuroraBorealis> yeah
<AuroraBorealis> thats what i did and then it worked
<marcamilly> nope
<marcamilly> just did it again
<marcamilly> still doesn't work
<AuroraBorealis> is it bash saying that the command isn't found?
<marcamilly> yes
<AuroraBorealis> did you open a new terminal?
<marcamilly> -bash: bzr: command not found
<marcamilly> yep
<marcamilly> closed terminal altogether
<marcamilly> and re-opened it
<AuroraBorealis> not sure why its not working then since it worked for me
<marcamilly> maybe restart machine?
<marcamilly> but that's sooooo windows
<vila> mgz: did you see http://www.themacaque.com/?p=954 ?
<AuroraBorealis> you can try, but it should of installed it to your path...
<AuroraBorealis> not sure why its not working for you
<AuroraBorealis> or you did the python 2.6 thing wrong
<marcamilly> k, lemme try restarting
<marcamilly> before doing anything more drastic
<marcamilly> like installing the 'Test' version
<AuroraBorealis> that dmg really needs to be updated =/
<mgz> vila: they don't actually say what the problem is in that post
<vila> mgz: wrong encoding ?
<mgz> but not having access to the environment block in unicode does break people who want to languages other than their system install
<mgz> their test would work on my box downstairs, because it would return CP932 that could then be correctly decoded
<vila> mgz: I didn't look to closely, but we rely on expanduser here and there and I thought you will be interested
<mgz> so, his question about whether it's fixed in Python 3 is funny
<mgz> the environment is unicode already in Python 3.
<mgz> vila: it's interesting.
<marcamilly> still no dice
<marcamilly> even after reset!
<mgz> but an edge case, most spanish users don't give themselves japanese user names
<vila> mgz: yup, let's handle the rare case befor the hairy one ;)
<mgz> vila, do you know anything about installing on osx for marcamilly?
<vila> hmm, not for a long time and never on lion, but let see
<vila> marcamilly: what's your PATH ?
<AuroraBorealis> there is an issue on lion
<marcamilly> how do I see that at the command line?
<AuroraBorealis> because it doesn't adapt for the fact that python2.7 is default
<vila> env | grep PATH
<vila> that's because noone with a lion setup has stepped up to build the installer :)
<marcamilly> my PATH: https://gist.github.com/1297769
<vila> it's pretty easy once you installed the dev dependencies
<vila> marcamilly: can you check that bzr is in /usr/local/bin ?
<marcamilly> how do I do that?
<marcamilly> just tried cd-ing to that folder, but it wouldn't allow me
<vila> ls -l /usr/local/bin/bzr
<marcamilly> permission denied
<vila> o.0
<marcamilly> ls: /usr/local/bin/bzr: Permission denied
<vila> ls -l /usr/local/
<marcamilly> k got that, sec
<marcamilly> https://gist.github.com/1297769
<AuroraBorealis> seems bzr didn't install or something o.o
<vila> marcamilly: ugly, '502' seems to be an unknown user and you miss 'x' there anyway
<vila> marcamilly: which means you cannot read the directory content
<marcamilly> yeh
<marcamilly> so how do I change it?
<vila> marcamilly: are you an admin on this machine ?
<marcamilly> yep
<vila> then 'sudo bash' and 'cd /usr/local/bin/
<vila> '
<vila> marcamilly: be aware that you get root powers once you 'sudo bash' and that you can destroy stuff (just mentioning in case)
<marcamilly> lol
<marcamilly> k
<marcamilly> ok i see bzr
<marcamilly> in /usr/local/bin
<vila> marcamilly: any idea about who '502' is ?
<marcamilly> nope
<marcamilly> how do I find out?
<marcamilly> and how do I replace it, if it's not 'legit'?
<marcamilly> could it be a Lion role/user?
<vila> well, that's the issue, a number is used because it's not known :)
<vila> did you upgrade from a previous osx release ?
<AuroraBorealis> would the lion upgrade really screw things up that badly?
<marcamilly> yeh i did
<marcamilly> from Snowleopard
<vila> well, if a user of a previous release did the install and wasn't migrated to lion...
<vila> then its id is hanging around
<marcamilly> but i didn't have 'many' users
<marcamilly> actually, just had one
<marcamilly> the main one
<marcamilly> and MAYBE guest
<vila> iirc, osx starts at 500 and increment so we're talking about the third created user but that also takes deleted users into account
<vila> anyway, is there something else than bzr in /uzr/loca/bin ?
<marcamilly> yah, lots of other stuff
<marcamilly> coda, compare, Magick++-config
<marcamilly> dot display djpeg diggimg
<marcamilly> and lots of others
<marcamilly> how should I proceed?
<vila> meh, given the path you pasted, I was expecting to find those in /opt/local/bin instead
<vila> so, that rules out deleting bin and reinstalling, let
<vila> 's try a more delicate fix then
<vila> in /usr/local do:
<vila> chown -R root:wheel bin
<marcamilly> LOL
<marcamilly> come out of sudo bash?
<vila> nope
<marcamilly> k
<vila> you need to be root to CHange OWNer
<marcamilly> done
<marcamilly> drwxr--r--  61 root       wheel  2074 Oct 19 03:11 bin
<vila> chmod -R go+x bin
<marcamilly> what's 'wheel' though?
<marcamilly> which folder should I be in?
<marcamilly> or can I run that command from anywhere?
<vila> /usr/local
<marcamilly> done
<vila> let's backtrack then
<vila> in a new terminal (keep the sudo's one around): ls -l /usr/local/bin/bzr
<marcamilly> -rwxr-xr-x  1 root  wheel  5439 Sep 13 17:45 /usr/local/bin/bzr
<marcamilly> great
<marcamilly> seems to work
<marcamilly> great
<marcamilly> bzr version works
<marcamilly> finally!
<marcamilly> thnx
<marcamilly> do I need to do anything else?
<vila> probably add /usr/local/bin to your path, how did you run 'bzr version' ? With the full path ?
<marcamilly> no
<marcamilly> just bar version
<marcamilly> *bzr
<marcamilly> 'bzr version'
<marcamilly> so it seems to have been added to my path
<vila> oh ! Missed /usr/loca/bin in your paste, you already have it
<vila> should be fine then
<marcamilly> hrmm
<marcamilly> kk
<marcamilly> thanks much
<marcamilly> btw, what's 'wheel'?
<marcamilly> admin user
<AuroraBorealis> he probably just saved you from some serious headaches
<marcamilly> ?
<AuroraBorealis> its the group for "sudo"
<marcamilly> nah I am pretty sure he did
<marcamilly> thnx much meng
<marcamilly> you were pleasant too
<marcamilly> :)
<marcamilly> rare combo in these here relay chatts
<vila> wheel is some king of group for admining, I never bother searching the details ;)
<marcamilly> hehehe
<marcamilly> kk
<marcamilly> well this is fine
<marcamilly> i really appreciate it
<vila> err kind not king (it's an interesting freudian lisp though ;)
<vila> lips
<vila> lol
<AuroraBorealis> The wheel group is a group which limits the number of people who are able to su to root. This usually consists of a group named âwheelâ and a set of users that are permitted to use the utility âsuâ in order to change to root.
<marcamilly> *slip you mean ;)
<marcamilly> not lips
<marcamilly> ok thnx again gents
<marcamilly> i'm off
<vila> AuroraBorealis: weird, sudo is preferred over su these days iiuc but who knows
<vila> it may be a BSD heritage ? fullermd ?
<AuroraBorealis> just got that off some unix website
<vila> oh, ok
<AuroraBorealis> basic idea is the same
<AuroraBorealis> but i doubt that the osx installer would ruin the permissions on /usr/local/bin o.o
<mgz> yeah, I never use su
<AuroraBorealis> apple's mantra is usually to try and not cause a terrible failure of the computer haha
<AuroraBorealis> and how easy is it to build the mac os x bzr dmg?
<AuroraBorealis> or installer
<mgz> likely a pre-borked system, lucky we have vila.
<mgz> the good thing about windows is restarting *would* have worked :)
<mgz> where as with unix you need someone who understands it to tell you what commands to type :)
<vila> AuroraBorealis: pretty easy, see https://launchpad.net/bzr-mac-installers
<millun> hello
<millun> bzr-explorer stopped working for me. i am looking for a good alternative
<vila> mgz: :)
<AuroraBorealis> bzr explorer is pretty good, define stopped working
<mgz> millun, can you be more specific than "stopped working", ideally with a traceback or screenshot?
<AuroraBorealis> vila, would i have to do anything because lion has python2.7 as the default?
<millun> /usr/lib/pymodules/python2.6/pygments/plugin.py:39: UserWarning: Module pygments was already imported from /usr/lib/pymodules/python2.6/pygments/__init__.py, but /usr/lib/pymodules/python2.6 is being added to sys.path
<AuroraBorealis> i think thats the main problem with it at the moment
<vila> AuroraBorealis: not sure but if you have it should be pretty straight forward, doxxx really did a good job there
<millun> import pkg_resources --> bzr: ERROR: exceptions.EOFError:
<jelmer> poolie: ^\
<vila> AuroraBorealis: the main issue is to setup the initial dev requirements (TeX is pretty big to download iirc)
<millun> oic. i did run out of space some weeks ago. that could be it? i will try to reinstall bzr
<jelmer> poolie: it was that sort of error that we were seeing for lazr.restfulclient as well
<AuroraBorealis> i'll look into it when i have time, hopefully this weekend
<vila> jelmer: wasn't it related to eggs or something ?
<vila> AuroraBorealis: that would be awesome
<jelmer> vila: nope, this is on Debian/Ubuntu which don't install eggs
<mgz> millun, if you have truncated pyc files, that could help
<mgz> but I need to see a full traceback to have an idea what's wrong.
<mgz> !pastebin
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<mgz> if you do `bzr explorer` on the command line, and put the full output up, that would help.
<poolie> yeah for the channel that was https://bugs.launchpad.net/ubuntu/+source/lazr.restfulclient/+bug/796992
<ubot5> Ubuntu bug 796992 in lazr.restfulclient (Ubuntu) "pth file overrides pythonpath" [High,Triaged]
<poolie> insane
<vila> oh, I thought .pth were related to eggs 0.O
<millun> http://www.sexshopik.cz/we-vibe-2-7249/
<poolie> i don't think so
<millun> sorry
<millun> my bad :-)
<millun> http://dpaste.com/637252/
<poolie> should i even click that?
<millun> not really, unless you want to
<poolie> i'm glad you're mistaken not a spambot :)
<millun> looking for an xmas present :-)
<poolie> or at least a clever one
<poolie> night all
<millun> night
<vila> poolie: night
<jelmer> g'night poolie
<mgz> variation on bug 814151
<ubot5> Launchpad bug 814151 in Bazaar Explorer "bazaar explorer no longer opens" [Medium,Confirmed] https://launchpad.net/bugs/814151
<vila> mgz: from JS Bach ?
<mgz> delete ~/.bazaar/explorer/history.dat
<mgz> and explorer will magically start working for you again millun
<millun> awesome
<millun> sweet!!
<millun> thanks
<millun> a lot
<mgz> guess I better fix that bug
<mgz> Riddell: when you mark bugs you've fixed, set yourself as the assignee and put in the milestone so you get blame on the release page
<Riddell> mgz: release page?
<mgz> Riddell: eg https://launchpad.net/bzr/+milestone/2.5b3
<Riddell> cor, I've never seen that before
<Riddell> do we use that, don't we just use the release-notes ?
<mgz> I've found having the info in launchpad can be useful for seeing just from a bug entry what version has the change
<mgz> vila: GlobalConfig.get_editor is telling bzr-explorer it's deprecated, what's the replacement?
<mgz> searching release notes for 2.4 and my mail archive isn't telling me.
<jelmer> mgz: would you perhaps be able to review a branch for me?
<mgz> jelmer: yes, that's on my list of stuff to do today
<mgz> is there a a paticular one you want me to look at before I go and have lunch?
<vila> mgz: that should be config.GlobalStack().get('editor')
<mgz> vila: and how far back does that work?
<mgz> ...current explorer wants to support bzr 2.3+ as far as I can see
<vila> 2.5 probably, let me check
<vila> nope, valid in 2.4 already
<jelmer> mgz: Cool, thanks :) https://code.launchpad.net/~jelmer/bzr/build-commit-parent-ids/+merge/79707 should be fairly simply and would unblock one of my other branches
<mgz> vila: but not 2.3 then so I'll need to do a dance of some kind I guess
<vila> mgz: what's the context ?
<mgz> jelmer: what confused me a little with that mp is you also add a allow_leftmost_as_ghost param
<vila> bzr-explorer ?
<mgz> vila: yup
<vila> no targeted branches for it ?
<mgz> jelmer: is that just being pulled out of the **kwargs or is it also new?
<jelmer> mgz: it's new
<mgz> vila: it's a little less strict than qbzr about having one series per bzr series
<jelmer> commit() doesn't take a parent_ids argument
<vila> mgz: well, the sooner the better then ;) Or more trouble is expected
<mgz> right, lunch lunch.
<jelmer> mgz: thanks!
<vila> jelmer: could you give feedback on https://code.launchpad.net/~bzr/bzr-svn/stacks/+merge/78259 ? Or should we just discuss it ?
<jelmer> vila: I'll have another look at it this afternoon
<vila> cool
<jelmer> sorry for letting it slip
<vila> np
<mgz> bug 878132 looks like a config interface change too
<ubot5> Launchpad bug 878132 in bzr-reserved-edit "Unable to run bzr red-enable" [Undecided,New] https://launchpad.net/bugs/878132
<jelmer> wow, we should really ahve another look at pypy
<jelmer> http://speed.pypy.org/
<jam> jelmer: I agree, with the main caveat that our actual performance sensitive code is written in Cython/C
<jam> which is often not compatible with pypy
<jam> it also depends a lot on JIT performance, and bzr is a process that starts and stops a lot
<jam> so may never 'warm up' enough to get the JIT effect.
<Lo-lan-do> Hi all :-)
<Lo-lan-do> jelmer: You say "bzr-git plugin is quite stable" â does that mean what I hope it means, and did I miss something important?
<jelmer> Lo-lan-do: it doesn't mean roundtripping works, but dpush/pull work pretty well
<Lo-lan-do> Ah.  How about multiple branches?
<jelmer> Lo-lan-do: there is basic support for those in bzr 2.5
<Lo-lan-do> Aha.  Good news :-)
<briandealwis> Hi all.  I'm currently using branch.revision_id_to_dotted_revno in tiplog to map a number of revision-ids for a branch.  It's quite slow if I go across the network.  Is there anything I can do to speed it up?
<briandealwis> Will obtaining a read lock on the branch help?
<briandealwis> never mind â I didn't read the report correctly
<jelmer> hi briandealwis
<briandealwis> hi jelmer
<jelmer> Lo-lan-do: basically, you can do something like "bzr dpush git+ssh://git.debian.org/git/collab-maint/heimdal,branch=experimental"
<jelmer> Lo-lan-do: local support for colocated branches still needs some more improvements (having to use "bzr switch file://`pwd`,branch=bar" rather than "bzr switch bar" is annoying)
<Lo-lan-do> That's just a matter of a shell alias :-)
<fullermd> vila: hmmwhut?
<vila> fullermd: what is the wheel group origin and use ?
<fullermd> Controls access to su (and repurposes for other similar uses by everyone of course).  I think it came out of Berkeley early on, like 2BSD era.  I'd have to dig around.
<fullermd> There's no wheel group in the SysIII dist at least.
<vila> I thought su was close to being deprecated by sudo (at least to become root) but it seems to be all over the place in osx
<vila> rhaa, s/it/wheel/
<fullermd> I can't imagine it will ever be _deprected_ in existence.
<fullermd> I hardly ever use it interactively of course.  But still, it's there in base, and gets used all over the place programmatically.
<fullermd> Anyway, I use the wheel group to control who can sudo   8-}
<vila> hehe
<vila> right, so it will never disappear because no one will even try to delete it ;)
<fullermd> Oh, people will try.  I hope not too many more, though.  The hole in my back yard is getting full.
<vila> hehe, time for BBQ instead
 * Lo-lan-do uses "su" daily
<fullermd> Probably more likely that 'operator' will get retired.  And I'm sure that won't happen anytime soon...
<vila> Lo-lan-do: really ? To get root access or to other users ?
<Lo-lan-do> Mostly for root, but often to other users too.
<Lo-lan-do> "su - postgres -c 'psql gforge'" is one command I use quite often.
<mgz> see, I didn't even know the syntax for switching user with su
<mgz> just use dumb basic option of act-as-root sudo
<vila> Lo-lan-do, fullermd : what I still don't get is why files and dirs get group wheel...
<fullermd> Which files?
<Lo-lan-do> Ah, I have no idea.  Never had anything to do with wheel myself.
<fullermd> I use the group to let just wheel people see stuff...
<fullermd> Considering that 'su' means 'switch user', it isn't hard to guess the syntax   :p
<vila> grr
<vila>  /usr hierarchy for example
 * fullermd shrugs.
<vila> (never ever type an absolute path at the beginning of a chat msg)
<fullermd> By default I s'pose.  The group doesn't mean much through there really.
<vila> ok
<fullermd> Rarely has differnt perms than 'other'.
<vila> yup
<fullermd> And usually when there are, it's a different group anyway.
<fullermd> e.g. -r-sr-x---  1 root  network  412392 Jul 30 21:53 /usr/sbin/ppp*
<vila> so yeah, used as a default as *one* group is needed
<vila> yup
<fullermd> And being gid 0, it's a good excuse for default  ;)
<vila> hmpf, silly me !
<vila> makes sense, uid(root) == 0 because he's here first, then gid(wheel) == 0 because root *may* have friends
<vila> the rest is optional ;)
<fullermd> If root gets friends, why don't I?  :(
<vila> fullermd: they are in your backyard :)
<fullermd> Hm, yeah.  Always present.  But they suck at bowling.
<mgz> I've hung vim, with cpu pegged at 100%, how the hell did I manage that
<fullermd> Maybe it's trying to start emacs.
<mgz> it died politely at least and...
<mgz> with an interestingly giant number in the output
<mgz> I think I may have accidentally told it to do something thousands of times, by not being in insert mode when pasting a bug number
<mgz> 814151 is pretty big.
<fullermd> It takes it a while to do brace matching on meg+ JSON files too.
<fullermd> Seems like that should be faster.
<mgz> yup, I seem to have a file with that number, probably repeated that number of times
<mgz> I'll get used to modality in the end...
<wonza> Hi, I have a little bzr problem in that I can't seem to create a new branch while logged into my work computer over ssh from home. http://pastebin.com/DCWj0LCF has the error listed. If anyone could help, that'd be really great :) (commits, and updates seem to work just fine btw)
<wgz> wonza: looks like bug 796873
<ubot5> Launchpad bug 796873 in launchpadlib "ec2 land generates gnomekeyring.IOError if run over an ssh session" [Low,Triaged] https://launchpad.net/bugs/796873
<wgz> so +affectsmeto that at least, and you can likely catch the error in the 'custom' plugin as suggested in the discussion there
<wgz> the change for this issue in bzr-gtk was basically just that: <http://bazaar.launchpad.net/~bzr-gtk/bzr-gtk/trunk/revision/685>
<wonza> thanks for the suggestion, I'll take a look
<thumper> hey
<thumper> is there a "stock" presentation for bazaar internals?
<thumper> I'm wanting to describe how revisions work, branching and merging, and why mainline is special
<thumper> also pipelines if one is around
<fullermd> I've got some of that piled up in my SpotDocs...
#bzr 2011-10-20
<poolie> hi all
<GRiD> hello
<poolie> hi grid
<Noldorin> hi jelmer
<michaelh1> HI. http://doc.bazaar.canonical.com/plugins/en/ is a bit broken at the moment - shows a directory index.
<michaelh1> I ended up there by Googling bzr colo which lead me to the missing http://doc.bazaar.canonical.com/plugins/en/colo-plugin.html
<poolie> hi michaelh1
<poolie> huh
<michaelh1> Hey
<poolie> i'll have a look at it
<poolie> actually, i have to go out right now, but i'll have a look at it soon, thanks for pointing it out
<mgz> morning all
<poolie> hi all
<mgz> hey poolie.
<poolie> just the man
<poolie> can you remind me - would python's default stream encoding change when it's run from cron?
<poolie> it seems like it fails there but not when run from a terminal
<poolie> even with LANG set
<mgz> I'll check, but eg sys.stdout.encoding possibly depends on having a terminal, it can sometimes be None certainly
<mgz> yup, in pythonrun.c
<mgz> for some reason, the setting of the encoding attribute depends on isatty
<mgz> if PYTHONIOENCODING is set to something (probably Python 2.7 only), that is used.
<poolie> i thought so
<poolie> and i'm lazy
<poolie> gar
<mgz> it's not terribly clear why this logic is used.
<poolie> ok
<poolie> kanbans have been failing from cron (and spamming me) because there is a unicode character somewhere in the output
<vila> hey guys
<poolie> i think i will just manually create an encoder
<mgz> shortest fix is probably replace sys.stdout with a codecs module wrapper that encodes to locale.getpreferredencoding
<poolie> hi vila
<vila> just recorded a new signature for lp being down, the package importer made tea happily and should do so for the next rollouts
<mgz> as long as you're consistent with trying to output unicode, and not mixing in non-ascii bytestrings
<poolie> it's actually writing to a file not stdout
<poolie> but yes
<vila> I'm still looking at the 6 failures which may also be recorded as identifying lp being down
<vila> s/6/4/
<poolie> oh?
<poolie> until we deploy a new restfulclient it will continue to mishandle 503 in reading a collection, perahps
<poolie> ... or actually i think i put in a new workaround?
<vila> hehe, one involves preload_root_objects :)
<vila> poolie: right
<vila> in the mean time 'requeue --auto <pkg>' is good enough
<vila> done, so 5 new signatures added,
<vila> the first one was *during* the downtime and as such represents the first access to lp which is the most important one
<poolie> ok running now, hopefully better, off to squash
<vila> the others were easy to analyze which is good as it means we can progressively update them to cover all cases as they appear
<vila> poolie: enjoy :)
<poolie> happy udd hacking
<mgz> happy squashing
<vila> excellent, imports aborted during lp down time have already been re-processed with success (with some 'requeue --priority' help ;)
<jnl> hi i've ran into a problem where im now missing a couple of commits: i had a colo-workspace with two branches "trunk" and "foo". i wanted to switch betweem them but forgot (or actually thought i didnt need it) to add the "colo:"-prefix and ran "bzr switch trunk" while on the foo branch, and then switched back with "bzr switch foo"
<jnl> but.. the foo-branch im on now is not the colo-branch "foo"
<jnl> in fact:
<jnl> bzr colo-branches
<jnl> bzr: ERROR: No colocated workspace in .
<jnl> is there any way to get my colo-workspace/branches back?
<jnl> i had a couple of commits in colo:foo that are gone now...
<jam> jnl: find . -path '*/.bzr/branch' ?
<jnl> jam: ah! ./.bzr/branches/foo/.bzr/branch
<jam> jnl: right, that is how colocated stores the real branches
<jam> I'm not sure how to get your working space colo-ified again
<jam> but the history is still available
<jnl> jam: bzr log in that dir looks like my missing branch!
<jnl> sweet, thanks!
<redwyrex> jelmer: I managed to get everything into svn, though I had to limit it to 100 changes at a time because the propery hook would fail for some reason after doing many
<jelmer> redwyrex: oh, that's odd
<jelmer> redwyrex: what's the error?
<redwyrex> umm something about the tip revision or something
<redwyrex> I assume it's on the svn side
<redwyrex> anyway, thanks for your help
<lamont> jelmer: still around?
<jelmer> lamont: yes, hi\
<lamont> see chinstrap:~lamont/bzr-logs/*
<lamont> the .1 on the version is me messing up the upload and repackaging the source with the right dsc format version :(
<jelmer> Hmm, I thought ~9 already had the source format changed back to "1.0" ?
<jelmer> lamont: The problem does appear to be that the patches aren't applied
<jelmer> lamont: is this ~9 from the cat-proposed archive, or yours?
<lamont> bah
<lamont> jelmer: it had source/format=1, but the .dsc was still new or such
<lamont> Architecture: any all
<lamont> so I rebuilt it.
<lamont> let me see how a .2 fares
<jam> mgz: I poked at https://answers.launchpad.net/bzr/+question/175127
<jam> if you could follow up, that would be great, as I spent a bit too much time on it already
<mgz> jam: I've just been reading that as I ate my lunch and was wondering how to send you a teddy bear
<mgz> will follow up as needed.
<jam> mgz: so we could do something like fix up leo-editor, which may require a losa to run a script we write (branch into a clean repo, copy that back over the original).
<jam> I've seen complaints about leo-editor in bug reports before
<jam> I'm pretty sure he didn't intend to include a file with 800MB of '\' characters
<mgz> yeah, and the good news is bzr does now have a check for that kind of accident
<lamont> jelmer: I suspect that I know what happened here, verifying that
<mgz> getting rid of that revision from the leo-editor repo sounds like a good plan
<lamont> jelmer: how much longer will you be aorund?
<jam> mgz: sort of. If you add a file in revision 1, and then in rev2 you bloat it to 800MB, bzr won't warn you
<jam> I don't think
<jam> (the check was put in 'add')
<jam> which is actually what happened here.
<jam> the file has a parent revision.
<jam> which is a wee bit smaller :)
<mgz> jam: I noticed when subscribing to things last night I'm down as the approver for foundatons-p-bzr-workflows
<jam> mgz: I think that was mostly that I wanted you to be present at the meeting, and by making you an 'Important Person' it will try to schedule around that.
<mgz> I'm now an essential subscriber, so I think the schedual should now know that I need to be there?
<jam> I think it is actually supposed to be in the linaro-training track, which was added after I was setting up the blueprint
<jam> I'll see if I can do something about it
<mgz> if there's anything else you need or would like me to do for UDS, poke
<jelmer> lamont: I'll be around for another 3 hours
<jam> mgz: it looks like the actually session is going to be: https://blueprints.launchpad.net/linaro/+spec/linaro-training-bzr
<jam> Andy set up a different session, so we'll just switch to that one
<jam> wow, I wanted to try and mark it superseded by the other session.
<jam> But if you try to go there
<jam> it requires that you select the superseding blueprint from a drop-down list
<jam> of *all* ubuntu sessions
<jam> it is about 1900 pixels wide
<jam> and probably 10,000 entries in it?
<jam> on the plus side, I can view source to actually get a reasonable view of it, and linaro-training-bzr isn't in there ...
<mgz> yep, that was pretty funny
<mgz> did you delete it then, or did my hack go horribly wrong?
<jam> mgz: I retargetted it to linaro, and then superseded it with the above spec
<mgz> ah, good good.
<jelmer> jam: wasn't a name change reason for updating a file's last modified data?
<jelmer> nevermind, there's something else going wrong
<jam> jelmer: yes, rename to another directory, and changing a filename are in the per-file graph. Note that renaming a directory isn't in the file's graph
<jelmer> jam: Thanks
<jelmer> jam: I just fixed the last failing bzr-svn test, which was related to that.
 * jelmer prepares a victory email for the mailing list
<jam> jelmer: congrats
<lamont> jelmer: your test suite runs forever on some architectures.  just sayin
<jelmer> lamont: what's your definition of forever ? :-) More than an hour?
<lamont> 8.3 hrs
<lamont> you know, forever
<jelmer> lamont: ah, worse than Launchpad's testsuite in its dark days. That is forever.
<lamont> it's also a bbg3
<Guest3968> exit
<Noldorin> hi jelmer
<jelmer> hi Noldorin \
<lamont> jelmer: ticket updated, still waiting on some of the bzr builds to finish
<jelmer> lamont: thanks
<jelmer> lamont: That's indeed very long. These were the arm/sparc builders?
<lamont> and I'll be updating a wiki page somewhere with lessons learned from the packaging fun
<lamont> yeah
<lamont> arm
<jelmer> lamont: thanks, that'd be useful
<lamont> jelmer: don't delete your final versions from your ppa - I'll want to go poke at them a little in doing that update
<jelmer> lamont: sure, I'll leave them around
<Noldorin> jelmer, how's things going?
<jelmer> lamont: do you know when hardy is going to disappear from the builders? after 12.04?
<jelmer> Noldorin: alright, how are you?
<jelmer> managed to get the full bzr testsuite to pass against bzr-svn earlier today, which I'm quite pleased with
<spiv> jelmer: \o/
<jelmer> g'morning spiv :)
<jelmer> how are things at the big G?
<thumper> jelmer: congratulations
<jelmer> thumper: thanks
<jelmer> I'll be really pleased when we manage to do this for git and hg, but that's some time away
<Noldorin> jelmer, pretty decent, just as busy as ever heh.
<Noldorin> jelmer, same with you? bzr 2.5 keeping you occupied?
#bzr 2011-10-21
<michaelh1> Hi there.  Can I add meta data to a commit?  I want to tag a commit as 'will not be sent upstream'
<james_w> michaelh1, there are revision properties, but I don't think that core provides command line options to set them
<michaelh1> OK.  I can embed meta data in the comment just fine.
<lamont> jelmer: two things are needed for hardy to fully disappear from the buildds: 1) an LTS with xen support (for the ppa host, especially - not actually a hard hard requirement), and 2) distro telling us that they're happy with using something newer than hardy to build all of the supported releases - dapper's EOL helps with that discussion, fwiw
<vila> hello bzr world
<jam> morning all
<mgz> morning
<vila> mgz: _o/
<mgz> morning jelmer. do you know off hand where the python-debian upstream repo is?
<jelmer> mgz: "bzr info apt:python-debian" :-)
<jelmer> or, if you have bzr-git installed: bzr branch apt:python-debian
<jelmer> git://git.debian.org/git/pkg-python-debian/python-debian.git
<mgz> ...oo, new command to me
 * mgz tries it
<jelmer> you need bzr-builddeb
<mgz> deprecation warnings, and it works
<mgz> I am impressed.
<jelmer> hmm, what deprecation warnings?
<jelmer> (are you on oneiric?)
<mgz> I'll put up a branch, it's a trivial spelling of fallback thing
<mgz> two in the style of:
<mgz> bzrlib/plugins/builddeb/directory.py:47: DeprecationWarning: Attribute 'Lookup'
<mgz> of the 'apt_pkg.SourceRecords' object is deprecated, use 'lookup' instead. lookup = getattr(sources, 'lookup', getattr(sources, 'Lookup', None))
<mgz> vila: babune windows seems especially unhappy of late
<vila> mgz: :-/
<vila> someone needs to bring it back to life :-/
<mgz> I seem to remember we had a can't-delete-sh-file problem before and fixed it, but I don't remember how
<vila> the infamous 'unable to delete <some tmp file>' was spurious but seem to turn into permanent
<vila> we never fixed it, it's a jenkings issue which kind of flip-flop over time
<vila> there is a 'hudson.remoting.RequestAbortedException: java.io.StreamCorruptedException: invalid type code: 68' in the backtrace doesn't look good
<vila> may be related to the leaks too (the leaks in (or releated to) the subunit stream
<mgz> yeah, seems like something is leaking through a stream, if that's even possible
<mgz> ...vila wins again
<vila> ?
<mgz> you said the same thing, faster :)
<vila> ha :)
<vila> worth noticing then, 'cause you're the fastest most of the time ;)
<vila> lol
<vila> just found a cryptic YARXU commit message....
<vila> .. wondered a bit
<vila> ... triggered my acronym decipherer
<vila> ... first guess: Yet Another Random Xml Update
<vila> win ! :)
<vila> I really wish we add a way to get better diffs (and commits) when xml files are involved. Most of the time one or two attributes in a "dict" are modified but the key/values are randomly shuffled. The end result is unreadable
<jelmer> vila: it would be really nice to have a mechanism for diffs similar to the merge hooks we have
<vila> indeed, they are closely related...
<jelmer> also, we currently already have some form of custom diff displayers
<jelmer> since we don't diff binary files by default
<vila> and doesn't qbzr display image diffs too ? (or rather both images)
<jelmer> vila: I wasn't aware of that. If it does, that's pretty cool
<jelmer> I know github has some fancy stuff for displaying image diffs
<mgz> okay, this looks tractable
 * mgz is back on bzr-builddeb
<mgz> or rather, the mess that is python-debian r95
<jelmer> where everything magically became unicode?
<mgz> yeah, but without ever checking the inputs
<mgz> ugh, setup.py.in
 * mgz just copies it
<jelmer> mgz: debian/rules has the magic to generate the setup.py IIRC
<jml> https://code.launchpad.net/~jml/udd/less-in-top-level/+merge/80037 up for review
<mgz> wants setuptools for no good reason too.
<jelmer> hey jml
<jml> jelmer: hi
<mgz> and given that it's just for a version number... which I don't even seem to be able to get at from the installed package, screw it
<mgz> what is it with people using fancy conf stuff on python packages then not actually having __version__ anywhere
 * mgz eyes subunit
<lifeless> mgz: patches appreciated
<mgz> I'd have to learn how all that worked to do that lifeless, which is exactly what I'm avoiding :)
<vila> mgz: windows slave still failing but at least with results
<mgz> woho.
<mgz> I've got bugs on the failures.
<vila> yakafokon :)
<vila> immortal chroots are pita
<mgz> you dig them up but they keep on growing back?
<vila> they refuse to die
<vila> ..can survive reboots and stay around for months
<mgz> okay, enough random poking of plugins, it's lunchtime
<vila> luckily it doesn't happen often (which of course makes it even harder to understand the cause)
<vila> bon appetit
<ccxCZ> ghost in z shell? :-)
<AuroraBorealis> speaking of those
<AuroraBorealis> the archive bit on some of my files refuses to clear :<
<mgz> hm, that was a failed attempt at not getting release notes conflict
<jml> mgz: thanks for the review
<jml> mgz: would you please merge the branch for me?
<mgz> jml: I don't have access either, will poke vila
<p2000> hello
<p2000> bzr wizards
<p2000> how do you translate "git --format-patch" to bzr ?
<jml> mgz: thanks.
<mgz> p2000: `bzr help bundle` is the diff + metadata thing in bzr
<mgz> s/is/for/
<p2000> it would b great if i could get the metadata in plaintext as well ... any option ?
<p2000> (havent found)
<mgz> format-patch is a bit cuter like that, but I never worked out how to send more than one revision with it
<mgz> I think there's a send email to file way of doing it
<p2000> just now i realize format-patch is probably not what i'm looking for ... intension misleaded me ... i saw the specific feature in gitweb only so far ... there i was able to get a page thatt shows me all commit messages along with the patches in a flat text file ... that's what i'd like to get from bzr but don't know how to get it from git actually ...
<p2000> s/intension/intention/
<p2000> s/wrong/right/
<mgz> s/True/False/ ? :P
<mgz> p2000: like `bzr log -p` maybe?
<p2000> yes ... looks realy good !
<p2000> that was it! ... thank you very much mgz !!!
<p2000> :-) same as in git i guess ...
<p2000> the 2 dvcs's are on par feature & technology -wise at the moment ... or what do the bzr-wizards say ?
<wgz> there's still enough minor things for people to argue about :)
<p2000> i mean git vs bzr ... bzr seems to have been quickly developping ... sure
<p2000> but there are no more minor differences i guess ... expect design of course
<p2000> anyway, thanks !! hanwe
<james_w> wgz, how does anyone add you to a team in Launchpad?
<james_w> ah, I can avoid the javascript version and do it
<briandealwis> jelmer, I just did a dpush to an eclipse repository and seem to have deleted most of the branches other than the branch I was pushing to and to master
<briandealwis> (with bzr-git)
<wgz> james_w: it's not just that I like making life hard for people...
<wgz> thanks for the conscription!
<jelmer> briandealwis: what versions of bzr-git/dulwich ?
<briandealwis> bzr-git 0.6.2 and dulwich 0.8.0
<briandealwis> It unfortunately happened after the support staff had left for home for the weekend.
<jelmer> ouch, sorry :-(
<jelmer> I've hit this before with tags and subsequently fixed it. I guess it's not in any releases yet
<briandealwis> I'm pretty sure I've dpushed to this repository previously though, without this problem!
<briandealwis> It would be nice to have a --dry-run flag :)
<jelmer> briandealwis: that wouldn't really help with a bug
<briandealwis> I'm kinda joking.  I had wondered why the push was taking so long.
<briandealwis> And we can't just recover by providing another packed-refs: unfortunately the push seems to have triggered a gc on the other side.
<briandealwis> I had meant to ask you what happens with dpush and tags, and if there's a way to not push tags
<jelmer> bradm: there is no way to not push tags
#bzr 2011-10-23
<jimis> hello all, is it possible to annotate from one revision until today?
<jimis> I've tried --revision=REVNO but I think it annotates up to that revision, any ideas?
<Noldorin> jelmer, update on progress, if any? :-)
<poolie> hi all
#bzr 2012-10-15
<mgz> morning!
<vila> morning mgz
<mgz> how are you vila?
<vila> pretty good for a  cloudy monday morning ;)
<mgz> hm, missed a quip earlier, every monday morning is a cloudy morning these days...
 * jelmer has no idea what a "quip" is but assumes it's some sort of accessory for trains
<mgz> there are so many strange parts of the english language I still need to confuse you with jelmer...
<fullermd> He has no idea what a flounifirelication he's in for...
<bobsapp> I suggest for a week 4chan should be run like a gulag, you have to enter 5 captchas to make one post, all images scaled down to 500x500 fixedsys font everywhere
<LarstiQ> would bzr transports be relevant to https://github.com/lvh/async-pep/blob/master/pep-3153.rst ?
<jelmer> hey LarstiQ!
<LarstiQ> hey jelmer :)
<jelmer> LarstiQ: it seems like there is some overlap
<delinquentme> heyy all! So i'm looking to examin the commit history for a single file
<delinquentme> ALSO is there any GUI for bazaar thats decent?
<jelmer> delinquentme: "bzr log FILE" should show you the history for a single file
<jelmer> delinquentme: qbzr/bzr-explorer and bzr-gtk are the main UIs
<lduros> hi, there's no equivalent of a tag in bzr? Like with svn when you reach version 2.0 you create a tag for easy reference...?
<janos> lduros: sure there is
<fullermd> None at all.  Aside from the thing 'bzr tag' does, anyway...
<lduros> ha!
<janos> you create tags using the 'bzr tag' command
<lduros> for some reason I missed that part from the documentation
<fullermd> We keep it hidden.  Can't have just ANYbody making takes, y'know.
<fullermd> Or tags, even.  Only piple who khan tipe.
<lduros> :-P
#bzr 2012-10-16
<mgz> morning
<jelmer> hij
<vila> hey
<poolie> jelmer, hi
<mgz> hey poolie!
<poolie> hi there mgz
<jelmer> hi poolie, mgz
<poolie> how are you
<poolie> hi
<mgz> I liked your motorcycle ride pics last week
<jelmer> poolie: Doing well, how are you?
<poolie> thanks, it was a nice ride
<poolie> yes, i'm good
<vila> hey poolie :)
#bzr 2012-10-17
<mgz> morning
<mgrandi> hey
<vivekimsit> Hi! how can I revert my changes to older revisions
<jelmer> vivekimsit: bzr revert -rX
<jelmer> where X is the revision number
<venefyxatu> does bzr branch load everything in memory before dumping anything to disk?
<venefyxatu> and, if yes, is it possible to disable this behaviour?
<vivekimsit>  jelmer: Thanks but let me tell you that my branch is not local i.e. I have co my branch
<jelmer> vivekimsit: you can unbind it
<vivekimsit> jelmer: Hmm, but when I ran above command it worked fine
<vivekimsit> but I think changes will be in my local only
<jelmer> vivekimsit: yes
<jelmer> vivekimsit: if you want the branch to go back, you can use "bzr up -rX"
<jelmer> venefyxatu: what do you mean?
<vivekimsit> jelmer: ok! its is for making the changes in the server, right?
<mgz> vivekimsit: say exactly what you want to do
<vivekimsit> But I have already run my command in my local branch: bzr revert -rN can I still use the above command
<mgz> if by "revert" you mean "back out a set of changes from trunk", that's another thing
<vivekimsit> mgz: I have my code on a server, I co from it and pushed the changes but now I want to revert my changes in the local as well as server
<mgz> you put the changes on the server by mistake? using a checkout probably needlessly confusing for you.
<venefyxatu> jelmer: I'm trying to branch a 568M repo from a remote host - on my local machine (4G RAM) this works fine, on my test server (600M RAM) the process dies eventually. Keeping an eye on ps aux shows me that RSS increases all the way up to +/- 416M on the server, 500something M on my local machine
<mgz> do you actually want the branch on the server?
<mgz> or just to deploy to it?
<mgz> anyway, for your original question you can either merge the inverse of the changes you want to remove, or just forcably push an old revision on top of the server
<vivekimsit>  mgz: we are a team and in which every person works on the local branch and pushes the code on the central server
<vivekimsit>  mgz: And as told told I already ran the command: bzr revert -rN on my local machine
<mgz> you want a central server for a team of people and a 600MB branch, and that server only has 600MB ram?
<mgz> revert only changes the tree.
<mgz> not the branch, local or remote.
<vivekimsit> mgz: So now what, my local tree is changed, should I push it on the server?
<mgz> no. I still don't know what you're actually trying to do.
<vivekimsit> (07:49:19  IST) mgz: revert only changes the tree.
<mgz> either you want to commit a change that makes the code the same as a previous revision, or you can just push up an old rev
<vivekimsit>  mgz: push up the older revision
<mgz> the first is for cases such as, you implemented a feature, but broke the build, and now want to change back to fix the build while you redo the feature
<vivekimsit> yes
<mgz> the second is for when you just messed up a push and can tell everyone else to not pull the mistaken revision
<vivekimsit> But the problem is that I reverted the change in my local
<vivekimsit> So, my server is at one revision higher than my local now
<mgz> that's not a problem, all you do in running `bzr revert` is change the tree
<vivekimsit>  mgz:  you got it
<mgz> vivekimsit: that was an either/or, I still don't know if you want 1 or 2
<vivekimsit>  mgz: Ya! now my next task it sync my tree with the server
<mgz> regardless, run `bzr revert` and get your local tree back to the current branch state
<vivekimsit> mgz: My tree: rev2, my branch:rev3
<mgz> see also <http://doc.bazaar.canonical.com/bzr.2.5/en/user-guide/core_concepts.html> and linked docs from there
<mgz> your tree does not have a revision.
<mgz> revisions are properties of branches, you just changed the contents of the files to look like they did in the previous rev, and I still don't know if you want to back out the change or just undo it
<vivekimsit> mgz: Let me summarize once again. I made some changes in my tree pushed it on the server but after some time I got to know that my changes were bad to by mistake I ran the command bzr revert which changed my local tree to the older and correct revision but I wanted to do the same on my server.
<mgz> vivekimsit: okay, let's do the back out version, as that's most generally applicable
<mgz> in which case, you should really merge the inverse of the change `bzr merge -r3..2` but for your case `bzr revert -r-2` as you did is okay (as there are no subsequent changes)
<mgz> that just changes the tree.
<mgz> you then commit that reversion, `bzr commit -m "Revert feature_branch_a which broke the build"` or whatever appropriate commit message
<mgz> that creates r4, which is similar to r2 but with different history,
<mgz> and in your case as you're using a remote branch, there is no `bzr push` step.
<vivekimsit>  mgz: ok! but to let you know when I do bzr diff it shows all the differences that I don't want now will your step work fine with it?. Also I usually do local commit first and then push
<mgz> the diff should only show things you want to change back, otherwise something has gone wrong.
<mgz> so, `bzr diff` should be the inverse of `bzr diff -r2..3` in your case
<vivekimsit>  mgz: whatever I don't want that diff now
<mgz> vivekimsit: I don't understand
<vivekimsit>  mgz: Sorry you were rigth
<vivekimsit>  mgz: ok! it worked
<vivekimsit>  mgz:  Is there any straightforward solution to it
<mgz> buy more ram?
<mgz> I'm not sure which conversation we're having right now.
<vivekimsit> I have one more issue, I often work on more than one project at a time. so it becomes diff to write the name of the projects every time. Eg: bzr push lp:~XXXX/my_branch_name. Is there any way by which my current tree name is automatically picked as a branch name during the push
<mgz> vivekimsit: yes, if you have a consistent local layout
<vivekimsit> like
<mgz> see <http://doc.bazaar.canonical.com/bzr.2.5/en/user-reference/configuration-help.html#section-options>
<ttilley> is there a sane and reasonable method of pulling bzr down to git? maybe not even pushing back. quilt is already in use, so good enough for me, right? i just don't grok branching and merging in bzr, whereas git is dead simple and very familiar.
<ttilley> just need to work on two projects at once, only one of which can be contributed back upstream (but both need to be included in the local product)
<ttilley> err... s/project/branch/
<hazmat>  how can one diff a  branch at a particular non head revision with another branch
<hazmat> even if the branch is updated to a particular rev, diff seems to use the head when diffing
<bob2> ttilley, it's pretty simple, it's just that each clone is a branch
<bob2> ttilley, so you'd: cd master ; bzr merge ../34559-add-bonghits
<bob2> instead of 'git checkout master ; git merge 34559-add-bonghits'
<hazmat> ah.. bzr dif -r revno  path_to_other_branch does the trick
#bzr 2012-10-18
<evillyEvil> where do I find the 'bazaar.conf' file?
<evillyEvil> I'm trying to install bazaar on my Ubuntu, but keep getting a warning about missing some precompiled component, and the suggested solution was to add certain line to that file
<spiv> evillyEvil: in the "Bazaar configuration" directory listed by 'bzr version'
<spiv> Typically ~/.bazaar
<spiv> Are you installing it from a PPA?
<evillyEvil> from the .tar obtained from the launchpad page
<evillyEvil> spiv:  ^
<bob2> you'll want to use the pp
<bob2> a
<spiv> Why not use the bzr PPA instead?
<evillyEvil> Sorry, I'm a little slow, how do I get the PPA?
<evillyEvil> only saw 2 options ".dmg" and ".tar" and the launchpad
<bob2> what ubuntu
<bob2> but tl;dr https://launchpad.net/~bzr/+archive/ppa
<evillyEvil> bob2: Ubuntu 3.2.0-31-generic #50 Ubuntu
<bob2> I meant the version of ubunutu, no idea what kernel release is in what, but anyway as above
<evillyEvil> well, thanks. added the line to the conf file and it resolves my problem
<mgz> morning all!
<vila> morning mgz and all !
 * fullermd waves vila around.
<vila> . o O (Of course waving someone has a meaning, you can't just expect fullermd to use approximate english without injecting a joke somewhere)
<mgz> being in a channel withh fullermd is an education in itself.
<fullermd> If you're not doing fun and generally illegal things to your English, you're not using it right.
<vila> ha, good, /me will not pursue efforts to avoid tyops (not that I put a lot of effort there ;)
<fullermd> Seek and ye shall be fined; nock and the dorlach shall be unpinned.
<venefyxatu> but if, after nocking, ye doth let go, something might get pinned...
<fullermd> Well, I'll not quarrel with that.  It's a fletching thought.
<jelmer> hey mgz
<mgz> hey jelmer!
<delinquentme> so I've got a bunch of removed files ... and I'd like to commit the removal of these files...
<delinquentme> do I just add those files which were removed?
<delinquentme> Ok ... how about how to drop a single file to the version contain in the last commit?
<aquarius> can I put a hook in a branch, rather than configuring it in people's clients, so that everyone who gets the branch runs the hook on commit?
<aquarius> I see some discussion of this on the bzr wiki but I'm not sure if it ever happened
<jelmer> aquarius: no, that's not supported - mostly for security reasons
<aquarius> darn.
<aquarius> I mean, I can understand why, but nonetheless: darn. :)
<aquarius> I was going to add a hook which ran on push and beat you to death if you hadn't run the test suite ;)
<jelmer> aquarius: there is actually a plugin like that
<jelmer> lp:bzr-testrunner I think
<aquarius> oh, certainly, but anyone who I would be able to convince to install the plugin is the sort of person who would run the test suite as a matter of course anyway ;)
<jelmer> aquarius: another option is to use something like tarmac to enforce running of the testsuite
<jelmer> of course, that requires setting up a tarmac instance somewhere..
<aquarius> yeah, and doing that sort of thing, and plugging in CI, and many other things like that are sorta-kinda on my list, but they're pretty heavy bits of hassle that I haven't done yet ;)
<delinquentme> ok so in bazaar ... different branches ... DONT have different directories right?
<aquarius> jelmer, thanks anyway. I'll just have to enforce running of the test suite by beating people up manually, like I normally do :)
<jelmer> aquarius: heh, fair enough
<delinquentme> bzr diff -r-148 -r-149  this should run a diff between these two revnos right?
<lifeless> no
<lifeless> bzr diff -r-148..-149
#bzr 2012-10-19
<delinquentme> is anyone in here familar with gits workflow ... I need to know if the branching practices in bzr are similar to git ... and perhaps some examples of how they might differ.
<bob2> it's the same
<delinquentme> bob2, thats waaaayyy too simplistic to be helpful or true
<bob2> it's not
<bob2> it's the same except that in bzr a branch is another dir
<bob2> (possibly colo is good enough to use now, I don't know)
<delinquentme> bob2, well now i've talked to a number of people in here and they're telling me that branches AREN"T additional directories
<bob2> as above
<delinquentme> bob2, sorry I dont follow?  "as above" ?
<bob2> 12:29:25 < delinquentme> bob2, well now i've talked to a number of people in here and they're telling me that branches AREN"T additional directories
<bob2> 12:29:05 < bob2> (possibly colo is good enough to use now, I don't know)
<bob2> colo = making bzr work like git with easy switching of branches in one """checkout"""
<delinquentme> bob2, do you have a online source that states definitively that a branch in normal vanilla bzr creates a new directory with every branch?
<delinquentme> bob2,
<delinquentme> any chance of definitive statement?
<spiv> "vanilla" is a bit of an imprecise terms.
<spiv> *term
<spiv> The bzr user guide explicitly describes multiple ways of working, with the understanding that the "best" way depends on the circumstances
<spiv> And the aspects that people care deeply about differ
<spiv> Some people strongly care about "feature branches" (one branch per work task)
<spiv> Some people strongly care about reusing the same workspace on disk for everything relating to a project.
<spiv> (Some people strongly care about both, for that matter.)
<spiv> So when you're asking if the branching practices are like git, I think you need to define your meaning a little more clearly (although I appreciate it's hard without having a thorough understanding of both systems).
<spiv> Because in the extreme, it can be interpreted as meaning "I can type 'git frob -x ...' when I want to frob my stuff"
<spiv> Or maybe you really want support for pushing a group of related branches in a single operation.  Or maybe you really want trivial support for pushing one branch without worrying about how it may be related to other branches you have.  Etc.
<spiv> Which is a long-winded way of saying bob2 is right that it's a simplistic question, even if it doesn't feel like one, so you're unlikely to find the definitive statement you're looking for.
<spiv> But perhaps you have more specific questions we can help with?
<jelmer> moin
<delinquentme> Hey all !  I'm looking for a definitive example of a branching workflow.  I'm used to running with Git and I use substantial branching in my own practices ... basically I'm not sure how branches in BZR work ... and if someone would address the long standing question of whether bazaar branches create their own directories .. that would be awesome
<AfC> delinquentme: branches work by ... branching
<AfC> delinquentme: and yes, bzr branches live in their own directories. That comes from several design decisions, including wanting to give each branch a URL
<delinquentme> AfC, I mean an example haha ... 1) branching 2) committing on both A and B branches 3) specifics on how they differ ... and then conflict resolution between the two
<delinquentme> AfC, final answer? I'm guessing you're pretty confident in bzr?
<AfC> delinquentme: you can certainly replicate Git's change-branch-in-place behaviour, but you need to take a certain amount of care to set things up to behave.
<AfC> delinquentme: everything you're describing is just 3rd generation Distributed Version Control. Any of the modern DVCSen have the same building blocks and the same capabilities.
<AfC> bzr is, in our opinion, a lot more explicit about the important things, and, once you "get it" a shit load easier to use, but whatever.
<AfC> delinquentme: there are any number of tutorials around, but for instance one I wrote is http://java-gnome.sourceforge.net/HACKING.html
<delinquentme> example of the important things?
<delinquentme> ok so in this line: $ bzr branch mainline/ working/
<delinquentme> this is your branching operation
<AfC> whole tree commits, explicit identity of branches and thence ease of comparing branches, merge performance, not shooting you in the foot when you try to resolve conflicts
<AfC> delinquentme: yes
<AfC> delinquentme: (assuming I already have taken some action to get a "branch" of mainline, which is the case there)
<AfC> delinquentme: (the other starting point would have been bzr init mainline/ but that's a bit pointless here)
<AfC> delinquentme: http://research.operationaldynamics.com/bzr/quill/ â lots o branches
<delinquentme> yeah i'm on about ... the local editing of existing branches
<AfC> one of which is mainline and "more special" but only by convention. Branches are peers.
<AfC> delinquentme: well, once you've got _commits_ in different branches
<AfC> delinquentme: (that have therefore diverged)
<delinquentme> yeap
<AfC> delinquentme: you can then do things like
<AfC> $ bzr missing --line ../other
<AfC> which tells you what revisions exist on each
<AfC> another stalwart is
<AfC> $ bzr diff -r ancestor:../mainline
<AfC> which shows you a diff not against the current branch's committed state
<AfC> (Whchi is what bzr diff does straight up)
<delinquentme> which is essentially is what commits is the current branch lacking from those in mainline
<AfC> but instead against whatever the common ancestor is between the two branches. It is, in effect, a merge prediction
<AfC> delinquentme: yes, that's `missing`
<AfC> and with that, my ferry has landed. Excuse me.
<jml> hey
<jml> I want a command like lp-propose, but that adds an approval vote with some trivial text (e.g. "rubberstamp") and also sets the approved revision on the status of the merge proposal
<jml> this is because we use tarmac for landing branches, and there's a non-trivial class of branches that we wish to land without requiring code review.
<jml> it seems pretty straightforward to implement
<jml> *but*
<jml> I can think of a couple of ways I might do it
<jml> a) totally new command
<jml> b) a new option to lp-propose ('--vote Approve', maybe?), along with a fix to --approved behaviour to set revid
<jml> c) a separate command for reviewing merge proposals
<jml> d) change the behaviour of --approved on lp-propose to also add a trivial comment & approve vote (as well as setting revid)
<jml> c) is most flexible, I think. d) is most convenient for my use case.
<mgz> does it want to be a bzr thing at all?
<mgz> with lp-propose you always have the branch you want to make an mp from right there, and it probably needs pushing
<mgz> but at best with reviewing you've got a copy of the other person's branch you'rve just run tests on, and the only change you want to make it to launchpad via it's api
<mgz> *is to
<jml> mgz: remember the use case is to push, propose and rubberstamp my own branch
<mgz> we want to encourage that? :)
<jml> mgz: so, insofar as lp-propose already partly caters to this use case by having an --approve option
<mgz> I'd extend lp-propose then, for that case.
<mgz> but not try and do the general case.
<jml> mgz: cool, I'm in favour of that.
<jml> phone
<jml> mgz: in testtools, there's a check that says if sys.version_info > (3, 3), expect "PermissionError". However, in actual released Python 3.3, it seems to be FileExistsError.
<jml> mgz: in t.tests.test_testresult.TestNonAsciiResults.test_os_error
<jml> mgz: naively, I'd change this to FileExistsError and remove the PermissionError branch. Do you know of a reason for me keeping a PermissionError branch to the conditional?
<mgz> I'll have a quick look and see
<jml> mgz: thanks.
<mgz> hm, that's a little icky
<mgz> it's probably platform dependant
<mgz> could make it assertThat(self._as_output(textoutput), MatchesRegex("(?:Permission|FileExists)Error: "))
<mgz> I think that will still get the str/unicode stuff right
<delinquentme> whats the closest bzr operation to a rebase?
<gmarkall> there's a rebase plugin
<gmarkall> although, it doesn't do interactive rebase afaik
<jml> mgz: thanks. I'll do that.
<LeoNerd> There is rebase, and it's just as rude as it is in git
<mgz> jml: reviewed, one similar issue noted
<jml> mgz: oh, thanks.
<lifeless> mgz: btw, lots of testtools discussions also happen in #subunit.
<delinquentme> LeoNerd, its just as rude?
<LeoNerd> It rewrites history
<LeoNerd> It throws away previously-committed revisions and replaces them with other ones
<delinquentme> so I thought I've run merges on bzr before and it annotated the differences within a single file?
<delinquentme> with <<<<< ====== and >>>>>>>> is there some magic to getting this orrrr
<delinquentme> So I've got a .BASE .OTHER and a .THIS
<delinquentme> :P
<delinquentme> what all is going on heeere
<delinquentme> ok so If i run a $ bzr merge ../some_branch  ... and then im going through the files ...   the conflicts labeled as " TREE " are those which were on the trunk ( being that I merged some_branch INTO trunk ) ... and those labeled as MERGE-SOURCE .. were those bits of code which were in the some_branch
<delinquentme> right/
<awolf> Hi folks, I'm a maintainer of a daily build of a package, and I use a source recipe on Launchpad, and I super love it and it's great.
<awolf> However, I need to make some changes to the recipe, so I'm rebuilding the environment on my local PC so I can test changes locally.
<awolf> I am finding that even when I modify the recipe to use bzr repos that are on my harddrive, they're abysmally slow.
<awolf> I've got a relatively beefy machine, ssd, and while doing a bzr dailydeb build where the recipe points to bzr repos that are only located on my machine, not lp: or over a network, I'm getting occasional timeouts!
<awolf> The timeout aren't happening every time, so I don't think I'm pointing to the wrong place--it geniuinely looks like a timeout.
<awolf> Any thoughts?
<delinquentme> bzr uncommit -r -3  this backs out to commit revno 3?
<delinquentme> or back 3 commits from the most current?
<beuno> delinquentme, should undelete the last 3 revnos
<delinquentme> hey all .. whats the modification I need to make to $bzr log to only get a few of the last commits ?
<mgrandi_> look at bzr help revisionspec
<mgrandi_> can limit the amount of commits you are looking through there
<delinquentme> mgrandi_, theres no ... just .. argument like a " -4 " I can add??
<delinquentme> seems silly/
<jelmer> delinquentme: --limit 4 ?
<delinquentme> jelmer, bzr log -l 4
<delinquentme> awesome
<danielbrauer> Hello, I'm running Bazaar on Mac OS, and running into this issue: https://bugs.launchpad.net/bzr-explorer/+bug/926439
<ubot5> Ubuntu bug 926439 in Bazaar Explorer "Can't open project in GUI "Too many open files"" [Medium,In progress]
<danielbrauer> I see that there is a patch there, but I'm not sure what to do with it.
<danielbrauer> Having used the disk image to install Bazaar, I'm actually not sure where all of its python files reside.
<mgrandi_> one sec
<mgrandi_> the directory you want to apply the patch is /Library/Python/2.6/site-packages/bzrlib/plugins/explorer
<mgrandi_> the lib file is in there
<mgrandi_> err directory
<danielbrauer> Thanks, looking now.
#bzr 2012-10-20
<mgrandi_> and then it should be just
<mgrandi_> cp lib/filesystemwatcher lib/__filesystemwatcher.py
<mgrandi_> patch -p0 workaroundwahtever.patch
<danielbrauer> Great, it appears to work now.
<danielbrauer> Oh I see. I applied it manually. But it still works. (:
<mgrandi_> yeah
<mgrandi_> this seems to be a bug with QT
<danielbrauer> That is unfortunate, since it already appears not to work on Windows.
<mgrandi_> well
<mgrandi_> yeah, i was commented out because of the same issue i believe
<mgrandi_> or the fact that files can lock themselves and that was causing problems
<danielbrauer> Yeah, I think it was permissions on Windows, and "too many files" on Mac OS.
<danielbrauer> Anyway, I've got to run. Thanks very much for pointing me to the right directory!
<Jordan_U> I'm trying to confirm that a directory with source code that I'm about to build and put into production is in fact the latest version, (I'm pretty sure but I want to be certain) by running "bzr status". However, when I do this I get this long error message: http://paste.ubuntu.com/1290774/
<fullermd> Corrupted dirstate maybe.
<Jordan_U> I'm using ubuntu 12.04, with bzr 2.5.1 and the directory is being accessed through Samba from a Windows file server, which I connected to using PCManFM, and actually navigated to in the terminal via ~/.gvfs .
<fullermd> But you only use it on the 3rd and 5th days before a new moon, when Jupiter is in Aquarius, right?
<Jordan_U> fullermd: Of course.
<fullermd> Phew.
<Jordan_U> Dodged that bullet.
<fullermd> Well, that probably gives ample opportunity for dirstate corruption.  I started whimpering in the corner just reading it.
<fullermd> There's a command that blats out a clean one.  I'll think of the name 30 seconds after someone else says it...
<Jordan_U> fullermd: Should I be generally concerned about this or is it a simple and isolated problem? This repository is very important to me.
<fullermd> Well, it's concerning any time files get corrupted.  How would have some impact on where the concern lies.
<fullermd> System crashes or the like (with a networked FS, a network dropout would be like) could cause it, and that's only concerning when you crash again.
<fullermd> Network filesystems tend to introduce a lot more complication points around things like locking, which dirstate relies on.
<fullermd> repair-workingtree, that's the command.
<fullermd> That'll dump out a clean dirstate file, which means any explicit changes you've made (like added/deleted/moved files) bzr won't know about.
<Jordan_U> fullermd: The output of "bzr repair-workingtree" http://paste.ubuntu.com/1290789/ (with the current directory being a temporary copy of the respository in /tmp/).
<fullermd> Mmm.  Probably really messed up then.
<Jordan_U> The last thing I did was make a commit listing the revision as final and ready to ship, and that was about a year ago.
<fullermd> Zero-length, maybe?
<fullermd> What's .bzr/checkout/dirstate look like?
<fullermd> Anyway, repair-workingtree takes a --revision, so if you're pretty sure it was at the head of the branch, doing a '-r-1' will be fine.
<Jordan_U> fullermd: http://paste.ubuntu.com/1290793/
<fullermd> And that's the end of it, or did paste block off after the first null?
<fullermd> It would be interesting and suggestive (of what, I don't know, but suggestive of something) if it did in fact get truncated right to the first nul.
<Jordan_U> fullermd: That's certainly not all of it, I didn't expect the pastebinit command to do that.
<fullermd> Right after that nul, it should have the revid.  You can use that for `repair-workingtree -r` to be sure.
<Jordan_U> fullermd: So I should run "bzr repair-workingtree -r jordan.uggla@gmail.com-20110513002446-lp90c9cig70b9ty8" ?
 * fullermd nods.
<mgrandi_> instead of using a networked filesystem you should probably be pushing/pulling from a repo on the server, i would think bzr protects against corruption in that case
<mgrandi_> using sftp:// or bzr+ssh://
<Jordan_U> fullermd: http://paste.ubuntu.com/1290799/
<mgrandi_> that does not look good, trying to read data that it is expecting but its just not there
<mgrandi_> its probably borked =/
<fullermd> Yeah, but it looks like it's trying to read data from the dirstate.  It shouldn't be doing that when the point of the command is to rebuild the dirstate   :p
<fullermd> OK, cheat.  do a 'bzr branch' of it to a temp location, then copy the .bzr/checkout/dirstate file over.  There's always a bigger hammer   :p
<Jordan_U> mgrandi_: Would the full dirstate file be useful to you? (It will take a little bit of work to copy it to my server to host it, but I can do so if it might help).
<mgrandi_> well it does call 'call dirblocks if needed', so maybe it needs some tof it in order to actually generate a new one?
<mgrandi_> or is that bug material
<fullermd> I'm pretty sure that's bug material, since the point of the command is to recover from a horked dirstate.
<Jordan_U> fullermd: OK, branching has gotten me a (seemingly) working repository. I'm not going to touch the main one today as I have to think about it more for safety.
<mgrandi_> yeah. the error itself isn't anything good, its just trying to read stuff that its not expecting to be gone
<mgrandi_> i'll file it later, and include le logs
<Jordan_U> mgrandi_: You'll file it later?
<mgrandi_> im  technically "working" at the moment so yeah =P
<mgrandi_> i'll do it when i get a free moment
<Jordan_U> mgrandi_: Thanks.
<mgrandi_> just about the fact that repair-workingtree is dying
<mgrandi_> i dunno if that will help you
<Jordan_U> mgrandi_: Yeah, but I appreciate you taking the time to file a bug report anyway.
<mgrandi_> an interesting test anyway
<mgrandi_> just put a repo on samba and yank out the cable during stuff
<mgrandi_> see what happens
<mgrandi_> but yes, in the future, dont access this via samba =P
<mgrandi_> have a branch on your local disk and then push to  server using sftp:// or something that way if one gets borked you have the other
<Jordan_U> I think that tomorrow I will take this branch that I just created with bzr branch, and copy the directory to the server using cp, replacing the current corrupt branch. This copy on the server was never meant to be pushed or pulled from (and never was that I can remember), at this point it's mostly documentation and verification that we have the latest code (by checking "bzr log" and seeing the "shipped" tag on the last revision), and ...
<Jordan_U> ... maybe for someone in the future to branch from though that probably won't happen as all our future projects use Atmel rather than ST chips.
<Jordan_U> Anyone see any problem with that solution (copying the branched repository to the server using cp)?
<fullermd> Eh, you could just push.
<Jordan_U> fullermd: Doesn't that introduce possible locking problems (I don't have access to the server to setup sftp for a proper push).
<mgrandi_> it could
<mgrandi_> if you keep using this over samba though its going to be the same problem,=/
<Jordan_U> mgrandi_: Does "bzr log" constitute "using"?
<mgrandi_> that doesn't change anything about the repo so you are fine there
<fullermd> Well, purely branch-related stuff is surely safer than WT stuff.  But yeah, if a smb filesystem is the only access you have to the server...   urgh.
<Jordan_U> Like I said, at this point the branch and history is only being used as verification and documentation.
<mgrandi_> bzr log shouldn't be changing anything about the branch so that should be fine
<mgrandi_> but don't push to it =P
<mgrandi_> kittens cry
<User_007> Hello, can you help me? the command "bzr bd -S" is returning a signfile error: secret key not available
<User_007> but i do have the key
<User_007> how to point the key to bzr?
<User_007> the error is about malformed e-mail
<User_007> it is using the e-mail of my user (user@computer) instead my real mail (user@mail.com)
<User_007> how does bazar know witch key do i want to use?
<User_007> ping?
<User_007> i solved the last problem, but now i get this error: Error: uploading files for distribution UNRELEASED to ppa not allowed
<User_007> i am on Quantal
<jelmer> is
<mark06> why bash recursively runs /etc/profile or  ~/.profile if I call a (shebanged) bash script from within these files?
<bob2> can't parse the question but the bash manpage explains which things are sourced when
<mark06> for example, in /etc/profile you have "do-something.sh" at the end
<mark06> in my case, do-something.sh starts executing /etc/profile again, which executes do-something.sh at the end, which... so it becomes endlessly recursive , with an infinitely growing list of bash processes raising in the OS
<bob2> ok as above
<mark06> ah, wrong channel. SORRY!
#bzr 2012-10-21
<delinquentme> sooo should running a branch of a project 663MB in size take more than a few minutes?
<jelmer> depends on your bandwidth, etc
<delinquentme> jelmer, local brancing
<jelmer> delinquentme: what bzr version?
<delinquentme> 2.1.4
<jelmer> delinquentme: sounds plausible, that's really old
#bzr 2013-10-14
<thumper> how do I move the branch tip back three revisions without uncommit?
<thumper> found it
<thumper> bzr pull . -r 1968 --overwrite
<thumper> in case you are interested
#bzr 2013-10-15
<helperW> Hello
<helperW> I just installed bazaar on my VPS. I have a project and I made a whoami and did a init of an online folder.
<helperW> What is the next step?
<helperW> no one here :(
<jpds> What are you trying to do?
<LeoNerd> helperW: Presumably now you start 'bzr add'ing files to it that want to be tracked, then 'bzr commit' them to form the first revision
<helperW> I'll try that thanks.
#bzr 2013-10-16
<lduros> hi, I changed permissions on some files in my repository, but for some reason bzr status didn't pick this up
<lduros> How can I make sure that the permissions I have set will stay?
<lifeless> bzr only tracks the x bit.
<lifeless> it should never remove it
<lduros> ok, cool
<lduros> lifeless: so if i do a bzr export, I'll get the same permissions as those I've set right?
<lifeless> for the x bit
<lifeless> the rest will depend on your umask
<lduros> ok
<helperW> Hello
<helperW> I have an online drupal website
<helperW> I want to use BZR
<helperW> BZR is already enabled on my webserver
<helperW> I have to make an edit on a module file
<helperW> How can I start using it?
<helperW> So I am sure It will not fallback to an older version
<helperW> I mean ' so i am sure I can fallback to an older / original version '
<helperW> No one? :s
<vila> helperW: well, it depends on how your drupal site (or even drupal itself and its modules) are organized in term of source trees, so this cannel can't really help you there
<helperW> Hmmm
<helperW> What do I have to let you know the structure
<helperW> ?
<vila> helperW: if you encounter issues while using bzr, this channel will be appropriate but for how to start... it's more related to drupal
<helperW> Oh ok
#bzr 2013-10-17
<davve123> hey! what are the available delivery protocols, and on what form are the uri:s for bzr?
<davve123> looking at the docs i see svn://.../trunk and svn+ssh://.../trunk is that it?
<mgz> davve123: there are several, the bzr: and bzr+ssh: ones are the main bzr specific bits
<davve123> mgz: oh cool. damn i posted that in the wrong channel :) sorry bout that.. what are the other ones?
<mgz> we also have some other +dectorated bits for http that are less commonly used
<davve123> so http: also?
<mgz> right and ftp: and git: when bzr-git is installed and such like
<mgz> it's extensible
<davve123> the latter part of the uri is unchanged regardless?
<Munksgaard> ls
<Munksgaard> erh
<mgz> davve123: I'm not sure what you're asking
<Munksgaard> What's the best way to undo a commit that has already been pushed to launchpad?
<mgz> what comes after the scheme is somewhat protocol specific
<davve123> mgz: no .bzr or such at the end of the repo..
<mgz> davve123: right, it knows to look under a .bzr directory as part of the comunication, you give it the containing dir
<davve123> mgz: great, thank you :)
<Wiz_KeeD> hey guys
<Wiz_KeeD> Is anyone around?
<LeoNerd> 88 users, by my count
<Wiz_KeeD> hahahaha
 * Wiz_KeeD laughs
#bzr 2013-10-20
<tuv> i am unable to branch a pretty large repo off lp on a machine with 512MB or memory. it runs out of memory, then I get "Connection Timeout: disconnecting client after...". logged into launchpad. is there anything i can do to complete the branch operation?
<tuv> *512MB of memory
<tuv> i am unable to branch a pretty large repo off lp on a machine with 512MB or memory. it runs out of memory, then I get "Connection Timeout: disconnecting client after...". logged into launchpad. is there anything i can do to complete the branch operation?
#bzr 2014-10-14
<catphish> would anybody be able to explain what might cause this error? http://paste.codebasehq.com/pastes/of5tw2n5odbwbqi8ai I suspect it's a problem with the HTTP server
#bzr 2014-10-15
<mark06> is this a message from bazaar? /d/Programas/Branches/git/MINGW-packages/mingw-w64-pidgin++/pidgin++ is not a branch of file:///D:/programas/branches/pidgin/pidgin++
<mark06> ah it looks like no, nevermind
<mark06> hi all, about this line: https://github.com/Alexpux/MSYS2-pacman/blob/master/scripts/makepkg.sh.in#L451
<mark06> the comparison is too simplistic and fails for both local and remote branches
<mark06> in my case, for a local branch I have two same branches but one with relative path and another without it
<mark06> for a remote branch, one http url has a literal + while the other has the + in url-encoded form
<mark06> in sum, a simple != won't do
<mark06> question: how can the code above reliably tell whether a local branch (folder) is a branch from a given branch location?
<mark06> .bzr/branch/branch.conf contains an absolute path, but bzr config parent_location returns a relative one... why?
#bzr 2016-10-18
<LeoNerd> oopsie
<LeoNerd> I shelved a bunch of changes that included adding a directory and now I can't unshelve them again :(
<LeoNerd> http://paste.debian.net/883488/
<LeoNerd> Any suggestions anyone?
<LeoNerd> https://bugs.launchpad.net/bzr/+bug/850594  <== appears to be somewhat of a variant of this
<ubot5`> Error: Could not gather data from Ubuntu for bug #850594 (https://launchpad.net/bugs/850594). The error has been logged
<LeoNerd> well thanks ubot
<LeoNerd> Title: unshelving new file fails if its directory has been committed since shelving
<LeoNerd> The bug has a rather short "well don't do that", but doesn't suggest how I might get out from having already done that
#bzr 2016-10-19
<LeoNerd> So.. Nobody has any thoughts about my broken shelf problem? Am I going to have to manually unpick the pack file myself?
<mgz> I think I had a way back, but has been a while and I'm not sure I remember it I'm afraid
<LeoNerd> It looks manually -possible-, just a little awkward. the changes that are shelved are one newly-added file (easy to pull out), and some inserts/deletes of lines in another file
<LeoNerd> The inserts look easy enough. the deletes look the hardest bit to unpick manually, because I'll have to count line numbers of the 'c' lines
<LeoNerd> I think the entire pack is only upset about the newly created directory, so if I can somehow split the pack file into two packs, one that creates the new file in the new directory and one that does the edits to existing files, that might make it simpler
<LeoNerd> The new file is added in a new dir- and that's the one I can easily unpick by hand]
<fullermd> Maybe you could try backing up to the rev where you'd shelved 'em, and unshelving there?
<LeoNerd> That's not the issue.
<LeoNerd> I don't think
<LeoNerd> I think the issue is that I shelved adding a file to a new directory, but I didn't shelve adding that directory
<fullermd> Seems like I have vague memories of some dance like that working once upon a time.
 * LeoNerd will give it a go anyway
<LeoNerd> Nope.. still upset about:  bzr: ERROR: No final name for trans_id 'new-3'
<LeoNerd> Is the pack format actually documented somewhere? I feel it ought to be justabout possible to manually split this file into two pieces.. one that adds a file and one that has all the other-file edits
<LeoNerd> I suspect it's only the former that's upset, but that one is easy for me to manually unpick
<LeoNerd> I'm just not -quite- sure I understand how to parse the metadata and attribs sections at the top of the file
<fullermd> Apart from the source (hopefully the comments in), I don't think so.
<LeoNerd> http://paste.debian.net/883914/
<LeoNerd> is the header
<LeoNerd> I've sortof worked out those lines that begin d
<LeoNerd> They appear to be a decimal number then a comma then that number of bytes... a list of strings. apparently an even-sized kv assoc list
<fullermd> Yeah, it's some sort of KLV.
<LeoNerd> The attribs one is harder. It seems to be 'd', a 10-byte string ("_id_number"), then the next stream character is 'i' which I'm not sure what it means
<LeoNerd> maybe it's an "integer" value, ... which could be 30, ending at the 'e'?
<fullermd> I think it's bencoding?
<LeoNerd> https://en.wikipedia.org/wiki/Bencode ?
<fullermd> Yeah.
<LeoNerd> Ah.. that looks useful, thanks
<LeoNerd> OK that looks quite simple. I wonder if I could write me up a quick bencode <-> JSON converter to make it easier to manually manipulate
 * LeoNerd , unrelatedly, still sad that pastie.org seems to have died :(
<fullermd> Well, considering bzrlib has a bencode implementation, and I'm sure somebody has written a JSON implementation for python sometime...
<LeoNerd> By far the best pastebin I used
<fullermd> Actually, in a little poking, bzrlib's implementation (at least the .py version; it uses a .pyx mostly) looks like just an import/edit of the code from some bittorrent implementation anyway.
<LeoNerd> Mmm :)
<fullermd> e.g., compare bzrlib/util/_bencode_py.py with http://www.math.uiuc.edu/~gfrancis/illimath/windows/aszgard_mini/pylibs/bzrlib/util/bencode.py
<fullermd> Take out some of the class wrapping and the like...
<LeoNerd> Eh; it looks quite easy and trivial enough to reÃ¯mplement
 * LeoNerd was going to use it as an excuse to add another example into Parser::MGC anyway
<fullermd> Pshaw.  Obviously you'd build it on Marpa...
<LeoNerd> Hellno
<fullermd> But then, there's apparently Convert::Bencode already too
<LeoNerd> Yah probably. Again, it's an excuse to write example code
<LeoNerd> Because people always complain I don't have enough
<fullermd> That leads to recursion, though.  You start writing some sample code, you shelve part of it, and then suddenly...
<LeoNerd> Then suddenly I'm stuck under a car fixing bits of it in order to change a lightbulb ;)
<fullermd> In point of fact, I did exactly that a couple years ago    :p
<fullermd> I had to go buy a switch to replace a stupid dimmer, and on the way back my brake caliper locked up.
<LeoNerd> Hrmmmmm...
<LeoNerd> d7:message13:State objects11:revision_id54:leonerd@leonerd.org.uk-20161018213449-8qaa6cpx1l9ph0j9eB1063   <== is the metadata field
<LeoNerd> It's a dict of  message => "State objects", revision_id => (that long string)  which ends at the 'e' and then that  B1063  seems to be trailing
<LeoNerd> Any idea what that is?
<LeoNerd> If I stop at that e then it's fine
<LeoNerd> Ooh... maybe I wasn't supposed to include that.. because before that, there was a  B98  marker
 * LeoNerd mumbles that pack format doesn't linefeed-terminate its blocks
<fullermd> B looks like a marker in the pack header.  At least in a quick glance at the code, which I can't read.
<LeoNerd> Yeah.. the pack file itself seems to be a one-line header, followed by data blocks that are B then a decimal integer giving the byte count then a linefeed then that many bytes
<LeoNerd> but no linefeed after the data block payload, meaning that the next B marker for every subsequent block starts at the end of the previousl ine
<LeoNerd> http://paste.debian.net/883932/  <== is my decoded attribs section anyway... this appears to be working :)
<LeoNerd> So.. I wonder if we can work out from here what the error message means
<fullermd> Oh, shucks, you can do that by deduction from the message itself   :p
<LeoNerd> I might if I knew what a "final name" is
<fullermd> Or rather, you can assume something plausible, and since there's nobody around to contradict it, you're right by default.
<LeoNerd> Oh.. that little "_new_name" chunk?
<LeoNerd> Ah.. maybe I just have to add  'new-3' => 'Room'  into that
<LeoNerd> Oh.. and _new_parent otherwise it doesn't know where to root it
<fullermd> The problem, as best I guess, is that new-%d is a standin file id shelf puts on things that don't already have one.
<fullermd> So since the dir wasn't committed yet when the file was shelved, it didn't have one, so got a standin.  Now there's nothing in the tree with that standin, so it has no idea where to put the file.
<LeoNerd> Hmmm
<fullermd> So, in _theory_, if you horked up the transform in the pack so it tried to put it under the actual file-id of the directory...
<LeoNerd> But it has a new id
<LeoNerd>                          'new-3' => 'room-20161015171947-i9zc40ts93rt5svr-1',
<fullermd> Is that the directory?
<LeoNerd> lib/Net/Async/Matrix/Room                          room-20161015171947-i9zc40ts93rt5svr-1
<LeoNerd> According to   bzr inventory --show-ids
<LeoNerd> and the dir exists
<fullermd> See?  If you'd just kept quiet, I would have been right.
<LeoNerd> Hah
<LeoNerd> I think I may start by splitting the shelf in half anyway, see if I can make those two separate pieces to simplify things
<fullermd> Having all those smarts in shelves is really nice, until it isn't   :|
<LeoNerd> Ooooh
<LeoNerd> So having nuked all mention of new-2 or new-3 and fixed up the byte lengths, unshelve --preview is happy
<LeoNerd> and bzr unshelve  itself did it :)
<LeoNerd> Woo.. this seems fine
<LeoNerd> Now all that's missing is the entire content of the new file but I can cut that verbatim from the shelf file
<LeoNerd> aaaaaand we're back
<LeoNerd> ofcourse my extracted code doesn't even compile let alone pass its tests, but that's my fault now. ;)
<fullermd> Man, that whole procedure sounds like something you'd find in chapter 7 of "Git For People Smarter Than You".
<LeoNerd> Anyhow thanks much for that bencode hint - that seemed to be the key to the whole process
<LeoNerd> fullermd++
<fullermd> Yay, I did something good.  I can go accomplish nothing the rest of the day then.
<LeoNerd> :)
<LeoNerd> meh.. now I'm too nervous to use the shelf with a pending mkdir hanging around
<LeoNerd> Hrm... also I find myself wanting an  unshelve  with yes/no questions per chunk
#bzr 2017-10-19
<kalpu> "bzr branch lp:xmms" fails with "bzr: ERROR: Revision {[('x_Arch_Librarian_<arch@canonical.com>_Tue_May_10_09:46:37_2005_2397.0', 'Arch-1:xmms@products.ubuntu.com%xmms--MAIN--0--patch-823')]} not present in "KnitVersionedFiles(<bzrlib.knit._KndxIndex object at 0x7fa4e242f450>, <bzrlib.knit._KnitKeyAccess object at 0x7fa4e242f510>)". Where should I report this error (already asked in #launchpad without an answer yet)?
